11-10-2011 02:17 PM - edited 03-16-2019 08:00 AM
Hello,
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:
v=0
o=CiscoSystemsSIP-GW-UserAgent 3031 6835 IN IP4 10.66.122.141
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 17024 RTP/AVP 0 101
c=IN IP4 0.0.0.0
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
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 66.2.202.133:23506
G128B L 53 N ANS T15 g711ulaw VOIP P5555555555 10.66.122.141:28774
G128B L 54 N ORG T15 g711ulaw VOIP P7777777777 66.2.202.134:17482
v=0
o=CiscoSystemsSIP-GW-UserAgent 3031 6835 IN IP4 10.66.122.141
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 17024 RTP/AVP 0 101
c=IN IP4 0.0.0.0
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
... and the call leg status looks like this:
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 66.2.202.133:23506
G128B L 53 N ANS T15 g711ulaw VOIP P5555555555 10.66.122.141:28774
G128B L 54 N ORG T15 g711ulaw VOIP P7777777777 66.2.202.134:17482
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
11-10-2011 02:18 PM
Forgot to mention, CUCM is 7.1.3, CUBE is 2951 with 15.1(4) M1.
11-10-2011 02:37 PM
Hi,
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.
Adam
11-30-2011 08:06 PM
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:
conf t
voice service voip
passthru content sdp
I upgraded to 15.1(2)T2 and all is well
12-01-2011 01:48 PM
OK. Thanks for that. Nice catch
Adam
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide