Mar 25

Poor Voice Quality. Is it My problem or the Telco’s?

Quite often in the voice world we are pointed at and told that our system doesn’t work, call quality is poor, the caller’s voice drops out, calls are being disconnected randomly etc. Then we have to go and decipher what is really going on and isolate the issue so we can determine where the fault lies within the network… or perhaps outside the network.

Rcvr Lost counter on an IP Phone simply states that the phone expected to receive x amount of packets and only receive y amount of packets, the difference being the RCVR Lost counter. How does the phone know what to expect? Well RTP is a stream of organised sequential packets, each packet has a sequential number associated to it.. If RTP packet number 1002 was lost along the way, then the phone would receive RTP packet 1001 and then 1003… the phone would be asking.. Hey where was RTP packet 1002? And then notch up the RCVR Lost counter. With enough packets lost in a RTP stream.. The callers now start to experience poor quality with words dropping out etc.

Of course this is our problem until proven otherwise, Telcos never want to investigate into the problem first.. I’ve outlined the process of what I undertook to essentially clear the phone system of any wrong doing and force the Telco to take a closer look at the issue.

First of all, this is a SIP ITSP connection.. I have a Cisco 2901 ISR acting as a CUBE, with CUCM sitting behind the CUBE.

1. Enable web access to the phone. View the phone from the web and select stream 1. This is the primary conversation. There will be a few counters in here.. But we interested in RCVR Lost counter and the customer is complaining about not being able to hear callers, as their voice drops in and out, hence we look at the incoming stream. If the RCVR Lost counter has any number higher then ’1′ then we have a potential issue.

2. Now lets log into the CUBE. We are looking for packets received and packets sent for the call conversation. These should exactly match the phone. Use the following command on the CUBE to view packets in / out. HOSTNAME# show call active voice brief

