Solved: Re: Calls over SIP are silent and then drops - Page 2

asharsidd · ‎09-02-2010

I am having issue routing calls over SIP to CUCM.

Call comes in, hit the SIP dialpeers, reach CUCM...both parties hear silence and the call drops in 8 secs.

I am not sure if it's a DSP issue or a Codec issue. I have taken all the relevant outputs in attached docs. The gateway has 2xPVDM-32, 1xE1, 2xFXS, 2xBRI, Hardware Transcoder & Conf Bridge, Software MTP.

They are using ISDN-30 to route calls via E1 for Route Pattern 9T and SIP trunk to route calls for Route Patterns 8T.

There is no SIP trunk configured at the Call manager. All calls hit just one Route List and one Route Group which points to this gateway.

There is just one region which is G711. The MRGL has two MRGs - the top one is gateway MRG with Hardware Conf, Hardware Transcoder and Software MTP at gatewat. The 2nd MRG is CUCM MRG with all Soft Media Resources.

In SIP and CCAPI traces, sometimes I am getting cause code =16 (normal call clearing) and sometimes I am getting caude code = 47 (CC_CAUSE_NO_RESOURCE).

Call manager = 192.168.212.1

H323 Bind = Fa0/0 = 192.168.212.4

SIP local interface = Fa0/1 = 94.x.x.194

SIP Remote Interface = 146.x.x.200

CCM Ver = 7.1.3.20000-2

Gateway = 2811 = 12.4(24)T2

You can see the CCAPI and CCSIP traces as well.

Call Flow:

PSTN (81763) ----- > 2311111 >>>> Hit Gateway >>> Translates to 2905 >>> dialpeer to reach CUCM >> Picks up the phone x2905 >>> Both Calling and Called party hear silence >>> Call drops in 8 secs

We have reloaded the gateway as well. After the reload there were some errors in the logs which I have highlighted in the attached doc (Something like this %SYS-2-INPUTQ: INPUTQ set, but no IDB, ptr=471925B4, -Traceback= 0x4038B480z 0x43874C80z 0x43875A54z 0x41C6BB8Cz 0x41C78890z)

Any help will be much appreciated.

asharsidd · ‎09-05-2010

Hi Steve,

Sorry I missed h225 before. I have re-run the debugs with h225 now for you.

Please see attached.

I have also tried changing the codec to g711ulaw and voice-class codec 1 at dial peer 50 but didn't make a darn difference.

Regarding SIP trunk at CCM, I have created one with the IP address of fa0/0.

interface FastEthernet0/0
ip address 192.168.212.4 255.255.255.240
ip access-group H323-Security-In in
duplex auto
speed auto
h323-gateway voip bind srcaddr 192.168.212.4
service-policy output QoS-LAN-Policy
!

Thanks.

Steven Holl · ‎09-05-2010

Your SIP provider is doing early-offer (note the SDP in the INVITE). When this happens, CUBE needs to do fast-start on the outbound h323

leg to CM. CM is not negotiating FS here. Check the 'Enable Inbound Fast Start' box on CM under the CUBE's H323 gateway config.

Also, I see that capabilities aren't exchanged when the H245 TCP channel is opened up. I bet you have 'Wait for far end h.245 capability exchange' checked on this gateway in CM. Uncheck that. 99.5% of the time on H323 gateways, uncheck that box.

After making those changes, hit 'reset gateway' and choose 'reset.'

That should fix it, I think. If not, collect logs again with these changes made.

asharsidd · ‎09-05-2010

Hi Steve,

You are the man! I did those changes and I could hear the automated message at the other end.

One problem though..after making 4-5 calls, the gateway hanged and it dropped my telent session. I was not able to ping the gateway as well.

After about 20-25 mins, it was accessible. I ran those debugs and called that number again but this time it was just ringing and my gateway hanged again!!

I am now waiting for it to be accessible again...

Any clue?

asharsidd · ‎09-05-2010

Should I add those sip bind commands again?

Steven Holl · ‎09-05-2010

I would leave the SIP bind commands off.

The router maybe crashed if you enabled the debugs, but forgot to disable console logging. The debugs are verbose and will spike the CPU if you don't stop them from printing to the console line.

If you can get access at some point, 'un all' will turn those off. A reboot of the router will make it come back up with the debugs off, too.

asharsidd · ‎09-05-2010

Hi Steve

You may be right..

Before it hung up on me, I had the traces enabled so I have collected the traces where you can see why it hung.

Please observe:

178549: *Sep 5 18:29:19.344: TCP0: bad seg from 192.168.212.1 -- outside window: port 52512 seq 230617620 ack 3936944684 rcvnxt 230617704 rcvwnd 3392 len 84
178550: *Sep 5 18:29:19.348: TCP0: bad seg from 192.168.212.1 -- outside window: port 27627 seq 410705363 ack 383835701 rcvnxt 410705665 rcvwnd 3639 len 302
178551: *Sep 5 18:29:19.348: TCP0: bad seg from 192.168.213.101 -- outside window: port 2000 seq 4168840848 ack 2634319899 rcvnxt 4168840860 rcvwnd 4080 len 12
178552: *Sep 5 18:29:19.348: TCP0: bad seg from 192.168.213.27 -- outside window: port 2000 seq 4207691274 ack 4045306335 rcvnxt 4207691286 rcvwnd 4080 len 12
178553: *Sep 5 18:29:19.348: TCP0: bad seg from 192.168.213.13 -- outside window: port 2000 seq 2271004882 ack 472973987 rcvnxt 2271004894 rcvwnd 4080 len 12
178554: *Sep 5 18:29:19.352: TCP0: bad seg from 192.168.213.17 -- outside window: port 2000 seq 766206946 ack 1900283394 rcvnxt 766206958 rcvwnd 4080 len 12
178555: *Sep 5 18:29:19.352: TCP0: bad seg from 192.168.213.31 -- outside window: port 2000 seq 3897760370 ack 1152166022 rcvnxt 3897760382 rcvwnd 4068 len 12
178556: *Sep 5 18:29:19.352: TCP0: bad seg from 192.168.213.15 -- outside window: port 2000 seq 2005795078 ack 1217632142 rcvnxt 2005795090 rcvwnd 4068 len 12
178557: *Sep 5 18:29:19.356: TCP0: bad seg from 192.168.213.62 -- outside window: port 2000 seq 1078146764 ack 3298653760 rcvnxt 1078146776 rcvwnd 4056 len

Steven Holl · ‎09-05-2010

I can't tell from that output. I'd need to see what the router was doing, and how the debugging was configured. Probably more effort than it is worth.

Just make sure the debugs are off and keep an eye on the gateway. It will probably be stable with the debugs off. If it continues to crash, get the output of 'sh ver' and the crashinfo files from flash and open a case with TAC.

asharsidd · ‎09-05-2010

Thanks Steve. All solved.

I will give you 5 star..your help very much appreciated.

At the end, for me and for anyone who will visit this thread later on...can you please copy paste those lines where you observed early offer in INVITE SDP from provider end...

Also..

These are the changes I made:

Removed SIP binding
Added MTP as seperate MRGs
The 'Enable Inbound FastStart' was already checked so I didn't make any change
I unchecked 'Wait for Far End H.245 Terminal Capability Set'
Note: There is no SIP trunk at Call manager

All started working.