Archive for the ‘CUBE – Border Element’ Category

I had an interesting case where SIP calls over a SIP trunk were dropping after like 75 minutes. The duration was not confirmed as sometimes it use to drop even before 75 minutes.

I looked into few CCSIP debugs (debug ccsip messages) and found that the ‘BYE’ message was actually coming from our end (Call manager/Gateway).

Platform information:

CCM: System version: 7.1.3.32900-4

CUBE-10#sh ver

Cisco IOS Software, 3800 Software (C3825-ADVIPSERVICESK9-M), Version 12.4(24)T4, RELEASE SOFTWARE (fc2)

Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
Compiled Fri 03-Sep-10 09:15 by prod_rel_team

ROM: System Bootstrap, Version 12.4(13r)T, RELEASE SOFTWARE (fc1)

CUBE-10 uptime is 27 weeks, 3 days, 44 minutes

voice-card 0
!
!
voice call send-alert
voice rtp send-recv
!
voice service voip
allow-connections sip to sip
fax protocol cisco
sip
options-ping 180
!
!
voice class codec 1
codec preference 1 g729r8
codec preference 2 g711alaw

!

voice class sip-profiles 1
request INVITE sip-header Allow-Header modify “, UPDATE” “”

!

dial-peer voice 10 voip
description *** Outbound to GXXX – SIP Provider ***
translation-profile outgoing OUTBOUND
huntstop
destination-pattern 9T
voice-class codec 1
voice-class sip early-offer forced
voice-class sip profiles 1
session protocol sipv2
session target ipv4:10.0.222.69
dtmf-relay rtp-nte
fax-relay sg3-to-g3
no vad

!
!

gateway
timer receive-rtp 1200

!
sip-ua
retry invite 1
retry response 2
retry bye 2
retry cancel 1
retry options 1
timers trying 200
!

!

!

Debug Output:

Jul 11 12:17:54.579 BST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Sent:

BYE sip:079XXXXXXX@10.0.222.69:5060 SIP/2.0

Via: SIP/2.0/UDP 10.0.222.65:5060;branch=z9hG4bK100B17D
From: “anonymous” <sip:anonymous@10.0.222.65>;tag=B891B2E8-282
To: <sip:079XXXXXXX@10.0.222.69>;tag=3519367399-656588
Date: Mon, 11 Jul 2011 11:15:27 GMT
Call-ID: D687F817-AADB11E0-A725957A-CA524E0B@10.0.222.65
User-Agent: Cisco-SIPGateway/IOS-12.x
Max-Forwards: 70
Timestamp: 1310383074
CSeq: 128 BYE
Reason: Q.850;cause=16
Content-Length: 0

Jul 11 12:17:54.591 BST: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:

Received:
SIP/2.0 200 OK

Via: SIP/2.0/UDP 10.0.222.65:5060;branch=z9hG4bK100B17D
To: <sip:079XXXXXXX@10.0.222.69>;tag=3519367399-656588
From: “anonymous” <sip:anonymous@10.0.222.65>;tag=B891B2E8-282
Call-ID: D687F817-AADB11E0-A725957A-CA524E0B@10.0.222.65
CSeq: 128 BYE

Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH

Contact: <sip:079XXXXXXX@10.0.222.69:5060>

Content-Leng

= = = =

This is what I have done to fix the problem:

I added these commands under sip-profile:

voice class sip-profiles 1
request INVITE sip-header Allow-Header modify “UPDATE,” “”      < < <  This was already there
request REINVITE sip-header Allow-Header modify ” UPDATE,” “”
response 200 sip-header Allow-Header modify “UPDATE,” “”
response 180 sip-header Allow-Header modify “UPDATE,” “”

The next step was to increase the Service Parameter “SIP Session Expire Timer” which you can find under Service Parameters > Call manager:

That was it, it fixed the issue and customer confirmed having a call for more than 3 hours.

Advertisements

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

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.