Posts Tagged ‘CallManager’

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

Had a bizarre issue with one of the customer where they were trying to dial an internal extension and it was going to a mobile phone. There were no CFA/CFNA/CFB set on the extension itself but for some reason it was following this path. The Call manager version was 6.x.

The call routing was designed in a way that when they dial any 7614XXXX extension, it hits a TP (7614XXXX )and gets translated to 60447614XXXX. For testing we dialed several 7614XXXX numbers and they all went fine to corresponding 60447614XXXX except when they dialed 76146920. As soon as they dial that number you will see on the display that it’s going to an outside mobile number.

I had to dig into traces where I found for some reason it is not even hitting the Translation pattern at all and was getting intercepted by a pattern 76146920 with a Time of Day routing on it which had that mobile number setup during a certain period of time. But when I checked, there was no such TOD routing setup on this extension,  moreover there was no such extension 76146920 which exist in the system. I ran some CLI commands to find if there are any database entries for this extension and found none. Customer told me that they use to have extensions like 7614XXXX before they migrated all extensions to 60447614XXXX which means may be previously someone did setup a CFA on this extension which is still stuck in it’s database.

|VoiceMailPilotNumber=
|RouteBlockFlag=BlockThisPattern <———block
|RouteBlockCause=1
|AlertingName=
|UnicodeDisplayName=
|DisplayNameLocale=33
|InterceptPartition=Internal
|InterceptPattern=76146920

cfa     = 755XXXXXX <———– Mobile number

This is what I did to resolve the issue:

  • Created an internal extension 76146920 and put it in Internal Partition
  • Assigned the extension to a dummy phone
  • Put a Call Forward ALL on the extension to some internal number
  • Made a test call which now hits this newly created DN and goes to that CFA internal extension
  • Removed CFA and saved
  • Deleted the DN 76146920
  • Made a test call and this time it was ringing the phone 604476146920

 

This was just a one off issue and Cisco TAC later confirmed that old versions of CCM may come across these kind of issues. This is rare but I thought to share it for the benefit of everyone.

An intercom line is one of those ‘must-have’ functions that must be available on every PBX. Fortunately, CUCM does have this function, but on the other hand, the documentation explaining how the feature works and its related configuration is not so accurate. Anyway, here’s my attempt at configuring this simple, but very handy feature in CUCM 6.x – 8.x:

Before I begin, I want to mention that an intercom line is represented by a Directory Number (DN) as is the case with any dial-able entity. Now that we have that out of the way, the first thing one needs to understand is how an intercom line works. Simply put, a user (generally a manager) presses an intercom line button on their phone and it dials the intercom line on other user’s (generally an assistant) phone and the call is auto-answered at this user’s end. However, the second user can only listen to the first user’s voice, but their own phone is muted by default. The general idea behind the intercom line is for a manager to speed-dial into a second user’s phone and have it auto-answer at the receiving end in muted mode. This allows the manager to deliver a quick, one-way audio message to the assistant. If the assistant wishes to respond back to the manager, they can hit the intercom line button on their phone and initiate a two-way conversation;  just like a normal phone call.

The intercom line is an additional line on an IP phone that is configured to reach another intercom line on another IP phone. Intercom lines are configured with “Intercom Partitions” and “Intercom Calling Search Spaces” and therefore only intercom lines can reach other intercom lines. When a user presses the intercom line on their IP phone, they can manually (or configure it to automatically) dial the corresponding intercom line on the other IP phone. Generally, a Manager will have an intercom line to their Assistant’s phone, which will be the scenario for our example.

The setup:

A manager would like to have an intercom line to their assistant such that they would simply need to press the line button and have the assistant’s phone auto-answer (in muted mode). The intercom should not work in reverse, that is, the assistant should not be able to speed-dial the manager’s intercom line.

The configuration:

– Create two ‘Intercom partitions’ for the Manager and the Assistant’s intercom DNs by navigating to Call Routing -> Intercom -> Intercom Route Partition. Title the partitions something along the lines of “PT-INTERCOM-MANAGER” and “PT-INTERCOM-ASSISTANT”.

– Create two ‘Intercom CSSs’ for the Manager and the Assistant’s intercom DNs by navigating to Call Routing -> Intercom -> Intercom Calling Search Space. Title the CSSs something along the lines of “CSS-INTERCOM-MANAGER” and “CSS-INTERCOM-ASSISTANT”. Configure the Manager CSS to contain the Assistant’s Intercom partition (PT-INTERCOM-ASSISTANT) so that the Manager’s Intercom CSS will having dialing access to the Assistant’s intercom DN. The Assistants Intercom CSS will also contain the Assistant’s intercom partition only because the CSS cannot be left empty.

