cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
9845
Views
5
Helpful
22
Replies
Highlighted
Beginner

Calls over SIP are silent and then drops

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.

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted

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.

View solution in original post

22 REPLIES 22
Highlighted
Beginner

Can someone please provide some suggestion on this?

Highlighted

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

Highlighted

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

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

Highlighted

Thanks, I look forward to digging into this deeper!

Highlighted
Beginner

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

It's just the inbound calls.

Highlighted
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

Highlighted

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).

Highlighted

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.

Highlighted

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.

Highlighted

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

!

Highlighted

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.

Highlighted

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)

Highlighted

Any more feedback on this?

I am still stuggling to make it work..

Highlighted

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.