According to RFC 2327, the c=IN IP4 68.164.107.234 takes precedence over the c=IN IP4 10.0.1.54 line because the c=IN IP4 68.164.107.234 line is the media level address and the c=IN IP4 10.0.1.54 is the session level address. In addition, SIP servers should not be embedding private IP addresses that are not reachable from the UC560 in their SDP descriptors. SIP ALGs actually take care of this problem by ensuring that only public IP addresses appear in standard SIP headers and SDP descriptors. SIP ALGs also rewrite the ports used for media streams, open up the correct ports on the router, and forward the media streams to the correct endpoint.

The problem you are having appears to be an IOS bug, but it is also being incorrectly handled by your SIP provider, as SDP descriptors should not contain private IP addresses that are unreachable from the other endpoint.

John is correct - what is the NAT device in front of the UC560 that is doing the NAT ALG. There is no issue on the UC560 per se - the ways to resolve this:

1. NAT ALG device should translate both c= lines (session level and media level) instead of only media level. Depending on the NAT box this may or may not be doable

2. Service Provider SIP proxy adheres to RFC3264 and only looks at media level c= line and ignores session level c= line

3. A hack is to remove the session level line in UC560 as below:

voice class sip-profiles 1
request ANY sdp-header Connection-Info remove
response ANY sdp-header Connection-Info remove

!

voice service voip

  sip

  sip-profiles 1

See if those help.