You’re probably wondering why we need to set up a CSS for the assistant since they won’t need any dialing privileges on their intercom line, however, both intercom partition and intercom CSSs are mandatory configuration entities for any intercom line regardless of the requirement. Go figure!

– Create an ‘Intercom Directory Number’ for the manager’s phone by navigating to Call Routing -> Intercom -> Intercom Directory Number as show in Figure 1. We will configure 3000 as the Manager’s Intercom DN.

Figure 1 – Intercom Directory Number Configuration for Manager

– Create a second ‘Intercom Directory Number’ for the assistant’s phone as show in Figure 2. We will configure 3001 as the Manager’s Intercom DN.

Figure 2 – Intercom Directory Number Configuration for Assistant

– Add an intercom line to the Manager’s phone by navigating to Device ->Phone and then selecting the phone to which the intercom line will be added. Click on the “Modify Button Items” button as show in figure 3. A small window may pop-up that reads: “Unsaved Changes may be lost! Continue?”. Click on OK and the “Reorder Phone Button Configuration” window will pop-up.

Figure 3 – “Modify Button Items” under the Phone Configuration window

– Highlight the ‘Intercom [1] – Add a new intercom’ option under the “Unassigned Associated Items” box on the right side of the window and press the “<” button to move the intercom line into the left box (Associated Items). Rearrange this option and place it in the line position where it will appear on the phone as shown in Figures 4 and 5. Note: The number of options in the left box must correspond to the number of lines on the phone. Hence, one of the unused lines may have to be moved over into the right box before the intercom option can be moved here. If this hasn’t been done and the user attempts to add an intercom line to the left box, the following error will be received: “Must Remove An Item From Associated List Before This Operation is Allowed”.

Figure 4 – Reorder Phone Button Configuration window Step 1

Figure 5 – Reorder Phone Button Configuration window Step 2

– Click on “Save” and then “Close”.

– Under the second line (where the intercom was configured) will now read: “Intercom [1] – Add a new Intercom”. Click on this link and on the next page enter the DN (3000 in our example) in the ‘Intercom Directory Number’ field and hit “tab”. The remaining fields will be automatically pulled from the Intercom Directory Number settings configured earlier as illustrated in Figure 6.

– The following fields may be entered if desired (Shown in Figure 6):

Display (Internal Caller ID)

ASCII Display (Internal Caller ID)

Line Text Label

ASCII Line Text Label

Figure 6 – Intercom Directory Configuration Window

– The “Speed Dial” field will set the intercom to dial this number (3001 in our example) as soon as the Intercom line button on the IP phone is pressed. This is illustrated in Figures 7 and 8.

Figure 7 – Normal State

Figure 8 – After Pressing the “Intercom Line”

Please feel free to post any questions or comments. I hope this post was helpful!

Overview

One of the concepts that many junior voice engineers struggle with is the class of control features of Partitions and Calling Search Spaces. I remember feeling like I was banging my head against a wall repeatedly until I hit that Ah-hah moment and it all made sense.

Now there are many great explanations out there on the inter webs that are all technically correct and great. Some use the Lock + Key analogy like the CIPT1 Study guide and some use a White Pages/Directory Analogy. In my opinion these can leave people without a whole lot of voice experience more confused than when they started.

Purpose – What are Partitions and Calling Search Spaces used for anyway?

In my opinion Partitions and Calling Search Spaces are primarily used as a way to find “things” in the phone system. They are used so endpoints (Phones, Gateways, Trunks) can dial resources (Directory Numbers, On-net Route Patterns, Off-net Route Patterns, Translation Patterns). From an end-users perspective these resources are generally represented by a number. Because you can use these Dial Plan constructs to limit what resources an endpoint can find, it allows you the ability to implement Class of Service.

Sure, you could just put everything in the none partition and be done with it all together but Tom Hollingsworth has already told us why this is a bad idea over at his blog networkingnerd.net

Yeah, Ok. But you still haven’t told me what Partitions and Calling Search Spaces do!

Hold your horses. This is the part you’ve all been waiting for….< Insert Drum Roll > Here it is:

  • Partitions contain “things”
  • Calling Search Spaces find “things”

