Archive for August, 2010

The Cisco Unified IP Phone 7931 includes 24 buttons that can be assigned to lines and call features. A 3-color LED provides call status information for each line.

The line buttons are numbered 24-1 from top to bottom. The numbers do not appear on the phone.

There are two ways how the top four buttons can be programmed.

enable
configure terminal
ephone template 15
button-layout set phone-type [1 | 2]**
exit

ephone 3
ephone-template 15
end

** Specifies which fixed set of feature buttons appears on a Cisco Unified IP Phone 7931G that uses a template in which this is configured.

•1—Includes two predefined feature buttons: button 24 is Menu and button 23 is Headset.

•2—Includes four predefined feature buttons: button 24 is Menu; button 23 is Headset; button 22 is Directories; and button 21 is Messages

More on 7931 and CME here.

The Cisco High-Density Packet Voice Digital Signal Processor (DSP) Module (PVDM2) enables Cisco Integrated Services Routers to provide high-density voice connectivity, conferencing, and transcoding capabilities in Cisco IP Communications solutions. PVDM stands for packet voice DSP module; it is the Cisco product name for the module that provides digital signal processing resources to a system. DSP stands for Digital Signal Processor; it is a generic Industry terminology. A PVDM module could be staffed with one or multiple DSPs.

PVDM2-8 = 8ch (G), 4ch (H), 4ch (M)

PVDM2-16 = 16ch (G), 6ch (H), 8ch (M)

PVDM2-32 = 32ch (G), 12ch (H), 16ch (M)

PVDM2-48 = 48ch (G), 18ch (H), 24ch (M)

PVDM2-64 = 64ch (G), 24ch (H), 32ch (M)

G=g711     H=G723.1,G728, G729, Gt29b, iLBC      M= G711, G729a, G729ab, G726, G722, Fax Relay

PVDM2-16 is one DSP chip (32=2, 48=3, 64=4)
PVDM2-8 is one DSP chip but less processing capacity than the DSP on the 16.
PVDM2-8 contains one TNETV2505GGW DSP; other PVDM2 modules contain 1 to 4 TNETV2510GGW DSPs (referred to C5510 in command outputs)

Codec Complexity and Flex Mode:

You can configure each DSP separately as either medium complexity, high complexity, or flex mode (C5510 only).Configure with voice-card x.  Then codec complexity (flex | high | medium). The DSP treats all calls according to its configured complexity, regardless of the actual complexity of the codec of the call. A resource with configured complexity equal or higher than the actual complexity of the incoming call must be available, or the call will fail.

3725 with NM-HDV in slot 0
!
Gateway#conf t
Gateway(config)#voice-card 0
Gateway(config-voicecard)#codec complexity ?
high    Set codec complexity high. High complexity, lower call density.
medium  Set codec complexity medium. Mid range complexity and call  density.
<cr>
Gateway(config-voicecard)#end

2811 with PVDM2-16 installed on main board.
!
GW_2811#config terminal
Enter configuration commands, one per line. End with CNTL/Z.
GW_2811(config)#voice-card 0
GW_2811(config-voicecard)#codec complexity ?
flex    Set codec complexity Flex. Flex complexity, higher call density.
high    Set codec complexity high. High complexity, lower call density.
medium  Set codec complexity medium. Mid range complexity and call density.

GW_2811(config-voicecard)#end
GW_2811#

For example, if a call requires a high-complexity codec but the DSP resource is configured for medium complexity mode, the call will fail. However, if a medium-complexity call is attempted on a DSP configured for high complexity mode, then the call will succeed and Cisco IOS will allocate a high-complexity mode resource.

Voice cards that do not have C5510 DSPs can be configured only for medium or high complexity. Voice cards that are equipped with C5510 DSPs have an additional complexity option called flex complexity. Setting the codec complexity to medium or high sets the number of voice terminations per DSP to a static number. Flex mode has an advantage when calls of multiple codecs must be supported on the same hardware because flex mode can support more calls than when the DSPs are configured as medium or high complexity. However, flex mode does allow oversubscription of the resources, which introduces the risk of call failure if all resources are used. With flex mode it is possible to have fewer DSP resources than with physical TDM interfaces.

DSP Sharing & Farming:

DSP sharing and DSP farming has been used interchangeably. Cisco IOS dspfarm command is used for both DSP sharing and DSP farming. The DSP farming term was originally used to describe using DSPs as media resources for CallManager. DSP sharing allows C5510 DSPs to terminate a voice call from a voice port that is located in another hardware slot. This can reduce the possibility of oversubscription when using flex complexity. It can also make it easier to add DSPs to an existing gateway. It is physically much easier to add PVDM2s to an NM-HDV2 than it is to add them to the main board of an ISR.

  • A local DSP is on the same voice card as the voice port.
  • A remote DSP is on a different voice card than the voice port.
  • The DSPs on the main board of an ISR are local to the High-Performance WAN Interface Card (HWIC) and Extension Voice Module (EVM) slots and are remote to the NM slots.
  • DSP sharing supports only voice termination not transcoding.
  • DSP sharing is supported on T1/E1 interfaces only.
  • DSP sharing is supported on PVDM2s that are installed on the main board of 2800 and 3800 ISRs.
  • DSP sharing is supported on NM-HDV2s that are installed in a 2800, 3700, or 3800 router.
  • All voice cards that share DSPs must have synchronized clocks.

You should configure all voice cards that share DSPs for the same complexity.
GW_2811(config)#voice-card 0
GW_2811(config-voicecard)#dspfarm
GW_2811(config-voicecard)#end

Please refer to configuration for IOS Transcoding and Hardware Conferencing.

Transcoding & MTP Resources:

Transcoding can be configured on following devices:

  • WS-X6608-T1/E1
  • WS-SVC-CMM-ACT
  • PVDM installed in NM-HDV
  • PVDM2s installed in NM-HDV2
  • PVDM2s installed in ISRs
  • NM-HD-1V/2V/2VE (C5510)
  • 1751/1760

Maximum number of transcoding sessions per device:

Device {Max Sessions}

WS-6608-T1/E1 {24 per port, 192 per module}
WS-SVC-CMM-ACT {64}
C549 {4}
C549 in 1751/1760  {2}
C5510 medium complexity {8}
C5510 high complexity {6}
c5510 flex complexity {16*}

* It is only possible to support 16 transcoding sessions when you are transcoding between two low- complexity codecs. Because this situation is rare, the practical maximum number of transcoding sessions per DSP is 8.

Note: Software-based MTPs can support two voice streams with the same packetization rates. If the voice streams use different packetization rates, a DSP is required. The number of software-based MTP sessions is CPU bound and varies per router platform. You can configure only the C5510 DSP to provide hardware-based MTP services. Each DSP can support 16 MTP sessions. If a call requires MTP services and no MTP is configured, a transcoder is used if available.

Conferencing:

You need to consider only one factor when calculating conference bridge DSP requirements: the number of conferences required.For example, the C5510 supports two mixed-mode conferences with up to eight participants each. Therefore, it is technically accurate to say that the C5510 supports 16 conference participants. But this does not mean we can have 4 conferences of 4 participants each. Number of DSPs required depends on number of Conferences. Particpants per conference are irrelevant.

Device {Max Conference – Max participant}

C549                               {1 – 6}
C5510 (G.711 only)           {8 – 8}
C5510 (G.729a/G.729)     {2 – 8}

E1 Card & PVDM:

How many DSPs/PVDM are required as per E1?

As a rule of thumb always consider One PVDM2-64 for 2 E1s. Each E1 takes up 30 channels (2×30 = 60 > 64). If you are using 1 x E1 then you may use one PVDM2-32.

A PVDM-12 or PVDM2 (32 or higher) can provide voice termination, transcoding, and conferencing simultaneously. The restriction on conferencing is per DSP, not per PVDM. The gateway does track the number of voice ports that are allocated to prevent oversubscription of DSPs. Even though the DSPs are not assigned to a specific voice port, the number of DSPs available for other purposes has been reduced.

You can also use Cisco DSP Calculator to find out DSP resources needed as per requirement.

Useful Commands:

sh voice dsp voice

show voice dsp group all

show dspfarm all

Show dspfarm dsp active

Gateway Outputs:

This is from a gateway which is using on-board PVDM-12 chips.

Show diag#

Slot 2:
High Density Voice Port adapter
Port adapter is analyzed
Port adapter insertion time unknown
EEPROM contents at hardware discovery:
Hardware Revision        : 1.1
Top Assy. Part Number    : 800-03567-01
Board Revision           : E0
Deviation Number         : 0-0
Fab Version              : 02
PCB Serial Number        : JAB04390KNG
RMA Test History         : 00
RMA Number               : 0-0-0-0
RMA History              : 00
Product (FRU) Number     : NM-HDV=
EEPROM format version 4
EEPROM contents (hex):
0x00: 04 FF 40 00 CC 41 01 01 C0 46 03 20 00 0D EF 01
0x10: 42 45 30 80 00 00 00 00 02 02 C1 8B 4A 41 42 30
0x20: 34 33 39 30 4B 4E 47 03 00 81 00 00 00 00 04 00
0x30: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x40: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x50: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x60: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x70: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

HDV SIMMs: Product (FRU) Number: PVDM-12
SIMM slot 0: Empty.
SIMM slot 1: Empty.
SIMM slot 2: PVDM-12 SIMM present.
SIMM slot 3: PVDM-12 SIMM present.
SIMM slot 4: PVDM-12 SIMM present.
.

GWY01#sh voice dsp

DSP  DSP             DSPWARE CURR  BOOT                         PAK     TX/RX
TYPE NUM CH CODEC    VERSION STATE STATE   RST AI VOICEPORT TS ABORT  PACK COUNT
==== === == ======== ======= ===== ======= === == ========= == ===== ============
C549 007 01 {medium}  4.1.45 IDLE  idle      0  0 2/0:15    01     0 95382631/933
51746
02 {medium}  4.1.45 IDLE  idle         0 2/0:15    02     0 47552148/467
89172
03 {medium}  4.1.45 IDLE  idle         0 2/0:15    03     0 20910677/206
87231
04 {medium}  4.1.45 IDLE  idle         0 2/0:15    04     0 8394645/8321
251
C549 008 01 {medium}  4.1.45 IDLE  idle      0  0 2/0:15    05     0 3004228/3000
106
02 {medium}  4.1.45 IDLE  idle         0 2/0:15    06     0 983950/97893
8
03 {medium}  4.1.45 IDLE  idle         0 2/0:15    07     0 538659/54259
5
04 {medium}  4.1.45 IDLE  idle         0 2/0:15    08     0 2102367/2139
512
C549 009 01 {medium}  4.1.45 IDLE  idle      0  0 2/0:15    09     0 8154416/8309
524
02 {medium}  4.1.45 IDLE  idle         0 2/0:15    10     0 23548128/239
63817
03 {medium}  4.1.45 IDLE  idle         0 2/0:15    11     0 56429286/574
41003
04 {medium}  4.1.45 IDLE  idle         0 2/0:15    12     0 106057197/10
7984725

This is from another gateway using PVDM2-32 & PVDM2-16:

GW_WCH_01#sh voice dsp group all

DSP groups on slot 0:
dsp 1:
State: UP, firmware: 4.4.24
Max signal/voice channel: 16/16
Max credits: 240
Group: FLEX_GROUP_VOICE, complexity: FLEX
Shared credits: 150, reserved credits: 0
Signaling channels allocated: 16
Voice channels allocated: 6
Credits used: 90
Voice channels:
Ch01: voice port: 0/0/0:15.29, codec: g711ulaw, credits allocated: 15
Ch02: voice port: 0/0/0:15.3, codec: g711alaw, credits allocated: 15
Ch03: voice port: 0/0/0:15.1, codec: g711alaw, credits allocated: 15
Ch04: voice port: 0/0/0:15.2, codec: g711alaw, credits allocated: 15
Ch05: voice port: 0/0/0:15.4, codec: g711alaw, credits allocated: 15
Ch06: voice port: 0/0/0:15.31, codec: g711alaw, credits allocated: 15

dsp 2:
State: UP, firmware: 4.4.24
Max signal/voice channel: 16/16
Max credits: 240
Group: FLEX_GROUP_VOICE, complexity: FLEX
Shared credits: 225, reserved credits: 0
Signaling channels allocated: 16
Voice channels allocated: 1
Credits used: 15
Voice channels:
Ch01: voice port: 0/0/0:15.5, codec: g711alaw, credits allocated: 15

dsp 5:
State: UP, firmware: 4.4.24
Max signal/voice channel: 16/16
Max credits: 240
Group: FLEX_GROUP_VOICE, complexity: FLEX
Shared credits: 240, reserved credits: 0
Signaling channels allocated: 2
Voice channels allocated: 0
Credits used: 0

DSP groups on slot 1:
This command is not applicable to slot 1

DSP groups on slot 2:
This command is not applicable to slot 2

0 DSP resource allocation failure

GW_WCH_01#sh voice dsp

DSP  DSP                DSPWARE CURR  BOOT                         PAK     TX/RX
TYPE NUM CH CODEC       VERSION STATE STATE   RST AI VOICEPORT TS ABORT  PACK COUNT
==== === == ======== ========== ===== ======= === == ========= == ===== ============

—————————-FLEX VOICE CARD 0 ——————————
*DSP VOICE CHANNELS*
DSP   DSP                DSPWARE CURR  BOOT                         PAK   TX/RX
TYPE  NUM CH CODEC       VERSION STATE STATE   RST AI VOICEPORT TS ABRT PACK COUNT
===== === == ======== ========== ===== ======= === == ========= == ==== ============
C5510 001 01 g711alaw     4.4.24 busy  idle      0  0 0/0/0:15  01    0    3128/3041
C5510 001 02 g711alaw     4.4.24 busy  idle      0  0 0/0/0:15  02    0  10125/10293
C5510 001 03 g711alaw     4.4.24 busy  idle      0  0 0/0/0:15  03    0    1432/1215
*DSP SIGNALING CHANNELS*
DSP   DSP                DSPWARE CURR  BOOT                         PAK   TX/RX
TYPE  NUM CH CODEC       VERSION STATE STATE   RST AI VOICEPORT TS ABRT PACK COUNT
===== === == ======== ========== ===== ======= === == ========= == ==== ============
C5510 001 01 {flex}       4.4.24 alloc idle      0  0 0/1/1     06    0         18/0
C5510 001 02 {flex}       4.4.24 alloc idle      0  0 0/1/0     06    0        442/0
C5510 001 03 {flex}       4.4.24 alloc idle      0  0 0/1/3     02    0         18/0
C5510 001 04 {flex}       4.4.24 alloc idle      0  0 0/1/2     02    0        110/0
————————END OF FLEX VOICE CARD 0 —————————-

GW_WCH_01#sh voice dsp active

DSP  DSP                DSPWARE CURR  BOOT                         PAK     TX/RX
TYPE NUM CH CODEC       VERSION STATE STATE   RST AI VOICEPORT TS ABORT  PACK COUNT
==== === == ======== ========== ===== ======= === == ========= == ===== ============

—————————-FLEX VOICE CARD 0 ——————————
*DSP ACTIVE VOICE CHANNELS*
DSP      DSPWARE           VOX DSP               SIG DSP            PAK   TX/RX
TYPE     VERSION CODEC    NUM CH TS VOICEPORT SLT NUM CH TS RST AI ABRT PACK COUNT
===== ========== ======== === == == ========= === === == == === == ==== ============
C5510 4.4.24 g711alaw 001 01 01 0/0/0:15  000 001 05 01   0  0    0  15825/15801
C5510 4.4.24 g711alaw 001 02 02 0/0/0:15  000 001 06 02   0  0    0  22822/23053
C5510 4.4.24 g711alaw 001 03 03 0/0/0:15  000 001 07 03   0  0    0  14129/14030
C5510 4.4.24 g711alaw 001 04 04 0/0/0:15  000 001 08 04   0  0    0    6865/5661
C5510 4.4.24 g711alaw 001 05 05 0/0/0:15  000 001 09 05   0  0    0    4636/4588
C5510 4.4.24 g711alaw 002 01 06 0/0/0:15  000 001 10 06   0  0    0    3141/3180
————————END OF FLEX VOICE CARD 0 —————————-

Transcoding SessionsWS-6608-T1/E1 {24 per port, 192 per module}

WS-SVC-CMM-ACT {64}

C549 {4}

C549 in 1751/1760  {2}

C5510 medium complexity {8}

C5510 high complexity {6}

