Came across a complex situation where customer was using this SIP trunk as an alternative to ISDN-30 (if all channels are used or if ISDN goes down). The ISDN-30 link was working fine but they had issues on SIP trunk (how many times I have heard this?) …. their outbound calls over SIP were using a prefix ’8′ to route calls on SIP trunk to SIP Provider. The Outbound calls were working fine. The inbound calls drop after 8 secs and none of the calling/called party could hear each other. Complete silence..
Call flow was something like this:
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
Some information off the gateway was something like this:
voice service voip
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
bind control source-interface FastEthernet0/1
bind media source-interface FastEthernet0/1
!
voice class codec 1
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 g729r8
!
!
!
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
!
interface FastEthernet0/1
ip address 94.x.x.194 255.255.255.248
ip access-group SIP-Security-In in
ip access-group SIP-Security-Out out
duplex auto
speed auto
auto qos voip trust
no cdp enable
service-policy output AutoQoS-Policy-Trust
!
dial-peer voice 50 voip
description **Incoming Call from SIP Trunk to CUCM**
translation-profile incoming SIP-CALLS-IN
preference 1
redirect ip2ip
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target ipv4:146.x.x.200
incoming called-number .%
dtmf-relay rtp-nte
no vad
!
dial-peer voice 60 voip
description **Outgoing Call to SIP Trunk**
translation-profile outgoing SIP-CALLS-OUT
huntstop
preference 5
destination-pattern 8.T
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target ipv4:146.x.x.200
dtmf-relay rtp-nte
no vad
!
dial-peer voice 31 voip
description *** Outbound calls from CUCM system ***
huntstop
redirect ip2ip
voice-class codec 1
incoming called-number 8T
no vad
!
I ran some traces but the issue was not clear as I was getting cause code = 16 normal call clearing. I followed the following steps to resolve the issue:
Step#1:
At Call manager their MTP and Transcoder were in same group which is not a good design approach. MTP and Transcoder should always be in different MRGs so that Call manager doesn’t use a Transcoder where an MTP is required as a Transcoder cannot do g729-g729. I made these changes:
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
HQ:
MRGL-HQ >> MRG-GW-MTP , MRG-CUCM-MTP, MRG-HQ
Step#2:
Removed the SIP bind commands. I tried pinging fa0/1 to CUCM which failed so I removed the binding and left it on IOS to pick closest LAN interface to CUCM and WAN interface for going outside
Step#3:
Under voice services voip – - added allow-connections h323 to h323 and removed redirect ip2ip. We should not need this command will redirect SIP phone calls to SIP phone calls.
Step#4:
Ran the following debugs:
debug voip ccapi inout
debug cch323 all
debug h225 asn1
debug h245 asn1
debug ip tcp trans
debug ccsip all
Collected debugs in the following manner:
Router(config)# service sequence
Router(config)# service timestamps debug datetime localtime msec
Router(config)# logging buffered 10000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router(config)# voice iec syslog
Router(config)#service timestamps log datetime localtime msec
Router# term len 0
<Enable session capture to txt file in terminal program.>
Router# sh logg
Step#5:
The debugs were huge but I could see
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 0×1
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
Observed no capability exchange when the call connects, the endSession is being sent by the far h323 side because h245 negotiation isn’t occurring.
Further down the lines found this:
163432: *Sep 5 17:36:35.240: //-1/xxxxxxxxxxxx/H323/cch323_h225_receiver: Received msg of type RELEASEIND_CHOSEN
163433: *Sep 5 17:36:35.240: //9761/F1DB1EE38000/H323/release_ind: Disconnect cause 16 location code 0
163434: *Sep 5 17:36:35.240: //-1/xxxxxxxxxxxx/H323/h323_set_release_source_for_peer: ownCallId[9761], src[4]
163435: *Sep 5 17:36:35.240: //9761/F1DB1EE38000/H323/cch323_h225_receiver: RELEASEIND_CHOSEN: src address = 192.168.212.4; dest address = 192.168.212.1
163436: *Sep 5 17:36:35.240: //9761/F1DB1EE38000/H323/run_h225_sm: Received event H225_EV_RELEASE_IND while at state H225_WAIT_FOR_H245
Noticed 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. I Checked the ‘Enable Inbound Fast Start’ box on CM under the CUBE’s H323 gateway config.
Also, observed that capabilities aren’t exchanged when the H245 TCP channel is opened up. Unchecked ‘Wait for far end h.245 capability exchange’ at the gateway config under CUCM. Reset the gateway.
This fixed the issue.