That’s it. I really believe this is the simplest way to think of how these two constructs work and behave.

Partitions

So we know that partitions can contain “things” but what exactly can they contain? A partition will only contain one or more of the following things:

  • Directory Numbers – These Directory Numbers represent other numbers in the Phone System that can be associated to Devices.
  • Route Patterns – Route Patterns represent off-net and on-net destinations and control how a call is routed to a destination. Route Patterns use Route Lists and Route Groups to send calls over a trunk or a gateway.
  • Translation Patterns –  I consider Translations Patterns an intermediate step to either matching a Directory Number or a Route Pattern. They are used to Transform the Calling or Called Party Information before using a Calling Search Space to find a suitable match. It is also worth noting that a Translation Patten can also be set to Block instead of route which can be useful when using the Line/Device Approach for implementing Class of Service
  • Transformation Patterns – Transformation Patterns are similar to Translation Patterns except they are not part of the CUCM’s routing construct. They are used for modifying Calling or Called Party Information for purposes of presentation but do not affect call routing. When you are using Transformation Patterns you should use dedicated Partitions and Calling Search Spaces for this function.

Calling Search Spaces

So if partitions contain “things” and Calling Search Spaces find “things”, what do they look in too find them? Well they look in partitions of course.

The following constructs use Calling Search Spaces to find things:

  • Devices – Phones use a CSS to find available patterns. This is generally referred to as the Device Calling Search Space
  • Directory Numbers – Directory Numbers also use a CSS to find available patterns. This is referred to as the Line Calling Search Space.
  • Trunks
  • Gateways
  •  Translation Patterns

This list was by no means exhaustive and there is a vast number of features that require Calling Search Spaces to be defined to control access to DN’s/Patterns for that feature. Things like Time of Day Routing, Presence, Call Forward Settings etc

When a Calling Search Space is looking through a series of ordered partitions it doesn’t work like an ACL in Cisco IOS that searches sequentially through the available partitions top-down until it finds a suitable match. No, It processes all listed partitions and matches on the best or longest match. The only time in which the order of the partitions matter is when you have equally specific patterns, in which the pattern in the partition closer to the top of the CSS list will win as a tie-breaker.

OK – So I think I get it, but I’ve noticed my Phone and my Directory Number both have a CSS. What’s up with that?

Well CUCM is flexible in that you could choose to set a CSS on just one of these elements and leave the other blank.  When you have both a Device and a Line CSS the CUCM combines the two into a single CSS with Line CSS above the Device CSS.

There is a good reason to use both. In order to effectively use features like extension mobility but enforce local dialling habits at remote offices it is recommended to set the Device CSS as too allow full access to the Dial Plan and then use the Line CSS to restrict unauthorised patterns from being dialled. The Partitions in your Line CSS should contain Translation Patterns that are set to block the restricted patterns and also have the “Urgent Priority” flag checked (It is on by default).

 

The setting below applies to packets generated by the router itself.

For H323 gateways

Default for signaling is af31 (26). Need to change this to cs3 (24).

dial-peer voice 1500 voip
ip qos dscp cs3 signaling 

For MGCP gateways

mgcp ip qos dscp cs3 signaling

To setup attendant console

a. Create pilot point say ACPilot with number specified, Select algorithm as Longest idle or First available

b. Create hunt group with specified members (directory numbers).

c. Create ac user and associate pilot point with ac user. ac user default password is 12345. pin = 12345.
To change ac user password from default to cisco (say), use c:\dcdsvr\bin\Passwordutils.exe  cisco (Run the above command from that folder in command line. Copy the encrypted password text you get as output.

d.  Open c:\program files\Cisco\CallmanagerAttendant\bin\ACserver.properties file and change the following

# Propery file that server uses.

#Jtapi Username
JTAPI_USERNAME=ac

#Jtapi Password
JTAPI_PASSWORD=0c0a000a2c

e. To change hunt mechanism to Circular,

In ACserver.properties file, change the following.
# Specify comma seperated pilot point device names for which
# circular hunting algorithm is used. This will override
# what is configured in the admin pages.
CIRCULAR_HUNTING_PILOT=ACPilot
e. Restart TCD service.

For an intercom line, remember to set the auto answer setting to speakerphone.

On the gateways and trunks, set the CSS to CSS_I_E so that when a call comes from PSTN to the manager, IPMA partition is matched and calls are intercepted by IPMA