Calls over SIP are silent and then drops

Answered Question
Sep 2nd, 2010
User Badges:

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.

Correct Answer by Steven Holl about 6 years 10 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
asharsidd Fri, 09/03/2010 - 02:33
User Badges:

Can someone please provide some suggestion on this?

Matthew Guerrera Fri, 09/03/2010 - 05:44
User Badges:

I looked at your config, there are a couple of lines I would change.


On a few of your dial-peers, redirect ip2ip is enabled. You should not need this; this command will redirect SIP phone calls to SIP phone calls.


Also under voice service voip, add allow-connections h323 to h323.


Other than that, the config and debugs on the SIP call leg look fine, the call is being told to clear normally. The call appears to be failing in UCM somewhere. Are you able to pull detailed traces from the UCM?



Thanks,


Matt

asharsidd Fri, 09/03/2010 - 05:57
User Badges:

I made those changes as suggested by you but no joy!


I am going to collect CCM traces now..will let you know.

asharsidd Fri, 09/03/2010 - 05:36
User Badges:

Just to add more .. Al outbound calls over SIP trunk are fine...no issues.

It's just the inbound calls.

Steven Holl Fri, 09/03/2010 - 07:11
User Badges:
  • Cisco Employee,

The traceback is a result of this bug, likely:


CSCtd75189
Error message %SYS-2-INPUTQ: INPUTQ set, but no IDB, ptr= on voice GW


Fixed in 12.4(24)T3.  I believe it is mostly cosmetic.  It shouldn't cause this issue which you are describing.


First, anytime you run voice debugs, run all the debugs at the same time.  Running CCAPI separate from SIP doesn't do much good--you can't see how the stacks talk to each other.  The debugs collected don't really help me see what's going on either--I can't leverage the complete story from them due to what was run and how it was run.


It is unclear the details of the call flow that is failing, since I  see this gateway has POTS and a SIP trunk, and SIP and H323 dial-peers  to CM.


Here are some suggestions, though:


* If you are seeing disconnect of 47 thrown, my guess is that is being thrown by CM due to a codec mismatch or failure to allocate an MTP.  Keep in mind that anytime you do rtp-nte to CUCM, you need to invoke an MTP so that the signaling path can be notified of a DTMF digit present in the media stream.


*If you are doing H323 from CUCM to the gateway, and out a SIP trunk,  you need to have 'MTP Required' checked on CM.  This ensures that we do  fast start out to CUBE, so that we do early offer out the SIP trunk.   Because chances are, your provider requires early offer.  If they want  delayed offer, ignore this point, and no need to require an MTP.


* Your MRGL on the CUBE instance in CM should look like this:

MRG1: Contains *only* a software MTP.  If calls in this trunk on do g711, a CUCM SW MTP will suffice.  If calls in are g729, you need an IOS SW MTP here.  If calls come in can be either 711 or g729, and if MTP required needs to be checked (previous bullet) you need to pick one codec only and hard code the IOS dial-peer to CUCM for that codec.

MRG2: Contains your transcoder, CFB, and MOH resources.


(Take this MRGL design to put the MTP in it's own MRG at the top as a golden rule for any implementation.  This configuration ensures that you don't invoke a trasncoder when you need an MTP.  For g711 scenarios it isn't a big deal, but it causes major issues in g.729 scenarios, since a transcoder looks like an MTP to CUCM, but fails to go g729-to-g729.  It's a common design misconfiguration that I see.)


* If we're doing g711 from the GW to CUCM, make sure the GW instance in CM is in a region that allows g711 to the called device.


If you get these debugs for a failure where 47 is thrown, it will shed more light, though:


debug voip ccapi inout

debug cch323 all

debug h225 asn1

debug h245 asn1

debug ip tcp trans

debug ccsip all


Collect debugs in the following manner:

Router(config)# service sequence
Router(config)# service timestamps debug datetime msec
Router(config)# logging buffered 10000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router(config)# voice iec syslog

Router# term len 0

Router# sh logg



-Steve

Steven Holl Fri, 09/03/2010 - 07:14
User Badges:
  • Cisco Employee,

One more thing: I see you are binding SIP traffic.  Note that when you bind SIP, it removes the SIP listener on all other interfaces (H323 bind doesn't behave this way, FYI).


Hence, since you bind SIP to FastEthernet0/1, you need to make sure of three things:

a) (Assuming we're doing SIP to CUCM) You can ping CUCM from the f0/1 interface.

b) (Assuming we're doing SIP to CUCM) The SIP trunk is added in CUCM with the IP of f0/1.

c) (If we're doing SIP out to a PSTN SIP ITSP) The service provider can also reach the IP of f0/1 (or that a static nat xlation is built properly for this IP on udp/5060).

asharsidd Fri, 09/03/2010 - 11:35
User Badges:

Brilliant explanation Steve!


I am at home and will VPN onto the network to make some tests as suggested by you.

However, before leaving office I did check the ping from fa0/1 to CUCM and it didn't work.


What I will have to do to make it work?


I will come back to you with more debugs later today.


Thanks again.

Steven Holl Fri, 09/03/2010 - 12:47
User Badges:
  • Cisco Employee,

asharsidd wrote:


before leaving office I did check the ping from fa0/1 to CUCM and it didn't work.


What I will have to do to make it work?




You certainly need to get that working.  This means that the network of f0/1 is not routeable in your network.  Consult your routing protocol configuration or your network guys in regards to that.


In IOS, we choose the closest interface to the destination IP to source voice traffic from.  So if you just remove the SIP bind commands, we'll use the closest LAN interface to CM to send from (and that's the IP you;'d want the trunk listed in CM as).  For most CUBE environments, binding is not necessary (I usually don't recommend it).  If your routing is solid, it will pick the LAN interface for CM legs, and the WAN/outside interface when going towards the SP.

asharsidd Fri, 09/03/2010 - 13:25
User Badges:

Steve,


I have collected the debugs as requested by you.


I have also made changes to the MRG which looks like this now:


MRG-GW-MTP >> This contains SW MTP at Gateway only

MRG-CUCM-MTP >> This contains CUCM SW MTP

MRG-Gateway >> GW-CON & GW-Xcode (both hardware)

MRG-HQ >> ANN_2, CFB_2, MOH_2


At Gateway:


MRGL-GW  >> MRG-GW-MTP , MRG-CUCM-MTP ,  MRG-Gateway, MRG-HQ


All devides have this MRGL:


MRGL-HQ >> MRG-GW-MTP , MRG-CUCM-MTP, MRG-HQ



I have also hard coded g711ulaw at dial peer 50.


dial-peer voice 50 voip
description **Incoming Call from SIP Trunk**
translation-profile incoming SIP-CALLS-IN
preference 1
redirect ip2ip
Codec g711ulaw
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target ipv4:146.101.248.200
incoming called-number .%
dtmf-relay rtp-nte
no vad

!

Attachment: 
asharsidd Fri, 09/03/2010 - 13:27
User Badges:

Sorry forgot to tell you. There is no SIP trunk configured at the gateway for this SIP call routing.


Outbound calls still work fine.


Do i just need to create a SIP trunk or I have to add it under some Route Patterns as well?


Thanks Steve for help.

asharsidd Fri, 09/03/2010 - 13:51
User Badges:

Hi Steve,


No luck so far!


Removed the binding from the voice service voip


!

voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
supplementary-service h450.12
fax protocol t38 ls-redundancy 2 hs-redundancy 2 fallback none
h323
  emptycapability
  h225 id-passthru
  h225 connect-passthru
  session transport udp
  h245 passthru tcsnonstd-passthru
sip

!


Added a SIP trunk with the same IP as 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
!


Tried both MRGLs at the trunk but didn't make any difference.


I have collected fresh logs after making these changes (please see attached)

asharsidd Sat, 09/04/2010 - 19:59
User Badges:

Any more feedback on this?


I am still stuggling to make it work..

Steven Holl Sun, 09/05/2010 - 05:59
User Badges:
  • Cisco Employee,

Those debugs which you collected were missing 'debug h225 asn1'


The call drops here:


045897: *Sep  3 20:46:57.975: TCP0: ACK timeout timer expired
045898: *Sep  3 20:47:05.679: //-1/xxxxxxxxxxxx/H323/cch323_process_carrier_update: Registered = 0, Event = 1, Reason = 2
045899: *Sep  3 20:47:05.907: //-1/xxxxxxxxxxxx/H323/cch323_ct_main: SOCK 3 Event 0x1
045900: *Sep  3 20:47:05.907: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: owner_data=0x4AE82D10, len=2, msgPtr=0x4A8F8D78
045901: *Sep  3 20:47:05.907: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: Received msg for H.245
045902: *Sep  3 20:47:05.907: h245_decode_one_pdu: more_pdus = 0, bytesLeftToDecode = 2
045903: *Sep  3 20:47:05.907: H245 MSC INCOMING ENCODE BUFFER::= 4A40
045904: *Sep  3 20:47:05.911:
045905: *Sep  3 20:47:05.911: H245 MSC INCOMING PDU ::


value MultimediaSystemControlMessage ::= command : endSessionCommand : disconnect : NULL



I only see FS H245 elements.  We should see a capability exchange when the call connects, which I don't see.  I think the endSession is being sent by the far h323 side because h245 negotiation isn't occurring.  I'd need to see the h225 debugs to see why h245 negotiation isn't happening properly.  I'm guessing the h245 address/port either isn't getting passed, or there is a failure to open that socket.


Please re-run another test with all of the debugs which I mentioned in my previous email.

asharsidd Sun, 09/05/2010 - 10:44
User Badges:

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 Sun, 09/05/2010 - 10:49
User Badges:
  • Cisco Employee,

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 Sun, 09/05/2010 - 11:32
User Badges:

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?

Correct Answer
Steven Holl Sun, 09/05/2010 - 11:39
User Badges:
  • Cisco Employee,

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 Sun, 09/05/2010 - 11:47
User Badges:

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 Sun, 09/05/2010 - 11:50
User Badges:
  • Cisco Employee,

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 Sun, 09/05/2010 - 12:03
User Badges:

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:


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


All started working.

Actions

This Discussion

Related Content