Archive for the ‘SIP’ Category

One of our customer reported an issue with ring back tone when calling their Contact center.

I made a test call and observed that as a caller when you call their main Contact center number all you hear is dead silence and then when agent picks up the phone you could hear them talk. There was no ring back tone and no automated messages before an agent picks up the call.

The call flow was something like this:

PSTN > ISDN30 > H323 Dial-peer > SIP Trunk > 3rd-party Contact Center Equipment

First I thought it could be the third-party equipment which was not sending back the ring back tone so I asked them to confirm this. They came back saying they are definitely sending ring back and there was no issue with their equipment.

Looking at Q931 debugs I could see ALERTING message with payload but wasn’t sure why there was no ring back.

The dial-peers were looking ok as well:

!

dial-peer voice 8500 voip
corlist outgoing CCM
description DC1CCM01
preference 1
destination-pattern 361[01].
progress_ind setup enable 3
progress_ind alert enable 8
session target ipv4:10.1.30.12
dtmf-relay h245-signal h245-alphanumeric
no vad

!

dial-peer voice 8501 voip
corlist outgoing CCM
description DC1CCM02 Cycos Ansage
preference 2
destination-pattern 361[01].
progress_ind setup enable 3
progress_ind alert enable 8
session target ipv4:10.1.30.13
dtmf-relay h245-signal h245-alphanumeric
no vad
!
I then decided to run some debugs to get a complete picture as to what is going wrong. These were the debugs I opened on the gateway:

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

Note: Please be very careful when you run the above debugs as these are processor intensive and make sure you are not logging monitor and console.

The debugs were massive but this is what I observed:

From Gateway traces I can see RINGBACK has definitely been sent to Gateway –

005302: *Aug 25 23:44:07.256: //-1/xxxxxxxxxxxx/H323/cch323_h225_receiver: Received msg of type ALERTIND_CHOSEN
005303: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/alert_ind: ====== PI = 0
005304: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/alert_ind: alert ind ie_bit_mask 0x1260, displayInfo
005305: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/alert_ind: delay H245 address in alert
005306: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/alert_ind: Call Manager detected
005307: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/cch323_h225_receiver: ALERTIND_CHOSEN: src address = 10.187.10.8; dest address = 10.1.30.12
005308: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/run_h225_sm: Received event H225_EV_ALERT_IND while at state H225_REQ_FS_CALLPROC
005309: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/cch323_get_embedded_obj_from_ccb: ccb=0x4715D7A0, tag=18, size=83
005310: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/cch323_get_embedded_obj_from_ccb: Extraction FAILED
005311: *Aug 25 23:44:07.256: //3610/D48C17148501/CCAPI/cc_api_set_called_ccm_detected:
CallInfo(called ccm detected=TRUE ccmVersion 3)
005312: *Aug 25 23:44:07.256: //3610/D48C17148501/CCAPI/cc_api_set_delay_xport:
CallInfo(delay xport=TRUE)
005313: *Aug 25 23:44:07.256: //3610/D48C17148501/CCAPI/cc_api_call_alert:
Interface=0x46B2BAA8, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
005314: *Aug 25 23:44:07.256: //3610/D48C17148501/CCAPI/cc_api_call_alert:
Call Entry(Retry Count=0, Responsed=TRUE)
005315: *Aug 25 23:44:07.256: //3610/D48C17148501/H323/cch323_h225_set_new_state: Changing from H225_REQ_FS_CALLPROC state to H225_REQ_FS_ALERT state
005316: *Aug 25 23:44:07.260: //3609/D48C17148501/CCAPI/ccCallAlert:
Progress Indication=INBAND(8), Signal Indication=SIGNAL RINGBACK(1)

Then ALERTING Signal shown in ISDN Q931 debug:

005331: *Aug 25 23:44:07.264: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x803A

But then Observed this:

005332: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/h323_open_rtp_stream: Media In-active notification object not attached to ccb
005333: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/cch323_set_dtmf_iw_enabled: negotiated dtmf relay: 0, dtmf_iw_enabled: 0, dtmf_sccp_enabled: 0
005334: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/cch323_caps_ind: gw_id=1
005335: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/cch323_peer_caps_ind_common: Load DSP with Preferred codec(16) g729r8, Bytes=20
005336: *Aug 25 23:44:07.264: //3610/D48C17148501/H323/cch323_peer_caps_ind_common: Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE
005337: *Aug 25 23:44:07.396: TCP0: ACK timeout timer expired
005338: *Aug 25 23:44:07.448: //-1/xxxxxxxxxxxx/H323/cch323_ct_main: SOCK 2 Event 0x1
005339: *Aug 25 23:44:07.448: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: owner_data=0x46DA9F30, len=53, msgPtr=0x475C62BC
005340: *Aug 25 23:44:07.448: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: Received msg for H.225

