Archive for the ‘Miscellaneous’ Category

If you want to check what has been configured on a Jabber-config.xml then you need to go to CLI of CUCM and execute this command to display its contents:

admin:file view tftp jabber-config.xml

<?xml version=”1.0″ encoding=”utf-8″?>
<config version=”1.0″>

end of the file reached
options: q=quit, n=next, p=prev, b=begin, e=end (lines 1 – 14 of 14) :


You can see the file by using this URL:



You can also find a local copy on user PC at:

%USERPROFILE%\AppData\Roaming\Cisco\Unified Communications\Jabber\CSF\Config

Remmeber EDI is used for authentication from LDAP directory server (default)

UDS is used for CUCM authentication (need to configure the UDS service and Proile)

CUCM 8.6 and above support UDS.

Since Cisco Unified Attendant Console has reached its end of life, clients are offered several alternatives from Cisco Solution Partners. This article will help you to make the rights choice.

Directory and Basic Call Control Features

If a Cisco IP phone is one of your main business tools you need the most convenient interface to:

  • quickly find any person and call him,
  • see who’s calling you,
  • perform the basic call control actions – call forward, conference, parking etc.

So, when selecting the attendant console for Cisco UCM pay attention directory and call control features. Make sure that the solution supports:

  • several directories – employees, clients, personal contacts etc,
  • customizable structure for each directory – for example, first/last name and position for employee, company name and city for clients and so on,
  • presence status for internal contacts,
  • convenient search and filter tools,
  • easy to use call control features – put the call on hold, forward the call (blind and consultative), organize an ad-hoc conference.

Then, depending on who is going to use the console software, pay attention to special features.

  1. Features for Managers

If the console app is going to be used by sales people or top managers, the key feature is the intuitive user interface which doesn’t require much training. Employees photo, large buttons, drag-and-drop features would be nice. And, of course, the call history panel.

  1. Features for Assistants

If you need a solution for top manager assistants, pay attention to some special features, like:

  • phone lines monitoring – to know who the manager is talking to and who’s calling him,
  • call interception – to intercept and answer the incoming call when the manager is away,
  • “whisper” feature – to notify manager about important call while he is on the phone,
  • conference control features – to create audio-meetings for manager and control the conference even without being its participant.
  1. Features for Receptionists and Contact Center Agents

Lastly, when it comes to reception or contact center personnel, whose main task is to answer incoming calls, make sure the attendant console provides superior call routing and distribution tools:

  • queue support (both UCCX and CUCM native queuing) with the ability to see who’s on queue and choose the call to answer,
  • intelligent call routing assistant, which shows a list of employees to whom calls from the current calling party were routed most often,
  • hot keys support to process the incoming calls as fast as possible,
  • dynamic search, fast enough even when searching tens of thousands of contacts,
  • comments to calls, visible for other operators.

The article is provided by Aurus, the official Cisco Solution Partner. Aurus PhoneUP is the application suite for Cisco Unified Communications Manager Enterprise and BE 6000/7000 which includes both Enterprise Directory and Attendant Console for CUCM modules.

I was working on this customer issue last week where they added a new 7841 phone but it was not registering properly or should I say it was registering briefly before unregistering.

Call Manager was which does not support 78XX phones so customer actually applied the device pack cmterm-devicepack9.1.2.12039-1.cop  so that they can add 78XX phones.

Looking at the logs I found that it is registering with Pub and not Sub even though Sub was the Primary CCM in Call Manager group. At Pub I can see something like this:


Via: SIP/2.0/TCP;branch=z9hG4bK739dd207
From: <sip:49715220XXXXX@>;tag=544a003629fd000a741be677-22e1dea8
To: <sip:49715220XXXXX@>
Call-ID: 544a0036-29fd0008-13a9ded8-614a41b9@
Max-Forwards: 70
Date: Tue, 17 Jun 2014 06:32:10 GMT
User-Agent: Cisco-CP7841/10.1.1
Contact: <sip:61131fd1-5eb6-b49e-5d2f-9f9aee1b125c@;transport=tcp>;+sip.instance=”<urn:uuid:00000000-0000-0000-0000-544a003629fd>”;+u.sip!”SEP544A003629FD”;+u.sip!”622″

[Registration Accepted by Publisher]
SIP/2.0 202 Accepted
Via: SIP/2.0/TCP;branch=z9hG4bK6c29941b
From: <sip:544a003629fd@>;tag=544a003629fd000c3890afb1-54d723a2
To: <sip:>;tag=875713562
Date: Tue, 17 Jun 2014 06:32:10 GMT
Call-ID: 544a0036-29fd0006-22434855-1719a3c1@
CSeq: 1000 REFER
Contact: <sip:;transport=tcp>
Content-Length: 0




But then I noticed this further down:

08:32:16.866 |AppInfo  |SIPStationD(607) – setUaTypeAndCepn: uaType is CISCO_ENHANCED_PHONE

08:32:16.866 |AppInfo  |SIPStationD(607) – Received REGISTER from 4971522036708@

08:32:16.866 |AppInfo  |SIPStationD(607) – verifyAddressAndPort — Endpoint unregistered (expires=0), old ip:, new ip:


08:32:16.866 |AppInfo  |SIPStationD(607) – parseLoad: InactiveLoad= name is: [sip78xx.10-1-1-9.loads]

08:32:16.866 |AppInfo  |SIPStationD(607) – processReasonCode:  Processing phone provided reason code=[105]

08:32:16.866 |AppInfo  |SIPStationD(607) – DevStat-NewState : line 4971522036708: Registered ==> Unregistered


While on Subscriber this is what I saw:



[Registration Request]

Via: SIP/2.0/TCP;branch=z9hG4bK5fead06f
From: <sip:49715220XXXXX@>;tag=544a003629fd00020eea65f9-659c5963
To: <sip:49715220XXXXX@>
Call-ID: 544a0036-29fd0003-4c3d829b-12a9daae@
Max-Forwards: 70
Date: Wed, 11 Apr 2012 08:28:24 GMT
User-Agent: Cisco-CP7841/10.1.1
Contact: <sip:61131fd1-5eb6-b49e-5d2f-9f9aee1b125c@;transport=tcp>;+sip.instance=”<urn:uuid:00000000-0000-0000-0000-544a003629fd>”;+u.sip!”SEP544A003629FD”;+u.sip!”622″
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-6.0.2,X-cisco-xsi-8.5.1
Reason: SIP;cause=200;text=”cisco-alarm:25 Name=SEP544A003629FD ActiveLoad=sip78xx.10-1-1SR1-4.loads InactiveLoad=sip78xx.10-1-1-9.loads Last=initialized”
Expires: 3600
Content-Type: multipart/mixed; boundary=uniqueBoundary
Mime-Version: 1.0
Content-Length: 1203


08:31:40.497 |AppInfo  |SIPStationD(684) – setUaTypeAndCepn: uaType is CISCO_ENHANCED_PHONE

08:31:40.497 |AppInfo  |CcmdbStationRegistrationProfileBuilder::init – No typemodel table-entry for device SEP544A003629FD.

08:31:40.497 |AppInfo  |CcmdbStationRegistrationProfileBuilder::getBasicRegistrationProfile::init() – failed rc(1)

08:31:40.497 |AppInfo  |SIPStationD(684) – Registration profile error: Database error, sending registration reject and closing station

08:31:40.497 |AppInfo  |SIPStationD(684) – sendRegisterResp: non-200 response code 404, ccbId 336776, expires 4294967295, warning Database error

08:31:40.497 |AlarmErr |AlarmClass: CallManager, AlarmName: EndPointTransientConnection




So what does it tells us?

Subscriber is not accepting the registration from this 7841 as it does not see that phone type as a legitimate phone.

But hang on did the customer not applied the device pack? yes they did.

A quick phone call with customer revelaed some secrets… Yes they did applied the device pack but rebooted only the Publisher. He questioned me in amazement  “Do we need to reboot Subscribers as well?”


Anyways, issue was resolved after rebooting the Sub as well. The device pack although applies would not take affect until you reboot it. So remember that if you are going to apply a device pack then:

  1. Apply on all nodes
  2. Reboot all nodes in cluster starting from Publisher





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:

CUBE-10#sh ver

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

Technical Support:
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
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
destination-pattern 9T
voice-class codec 1
voice-class sip early-offer forced
voice-class sip profiles 1
session protocol sipv2
session target ipv4:
dtmf-relay rtp-nte
fax-relay sg3-to-g3
no vad


timer receive-rtp 1200

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:


BYE sip:079XXXXXXX@ SIP/2.0

Via: SIP/2.0/UDP;branch=z9hG4bK100B17D
From: “anonymous” <sip:anonymous@>;tag=B891B2E8-282
To: <sip:079XXXXXXX@>;tag=3519367399-656588
Date: Mon, 11 Jul 2011 11:15:27 GMT
Call-ID: D687F817-AADB11E0-A725957A-CA524E0B@
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:

SIP/2.0 200 OK

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


Contact: <sip:079XXXXXXX@>


= = = =

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.

QoS is very important for Voice traffic which is delay sensitive. I won’t go into details of QoS over here and will just explain the configuration we normally use on a Voice gateway for QoS.

class-map match-any Voice-RTP
match ip precedence 5
match ip dscp ef
match ip rtp 16384 16383
class-map match-any Voice-Cntl
match ip precedence 3
match ip dscp af31
match access-group name voice-signal
ip access-list extended voice-signal
permit tcp any any range 2000 2002
permit udp any any eq 2427
permit tcp any any eq 2428
permit tcp any any eq 1720
permit tcp any any range 11000 11999
policy-map QoS-LAN-Policy
class Voice-RTP
set dscp ef
priority 500
class Voice-Cntl
set dscp af31
bandwidth 30
class class-default

Apply it on Voice VLAN interface or towards the WAN interface if you are configuring it between sites:

interface FastEthernet0/1
ip address
ip rip advertise 2
ip virtual-reassembly
ip tcp adjust-mss 1360
duplex full
speed 100
service-policy output QoS-LAN-Policy


interface GigabitEthernet0/0.105
description *** Voice VLAN ***
encapsulation dot1Q 105
ip address 10.60.x.x
h323-gateway voip bind srcaddr 10.60.x.x
service-policy output QoS-LAN-Policy


Confirmation that the voice packets are hitting the service policy:

GW#sh policy-map int fa0/1

Service-policy output: QoS-LAN-Policy

Class-map: Voice-RTP (match-any)
55890 packets, 11178000 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip precedence 5
55890 packets, 11178000 bytes
5 minute rate 0 bps
Match: ip dscp ef (46)
0 packets, 0 bytes
5 minute rate 0 bps
Match: ip rtp 16384 16383
0 packets, 0 bytes
5 minute rate 0 bps
QoS Set
dscp ef
Packets marked 55890
Strict Priority
Output Queue: Conversation 264
Bandwidth 500 (kbps) Burst 12500 (Bytes)
(pkts matched/bytes matched) 55890/11960460
(total drops/bytes drops) 0/0

Class-map: Voice-Cntl (match-any)
605 packets, 80661 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip precedence 3
605 packets, 80661 bytes
5 minute rate 0 bps
Match: ip dscp af31 (26)
0 packets, 0 bytes
5 minute rate 0 bps
Match: access-group name voice-signal
0 packets, 0 bytes
5 minute rate 0 bps
QoS Set
dscp af31
Packets marked 605
Output Queue: Conversation 265
Bandwidth 30 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 605/76019
(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)
1103573 packets, 80456575 bytes
5 minute offered rate 151000 bps, drop rate 0 bps
Match: any
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0

For one of our customer we noticed several RTMT SyslogSeverityMatchFound alerts generated every few minutes for Certificates expiration. The alerts I was getting were as follows:

Feb 15 16:00:00, CCM-PUB, Emergency, Cisco Certificate Monitor, : 8947: Feb 15 16:00:00.57 UTC : %CCM_UNKNOWN-CERT-0-CertExpiryEmergency: Certificate Expiry EMERGENCY_ALARM Message:Certificate expiration Notification. Certificate name:tomcat Unit:tomcat Type:own-cert Expiration:Wed Mar 3 08:16:58:000 GMT 2010 Cluster ID: Node ID:CCM-PUB, 42

Feb 15 16:00:00, CCM-PUB, Emergency, Cisco Certificate Monitor, : 8948: Feb 15 16:00:00.57 UTC : %CCM_UNKNOWN-CERT-0-CertExpiryEmergency: Certificate Expiry EMERGENCY_ALARM Message:Certificate expiration Notification. Certificate name:CallManager Unit:CallManager Type:own-cert Expiration:Thu Mar 4 08:41:45:00 Cluster ID: Node ID:CCM-PUB, 43

Feb 15 16:00:00, CCM-PUB, Emergency, Cisco Certificate Monitor, : 8949: Feb 15 16:00:00.58 UTC : %CCM_UNKNOWN-CERT-0-CertExpiryEmergency: Certificate Expiry EMERGENCY_ALARM Message:Certificate expiration Notification. Certificate name:CAPF Unit:CAPF Type:own-cert Expiration:Thu Mar 4 08:41:46:000 GMT 2010 / T Cluster ID: Node ID:CCM-PUB, 44

Feb 15 16:00:00, CCM-PUB, Emergency, Cisco Certificate Monitor, : 8950: Feb 15 16:00:00.58 UTC : %CCM_UNKNOWN-CERT-0-CertExpiryEmergency: Certificate Expiry EMERGENCY_ALARM Message:Certificate expiration Notification. Certificate name:CAPF-e00e8760 Unit:CallManager-trust Type:trust-cert Expiration:Thu Mar 4 0 Cluster ID: Node ID:CCM-PUB, 45

Feb 15 16:00:00, CCM-PUB, Emergency, Cisco Certificate Monitor, : 8951: Feb 15 16:00:00.59 UTC : %CCM_UNKNOWN-CERT-0-CertExpiryEmergency: Certificate Expiry EMERG

These alerts are usually thrown if the certificates at Call manager are about to expire or expired.

I went into OS Admin and checked the status of all certificates:

Then I went into each of them to check the ‘Not After’ date:

The ones which were expired, I just regenerated them:

This stopped all RTMT alerts.

You can also regenerate certificates from CLI:

admin: set cert regen tomcat

Today was a hectic day. I walked into my office and immediately started getting calls that phones have gone 1 hour behind. I was a bit surprised as Daylight Saving will be finishing here in UK on 31st October so how come phones gone behind a week earlier. I thought may be customer has got some messed up NTP settings. So, I started investigating it and found the NTP server is their gateway which is in synch with an external time source. Time on the gateway was correct. I did show system at Call manager and found the Call manager time was correct as well. As I was working on this issue I had a quick look at my desk phone (a 7960) and was taken by surprise. My phone was 1 hr behind as well. I walked to my manager’s desk and found his phone is showing correct time (7961). Immediately I came to conclusion that 1st/2nd generation phones are affected as 3rd Gen phones are java based and they don’t rely so much on Date/time group settings. As I was trying to sort out this issue I started getting more calls regarding this issue. In a span of 20 minutes I had eight customers with the same problem – 7940/7960/7912 phones have gone back an hour. I decided to do a quick fix and changed the TIMEZONE in Date/time group settings from Europe/London to CET (GMT+1). Reset the phones (7940s/7960s) and all started showing correct time. Remember, the 3rd generation phones were unaffected by this change.  The affected Call manager versions were 7.1.3 & 7.1.5. I raised a Cisco TAC case and it was quite amusing when she said that she already took some 10 calls since morning regarding same issue. One of the TAC engineer came back to me with the following solution:

Bug – CSCtj70240    CUCM applying DST changes 1 week before needed (2010)


Workaround #1:

Affected customers can choose to do nothing and wait for the time to automatically update.

Workaround #2:

Time of Day Routing
Adjust the time schedules behind one hour.

1. Choose System > Date / Time Group from CUCM Admin.
2. Create a new Date / Time group that is one hour ahead of local time.
3. Choose System > Device pool.
4. Create a New Device pool and assign the (one hour ahead Date time group) to this new device pool.
5. Assign the new device pool to the Cisco IP Phones that display the incorrect time.

Note: The CUCM time updates occur automatically (dates vary per timezone).
Change your Time of Day Routing and Device Pools back to the original Date / Time group accordingly.

Note: Just had a response from Cisco TAC that this bug will only affect systems in 2010. It will be fine next year.

Bug Fix:

Update from Cisco TAC: 26/10/2010 22:13

The following versions are affected:

* 7.1.3: all CM versions below 007.001(003.33031.001)

* 7.1.5: all CM versions below 007.001(005.12008.001)