c5510 flex complexity {16*}

* It is only possible to support 16 transcoding sessions when you are transcoding between two low- complexity codecs. Because this situation is rare, the practical maximum number of transcoding sessions per DSP is 8.

How you can restrict access to corporate directory?

If you remember, corporate directory is accessible globally from a cluster and restricting its access needs some configuration changes. In pre-CUCM 7.x you cannot accommodate it at individual level but in CUCM7.x you have flexibility.

You can run a sql command to access corporate directory information from ‘enduser’ table.

admin:run sql select userid,firstname,lastname,telephonenumber from enduser
userid firstname lastname telephonenumber
====== ========= ======== ===============
hqph1            hqph1
hqph2            hqph2
br1ph1           br1ph1
br1ph2           br1ph2
JTAPI            JTAPI

In Pre-CUCM 7.x build you can disable corporate directory by following these steps:

  • Go to Enterprise parameters and go down in Phone URL parameters and delete the URL. Click save and reset the phones.

But  if you want to restrict few users then you will have to delete the URL from Enterprise parameters and enter manually under each phone the URL of Services (under External Data Locations Information). You may use Bulk Admin tool to speed up the process (Bulk Admin > Phones > Update phones > Query).

In CUCM7.x and later various directories like Missed calls, Received calls etc are now IP phone services as you can see below:

An IP phone service if setup as Enterprise Subscription, it is accessible automatically from every phone in the cluster. There are some services which are ‘enterprise’ enabled and cannot be changed easily. In CUCM 7.x there is a new feature called “Enhanced Service Provisioning”.  It basically allows an administrator to set a parameter which tells a phone to get service configurations either internally (using TFTP config file) or externally (using service URLs).

The behavior of phones is controlled by enterprise parameter ‘Service Provisioning’.

This can also be controlled from Device > Device settings > Common Phone Profile:

The default under common phone profile is to use Service Provisioning which means Message/Directories URL Parameters are not used and Phone services are provisioned using IP phone services. When the Parameter is set to external that would use URLs from Enterprise parameters and Internal is default.

To disable Personal directory across the cluster you may do by un-checking the checkbox from Enable field under Device > Device settings > Phone services. This will disable Personal directory across each Phone. What if we want to do this for few phones? By default phones use internal service provisioning which means Directory URL is ignored. Also, if we use external service provisioning we wont get a separate link for Personal directory. The personal directory has ‘Enterprise Subscription’ flag enabled. So, to provision few phones for Personal directory, you may have to delete and re-create Personal directory service with same parameters but by NOT enabling enterprise subscription. You may then go in each phone and subscribe it to Personal directory. You can also do this from Bulk Admin > Phones > update Phones.

If we want to disable ‘directories’ button for some phones in a cluster then we can do by configuring a separate common phone profile and selecting External URL in there. We then need to delete the ‘URL directories’ to completely disable the button.

Fax machines connected to ATA were not working.

The first thing I checked on the gateway…is fax-relay was being used or fax protocol cisco was configured? Fax-relay is NOT supported by ATA.

This is what I found at the Voice gateway:
voice service voip
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
supplementary-service h450.12
fax protocol cisco

I found the reason why faxes were not working. Fax protocol cisco was used which enabled default fax-relay.

I configured the following:

voice service voip
fax protocol none {or could have configured modem passthrough nse codec g711ulaw}

dial-peer voice 40 voip
description **Outgoing Call to SIP Trunk**
translation-profile outgoing SIP-CALLS-OUT
preference 1
destination-pattern 9.T
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target sip-server
dtmf-relay rtp-nte
fax rate disable <<<<<<
no vad

!
!

dial-peer voice 50 voip
description **Incoming Call from SIP Trunk**
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 sip-server
incoming called-number .%
dtmf-relay rtp-nte
fax rate disable <<<<<<
no vad
!

Everything started working!

A new feature has been introduced in Cisco IOS® Software Release 15.1(2)T to guard against the incidence of toll-fraud on Voice GateWays (VGWs) installed with Cisco IOS. Starting with IOS 15.1(2)T and newer releases of IOS based on this version, the toll-fraud prevention settings are the default behavior of Cisco IOS-based VGWs.

Behavior Before 15.1(2)T

For all IOS releases before 15.1(2)T, the default behavior for IOS voice gateways is to accept call setups from all sources. As long as voice services are running on the router, the default configuration will treat a call setup from any source IP address as a legitimate and trusted source to set a call up for. Also, FXO ports and inbound calls on ISDN circuits will present secondary-dial tone for inbound calls, allowing for two-stage dialing. This assumes a proper inbound dial-peer is being matched.

Behavior with 15.1(2)T and Later Releases

Starting with 15.1(2)T, the router’s default behavior is to not trust a call setup from a VoIP source. This feature adds an internal application named TOLLFRAUD_APP to the default call control stack, which checks the source IP of the call setup before routing the call. If the source IP does not match an explicit entry in the configuration as a trusted VoIP source, the call is rejected.

The following command is enabled:

  voice service voip
    ip address trusted authenticate   

Additional valid ip addresses can be added via the
 following command line:
   voice service voip
    ip address trusted list
     ipv4 <ipv4-address> [<ipv4 network-mask>] 