I was a bit surprised as to why G729 codec was negotiated when the whole path is G711. Even the SIP trunk was in all-G711 region.

Looking closely at dial-peers I found what was missing!! The VOIP dial-peers were missing the “Voice class codec 1” command which had G711 as priority 1 codec. As the command was not there, the call was matching dial-peer 0 and hence negotiating G729 codec. I added the command and the problem was solved. I can now hear ring back tone as well as all automated messages.

This is how it looks after I made the changes:

005935: *Aug 26 00:15:26.432: //3620/349708E58506/H323/h323_open_rtp_stream: Media In-active notification object not attached to ccb
005936: *Aug 26 00:15:26.432: //3620/349708E58506/H323/cch323_set_dtmf_iw_enabled: negotiated dtmf relay: 0, dtmf_iw_enabled: 0, dtmf_sccp_enabled: 0
005937: *Aug 26 00:15:26.432: //3620/349708E58506/H323/cch323_caps_ind: gw_id=1
005938: *Aug 26 00:15:26.432: //3620/349708E58506/H323/cch323_peer_caps_ind_common: Load DSP with Preferred codec(5) g711ulaw, Bytes=160
005939: *Aug 26 00:15:26.432: //3620/349708E58506/H323/cch323_peer_caps_ind_common: Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE
005940: *Aug 26 00:15:26.568: TCP0: ACK timeout timer expired
005941: *Aug 26 00:15:26.620: //-1/xxxxxxxxxxxx/H323/cch323_ct_main: SOCK 2 Event 0x1
005942: *Aug 26 00:15:26.620: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: owner_data=0x46DAB900, len=53, msgPtr=0x475C5200
005943: *Aug 26 00:15:26.620: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: Received msg for H.225
005944: *Aug 26 00:15:26.620: H225.0 INCOMING ENCODE BUFFER::= 28501900060008914A0005003497A50DEE3911E19D37B87571A7872310800100
005945: *Aug 26 00:15:26.620:
005946: *Aug 26 00:15:26.620: H225.0 INCOMING PDU ::=

Most of the time problems like these are Codec or MRG related so it’s always a good idea to start checking your codecs first.

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.

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
fair-queue
!

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

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

OR

!
interface GigabitEthernet0/0.105
description *** Voice VLAN ***
encapsulation dot1Q 105
ip address 10.60.x.x 255.255.255.0
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
FastEthernet0/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
Queueing
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
Queueing
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
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0

Came across a complex situation where customer was using this SIP trunk as an alternative to ISDN-30 (if all channels are used or if ISDN goes down). The ISDN-30 link was working fine but they had issues on SIP trunk (how many times I have heard this?) …. their outbound calls over SIP were using a prefix ‘8’ to route calls on SIP trunk to SIP Provider. The Outbound calls were working fine. The inbound calls drop after 8 secs and none of the calling/called party could hear each other. Complete silence..

Call flow was something like this:

PSTN (81763)  —– > 2311111  >>>> Hit Gateway >>> Translates to 2905 >>> dialpeer to reach CUCM >> Picks up the phone x2905 >>> Both Calling and Called party hear silence >>> Call drops in 8 secs

Some information off the gateway was something like this:

voice service voip
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
supplementary-service h450.12
fax protocol t38 ls-redundancy 2 hs-redundancy 2 fallback none
h323
emptycapability
h225 id-passthru
h225 connect-passthru
session transport udp
h245 passthru tcsnonstd-passthru
sip
bind control source-interface FastEthernet0/1
bind media source-interface FastEthernet0/1

!

voice class codec 1
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 g729r8
!
!
!

interface FastEthernet0/0
ip address 192.168.212.4 255.255.255.240
ip access-group H323-Security-In in
duplex auto
speed auto
h323-gateway voip bind srcaddr 192.168.212.4
service-policy output QoS-LAN-Policy
!
interface FastEthernet0/1
ip address 94.x.x.194 255.255.255.248
ip access-group SIP-Security-In in
ip access-group SIP-Security-Out out
duplex auto
speed auto
auto qos voip trust
no cdp enable
service-policy output AutoQoS-Policy-Trust

!

dial-peer voice 50 voip
description **Incoming Call from SIP Trunk to CUCM**
translation-profile incoming SIP-CALLS-IN
preference 1
redirect ip2ip
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target ipv4:146.x.x.200
incoming called-number .%
dtmf-relay rtp-nte
no vad
!

dial-peer voice 60 voip
description **Outgoing Call to SIP Trunk**
translation-profile outgoing SIP-CALLS-OUT
huntstop
preference 5
destination-pattern 8.T
voice-class codec 1
voice-class sip dtmf-relay force rtp-nte
session protocol sipv2
session target ipv4:146.x.x.200
dtmf-relay rtp-nte
no vad
!
dial-peer voice 31 voip
description *** Outbound calls from CUCM system ***
huntstop
redirect ip2ip
voice-class codec 1
incoming called-number 8T
no vad
!