* 8.0.2: all CM versions below 008.000 (002.41007.001 begin_of_the_skype_highlighting              002.41007.001      end_of_the_skype_highlighting), 8.0.3 shouldn’t be affected.

Developers provided COP files with fixes for the 3 branches mentioned above:

* COP for 7.1.3 ->

* COP for 7.1.5 -> Can be found on already:

* COP for 8.0.2 ->

In case you decide to install COP files, please bear in mind the following suggestions when installing the COP files:

– Installation to all machines in the cluster is required

– As with any installation or upgrade, it is recommended that you apply this Update during off peak hours.

– When applying this Package be advised that a clusterwide reboot is required.

– It is also recommended that this update be installed on all  machines in the cluster before the cluster is rebooted.

I was looking into this customer issue where they upgraded from Call manager 4.x to 7.x and almost all users on 7912 phone lost their speed dials.

I checked the phones and CCMUSER page and found that the dials where there but they are not able to access it.

Created a new Softkey template including “AbbrDial” at “off Hook” mode. Reset the phones and asked them to check.

Customer came back saying they cannot see “AbbrDial” Softkey. All settings in Call manager were fine but for some reason they were not able to see the Abbreviated Dial Softkey.

I checked the firmware for 7912 and it was CP7912080003SCCP070409A.

I decided to upgrade the firmware for 7912 to the latest one CP7912080004SCCP080108A. I loaded the new firmware, restarted TFTP, reset the phones and it all started working fine.

Later I came to know that it’s a kind of a bug that if you upgrade from CCM 4.x to 7.x then your 7912 phones will have issues in AbbrDial Softkey. If you come across this issue, upgrade the firmware and you will be good.

Came across an MoH issue for a customer where the file was missing from Subscriber. As you may be aware that an MoH file should always be uploaded across the cluster on each server to work properly. If you only upload the MoH file on Publisher then it won’t be replicated on other servers. You can check that by going into those servers > Media Resources > Audio Source file. cut long story short, I went back to customer to give me that wave file which was uploaded on Pub so that I can upload it on Sub as well. Customer came back saying that they don’t have that file and I should do something to get the file from Publisher.

Using my CLI skills, I downloaded the MoH file from Call manager and then uploaded it on Sub. The file has different formats like.alaw ulaw g729 etc. Once you download it, you can change it back to .wav file. This is  how I downloaded it.

CCMRoot@’s password:
Last login: Fri Sep 24 12:45:46 2010 from

Welcome to the Platform Command Line Interface

Uptime              : 13:27:13  up 175 days,  2:23,  1 user,
Load average        : 0.15, 0.15, 0.16
Platform OS version : UCOS
HW model            : 7825H3

admin:file list activelog mohprep/* [this will show you all files in MoH dir]
CiscoMOHSourceReport.xml                SampleAudioSource.alaw.wav
SampleAudioSource.g729.wav              SampleAudioSource.ulaw.wav
SampleAudioSource.wb.wav                SampleAudioSource.xml
TheBoysFromLiverpool.alaw.wav           TheBoysFromLiverpool.g729.wav
TheBoysFromLiverpool.ulaw.wav           TheBoysFromLiverpool.wb.wav
dir count = 0, file count = 11
admin:file get activelog mohprep/TheBoysFromLiverpool.alaw.wav
Please wait while the system is gathering files info …done.
Sub-directories were not traversed.
Number of files affected: 1
Total size in Bytes: 1831882
Total size in Kbytes: 1788.9473
Would you like to proceed [y/n]? y
SFTP server IP:
SFTP server port [22]:
User ID: cisco
Password: *****

Download directory: \

The authenticity of host ‘ (’ can’t be established.
RSA key fingerprint is 7b:cf:ae:e3:8d:00:09:f0:20:d1:25:8b:f2:b9:38:bc.
Are you sure you want to continue connecting (yes/no)? yes
Transfer completed.

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
h225 id-passthru
h225 connect-passthru
session transport udp
h245 passthru tcsnonstd-passthru
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
ip access-group H323-Security-In in
duplex auto
speed auto
h323-gateway voip bind srcaddr
service-policy output QoS-LAN-Policy
interface FastEthernet0/1
ip address 94.x.x.194
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
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 ***
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:


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:




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


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.


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


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 =; dest address =
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.