call_active_voice_bri
In the above output, you can see between the Inbound and outbound call legs (same Call IDs), the rx (received) packet count on the inbound call leg exactly matches the tx (transceive) packet count on the outbound call leg. (The yellow highlight represents the call flow inbound and the Red underline represents the call flow outbound.

When the rx and tx are matching, this indicates the CUBE is not dropping any packets in the RTP stream. So we must look further out to the Telco.

4. Also check the Switching interfaces for lost packets, this is quite rare, but worth verifying to ensure switch ports or QoS are not dropping packets etc.

5. Lets take a packet capture on the outside interface of the CUBE. We want to do this to explicitly identify if the any RTP packets have been lost before arriving at the CUBE. We can also playback the RTP stream in wireshark to listen for the defect in the voice.

6. To capture packets on the CUBE follow the below. There is also a great article, which I have linked below that expands on capturing packets.

(config)# monitor capture buffer BUF size 2048 max-size 1518 linear

(config)# ip access-list extended RTP
(config-ext-nacl)# permit udp any any range 16384 32767
(config-ext-nacl)# permit tcp any any eq 5060
(config-ext-nacl)# permit udp any any eq 5060

(config)# monitor capture buffer BUF filter access-list RTP

Select the interface of the capture point. Also select the switching plan.. Which should be cef and not process.

(config)# monitor capture point ip cef POINT gigabitethernet 0/1 both

(config)# monitor capture point associate POINT BUF

(config)# monitor capture point start POINT

(config)# monitor capture point stop POINT

(config)# monitor capture buffer BUF export tftp://10.1.1.1/BUF.pcap

Delete capture point and capture buffer

(config)# no monitor capture point ip cef POINT fastEthernet 0 both
(config)# no monitor capture buffer BUF

7. Now we can open the stream in wireshark. If the stream is g711u/alaw then wireshark will have no problems analysing the RTP stream and playing it back to you. If the stream is G729 however, I’ll add a note onto the bottom of this blog to take you through decoding g729, actually I’ll add this is as a separate blog entry.

8. Open the PCAP file in wireshark. Navigate to Telephony -> RTP -> RTP Streams. This will display the captured RTP Streams.

rtp_streams_wireshark

We can also see from here that the inbound call leg for the external facing interface is displaying lost packets and a high jitter number. These lost packets are known because the RTP stream is sequential.. Hence the CUBE knows how many packets it should have received vs the packets is has received. In this case we can send this result to the Telco as this definitively states the issue lies before the one-premise CUBE processes the RTP Stream.

We can also play the stream to hear for any missing voice etc. Select the ‘Analyze’ button. This will display a window with more statistics for the RTP Stream.

rtp_streams_analyze

No select Play Stream. This will playback the stream.

rtp_streams_play

Link to capturing packets on Cisco IOS Router.
www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-embedded-packet-capture/116045-productconfig-epc-00.html

Mar 23

SIP Calls Disconnecting After 30 Minutes – ITSP

Having issues with calls being disconnected after the Min Session Timer expires, which by default on a Cisco UC system is 30 minutes. I found the Session-Expires SIP header was not being passed through by the Cisco CUBE. Therefore the 200 OK Message also did not contain the Session-Expires SIP Header back to the ITSP. As the ITSP did not receive the Session-Expires SIP Header the return 200 OK message, the call will be torn down (by the ITSP) after the Session_Expires timer expires (that was a mouth full).

Summary of what Users will see.

Call ends 29:59sec, the remote device (PSTN) will disconnect, however the Jabber Client (in my case) remained established, however obviously not connected to anything. The User then had to hangup the call.

To resolve this and allow the CUBE to effectively be transparent in SIP session timer refreshing process, we need to add the following command to the Voice Services VOIP -> SIP menu or to the Dial-Peer.

*** Global ***

geneaic2vg001(config)#voice service voip
geneaic2vg001(conf-voi-serv)#sip
geneaic2vg001(conf-serv-sip)#session refresh

*** Dial-Peer ***

geneaic2vg001(config)#dial-peer voice 1
geneaic2vg001(config-dial-peer)#voice-class sip session refresh

****** BEFORE THE CHANGE *******

Mar 23 10:31:45.248: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
UPDATE sip:0232282750@192.168.240.20:5060 SIP/2.0
Via: SIP/2.0/UDP 210.193.202.100:5060;branch=z9hG4bKhee5hq103g3h299jm431cmsp90n13.1
From: <sip:0428842486@210.193.202.4;user=phone>;tag=1640860859-1490224603520-
To: “282282750 282282750″<sip:0232282750@macquarietelecom.com;user=phone>;tag=66B126F4-1974
Call-ID: BW101643520230317-1846521292@210.193.202.4
CSeq: 1009217731 UPDATE
Contact: <sip:0428842486@210.193.202.100:5060;transport=udp>
Supported: timer
Min-SE: 1800
Session-Expires: 1800;refresher=uac
Max-Forwards: 29
Content-Length: 0

Mar 23 10:31:45.252: //1258857/7263E0D597B2/SIP/Msg/ccsipDisplayMsg:
Sent:
UPDATE sip:0232282750@192.168.240.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.240.20:5060;branch=z9hG4bKA2A101A89
From: <sip:+61428842486@macquarietelecom.com>;tag=66B126B8-570
To: <sip:0232282750@192.168.240.10>;tag=9418806~1fee70d6-16c8-4723-9338-a8bd4c2554c2-28985743
Date: Wed, 22 Mar 2017 23:16:43 GMT
Call-ID: 726519BD-E8C11E7-97B8AB1C-AE5BD661@192.168.240.20
User-Agent: Cisco-SIPGateway/IOS-15.5.1.T2
Max-Forwards: 70
Supported: timer,resource-priority,replaces,sdp-anat
Timestamp: 1490225505
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 102 UPDATE
Contact: <sip:+61428842486@192.168.240.20:5060>
Min-SE: 1800
Content-Length: 0

Mar 23 10:31:45.252: //1258856/7263E0D597B2/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 210.193.202.100:5060;branch=z9hG4bKhee5hq103g3h299jm431cmsp90n13.1
From: <sip:0428842486@210.193.202.4;user=phone>;tag=1640860859-1490224603520-
To: “282282750 282282750″<sip:0232282750@macquarietelecom.com;user=phone>;tag=66B126F4-1974
Date: Wed, 22 Mar 2017 23:31:45 GMT
Call-ID: BW101643520230317-1846521292@210.193.202.4
Server: Cisco-SIPGateway/IOS-15.5.1.T2
CSeq: 1009217731 UPDATE
Allow-Events: telephone-event
Contact: <sip:0232282750@192.168.240.20:5060>
Supported: timer
Content-Length: 0

Mar 23 10:31:45.256: //1258857/7263E0D597B2/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.240.20:5060;branch=z9hG4bKA2A101A89
From: <sip:+61428842486@macquarietelecom.com>;tag=66B126B8-570
To: <sip:0232282750@192.168.240.10>;tag=9418806~1fee70d6-16c8-4723-9338-a8bd4c2554c2-28985743
Date: Wed, 22 Mar 2017 23:31:45 GMT
Call-ID: 726519BD-E8C11E7-97B8AB1C-AE5BD661@192.168.240.20
Server: Cisco-CUCM11.5
CSeq: 102 UPDATE
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-ID: 000066cd00105000a00000059a3c7800;remote=24d15a06715421e863228f8ab9418806
P-Asserted-Identity: “Ben Morgan” <sip:2750@192.168.240.10>
Remote-Party-ID: “Ben Morgan” <sip:2750@192.168.240.10>;party=called;screen=yes;privacy=off
Contact: <sip:0232282750@192.168.240.10:5060>;+u.sip!devicename.ccm.cisco.com=”CSFBENMORGAN”;video;bfcp
Content-Length: 0

****** AFTER THE CHANGE *******

Mar 23 01:08:37.492: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
UPDATE sip:0232282750@192.168.241.20:5060 SIP/2.0
Via: SIP/2.0/UDP 210.193.202.100:5060;branch=z9hG4bK13p7q400b01053t5s670cms1eq4b3.1
From: <sip:0428842486@210.193.202.4;user=phone>;tag=1132754884-1490226813863-
To: “282282750 282282750″<sip:0232282750@macquarietelecom.com;user=phone>;tag=5C0C230-1AB1
Call-ID: BW105333863230317-1887904559@210.193.202.4
CSeq: 1010322902 UPDATE
Contact: <sip:0428842486@210.193.202.100:5060;transport=udp>
Supported: timer
Min-SE: 1800
Session-Expires: 1800;refresher=uac
Max-Forwards: 29
Content-Length: 0

Mar 23 01:08:37.492: //667358/97DC18C3A58D/SIP/Msg/ccsipDisplayMsg:
Sent:
UPDATE sip:0232282750@192.168.240.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.241.20:5060;branch=z9hG4bK892821863
From: <sip:+61428842486@macquarietelecom.com>;tag=5C0C20C-15FA
To: <sip:0232282750@192.168.240.10>;tag=9427326~1fee70d6-16c8-4723-9338-a8bd4c2554c2-28987887
Date: Wed, 22 Mar 2017 23:53:33 GMT
Call-ID: 97DD5113-E9111E7-A593BCA3-13A15289@192.168.241.20
User-Agent: Cisco-SIPGateway/IOS-15.5.1.T2
Max-Forwards: 70
Supported: timer,resource-priority,replaces,sdp-anat
Timestamp: 1490227717
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 102 UPDATE
Contact: <sip:+61428842486@192.168.241.20:5060>
Min-SE: 1800
Session-Expires: 1800;refresher=uac
Content-Length: 0

Mar 23 01:08:37.496: //667357/97DC18C3A58D/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 210.193.202.100:5060;branch=z9hG4bK13p7q400b01053t5s670cms1eq4b3.1
From: <sip:0428842486@210.193.202.4;user=phone>;tag=1132754884-1490226813863-
To: “282282750 282282750″<sip:0232282750@macquarietelecom.com;user=phone>;tag=5C0C230-1AB1
Date: Thu, 23 Mar 2017 00:08:37 GMT
Call-ID: BW105333863230317-1887904559@210.193.202.4
Server: Cisco-SIPGateway/IOS-15.5.1.T2
CSeq: 1010322902 UPDATE
Allow-Events: telephone-event
Contact: <sip:0232282750@192.168.241.20:5060>
Session-Expires: 1800;refresher=uac
Require: timer
Supported: timer
Content-Length: 0

Mar 23 01:08:37.500: //667358/97DC18C3A58D/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.241.20:5060;branch=z9hG4bK892821863
From: <sip:+61428842486@macquarietelecom.com>;tag=5C0C20C-15FA
To: <sip:0232282750@192.168.240.10>;tag=9427326~1fee70d6-16c8-4723-9338-a8bd4c2554c2-28987887
Date: Thu, 23 Mar 2017 00:08:37 GMT
Call-ID: 97DD5113-E9111E7-A593BCA3-13A15289@192.168.241.20
Server: Cisco-CUCM11.5
CSeq: 102 UPDATE
Allow-Events: presence, kpml
Supported: X-cisco-srtp-fallback
Supported: Geolocation
Session-Expires: 1800;refresher=uac
Require: timer
Session-ID: 0000190000105000a00000059a3c7800;remote=3062c55c0330af1676d56a3ab9427326
P-Asserted-Identity: “Ben Morgan” <sip:2750@192.168.240.10>
Remote-Party-ID: “Ben Morgan” <sip:2750@192.168.240.10>;party=called;screen=yes;privacy=off
Contact: <sip:0232282750@192.168.240.10:5060>;+u.sip!devicename.ccm.cisco.com=”CSFBENMORGAN”;video;bfcp
Content-Length: 0

As we can now see the CUBE passes the Session-Expires SIP Header through to the CUCM Server. The call can now keep refreshing and remain up long past 30 mins.

Oct 15

SIP VOIP Dial-Peer Resiliency on IOS Gateway

Configuring resiliency into UC Voice gateway connecting to a CUCM Cluster via SIP Trunks. Typically we would configure retry timers and counts to force the IOS Gateway to route via lower preference dial-peers. With the introduction of SIP Options, we can now effectively shut the dial-peer down (busy-out) if the IOS Gateway cannot reach the CUCM Server within the configured thresholds. This is a proactive method to ensure calls are not being delayed toward the CUCM Cluster. Change the SIP Options Keepalive Up/Down timers to suit your requirements.

I’ve listed below the general Voice Class and relevant dial-peer configuration.

Voice Class

voice class sip-options-keepalive 1
 down-interval 40
 up-interval 20

Dial Peer

dial-peer voice 10 voip
 preference 1
 destination-pattern 0212348[12]..
 session protocol sipv2
 session target ipv4:192.168.41.20
 incoming called-number .
 voice-class codec 1
 voice-class sip options-keepalive profile 1
 dtmf-relay rtp-nte
 no vad
dial-peer voice 11 voip
 preference 2
 destination-pattern 0212348[12]..
 session protocol sipv2
 session target ipv4:192.168.51.20
 incoming called-number .
 voice-class codec 1
 voice-class sip options-keepalive profile 1
 dtmf-relay rtp-nte
 no vad

Verify

To verify both dial-peers are operational run the below cmd.

show dial-peer voice summary

Cisco sip-options

Jul 10

Mobile Voice Access (MVA) – Setup Start to Finish

Mobile Voice Access (MVA) essentially allows authorised users to relay or bounce calls off a CUCM Cluster toward the PSTN. Benefits for this is the user’s calling number is masked by his/her office extension/DID phone number. MVA couple with Single Number Reach (SNR), also allows the called party to return the call to the masked office extension/DID phone number, the CUCM Cluster will then route the call to the mobile (SNR Destination).

User Requirements

1. Ensure the source PSTN phone is configured as a Remote Destination in CUCM.
2. The User PIN is known.
3. Mobile Voice Access is enabled for the User.

The workings of MVA

1. A call is placed from a mobile phone to the configured MVA Phone Number (0255551234).
2. This will match a pots dialpeer. This pots dialpeer will be associated to the MVA Service on the Cisco ISR.
3. The MVA service initiates the MVA IVR on CUCM. If the mobile phone number matches a remote destination, the IVR will prompt you a PIN.
4. Once authenticated, the user will have the option to Dial a number. (Generally this is option 1, following by the PSTN number).
5. CUCM now request that the Cisco ISR forward the call to the MVA phone number (extension 1234). Now if the Cisco ISR doesn’t have a dialpeer matching this MVA extension the Call will simply disconnect.
6. If the dialpeer matches the MVA extension, the call is forwarded. In debugs, you will see the called number being the MVA extension, with a diversion header containing the PSTN number the user called via the MVA IVR menu.
7. The Remote Destination Profile must have access to the called PSTN number. This is the DEVICE CSS field. The REROUTING CSS field is used for SNR.
8. When using SIP and the Cisco ISR is a CUBE, ensure the source interface is known to the CUCM Cluster.

Configuring MVA

CUCM side Configuration

Lets go through and set some of the Service Parameters.

Service Parameters -> Cisco CallManager -> Clusterwide Parameters (System – Mobility)

Enable Mobile Voice Access = “True”
Mobile Voice Access Number = “1234″
Matching Caller ID with Remote Destination = “Partial Match”
Number of Digits for Caller ID Partial Match = “7″
System Remote Access Blocked Numbers = “0000, 000″ (OPTIONAL)

Cisco Mobile Voice AccessMedia Resources -> Mobile Voice Access

Mobile Voice Access Directory Number = “1234″
Mobile Voice Access Partition = “AU_PHONE_PT”
Selected Locales = “English United States”

Cisco Mobile Voice AccessUser Management -> End User

Enable Mobility = “Checked”
Enable Mobile Voice Access = “Checked”

Cisco Mobile Voice AccessDevice -> Device Settings -> Remote Destination Profile

Create a new Remote Destination Profile and completed the required fields. Important to note is the Calling Search Space and the User ID Field. The Line number should reflect the same extension as the User’s office extension. (Essentially this is a shared line setup)

Cisco Mobile Voice AccessDevice -> Remote Destination

Create a new Remote Destination and associate to the Line configured on the Remote Destination Profile. Ensure the Destination Number is in the correct format, as you would when you dial the number from an Internal extension. As you can see I have prefixed a ’0′ to cater for my PSTN Access Code.

Cisco Mobile Voice AccessCisco IOS Side

Steps are to configure the Application/Service. Then create two dialpeers, one for inbound and the second for outbound.

application
  service mva http://10.10.10.1:8080/ccmivr/pages/IVRMainpage.vxml

dial-peer voice 10 pots
  description ** MVA IVR **
  service mva
  direct-inward-dial
  incoming called-number 0255551234$

dial-peer voice 100 voip
  description ** CUCM MVA **
  destination-pattern 1234
  session protocol sipv2
  session target ipv4:10.10.10.1
  voice-class sip bind control source-interface FastEthernet0/0
  voice-class sip bind media source-interface FastEthernet0/0
  dtmf-relay rtp-nte
  voice-class codec 6
  no vad

NOTE: Don’t forget to check if the Mobile Voice Access service has been activated under Unified Serviceability. This service is not included in the “Set Default” services button, so you will have to manually click on the service radio button and activate.

May 15

Fax Not Answering on ATA190

Come across a fax issue with an ATA190 device. The issue was the fax machine wouldn’t answer any calls. I could see the ATA190 would be in a ‘ringing’ state, however the fax machine wouldn’t budge. The calling endpoint would just ring out.

Checking the setting on the ATA190 as per below, the Ring Voltage set to 85 V and Ring Frequency set to 20 Hz.

Cisco ATA190
All that needed to be done in this case was to adjust both the Ring Voltage and Ring Frequency for the Fax Machine to essentially be compatible and pickup the incoming call. Thank you TAC.

On ATA190 web GUI, navigate to Voice -> Regional -> Ring and Call Waiting Tone Spec

Modify the below values, save the configuration, then reboot the ATA190 device.

Ring Voltage : 70V
Ring Frequency : 25 Hz

Feb 17

Multiple Patterns for VOIP Dial Peers

To make life easier configuring a Cisco Voice Gateway with an organisation that has multiple inbound number ranges, we can group the number ranges together and then apply the group to a single dial-peer saving lines of extra code.

First is to create a voice class e164-pattern-map, from the sub-menu we need to enter the number ranges as you would normally on a dial-peer using regex expressions. The second step is to apply the voice class to a dial-peer.

voice class e164-pattern-map 1
e164 296451[016]..
e164 296527[6-9]..
e164 2963268..
e164 2965145..

dial-peer voice 2 voip
description ## PSTN INBOUND ##
rtp payload-type nse 99
session protocol sipv2
session target sip-server
incoming called e164-pattern-map 1
voice-class codec 10
voice-class sip dtmf-relay force rtp-nte
dtmf-relay rtp-nte
fax protocol none

Nov 20

Sip Calls being Rejected – CUBE

When calling through to any of the DID number range for a customer, it was found that only a small percentage of calls were successful. The failed calls would either play an ISP announcement or just ring continuously until the timer expired.

This customer had a newly provisioned SIP Trunk to the ITSP and all was working well until this point. No changes had been made by the Internal IT. After tracing successful and failed inbound call attempts it was found the ITSP was sending additional information in the SIP SDP. The information being sent was the QoS SDP Parameters, the local CUBE was not equipped to handle/negotiate these parameters therefore the call negotiation process would fail.

Resolution was to provide the below information to the ITSP to strip the QoS SDP Parameters.

INVITE Captured during trace.

Received:
INVITE sip:2XXXXXXXX@X.X.X.X:5060 SIP/2.0
Via: SIP/2.0/UDP 203.52.1.167:5060;branch=z9hG4bKhs0g8n00eogroamlbun0.1
From: <sip:2XXXXXXXX@X.X.X.X;user=phone>;tag=866784654-1439255743666-
To: “Name”<sip:2XXXXXXXX@domain.com.au;user=phone>
Call-ID: BW111543666110815-468528800@10.83.154.184
CSeq: 220849754 INVITE
Contact: <sip:2XXXXXXXX@203.52.1.167:5060;transport=udp>
Supported: 100rel
Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE
Accept: application/media_control+xml,application/sdp,multipart/mixed
Max-Forwards: 29
Content-Type: application/sdp
Content-Length: 641

v=0
o=BroadWorks 3668715 1 IN IP4 X.X.X.X
s=-
c=IN IP4 X.X.X.X
t=0 0
a=sendrecv
a=media-release:hngl5rp9pujvivh05pvu6ibgr83pv898756s7s8auvmg62o6u724a2ur96v3nd0v1350ln1-6
a=media-release-con-addr:d6v1k1hv6hvh1002o9j0
m=audio 18064 RTP/AVP 8 0 18 96 97
c=IN IP4 X.X.X.X
b=RR:3000
b=RS:1000
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos optional remote sendrecv
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:96 AMR/8000
a=fmtp:96 mode-set=7;max-red=0
a=rtpmap:97 telephone-event/8000
a=fmtp:97 0-15
a=maxptime:40

Nov 10

Configuring an Analogue Device on the Second Port of an ATA190

To access the second port on an ATA190 device, you need to shift the device MAC Address by two digits and append the digits ’01′ to the end of the device MAC Address. Below is an example.

First Analogue Port MAC Address.

MAC Address of ATA190 is 34DBFD184921

Second Analogue Port MAC Address.

MAC Address of ATA190 is DBFD18492101 (the ’34′ has been discarded and ’01′ has been appended to the end)

Simply Add New Devices, select ATA190 then enter the required MAC Address to access the device configuration page.

Oct 20

Caller-ID SIP – Displaying Names for PSTN Callers

Calling Party’s Name is not passed through carriers, only the Calling Party’s phone number is passed through. This results in having the caller-id display as a phone number on an Internal Phone. In some cases I’ve had requests to setup a handful of key PSTN/Mobile phone numbers to resolve from phone number to display name. Below is how an example configuration piece on a Cisco IOS Gateway that I configure to resolve phone numbers to display names.


voice class sip-profiles 10
request INVITE sip-header Remote-Party-ID modify “(<sip:00408842426@.*>)(.*)” “\”Ben Morgan\” \1\2″


dial-peer voice 9500 voip
description Mobile-Name-Conversion
destination-pattern ^4…      *** Internal Extension Range
session protocol sipv2
session target ipv4:192.168.0.1    **** CUCM Subscriber Host
voice-class codec 1
voice-class sip profiles 10    **** References above SIP Profile
dtmf-relay rtp-nte
no vad

Sep 20

Faxing T.38 Relay MGCP to SIP

Not so commonly discussed area of the Voice Communication world is the T.38 Fax Relay between multiple signalling protocols. I was tasked to complete a Fax Server install into an existing Cisco UC environment. The Fax Server communicated to the CUCM via the SIP Protocol and the existing UC infrastructure inclusive of VG224 and a 2811 ISR was controlled via the MGCP protocol.

First thing first, gain connectivity between the CUCM and the Fax Server to ensure SIP is correctly working. Make a call to the fax server and you should receive the fax signalling sounds.. done.

Now lets work on the 2811 Voice Gateway. This is an ISDN Gateway controlled via the MGCP Protocol through CUCM. However we don’t need to log into CUCM to allow the T.38 Fax Relay protocol. Enable T.38 Fax Relay Globally under the Voice Services VOIP Menu.

(Config)# voice service voip
(Config-voip)# fax protocol t38 ls-redundancy 2 hs-redundanyc 0 fallback passthru g711alaw

In the above exampled I chose to fallback to Passthru method, as this is the existing method on the Voice Gateway.

Now lets enable the T.38 Fax Relay Protocol under MGCP.

(Config)# mgcp default-package fxr-package
(Config)# no fax t38 inhibit

Now lets restart the MGCP Application. *Depending your MGCP Configuration, this may disrupt existing calls.

(Config)# no mgcp
(Config)# mgcp

Faxing inbound/outbound the UC network should now be working as normal.

The VG224 configuration is exactly the same as the 2811 Voice Gateway. As organisations still have a need to fax internally, the VG224 needs the above configuration mended as well.

Below is the summary of configuration changes made.

(Config)# voice service voip
(Config-voip)# fax protocol t38 ls-redundancy 2 hs-redundanyc 0 fallback passthru g711alaw
(Config)# mgcp default-package fxr-package
(Config)# no fax t38 inhibit
(Config)# no mgcp
(Config)# mgcp