I ran some traces but the issue was not clear as I was getting cause code = 16 normal call clearing. I followed the following steps to resolve the issue:

Step#1:

At Call manager their MTP and Transcoder were in same group which is not a good design approach. MTP and Transcoder should always be in different MRGs so that Call manager doesn’t use a Transcoder where an MTP is required as a Transcoder cannot do g729-g729. I made these changes:

MRG-GW-MTP >> This contains SW MTP at Gateway only
MRG-CUCM-MTP >> This contains CUCM SW MTP
MRG-Gateway >> GW-CON & GW-Xcode (both hardware)
MRG-HQ >> ANN_2, CFB_2, MOH_2

At Gateway:
MRGL-GW  >> MRG-GW-MTP , MRG-CUCM-MTP ,  MRG-Gateway, MRG-HQ

HQ:

MRGL-HQ >> MRG-GW-MTP , MRG-CUCM-MTP, MRG-HQ

Step#2:

Removed the SIP bind commands. I tried pinging fa0/1 to CUCM which failed so I removed the binding and left it on IOS to pick closest LAN interface to CUCM and WAN interface for going outside

Step#3:

Under voice services voip – – added allow-connections h323 to h323 and removed redirect ip2ip. We should not need this command will redirect SIP phone calls to SIP phone calls.

Step#4:

Ran the following debugs:

debug voip ccapi inout
debug cch323 all
debug h225 asn1
debug h245 asn1
debug ip tcp trans
debug ccsip all

Collected debugs in the following manner:

Router(config)# service sequence
Router(config)# service timestamps debug datetime localtime msec
Router(config)# logging buffered 10000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router(config)# voice iec syslog

Router(config)#service timestamps log datetime localtime msec

Router# term len 0
<Enable session capture to txt file in terminal program.>
Router# sh logg

Step#5:

The debugs were huge but I could see
045897: *Sep  3 20:46:57.975: TCP0: ACK timeout timer expired
045898: *Sep  3 20:47:05.679: //-1/xxxxxxxxxxxx/H323/cch323_process_carrier_update: Registered = 0, Event = 1, Reason = 2
045899: *Sep  3 20:47:05.907: //-1/xxxxxxxxxxxx/H323/cch323_ct_main: SOCK 3 Event 0x1
045900: *Sep  3 20:47:05.907: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: owner_data=0x4AE82D10, len=2, msgPtr=0x4A8F8D78
045901: *Sep  3 20:47:05.907: //-1/xxxxxxxxxxxx/H323/cch323_gw_process_read_socket: Received msg for H.245
045902: *Sep  3 20:47:05.907: h245_decode_one_pdu: more_pdus = 0, bytesLeftToDecode = 2
045903: *Sep  3 20:47:05.907: H245 MSC INCOMING ENCODE BUFFER::= 4A40
045904: *Sep  3 20:47:05.911:
045905: *Sep  3 20:47:05.911: H245 MSC INCOMING PDU ::

value MultimediaSystemControlMessage ::= command : endSessionCommand : disconnect : NULL

Observed no capability exchange when the call connects,  the endSession is being sent by the far h323 side because h245 negotiation isn’t occurring.

Further down the lines found  this:

163432: *Sep  5 17:36:35.240: //-1/xxxxxxxxxxxx/H323/cch323_h225_receiver: Received msg of type RELEASEIND_CHOSEN
163433: *Sep  5 17:36:35.240: //9761/F1DB1EE38000/H323/release_ind: Disconnect cause 16 location code 0
163434: *Sep  5 17:36:35.240: //-1/xxxxxxxxxxxx/H323/h323_set_release_source_for_peer: ownCallId[9761], src[4]
163435: *Sep  5 17:36:35.240: //9761/F1DB1EE38000/H323/cch323_h225_receiver: RELEASEIND_CHOSEN: src address = 192.168.212.4; dest address = 192.168.212.1
163436: *Sep  5 17:36:35.240: //9761/F1DB1EE38000/H323/run_h225_sm: Received event H225_EV_RELEASE_IND while at state H225_WAIT_FOR_H245

Noticed SIP provider is doing early-offer (note the SDP in the INVITE).  When this happens, CUBE needs to do fast-start on the outbound h323 leg to CM.  CM is not negotiating FS here.  I Checked the ‘Enable Inbound Fast Start’ box on CM under the CUBE’s H323 gateway config.

Also, observed that capabilities aren’t exchanged when the H245 TCP channel is opened up. Unchecked ‘Wait for far end h.245 capability exchange’ at the gateway config under CUCM. Reset the gateway.

This fixed the issue.

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.