Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Community Member

SIP 488 Disconnect - Negotiated Codec Byte & Source IP Port

Hi everyone,

 

I'm having a strange issue...wondering if anyone has seen this before:

 

Our scenario is the following setup:

 

H323 Gateway -> CUCM -> SIP CUBE à PSTN

 

We have multiple cubes all over the world (USA, UK, Singapore, ect). All the cubes have the same config and are running very similar IOS versions. However, one CUBE (the one in the UK) is not able to properly negotiate codec Byte size without an MTP required on the sip trunk (should be 40 Bytes).

 

We are using Early offer on all the CUBES, however, I have selected Early offer support for voice and video calls (insert MTP if needed) on the SIP Profile. Additionally, selecting MTP required on the sip trunk gives us no ringback.

 

Also, I have tested this with a SIP VGW, and a SCCP phone – there were no issues so this only seems to affect H323. On the H323 Gateway I have tried enabling outbound faststart, but this makes no difference.

 

What is strange is the codec is being negotiated ok, but the media source port and the codec bytes are not being negotiated at all:

 

Here is a debug ccsip calls output.

H323: 10.208.24.7

CUCM: 10.225.0.12

CUBE: 129.87.145.49 (this is actually an internal IP that is reachable by all devices, our network engineering team over in the UK decided they were too cool for private addressing)

 

006082: Aug 28 12:03:07.062: //400617/D318D8800000/SIP/Call/sipSPICallInfo:

The Call Setup Information is:

Call Control Block (CCB) : 0x2C1DF3A0

State of The Call        : STATE_DEAD

TCP Sockets Used         : YES

Calling Number           : 7133368680

Called Number            : 447801694614

Source IP Address (Sig  ): 129.87.145.49

Destn SIP Req Addr:Port  : 10.225.0.12:0

Destn SIP Resp Addr:Port : 10.225.0.12:56077

Destination Name         : 10.225.0.12

 

006083: Aug 28 12:03:07.066: //400617/D318D8800000/SIP/Call/sipSPIMediaCallInfo:

Number of Media Streams: 1

Media Stream             : 1

  • Negotiated Codec         : g729r8
  • Negotiated Codec Bytes   : 0

Nego. Codec payload      : 18 (tx), 18 (rx)

Negotiated Dtmf-relay    : 0

Dtmf-relay Payload       : 0 (tx), 0 (rx)

Source IP Address (Media): 129.87.145.49

  • Source IP Port    (Media): 0

Destn  IP Address (Media): 10.208.24.7

Destn  IP Port    (Media): 17650

Orig Destn IP Address:Port (Media): [ - ]:0

         

006084: Aug 28 12:03:07.066: //400617/D318D8800000/SIP/Call/sipSPICallInfo:

  • Disconnect Cause (CC)    : 65
  • Disconnect Cause (SIP)   : 488
2 REPLIES
Cisco Employee

Hi,Kindly share the running

Hi,

Kindly share the running config and the debugs already collected.

As i understand , the CUBE is a SIP-SIP CUBE . Check the codecs mentioned under the incoming and the outgoing dial-peers. If they are different , we would need a local xcoder on the CUBE.

 

Regards,

Harsh.

 

Community Member

It turns out a router reload

It turns out a router reload solved the issue...was just difficult to scheduled since we had so much traffic going through that cube.

Not sure why this only affected H323 gateways (SIP gateways and SCCP ip phones had no issues), or why a router reload solved the problem...just happy it is fixed.

217
Views
0
Helpful
2
Replies
CreatePlease to create content