cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1474
Views
0
Helpful
4
Replies

Problem with Offnet to Offnet Transfer with SIP, CUBE, CUCM

cnattress
Level 1
Level 1

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

4 Replies 4

cnattress
Level 1
Level 1

Forgot to mention, CUCM is 7.1.3, CUBE is 2951 with 15.1(4) M1.

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

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

OK. Thanks for that. Nice catch

Adam