Apr 30

Cisco Jabber cannot Call out to PSTN

Migrated to SIP Carrier and experience an issue where Deskphones could call out to the PSTN, however the Cisco Jabber softphones could not. The annunciator message was played from the carrier network. The remote device (being the device across the PSTN Network) would ring once.

Tracing the SIP messages, I could see the carrier was sending back a SIP reason of “Q.850;cause=41″. Looked up the code which is “Temporary Network Failure – Try again”. So not too much help there..

I analysed the SDP being sent to the carrier from the Cisco Jabber softphone vs the Deskphone and found the video and content sharing attributes were being passed out to the Telco. This Telco connection is just an audio PSTN service, so it would not support video.

I created a new Device Pool for the SIP Trunk to the CUBE, along with a new Region and set the Video to “None”. This effectively disables Video, hence any endpoint including Cisco Jabber establishing call, will not send the Video/Content media attributes. Telco is now happy and calls proceed through the PSTN.

FYI, have pasted below the differences in the SDP.

SDP – Cisco Jabber

v=0
o=CiscoSystemsSIP-GW-UserAgent 9138 8218 IN IP4 192.168.241.20
s=SIP Call
c=IN IP4 192.168.241.20
t=0 0
m=audio 17206 RTP/AVP 8 0 18 101
c=IN IP4 192.168.241.20
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
m=video 51372 RTP/AVP 31
c=IN IP4 192.168.241.20
m=application 17458 RTP/AVP 125
c=IN IP4 192.168.241.20

SDP – Standard IP Phone (No Camera)

v=0
o=CiscoSystemsSIP-GW-UserAgent 7438 4222 IN IP4 192.168.241.20
s=SIP Call
c=IN IP4 192.168.241.20
t=0 0
m=audio 18034 RTP/AVP 8 0 18 101
c=IN IP4 192.168.241.20
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

a=ptime:20

Apr 19

MoH – SIP CUBE to ITSP without MTP

No Music to PSTN using SIP Cube toward ITSP? Using an MTP would resolve this issue, however if using an MTP was not an option, then use the below SIP Profile statement to allow Music on hold to stream toward the PSTN.

Create (or append if you are already using sip-profiles) a sip-profile voice class and add statements.

voice class sip-profiles 1
request REINVITE sdp-header Audio-Attribute modify “inactive” “sendrecv”
request ACK sdp-header Audio-Attribute modify “sendonly” “sendrecv”
response 200 sdp-header Audio-Attribute modify “sendonly” “sendrecv”

Apply the sip-profiles globally or on the Dial-Peer.

** GLOBAL**

Voice service voip
sip
sip-profiles 1

** DIAL-PEER **

Voice-class sip profiles 1

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.