Archive for July, 2011

Interesting case today. I had a call from customer saying they had a power cut and when the power was restored all their phones went into ‘Registering’ status.

I initially thought it could be a network issue from switches to CUCME gateway as the config was looking fine to me. I did a show ephone summary and found all of them in ‘Unregistered’ status. Nothing changed really, the config was all ok and these phones were all working fine few minutes before. So what has gone wrong?

I started going through the config if anything has changed but nothing changed. Then I did show telephony service and found below:

=====================
Version 8.1
Max phoneload sccp version 17
Max dspfarm sccp version 18
Cisco Unified Communications Manager Express
For on-line documentation please see:
http://www.cisco.com/en/US/products/sw/voicesw/ps4625/tsd_products_support_series_home.html

protocol mode default
ip source-address 172.16.49.250 port 2000
ip qos dscp:
ef (the MS 6 bits, 46, in ToS, 0xB8) for media
cs3 (the MS 6 bits, 24, in ToS, 0x60) for signal
af41 (the MS 6 bits, 34, in ToS, 0x88) for video
default (the MS 6 bits, 0, in ToS, 0x0) for serviceservice directed-pickup
no auto-reg-ephone
load 7937 apps37sccp.1-3-4-0
load 7942 SCCP42.8-5-4S
max-ephones 25
max-dn 200
max-conferences 8 gain -6
dspfarm units 0
dspfarm transcode sessions 0
conference software
.
.
.
.
.
.
.
web admin customer name Customer
edit DN through Web:  enabled.
edit TIME through web:  disabled.
Log (table parameters):
max-size: 150
retain-timer: 15
create cnf-files version-stamp 7960 Jul 29 2011 15:25:03
transfer-system full-consult
transfer-digit-collect new-call
local directory service: enabled.
Extension-assigner tag-type ephone-tag.
shutdown

Did you guys see what was wrong?

Somehow the telephony service went into shutdown state. I did a no shut on telephony service and they all start registering.

Advertisements

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.

I had a request to do a quick write up on how to configure extension mobility properly.

These are the steps involved (considering Call manager Linux versions):

1 – Configure extension mobility service by going into Device > Device settings > Phone Services

The service URL is : http://call-manager-IP:8080/emapp/EMAppServlet?device=#DEVICENAME#

If you want to set it up as an Enterprise service then check that box “Enterprise Subscription” otherwise leave it. If you check that box, extension mobility service will appear globally for all phones and you won’t be able to find this service under phone Subscribe services in Step 2. If you don’t check that box then move to step 2

2 – Under phone, susbcribe this service as follows by dropping down the menu at top right corner and then going into “Subscribe/Unsubscribe Service”

3- Staying on the same phone page, scroll down and check the extension mobility check box otherwise no one will be able to login:

4 – Create a User device profile Device > Device Settings > Device profile. Any higher generation phone profile will work on lower one but that’s not true the other way around. So a Cisco 7960 device profile can be used to login oo a 7912 phone but a Cisco 7912 UDP won’t login on a Cisco 7960 phone.

5 – After creating UDP, the most important and sometimes missed step is to subscribe the Extension mobility service again like step 2 at UDP level

6 – Go into user from from User management > End user and add that device profile to it. Also select the primary extension at that user page.

Login and you should be good to go. Any issues, it would either be related to service not subscribed at UDP level or a UDP not associated with a user.

Web Link for EM:

There can be a situation where your Pub is down or inaccessible and users wants to login or logout. As EM service is dependent on Publisher they won’t be able to login/logout and will get “host not found”.

There is a workaround where users can login to their phones through a web link.

To login using URL:

http://<CUCM-SUB IP Address>/emapp/EMAppServlet?device=MACADDR&userid=USERID&seq=XXXXX

XXXXX = Pin

Example:

http://192.168.70.11/emapp/EMAppServlet?device=SEP001E4AF0F9E4&userid=ajon&seq=12345

To logout the user:

http://&lt; CUCM-SUB IP Address>/emapp/EMAppServlet?device=SEP001646D97913&doLogout=true

I had an interesting case last week where calls over ICT trunk would connect but then either party will not hear each other for 8-10 seconds.

The issue was first reported from US users trying to reach UK users over an Inter-cluster trunk (Non-GK). Both clusters had two call managers version 8.0.3. The whole issue started after US call managers were re-located and their IP addresses were changed. The ping response between two clusters was about 145ms which wasn’t too bad. I did a test call to a UK phone by connecting my IP communicator to US (due to time difference it was very difficult to get someone in US to make test calls). I did a CFA on UK phone to Voicemail and could see on my communicator that the call has connected but I didn’t hear the first 10 seconds of the voicemail.

I made a similar test by calling a UK phone but this time asked someone to answer it. The call was connected fine but we couldn’t hear each other for like 10 seconds. After 10 s it was all ok.

The issue was bit different when someone from UK to US would call. In that case call will connect 70% of the time with no issues but 30% of the time it will connect and drop.

I had to run through different CCM traces on both clusters to find below:

### Digit analysis for the call
04:42:47.464 |Digit analysis: match(pi=”2″, fqcn=”XXXXXX1409″, cn=”1409″,plv=”5″, pss=”PT_FRNA_INTERNAL:PT_FRNA_ROUTE”, TodFilteredPss=”PT_FRNA_INTERNAL:PT_FRNA_ROUTE”, dd=”303165″,dac=”0″)|2,100,49,1.20123926^10.128.68.1^SEP002318D1DF43
04:42:47.464 |Digit analysis: analysis results|2,100,49,1.20123926^10.128.68.1^SEP002318D1DF43
04:42:47.464 ||PretransformCallingPartyNumber=1409
|CallingPartyNumber=201409
|DialingPartition=PT_FRNA_INTERNAL
|DialingPattern=21XXXX
|FullyQualifiedCalledPartyNumber=303165

04:42:47.464 |DeviceManager::star_DmPidReq – RequestedName=dec100fa-40c7-ac1a-9dcb-50a73af41700 LookupName=dec100fa-40c7-ac1a-9dcb-50a73af41700|2,100,49,1.20123926^10.128.68.1^SEP002318D1DF43
04:42:47.464 |Digit analysis: wait_DmPidRes- Partition=[8a2bfaaa-13f0-4631-9c26-02a08a573cf7] Pattern=[21XXXX] Where=[],cmDeviceType=[AccessDevice], OutsideDialtone =[0], DeviceOverride=[0], PID=RouteListControl(2,100,73,10)|2,100,49,1.20123926^10.128.68.1^SEP002318D1DF43

### H225 set-up sent via ICT:
04:42:47.616 |Out Message — H225SetupMsg — Protocol= H225Protocol|*^*^*
04:42:47.616 |Ie – H225BearerCapabilityIe IEData= 04 03 80 90 A2 |*^*^*
04:42:47.616 |Ie – Q931DisplayIe IEData= 28 0B 43 68 61 64 20 48 61 69 6E 65 73 |*^*^*
04:42:47.616 |Ie – H225CallingPartyIe IEData= 6C 08 00 81 32 30 31 34 30 39 |*^*^*
04:42:47.616 |Ie – Q931CalledPartyIe IEData= 70 05 80 33 30 36 33 |*^*^*

### Connect received (call answered)
04:42:49.461 |In  Message — H225ConnectMsg — Protocol= H225Protocol|*^*^*
04:42:49.461 |Ie – H225BearerCapabilityIe — IEData= 04 03 80 90 A2 |*^*^*
04:42:49.461 |Ie – Q931DisplayIe — IEData= 28 0C 53 74 65 76 65 20 47 61 72 6E 65 72 |*^*^*
04:42:49.461 |Ie – Q931ConnectedNumIe — IEData= 4C 06 00 81 33 30 36 33 |*^*^*

### outgoing TCS sent after about 8 seconds:
04:42:57.260 |TranslateAndTransport(21728)::waitForSdlRsp_H245TcpConnectionInfo – received H245TcpConnectionInfo from H245Handler|0,0,0,0.0^*^*
04:42:57.264 |
H245ASN – TtPid=(21728) -Outgoing #195026  -value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :

¬Also, the SDL logs indicate a significant delay in the TCS being sent out:
Line 135: 027643128| 2011/07/06 04:42:49.465| 002| SdlSig    | H245ConnectReq                        | wait                          | H245Handler(2,100,24,1)         | TranslateAndTransport(2,100,16,21728)| (2,100,23,21728).1-(*:*)                | [NP – PQ: 0]
Line 331: 027643324| 2011/07/06 04:42:57.259| 002| SdlSig    | H245TcpConnectionInfo                 | waitForSdlRsp                 | TranslateAndTransport(2,100,16,21728)| H245Handler(2,100,24,1)         | (0,0,0,0).0-(*:*)                       | [R:NP – HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]
Line 332: 027643325| 2011/07/06 04:42:57.259| 002| SdlSig    | TtControlChannelEstablished           | waitForTransportEstablishment | H245SessionManager(2,100,23,21728)| TranslateAndTransport(2,100,16,21728)| (0,0,0,0).0-(*:*)                       | [R:NP – HP: 0, NP: 0, LP: 0, VLP: 0, LZP: 0 DBP: 0]
Lin

This shows the H225 part of H323 is fine but H245 was taking time. I did reset of trunks, changed Call manager priorities etc but that didn’t help.

I then enabled ‘Outbound FastStart’ for all outbound calls from US to UK and enabled the same for inbound calls on UK trunk. This fixed the issue.

I had to provide a MTP resource under MRGL at US trunk as FastStart needs MTP.

US Cluster:

UK Cluster:

A little about how ‘Outbound FastStart’ works from Cisco:

Outbound Calls :

Enable Outbound FastStart   

Check this check box to enable the H.323 FastStart feature on outgoing calls.
By default, the check box remains unchecked for the H.323 gateway or trunk.
When you check the Enable Outbound FastStart check box, you must set the Media Termination Point Required, Media Resource Group Lists, and Codec for Outbound FastStart.

Inbound Calls:

Enable Outbound FastStart   

Check this check box to enable the H.323 FastStart call connections on incoming calls.
By default, the check box remains unchecked for the H.323 gateway.
For intercluster calls, you must check the Enable Inbound FastStart check box on Cisco CallManager servers in other clusters for the outbound FastStart feature to work.
If you updated Cisco CallManager 3.3(2) servers in other clusters with support patch B, do not enable inbound FastStart because 3.3(2)spB does not support the inbound FastStart feature over intercluster trunks