If Toll fraud is blocking the call then you will have Q.850 disconnect cause code with value of 21.
%VOICE_IEC-3-GW: Application Framework Core: Internal Error (Toll fraud call rejected):
IEC=1.1.228.3.31.0 on callID 3 GUID=F146D6B0539C11DF800CA596C4C2D7EF
000183: *Apr 30 14:38:57.251: //3/F146D6B0800C/CCAPI/ccCallSetContext:
Context=0x49EC9978
000184: *Apr 30 14:38:57.251: //3/F146D6B0800C/CCAPI/cc_process_call_setup_ind:
>>>>CCAPI handed cid 3 with tag 1002 to app “_ManagedAppProcess_TOLLFRAUD_APP”
000185: *Apr 30 14:38:57.251: //3/F146D6B0800C/CCAPI/ccCallDisconnect:
Cause Value=21, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)

How you can return back to pre-15.1(2) IOS behaviour?

voice service voip
no ip address trusted authenticate

To authenticate all sources for VoIP calls:

voice service voip
ip address trusted list
ipv4 0.0.0.0 0.0.0.0

More can be read from Cisco Technote.

This was an interesting scenario where incoming calls were getting ‘user busy’ message at the gateway and an engage tone was heard at calling party side.

*Aug 18 08:36:53.581: ISDN Se0/0/0:15 Q931: RX <-CALL_PROC pd = 8  callref = 0x8D7E
Channel ID i = 0xA9839E
Exclusive, Channel 30

*Aug 18 08:36:54.997: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x8D7E
Cause i = 0x8091 -User busy

It was not just one extension but several extensions which were having the same issue. They were all running fine till yesterday!

Something must have happened…

I did debug voip ccapi inout for a working extension and a non-working one, this is what I found:

Successful call to 7536 and un-successful call to 7534:

Call to 7536:

Aug 19 08:41:00.697: //757/541618588180/CCAPI/cc_api_display_ie_subfields:

ccCallSetupRequest:
cisco-username=
—– ccCallInfo IE subfields —–

cisco-ani=9XXXXXXX395
cisco-anitype=2
cisco-aniplan=1
cisco-anipi=0
cisco-anisi=1
dest=7536
cisco-desttype=0
cisco-destplan=1
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-lastrdn=
cisco-rdntype=-1
cisco-rdnplan=-1
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1   fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0

Aug 19 08:41:00.697: //757/541618588180/CCAPI/ccIFCallSetupRequestPrivate:
Interface=0x480CDF30, Interface Type=1, Destination=, Mode=0x0,
Call Params(Calling Number=9XXXXXXX395,(Calling Name=)(TON=National, NPI=ISDN, Screening=User, Passed, Presentation=Allowed),
Called Number=7536(TON=Unknown, NPI=ISDN), Calling Translated=FALSE,
Subscriber Type Str=RegularLine, FinalDestinationFlag=TRUE, Outgoing Dial-peer=10, Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)
Aug 19 08:41:00.701: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
Aug 19 08:41:00.701: :cc_get_feature_vsa malloc success
Aug 19 08:41:00.701: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
Aug 19 08:41:00.701:  cc_get_feature_vsa count is 8
Aug 19 08:41:00.701: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Aug 19 08:41:00.701: :FEATURE_VSA attributes are: feature_name:0,feature_time:1187854080,feature_id:785
Aug 19 08:41:00.701: //758/541618588180/CCAPI/ccIFCallSetupRequestPrivate:
SPI Call Setup Request Is Success; Interface Type=1, FlowMode=1
Aug 19 08:41:00.701: //758/541618588180/CCAPI/ccCallSetContext:
Context=0x46B3748C
Aug 19 08:41:00.701: //757/541618588180/CCAPI/ccSaveDialpeerTag:

Outgoing Dial-peer=10

Aug 19 08:41:00.901: //758/541618588180/CCAPI/cc_api_set_called_ccm_detected:
CallInfo(called ccm detected=TRUE ccmVersion 1)
Aug 19 08:41:00.901: //758/541618588180/CCAPI/cc_api_call_proceeding:
Interface=0x480CDF30, Progress Indication=NULL(0)
Aug 19 08:41:00.905: //758/541618588180/CCAPI/cc_api_set_called_ccm_detected:
CallInfo(called ccm detected=TRUE ccmVersion 1)
Aug 19 08:41:00.905: //758/541618588180/CCAPI/cc_api_set_delay_xport:
CallInfo(delay xport=TRUE)
Aug 19 08:41:00.905: //758/541618588180/CCAPI/cc_api_call_alert:
Interface=0x480CDF30, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
Aug 19 08:41:00.909: //758/541618588180/CCAPI/cc_api_call_alert:
Call Entry(Retry Count=0, Responsed=TRUE)
Aug 19 08:41:00.909: //758/541618588180/CCAPI/cc_api_set_called_ccm_detected:

CallInfo(called ccm detected=TRUE ccmVersion 1)

Aug 19 08:41:00.909: //758/541618588180/CCAPI/cc_api_call_notify:
Data Bitmask=0x5, Interface=0x480CDF30, Call Id=758
Aug 19 08:41:00.909: //757/541618588180/CCAPI/ccCallAlert:
Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
Aug 19 08:41:00.909: //757/541618588180/CCAPI/ccCallAlert:
Call Entry(Responsed=TRUE, Alert Sent=TRUE)
Aug 19 08:41:00.913: //757/541618588180/CCAPI/ccGenerateToneInfo:

Stop Tone On Digit=FALSE, Tone=Ring Back,

Tone Direction=Network, Params=0x0, Call Id=757
Aug 19 08:41:00.921: //758/541618588180/CCAPI/cc_api_get_ssCTreRoutingNotSupported:
CallInfo(ssCTreRoutingNotSupported=FALSE)
Aug 19 08:41:00.921: //758/541618588180/CCAPI/cc_api_get_ccm_detected:
CallInfo(ccm detected=TRUE)
Aug 19 08:41:00.921: //757/541618588180/

CCAPI/ccCallNotify:
Data Bitmask=0x5, Call Id=757

Call to 7534:

—– ccCallInfo IE subfields —–

cisco-ani=9XXXXXXX395
cisco-anitype=2
cisco-aniplan=1
cisco-anipi=0
cisco-anisi=1
dest=7534
cisco-desttype=0
cisco-destplan=1
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-lastrdn=
cisco-rdntype=-1
cisco-rdnplan=-1
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1   fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0

Aug 19 08:36:26.159: //-1/B07908F8816D/CCAPI/cc_api_call_setup_ind_common:
Interface=0x49470D5C, Call Info(Calling Number=9XXXXXXX395,(Calling Name=)(TON=National, NPI=ISDN, Screening=User, Passed, Presentation=Allowed),Called Number=7534(TON=Unknown, NPI=ISDN),

Calling Translated=FALSE, Subscriber Type Str=RegularLine, FinalDestinationFlag=TRUE,
Incoming Dial-peer=2, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=-1
Aug 19 08:36:26.159: //-1/B07908F8816D/CCAPI/ccCheckClipClir:
In: Calling Number=9XXXXXXX395(TON=National, NPI=ISDN, Screening=User, Passed, Presentation=Allowed)
Aug 19 08:36:26.159: //-1/B07908F8816D/CCAPI/ccCheckClipClir:
Out: Calling Number=9XXXXXXX395(TON=National, NPI=ISDN, Screening=User, Passed, Presentation=Allowed)
Aug 19 08:36:26.159: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Aug 19 08:36:26.163: :cc_get_feature_vsa malloc success
Aug 19 08:36:26.163: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Aug 19 08:36:26.163:  cc_get_feature_vsa count is 11
Aug 19 08:36:26.163: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:

Aug 19 08:36:26.163: :FEATURE_VSA attributes are: feature_name:0,feature_time:1187856544,feature_id:752
Aug 19 08:36:26.163: //725/B07908F8816D/CCAPI/cc_api_call_setup_ind_common:

Set Up Event Sent;
Call Info(Calling Number=9XXXXXXX395(TON=National, NPI=ISDN, Screening=User, Passed, Presentation=Allowed),
Called Number=7534(TON=Unknown, NPI=ISDN))
Aug 19 08:36:26.167: //725/B07908F8816D/CCAPI/cc_process_call_setup_ind:

Event=0x48577A78
Aug 19 08:36:26.167: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:

Try with the demoted called number 7534

Aug 19 08:36:26.167: //725/B07908F8816D/CCAPI/ccCallSetContext:
Context=0x46B3C0AC
Aug 19 08:36:26.167: //725/B07908F8816D/CCAPI/cc_process_call_setup_ind:
>>>>CCAPI handed cid 725 with tag 2 to app “_ManagedAppProcess_Default”
Aug 19 08:36:26.179: //725/B07908F8816D/CCAPI/ccCallProceeding:
Progress Indication=NULL(0)

Aug 19 08:36:26.183: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
Try with the demoted called number 7534
Aug 19 08:36:26.183: //-1/xxxxxxxxxxxx/CCAPI/cc_update_feature_vsa:
Aug 19 08:36:26.183: : updating existing feature vsa
Aug 19 08:36:26.183: //-1/xxxxxxxxxxxx/CCAPI/cc_update_feature_vsa:

Aug 19 08:36:26.183:  feature call basic
Aug 19 08:36:26.203: //725/B07908F8816D/CCAPI/ccCallDisconnect:
Cause(Value=17, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Aug 19 08:36:26.203: //725/B07908F8816D/CCAPI/ccCallDisconnect:

Cause Value=17, Call Entry(Responsed=TRUE, Cause Value=17)

Aug 19 08:36:26.203: //725/B07908F8816D/CCAPI/cc_api_get_transfer_info:
Transfer Number Is Null
Aug 19 08:36:26.371: //725/B07908F8816D/CCAPI/cc_api_call_disconnect_done:
Disposition=0, Interface=0x49470D5C, Tag=0x0, Call Id=725,
Call Entry(Disconnect Cause=17, Voice Class Cause Code=0, Retry Count=0)
Aug 19 08:36:26.375: //725/B07908F8816D/CCAPI/cc_api_call_disconnect_done:
Call Disconnect Event Sent
Aug 19 08:36:26.375: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
Aug 19 08:36:26.375: :cc_free_feature_vsa freeing 46CD4098
Aug 19 08:36:26.375: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:

The above results show that a successful call did hit the outbound VoIP dialpeer which was pointing to CCM but the failed call was just hitting the Inbound POTS dialpeer and was not routing to the VoIP dialpeer. Why in the world one DDI of same range is routing to CCM while other is returning user busy (the cause code 17 is user busy). The phone at x7534 was registered to call manager and there were all ISDN channels available (Show isdn service). I checked the gateway configuration and found telephony-service configured on it with auto-provision none.

telephony-service
srst mode auto-provision none
srst ephone template 1
srst ephone description srst fallback auto-provision phone
srst dn template 1
srst dn line-mode dual

.

.

But I could also see all ephones and ephone-dn’s in the configuration. I found out that this failed extension x7534 was sitting there under one of the ephone-dn. I confirmed that a third party engineer configured SRST on the router previous evening and he checked everything working fine ….. what he did….he configured srst auto provision all to learn the dn’s so that he can configure the hunt groups and then locked it down using srst auto provision none. This, however, produced abnormal results as the phones which were learned by the gateway were preferred over VoIP dialpeer and a call to these numbers was not getting routed to Call manager. This is what I did to solve this issue:

Router(config)# dial-peer hunt 3
•0—Specifies longest match in phone number, explicit preference, random selection (default)
•1—Specifies longest match in phone number, explicit preference, least recent use.
•2—Specifies explicit preference, longest match in phone number, random selection.
•3—Specifies explicit preference, longest match in phone number, least recent use.
•4—Specifies least recent use, longest match in phone number, explicit preference.
•5—Specifies least recent use, explicit preference, longest match in phone number.
•6—Specifies random selection.
•7—Specifies least recent use.

ephone-dn  1  dual-line
preference 8
!
!
ephone-dn  2  dual-line
preference 8
!
!
ephone-dn  3  dual-line
preference 8
!
!
ephone-dn  4  dual-line
preference 8
!
!
ephone-dn  5  dual-line
preference 8
!
!
ephone-dn  6  dual-line
preference 8
!

to ephone-dn 45

– same –

Tested the call all working fine.

What was happening – the call was coming in and because the phone was learned as ephone it was preferred over VoIP dialpeer.

To avoid incorrect routing when you prebuild ephone-dns for Cisco Unified Communications Manager phones in Cisco Unified CME, use the preference command in ephone-dn and voip-dial-peer configuration mode to create a higher preference (0 being the highest) for the voip dial peer than the preference for the prebuilt directory number.

I came across this customer where we upgraded their CUCM from 6.x to 7.x and changed the mother board of the UCS Server (there were some issues with it).

After the upgrade the Call manager had major Licensing issues as the MAC address got changed. All the units went into negative and there was an error in red saying Call manager is running out of license blah blah..

There is a process of re-homing your license if the MAC address has been changed. One way could be to send any of the previous license files to Cisco licensing licensing@cisco.com asking them to rehome it to new MAC address. You can also send an email to the same address with something on these lines:

We have license tied to PAK code YYYYYYY for our CUCM ver 7.1.3. The hardware on the Call manager was replaced and we would like the license to be re-homed to our new MAC address 45EF.AB43.BC78.  The Enduser name is Company Ltd with blah blah address.

Cisco Licensing team has been very helpful in sorting out these kind of issues.

Customer reported a fault that several fax machines which were working fine last week have suddenly stopped working. All they were getting for incoming faxes was just the header. No content of the actual fax.

Rule of thumb – anything which was working before and not working now means something must have changed. I jumped on the main Voice gateway which was connected to the switch and the Fax machines were connected to the VG224. A typical depiction could be as follows:

PSTN >> VGW >> SW >> VG224 >> FAX

There were 3x E1 cards on the Voice gateway. One of them was connected to PSTN which was used for incoming/outgoing calls, the other one was connected to Meridian PBX system and the third one to Investec DealerBoard.

E1 0/0/0 – PBX
E1 0/1/0 – ISDN30
E1 0/2/0 – Dealer Board

I first checked the network-clock-participate and network-clock-select as they are very important for Fax issues. I found  this:
network-clock-participate wic 0
network-clock-participate wic 1
network-clock-participate wic 2
network-clock-select 1 E1 0/0/0

So the Primary clock source was Meridian PBX side. I then checked the controllers and found as follows:

E1 0/1/0  – Connected to ISDN PSTN  – faxes are coming on this line

Total Data (last 24 hours)
0 Line Code Violations, 0 Path Code Violations,
18475 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
18475 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

LON-VG1-3825#

E1 0/2/0 – Connected to ITS Dealerboard

195 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 24 hours)
0 Line Code Violations, 0 Path Code Violations,
18701 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
18701 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs

!

I found the issue. The E1 had so many Slip seconds and that was the main reason for fax issues. I later found out that there was some planned work carried out by third party which changed some configuration at the Meridian PBX side. This obviously created some clocking issues. I re-configured the clock-select as follows:

no network-clock-select 1 E1 0/0/0
network-clock-select 1 E1 0/1/0
network-clock-select 2 E1 0/0/0

This way I made the PSTN as main clocking source which eliminated the slip seconds issue and the fax started working.

ATA 186 – 2 x voice ports + 1 x RJ-45 10BaseT port

ATA 188 – 2x voice ports +  2 x RJ-45 10/100BaseT port

The Cisco ATA supports two modes of fax services, in which fax signals are transmitted using the G.711 codec. It cannot support fax relay. ATA is accessed by web through http://<ipaddress_of_ata>/dev

•Fax pass-through mode—Receiver-side Called Station Identification (CED) tone detection with automatic G.711A-law or G.711µ-law switching.
•Fax mode—The Cisco ATA is configured as a G.711-only device.

Fax Pass-through Mode: Fax pass-through mode allows for maximum codec flexibility because users may set up a voice call using any voice codec, then renegotiate to a G.711 codec for the fax session. To use fax pass-through mode, first configure the Cisco ATA and supporting Cisco gateways to support the Cisco-proprietary G.711fax upspeed method. Then, disable fax relay on the far-end gateway—either for the entire gateway or for the dial peer engaged in the fax call with the Cisco ATA.

This requires configuration of two parameters at the ATA i.e. AudioMode & ConnectMode.

Audio Mode: The AudioMode parameter is a 32-bit value. The lower 16 bits apply to the Phone 1 port of the Cisco ATA and the upper 16 bits apply to the Phone 2 port of the Cisco ATA.

To configure Phone 1 for Fax pass through:

0xXXXX0015 => xxxx.xxxx.xxxx.xxxx 0000.0000.0001.0101

•Bit 0 = 1—Enables G.711 silence suppression (VAD)
•Bit 2 = 1—Enables Fax CED tone detection and switchover upon detection
•Bit 4 = 1, Bit 5 = 0—DTMF transmission method = out-of-band through negotiation
•Bit 6 = Bit 7 = 0—Hookflash transmission method = disable sending out hookflash

Connect Mode: The ConnectMode parameter is a 32-bit value. The parameter settings apply to both lines of the Cisco ATA. Configure ConnectMode after configuring AudioMode for fax pass-through mode. Cisco Recommends a value of 0x90000400.

0x90000400 => 1001.0000.0000.0000.0000.0100.0000.0000

•Bit 2,7-15 are important for Fax-pass through (made bold above)

•Bit 2 = 0—Uses RTP payload number 126/127 for fax upspeed to G.711m-law/G.711A-law. Set this value to 1 if you want to use RTP payload number 0/8 for fax upspeed.
•Bit 7 = 0—Disables fax pass-through redundancy. Set this bit to 1 to enable redundancy. With redundancy enabled, the Cisco ATA sends each packet twice. Because of bandwidth and transmission time costs, use this option only if network quality is poor and all other gateways used in the network support this feature.
•Bits {12, 11, 10, 9, 8} = {0, 0, 1, 0, 0}—Sets the offset to NSE payload-type number 96 to 4. Setting the offset to 4 results in the Cisco ATA sending an NSE payload-type value of 100 by default. Valid offset values range from 2 to 23 (NSE payload type value of 98 to 119). Set this value to match the value for your Cisco gateways.
Most Cisco MGCP-based gateways, such as Cisco 6608, use NSE payload type 101 by default. Most Cisco H.323/SIP-based gateways use NSE payload type 100 by default.
•Bit 13 = 0—Uses G.711m-law for fax pass-through upspeed. Set this bit to 1 to use G.711A for fax pass-through upspeed.
•Bit 14 = Bit 15 = 0—Enables fax pass-through mode using the Cisco proprietary method (recommended). Set both of these bits to 1 to disable fax pass-through mode.

To configure Fax pass through on the IOS gateway, follow these steps:

voice service voip
modem passthrough nse codec g711ulaw
fax rate disable  {this disables the default fax relay}

!

H323:

voice service voip
h323
modem passthrough nse codec g711alaw

dial-peer voice 500 voip
incoming called-number .
destination-pattern 550
session target ipv4:10.100.90.89
fax rate disable
codec g729r8

!

SIP:
voice service voip
fax protocol pass-through g711ulaw
sip
!

dial-peer voice 2000 voip
fax rate disable
fax protocol pass-through g711alaw
MGCP:

mgcp
mgcp call-agent 10.3.222.1 service-type mgcp version 0.1
mgcp modem passthrough voip mode nse
mgcp package-capability rtp-package
mgcp fax t38 inhibit  {disable fax relay}

!

Note: If you need to configure fax pass-through to work with Cisco CallManager (CCM), you must use the modem passthrough nse command. The fax protocol pass-through command does not work with CCM, which relies on NSE information.

Sample configuration for a FAX machine connected to FXS port.

Fax connected to FXS Port:

voice-port 0/1/0
cptone GB
description ### Admin Fax 0209001 ###
!

dial-peer voice 50 pots
description ### Admin Fax 209001 ###
destination-pattern 9001
progress_ind alert enable 8
progress_ind progress enable 8
progress_ind connect enable 8
fax rate disable
port 0/1/0
!

RTP: Voice payloads are encapsulated by RTP, then by UDP, then by IP. A Layer 2 header of the correct format is applied; the type obviously depends on the link technology in use by each router interface. A single voice call generates two one-way RTP/UDP/IP packet streams. UDP provides multiplexing and checksum capability; RTP provides payload identification, timestamps, and sequence numbering.

Each RTP stream is accompanied by a Real-Time Transport Control Protocol (RTCP) stream. RTCP monitors the quality of the RTP stream, allowing devices to record events such as packet count, delay, loss, and jitter (delay variation). A single voice packet by default contains a payload of 20 msec of voice (either uncompressed or compressed). Because sampling is occurring at 8000 times per second, 20 msec gives us 160 samples. If we divide 8000 by 160, we see that we are generating 50 packets with 160 bytes of payload, per second, for a one-way voice stream.

G711 G729
Payload 160 b 20 b
Codec BW 64kbps 8kbps
L3/L4 header:
RTP 12 12
UDP 8 8
IP 20 20
Protocol Payload 40 40
Total before L2 200 b 60 b
Bamdwidth/call = Payload + Protocol Payload / Payload x CodecBW
BW/call (without L2) (160+40)/160 x 64 = 80kbps (20+40)/20 x 8 = 24kbps
Frame Relay Overhead
Frame Relay 6 b 6 b
Total L2 206 b 66 b
BW/call (160+(40+6))/160 x 64 =82.4 kbps (20+(40+6))/20 x 8 = 26.4kbps
Multilink PPP Overhead
Multilink 6 b 6 b
Total L2 206 b 66 b
BW/call (160+(40+6))/160 x 64 =82.4 kbps (20+(40+6))/20 x 8 = 26.4kbps
Ethernet Overhead
Ethernet 18 b 18 b
Total L2 218 b 78 b
BW/call (160+(40+18))/160 x 64 =87.2 kbps (20+(40+18))/20 x 8 = 31.2kbps
cRTP Applied
CRTP 40 => 4 40 => 4
Before L2 160+4 / 160 x 64 =65.6kbps 20+4 / 20 x 8= 9.6kbps
After L2 160+(4+6) / 160 x 64 =68kbps 20+(4+6) / 20 x 8= 12kbps
% GAIN with cRTP 18% 60%