I am running into an issue where trying to transfer an off-net call leg to another off-net call leg fails. The call is not terminate but remains up on the CUBE gateway.
It seems as if somewhere after I press the transfer button that the SDP starts showing 0.0.0.0 for the address.
If on the SIP trunk to the CUBE I check MTP required it works but I need to try to avoid the forcing of an MTP for all calls through the CUBE.
Here is the last SDP that is displayed:
o=CiscoSystemsSIP-GW-UserAgent 3031 6835 IN IP4 10.66.122.141
c=IN IP4 0.0.0.0
m=audio 17024 RTP/AVP 0 101
G<id> L<id> Elog A/O FAX T<sec> Codec type Peer Address IP R<ip>:<udp>
G1284 L 4F N ANS T57 g711ulaw VOIP P5555555555 0.0.0.0:24542
G1284 L 50 N ORG T57 g711ulaw VOIP P6666666666 188.8.131.52:23506
G128B L 53 N ANS T15 g711ulaw VOIP P5555555555 10.66.122.141:28774
G128B L 54 N ORG T15 g711ulaw VOIP P7777777777 184.108.40.206:17482
... and the call leg status looks like this:
I've seen this over a year ago with another deployment but I was not invovled with the resolution. All I do recall is the resolution did not involve checking MTP required.
Thanks for the help in advance
Forgot to mention, CUCM is 7.1.3, CUBE is 2951 with 15.1(4) M1.
The 0.0.0.0 is a method used when placing a call on hold, to signal to the remote end not to bother sending media.
There should be a later re-invite which sorts this out, but for some reason it sounds like your call isn't getting this far.
It's possible the SIP Service Providermay not support 'referring' a call to another offnet calls, possibly because of billing.
I suggest disabling SIP refer and moved to the SP, so see if this helps.
Thanks for the reply, Adam. Finally found the issue - it is, a bug:
CSCti23583 CUBE sends a c=0.0.0.0 on Hold & Resume
The best way to find out would be by testing the workaround; which is to add the following command:
voice service voip
passthru content sdp
I upgraded to 15.1(2)T2 and all is well
OK. Thanks for that. Nice catch