09-02-2010 02:58 PM - edited 03-16-2019 12:35 AM
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.
Solved! Go to Solution.
09-05-2010 11:39 AM
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.
09-03-2010 02:33 AM
Can someone please provide some suggestion on this?
09-03-2010 05:44 AM
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
09-03-2010 05:57 AM
I made those changes as suggested by you but no joy!
I am going to collect CCM traces now..will let you know.
09-03-2010 06:12 AM
Thanks, I look forward to digging into this deeper!
09-03-2010 05:36 AM
Just to add more .. Al outbound calls over SIP trunk are fine...no issues.
It's just the inbound calls.
09-03-2010 07:11 AM
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
09-03-2010 07:14 AM
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).
09-03-2010 11:35 AM
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.
09-03-2010 12:47 PM
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.
09-03-2010 01:25 PM
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
!
09-03-2010 01:27 PM
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.
09-03-2010 01:51 PM
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)
09-04-2010 07:59 PM
Any more feedback on this?
I am still stuggling to make it work..
09-05-2010 05:59 AM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: