Tag Archives: ios

CUBE URI-based Routing and Multiple Via Headers

Cisco introduced some pretty cool URI enhancements for CUBE from 15.4(1)T that have added some great extensions to the CUBE feature set, and specifically include some fine-grained SIP routing control.  These have been long overdue as IOS-based VoIP routing has been heavily dependent on numerical pattern matching due to Cisco’s ongoing support for H.323-style legacy configuration.

These enhancements are covered in a lovely Cisco doc here.  I’ve also blogged previously on a similar topic on how to utilize these and other new CUBE SIP features to provide Loop Prevention on CUBE.

 

To start, the basic configuration for URI dial-peer matching is somewhat trivial:

!
voice class uri voice-class-uri-tag sip|tel
    host hostname-pattern
    host ipv4:ipv4-address
    host ipv6:ipv6-address
    host dns:dns-address
    pattern uri-pattern
    user-id username-pattern
!
dial-peer voice tag voip
 session protocol sipv2
 incoming uri { from | request | to | via } voice-class-uri-tag
!

Here we see that incoming called-number is dropped and is instead routing using incoming uri.  Typically, we’d match the URI on a via header, with our voice class uri container applying a match on our preferred IP Address / DNS address.

I am referring to RFC compliant behaviour for the Via header from RFC 3261:

8.1.1.7 Via

   The Via header field indicates the transport used for the transaction
   and identifies the location where the response is to be sent.  A Via
   header field value is added only after the transport that will be
   used to reach the next hop has been selected (which may involve the
   usage of the procedures in [4]).

   When the UAC creates a request, it MUST insert a Via into that
   request.  The protocol name and protocol version in the header field
   MUST be SIP and 2.0, respectively.  The Via header field value MUST
   contain a branch parameter.  This parameter is used to identify the
   transaction created by that request.  This parameter is used by both
   the client and the server.

Here we note that a SIP Request can contain multiple Via headers.  This is used as a loop prevention mechanism for SIP Routing.  This becomes incredibly import when multiple SIP Proxies forward requests.  This is well described here for the SIP initiate.

 

With this in mind, I came across an interesting scenario recently where a call route through an ITSP’s SIP Proxy network changed without my knowledge, meaning that the Via header ordered list in the inbound INVITE changed.  This resulted in not matching my voice class uri configuration.  This stymied me at first until I noted the following for this feature:

In a scenario where multiple SIP hops are involved in a call, there would 
be multiple via headers involved, and the topmost via header of an 
incoming SIP invite represents the last hop that forwarded the SIP 
request, and the bottom-most via header would represent the originator 
of the SIP request. This feature supports matching by the last hop that 
forwarded the request (neighboringSIPentity), which is the topmost via 
header.

 

From the PDF link’s worked examples, we can see the matching will use the following behaviour:

INVITE sip:123@1.2.3.4:5060 SIP/2.0

Via: SIP/2.0/TCP 10.10.10.1:5093;branch=z9hG4bK-17716-1-0

Via: SIP/2.0/TCP 10.10.14.20:5093;branch=z9hG4bK-28280-1-0

 

In my situation, I’d been using a voice class uri that looked something like this:

!
voice class uri ITSP sip
    host ipv4:10.10.14.20
!
dial-peer voice tag voip
 session protocol sipv2
 incoming uri via ITSP
!
I would have expected the feature to consider the ordered list in decreasing priority, but the dial-peer never matched…  As per the feature description, only the “neighboringSIPentity” is considered.
Just something to note when deploying this feature in future.
#dontcalltac
Tagged , , , , , ,

ISR G2 PVDM3 Video Conferencing Deprecated

If you are in the process of preparing for the CCIE lab, you will be interested and very happy to see this!  A terrible “feature” finally put out to pasture.  So many caveats and considerations to get this to work 😦

A very good move for Cisco as they continue to migrate their video architecture.

The Feature Deprecation Announcement is below:

http://www.cisco.com/c/en/us/products/collateral/unified-communications/tdm-gateways/bulletin-c25-735945.html

 

In 2009, the Cisco® Integrated Services Routers Generation 2 (ISR G2), along with the Cisco Packet Voice Digital Signal Processor Module (PVDM3), introduced an experimental video conferencing feature with Cisco IOS® Software Release 15.1(4)M. This feature enabled the ISR G2 to provide homogeneous video switching features for selected Cisco IP phone models with resolutions of 720p or lower, such as the Cisco Unified IP Phone 7985G, 9951, and 9971. The platform was limited to video switching and did not support video mixing or overlays.

Video transcoding was also possible for a few channels (fewer than 5) for point-to-point video calls using Cisco Unified Border Element (CUBE).

While the intention was to fully support this feature via the use of a Unified Conferencing Video license, the feature was never fully productized or supported. Cisco provided limited best effort support on an as-needed basis.

This feature will be disabled with Cisco IOS Software Release 15.5(3)M. This issue is addressed with the following defect:

CSCus97643: PVDM3: Cisco IOS Software based video transcoder and conferencing commands purged.

 

The bug itself can be viewed here.

For a full list of IOS-supported features that integrate with CUCM, please see the following:

http://www.cisco.com/c/en/us/products/collateral/routers/3900-series-integrated-services-routers-isr/data-sheet-c78-729824.html

A very useful document in my opinion.

Tagged , , , , , , , , , , , ,

CUBE SIP Profiles – Normalizing Incorrect RURI/To Headers using Diversion

Had a strange requirement today.  Needed to replicate a behaviour that is apparently quiet common on Asterisk, but haven’t seen it before myself.

Our ITSP implemented a new softswitch/SBC setup that currently appears to be limiting (may just be configuration) when they “forward” a call internally within the softswitch to a trunk.

Our situation is that a client has a hybrid setup where a DID range is shared between extensions registered to their on-site CUCM cluster, and the hosted ITSP softswitch.  The inbound voice traffic is via a PRI that terminates on the client’s Cisco Voice Gateway.

This brings in the following type of call flow:

  1. Inbound traffic from ISDN
  2. Route traffic to CUCM
  3. Match DNs in Internal Partition, if not, Route Pattern back out same SIP Trunk to CUBE
  4. CUBE has registered trunk to ITSP, Loop Prevention is implemented to avoid extensions bouncing back and forth between system

External traffic is routed via ITSP, and both sides need to support 4-digit dialling between systems.

The challenge came on the softswitch side getting calls from softswitch-registered endpoints to CUCM.  The ITSP needed to provision aliases for the CUCM extensions and implement forwarding rules to the SIP Trunk SIP Account.

The result wasn’t pretty when it hit the CUBE inbound:

006846: Mar 17 21:33:56.184: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:4396594@44.55.66.77:5060 SIP/2.0
Via: SIP/2.0/UDP 55.66.77.88:5060;branch=z9hG4bK0cB81sdf867sdf7
From: “Jonathan%20%20Els” <sip:0112223333@55.66.77.88>;tag=gK0c7b172a
To: <sip:4396594@44.55.66.77>
Call-ID: 19662878_12345657@55.66.77.88
CSeq: 957845045 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Accept: application/sdp, application/isup, application/dtmf, application/dtmf-relay, multipart/mixed
Contact: “Jonathan%20%20Els” <sip:0112223333@55.66.77.88:5060;reg-info=1280c>
P-Preferred-Identity: “Jonathan%20%20Els” <sip:0112223333@55.66.77.88:5060>
Diversion: <sip:27445556666@55.66.77.88:5060>;privacy=off;screen=no; reason=unknown; counter=1
Supported: timer,100rel,precondition,replaces
Session-Expires: 1800
Min-SE: 90
Content-Length: 269
Content-Disposition: session; handling=required
Content-Type: application/sdp

v=0
o=Sonus_UAC 884721489 1041972446 IN IP4 55.66.77.88
s=SIP Media Capabilities
c=IN IP4 55.66.77.88
t=0 0
m=audio 48880 RTP/AVP 18 8 101
a=rtpmap:18 G729/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:20

There’s a lot going on (*wrong :)) here…  Let’s break it down:

  • 4396594 – Called Party information is set to the SIP Account, not the DID that the hosted-PBX user tried to dial
  • 0112223333 – Calling number is set to the DID, and in local E.164 format
  • 27445556666 – Diversion header contains the Called Party information (i.e. based on the ITSP configuration described above, this is the “forwarding Alias”).  This is already in a plus-stripped E.164 format – not routable on our CUCM at the moment.
  • Jonathan%20%20Els – Oops, whitespace is duplicated and is URL encoded.

 

So, to normalize this, we need to do the following:

  1. Copy Diversion header DID and replace in the Inbound INVITE Request URI and To headers
  2. Calling Number is localized already – no need to cater for that
  3. Called number should be normalized to localized E.164 10-digit formatting – a task we will leave to CUCM to do.
  4. Encoded URL can be ignored – CUBE will translate this natively

 

As with all normalizations, we have 2 solutions available:

  • SIP Profiles in IOS
  • Lua Scripting in CUCM

 

I was requested to solve this in SIP Profiles.  To do this, we’ll need to make use of the  Support for Conditional Header Manipulation of SIP Headers feature that was implemented in 15.1(3)T:

The Support for Conditional Header Manipulation of SIP Headers feature provides the following enhancements to Cisco UBE:

  • The ability to pass unsupported parameters present in a mandatory header from one call leg to another.
  • The ability to copy contents from one header to another header in an outgoing SIP message.

 

Unfortunately the guide contains errors… thanks Cisco.  Here’s a working configuration to meet my requirement below:

Create copy list:

!
voice class sip-copylist 2
sip-header Diversion

!

Apply to copylist to inbound dial-peer:

!
dial-peer voice 200 voip
description *** ITSP ***
session protocol sipv2
session target sip-server
destination dpg 2
destination e164-pattern-map 2
incoming called-number .
voice-class codec 1
voice-class sip options-keepalive profile 2
voice-class sip copy-list 2
dtmf-relay rtp-nte sip-kpml
no vad
!

Copy Diversion in about sip-profile, and apply to RURI and To headers:

!
voice class sip-profiles 1
request INVITE peer-header sip Diversion copy “sip:(.*)@” u01
request INVITE sip-header SIP-Req-URI modify “.*@(.*)” “INVITE sip:\u01@\1″
request INVITE sip-header To modify “.*@(.*)” “To: <sip:\u01@\1″
!

Apply to CUCM dial-peer:

!
dial-peer voice 100 voip
description *** CUCM – SAIG ***
session protocol sipv2
session server-group 1
destination dpg 1
destination e164-pattern-map 1
incoming uri via CUCM
voice-class codec 1
voice-class sip profiles 1
voice-class sip options-keepalive profile 1
dtmf-relay rtp-nte sip-kpml
no vad
!

We still need to add routing for the SIP Account to actually HIT the outbound dial-peer, so we update our CUCM e164-pattern-map accordingly:

!
voice class e164-pattern-map 1
description *** To CUCM ***
e164 4396594
!

 

The final product sent to CUCM looks  good!

 

006848: Mar 17 21:33:56.192: //2592/C9846AB38DFD/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:27445556666@192.168.1.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.254:5060;branch=z9hG4bK8EF1AD4
Remote-Party-ID: “Jonathan   Els” <sip:0112223333@mycube.local>;party=calling;screen=no;privacy=off
From: “Jonathan   Els” <sip:0112223333@myitsp.com>;tag=136DF10-11BA
To: <sip:27445556666@192.168.1.1>
Date: Thu, 17 Mar 2016 21:33:56 GMT
Call-ID: C98506DB-EBBE11E5-8E03ED66-DEC6DF88@mycube.local
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 3380898483-3955102181-2382228838-3737575304
User-Agent: Cisco-SIPGateway/IOS-15.5.2.T
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1458250436
Contact: <sip:0112223333@mycube.local:5060>
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 69
Diversion: <sip:27126575370@41.180.51.2>;privacy=off;reason=unknown;counter=1;screen=no
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 298

v=0
o=CiscoSystemsSIP-GW-UserAgent 2555 5070 IN IP4 192.168.1.254
s=SIP Call
c=IN IP4 192.168.1.254
t=0 0
m=audio 17336 RTP/AVP 18 8 101
c=IN IP4 192.168.1.254
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

All that’s remaining is the change from 27XXXXXXXXX to 0XXXXXXXXX for called party information – a simple translation in CUCM can sort that out to keep the sip-profiles clean!

 

#dontcalltac

Tagged , , , , , , , , ,

Incorrect SIP Realm – CUBE Not Responding to 401 Unauthorized

Had an issue today where we had to migrate a client as our ITSP migrated the client to a different SBC platforms.  After re-pointing, the SIP Trunk was failing to register.

The sip-ua configuration needed is pretty simple:

!
sip-ua
credentials username <myusername> password 7 <myencryptedpassword> realm myrealm.com
authentication username <myusername> password 7 <myencryptedpassword> realm myrealm.com
nat symmetric check-media-src
nat symmetric role active
registrar dns:myrealm.com expires 3600
sip-server dns:myrealm.com
!

So… what do we see?

Firstly, our SIP trunk is down:

Capture.PNG

So, we made some calls and tried to pick up an error.  The following SIP Ladder showed us a problem:

Capture2.PNG

So, the issue?  CUBE is not re-INVITEing to the ITSP, based on the supplied in the WWW-Authenticate header:

000611: Mar 17 17:11:09.936: //460/3CBC3A000000/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 44.55.66.77:5060;branch=z9hG4bK12A75C
From: “End User 1” <sip:+27456478349@myrealm.com>;tag=464B7C-1D14
To: <sip:+272347897120@myrealm.com>;tag=gK08bac03c
Call-ID: 14005099-EB9A11E5-81CCED66-DEC6DF88@192.168.1.1
CSeq: 101 INVITE
WWW-Authenticate: Digest realm=”sip-2.ITSP_1″,nonce=”f3582aaf8sdf876b596d4f56a”
Content-Length: 0

Oops!  Looks like our ITSP is still busy developing their new platform?  We’re expecting Digest realm=”myrealm.com” but are getting something else!

So, what’s our solution?

Well…  to answer that, we actually need to look at the realm usage, which is well-defined in the appropriate SIP-UA RFC:

https://tools.ietf.org/html/rfc6011#section-3.1.2

 

On the CUBE, our realm configuration is is actually needed for accommodating Multiple Registrars:

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book/voi-sip-multi-trunks.html

Most specifically, the login applied for Authorization/Authentication is well summed up here:

Determination of Authentication Details
When a SIP INVITE or SIP REGISTER request is challenged, the username and password details for authentication are determined in the following order:

  1. If the realm specified in the challenge matches the realm in the authentication configuration for a POTS dial peer, the system uses the corresponding username and password
  2. If the realm specified in the challenge doesn’t match the configured authentication for the POTS dial peer, then it will check for credentials configured for SIP UA.
  3. If the realm specified in the challenge does not match the realm configured for credentials, then it will check for authentication configurations for SIP UA.
  4. If the system does not find a matching authentication or credential for the received realm, then the request is terminated.
  5. If there is no realm specified for the authentication configuration, then the system uses the username received from the challenge to build the response message

So, in our case, we had a realm mismatch, and since only one realm was applied, and the ITSP didn’t prompt for a username in the challenge, CUBE failed the call.  This is working as designed.

The fix (besides raising this with the ITSP of course!) was to remove the realm config from the SIP User Agent configuration for authentication.  This allowed the CUBE to respond to requests successfully, as it searched the authentication configurations:

!
sip-ua
credentials username <myusername> password 7 <myencryptedpassword> realm myrealm.com
authentication username <myusername> password 7 <myencryptedpassword>
nat symmetric check-media-src
nat symmetric role active
registrar dns:myrealm.com expires 60
sip-server dns:myrealm.com
!

After being applied, the trunk immediately registered, and calls were successful.

#dontcalltac

Tagged , , ,

Troubleshooting DTMF from ISDN PSTN

Sometimes we unfortunately still have legacy requirements to support ISDN that still need to upgrade to SIP Trunking.  DTMF and even fax tones can be a pain to troubleshoot.

This guide from the Cisco Support Forums is brilliant, so I’ll just send you straight to it:

https://supportforums.cisco.com/document/148401/how-troubleshoot-dtmf-isdn-pri

I will however make one specific note from the guide that is of key importance:

If there are still doubts on the DTMF being received by the gateway or not, move ahead with “PCM Capture on ISDN” however keep in mind that there is no 3rd party tool available to decode the PCM captures. You need to involve Cisco TAC to decode the PCM captures.
With this in mind, if the debugs show you nothing, you have no other option than to go to TAC to analyze PCM.  Often this is the case for advanced Faxing tshooting over ISDN as well.

Hope this helps, it helped me a lot!

Tagged , , , ,

Implementing Loop Prevention on CUBE

We work quite a lot with a single ITSP in our smaller deployments, but keep hitting a problem with number porting.  We’re repeatedly facing a problem whereby the number porting is done up front, and often in the case of BE6K installations includes numerous number ranges, BRI’s, analog extensions etc.  Often at the time of porting we need to account for 20+ different patterns across 5 or so sites.

The problem crops up when asking for all these ported patterns/ranges in a single list to place on the CUBE.  Quickly it appears that different people requested it, the porting requests were done piecemeal, etc – long story getting all the numbers up front can become a bit tricky.  Not that there is a good reason from it.  It’s a bit of a joke.  But this is what happens.

Come to porting, and we miss a pattern or five.  Now (my favourite part), the upstream provider for our ITSP starts crying because (and wait for it)… we have brought down their network.  They can’t seem to implement loop prevention, and somehow the looping that results from an inbound INVITE only matching the intended outbound dial-peers bombs the providers Media Server – but my little 2RU 2921 stands firm.  I kid you not. 🙂

So, after laughing for about 5min, let’s implement Loop Prevention on our side.  This can be done with COR Lists (vomit), but I prefer to use the newer features in IOS 15.4+, and stick to whats prescribed in the CVD BE6K Edge document.

Here’s the dial plan config that’s pretty much completely scalable – implemented with only 2 dial peers!

 

!
voice class uri 1 sip
host ipv4:<cucm-ip-sub-primary>
host ipv4:<cucm-ip-sub-secondary>
!
voice class uri 2 sip
host ipv4:<itsp-ip>
!
voice class e164-pattern-map 1
description *** To CUCM ***
e164 <internal-dn-range1>
e164 <internal-dn-range2>
e164 <internal-dn-range3>
!
voice class e164-pattern-map 2
description *** To ITSP ***
e164 .T
!
voice class dpg 1
dial-peer 100
!
voice class dpg 2
dial-peer 200
!
voice class server-group 1
ipv4 <cucm-ip-sub-primary>
ipv4 <cucm-ip-sub-secondary> pref 1
description *** CUCM ***
!
voice class server-group 2
ipv4 <itsp-ip>
description *** ITSP ***
!
dial-peer voice 100 voip
description *** CUCM ***
session protocol sipv2
session server-group 1
destination dpg 2
destination e164-pattern-map 1
incoming uri via 1
voice-class codec 1
dtmf-relay rtp-nte sip-kpml
no vad
!
dial-peer voice 200 voip
description *** ITSP ***
session protocol sipv2
session server-group 2
destination dpg 1
destination e164-pattern-map 2
incoming uri via 2
voice-class codec 1
voice-class sip bind control source-interface <external-interface>
voice-class sip bind media source-interface <external-interface>
no vad
dtmf-relay rtp-nte sip-kpml
!

 

Some Notes:

  • The loop prevention hinges on the face that you exclude dial peers using dial-peer groups.  An absolutely fantastic feature.
  • Outbound destinations are serviced by server groups – another brilliant addition.
  • Inbound matching is done using the URI Enhancements provided in 15.x and up
  • I tend to prefer to localize E.164 in CUCM for a Central Breakout Design.  I just like the extensible nature of Called and Calling Transformations.  I believe that this is more in line with the CVD/SRND – could be debated though.

 

A possible modification could drop the server groups (the limitation is that these only support IP), and instead route using DNS SRVs.  I like this approach a lot, and try and implement as such whenever possible.

What’s lovely about this is that the skeleton never changes – I get my patterns added to the e164 pattern map, adjust my IP’s and I’m good to go.

 

Voila!  CUBE implemented in under 5min.  Hope this helps some of you out there.

 

Tagged , , , , ,

SIP SRST Dialling Fails Due to Header Addressing – CSCur95578

Haven’t been able to post in a while as my current project is keeping me very busy!

As the core multi-cluster deployment is now complete, we’ve moved on to site deployments, which has posed a significant challenge as I am attempting to streamline and automate the user and site configuration for about 3000 sites spread across 9 leaf clusters.

One of challenges was to define a working SRST template to account for some very specific business requirements, including differentiated Class of Restriction in SRST for older SCCP and newer SIP models.  We also opted not to pursue SRST Manager, so a balance was struck between feature support and limiting configuration overhead, as the client’s support  team is quite small for the scope of deployment, and simplicity was the key.  This was all finalized and lab-tested and we were ready to proceed to site deployments and testing SRST on live sites.

However, at the first site test SRST failed!  Problem description was:

  • MGCP fallback was successful
  • SCCP and SIP phones registered successfully
  • SCCP devices were able to make/receive external calls
  • SIP devices could make external calls, but could not receive external calls
  • SIP devices could not make/receive internal calls
  • When making a call from a SIP device, no ring-back was heard, and the remote party’s phone didn’t ring.

Based on the problem description, I was immediately able to determine the following:

  1. Problem was a SIP signalling issue
  2. No ring back – calling party was never receiving 18X
  3. No called party ringing – remote party never received, or wasn’t processing the INVITE from IOS gateway

Very strange, as this was working in the lab!

I looked at my basic voice service voip and voice register global configuration, and could not find anything a-miss:

!
voice service voip
allow-connections sip to sip
allow-connections h323 to h323
allow-connections sip to h323
allow-connections h323 to sip
supplementary-service sip refer
supplementary-service sip moved-temporarily
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711alaw
sip
registrar server
bind all source <loopback-interface>
g729 annexb-all
asymmetric payload full
!

!
voice register global
timeouts interdigit 5
system message Service Interruption
max-dn <#>
max-pool <#>
timezone 29
dialplan-pattern 1 0XXXXXX… extension-length 4 extension-pattern X… demote
!

So, time to look at the call flow signalling…  I pulled debug ccsip messages from the gateway

Sample SIP Trace

005298: Oct 29 10:24:38.192: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
INVITE sip:0223333733@192.168.1.1;user=phone SIP/2.0
Via: SIP/2.0/UDP 10.1.2.3:5060;branch=z9hG4bK03efbc86
From: “Mr End User” <sip:0223333780@192.168.1.1>;tag=c47295a8075762c24ee36b42-7321fcdb
To: <sip:0223333733@192.168.1.1>
Call-ID: c47295a8-075701fc-0adbec71-182993ef@10.1.2.3
Max-Forwards: 70
Date: Thu, 29 Oct 2015 10:24:37 GMT
CSeq: 101 INVITE
User-Agent: Cisco-CP7841/10.3.1
Contact: <sip:d029fdee-4ea8-b62e-793a-8db0132ff40f@10.1.2.3:5060;transport=udp>
Expires: 180
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER,REGISTER,UPDATE,SUBSCRIBE,INFO
Remote-Party-ID: “Mr End User” <sip:0223333780@192.168.1.1>;party=calling;id-type=subscriber;privacy=off;screen=yes
Supported: replaces,join,sdp-anat,norefersub,resource-priority,X-cisco-srtp-fallback,X-cisco-xsi-8.5.1
Allow-Events: kpml,dialog
Content-Length: 350
Content-Type: application/sdp
Content-Disposition: session;handling=optional

v=0
o=Cisco-SIPUA 19428 0 IN IP4 10.1.2.3
s=SIP Call
t=0 0
m=audio 31580 RTP/AVP 9 0 8 116 18 101
c=IN IP4 10.1.2.3
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:116 iLBC/8000
a=fmtp:116 mode=20
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

005327: Oct 29 10:24:38.196: //65387/17A79D7C8B2A/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.1.2.3:5060;branch=z9hG4bK03efbc86
From: “Mr End User” <sip:0223333780@192.168.1.1>;tag=c47295a8075762c24ee36b42-7321fcdb
To: <sip:0223333733@192.168.1.1>
Date: Thu, 29 Oct 2015 10:24:38 GMT
Call-ID: c47295a8-075701fc-0adbec71-182993ef@10.1.2.3
CSeq: 101 INVITE
Allow-Events: kpml, telephone-event
Server: Cisco-SIPGateway/IOS-15.4.3.M1
Content-Length: 0
005361: Oct 29 10:24:38.200: //65388/17A79D7C8B2A/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:0223333733@10.2.3.4:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK4001264
Remote-Party-ID: “Mr End User” <sip:3780@10.0.0.1>;party=calling;screen=yes;privacy=off
From: “Mr End User” <sip:3780@10.0.0.1>;tag=A32FEE28-18F2
To: <sip:0223333733@10.2.3.4>
Date: Thu, 29 Oct 2015 10:24:38 GMT
Call-ID: 17A8D664-7D5E11E5-8B30FF52-8FAD66E0@10.0.0.1
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
Cisco-Guid: 0396860796-2103316965-2334850898-2410505952
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M1
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1446114278
Contact: <sip:3780@10.0.0.1:5060>
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 324

v=0
o=CiscoSystemsSIP-GW-UserAgent 7919 527 IN IP4 10.0.0.1
s=SIP Call
c=IN IP4 10.0.0.1
t=0 0
m=audio 24612 RTP/AVP 0 8 18 101
c=IN IP4 10.0.0.1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

005363: Oct 29 10:24:38.700: //65388/17A79D7C8B2A/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:0223333733@10.2.3.4:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.1:5060;branch=z9hG4bK4001264
Remote-Party-ID: “Mr End User” <sip:3780@10.0.0.1>;party=calling;screen=yes;privacy=off
From: “Mr End User” <sip:3780@10.0.0.1>;tag=A32FEE28-18F2
To: <sip:0223333733@10.2.3.4>
Date: Thu, 29 Oct 2015 10:24:38 GMT
Call-ID: 17A8D664-7D5E11E5-8B30FF52-8FAD66E0@10.0.0.1
Supported: 100rel,timer,resource-priority,replaces
Min-SE: 1800
Cisco-Guid: 0396860796-2103316965-2334850898-2410505952
User-Agent: Cisco-SIPGateway/IOS-15.4.3.M1
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1446114278
Contact: <sip:3780@10.0.0.1:5060>
Expires: 180
Allow-Events: kpml, telephone-event
Max-Forwards: 69
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 324

v=0
o=CiscoSystemsSIP-GW-UserAgent 7919 527 IN IP4 10.0.0.1
s=SIP Call
c=IN IP4 10.0.0.1
t=0 0
m=audio 24612 RTP/AVP 0 8 18 101
c=IN IP4 10.0.0.1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

Suddenly the problem was immediately apparent, but made no sense!  So, what is happening here?

  • Side A phone IP : 10.1.2.3
  • Side B phone IP : 10.2.3.4
  • IOS Loopback IP : 192.168.1.1
  • IOS Ethernet IP : 10.0.0.1

As we can see from the trace:

  1. Despite the Loopback binding, the IOS device was sourcing outbound SIP traffic from the outbound physical interface, instead of the loopback
  2. Outbound INVITE is sent to Side B, but is clearly never processed, as IOS never receives a 1XX Trying/Ringing.  As a result, IOS never sends on a 18X Ringing to Side A, and ring back is never played to the calling party
  3. Multiple INVITEs are re-sent to Side B, which never responds to the call (call setup eventually ended with a  CANCEL from Side A)

Why is this happening!?  Well, the SRST reference in the phone was the Loopback IP, and as a result, the phones registered to the Loopback interface in SRST mode.  As such, they are only going to respond to call setup signalling sourced from this IP – Side B is effectively ignoring the call setup request.

As I’m sure you can guess, this behaviour is not expected, and I immediately thought this was a bug.  What had changed between lab testing and production?  IOS version…  The remote deployment teams had been deploying routers without an upgrade to the Cisco-recommended version that we had tested in the lab.  To validate my conclusion, I looked on cisco.com Bug Search, and got a 1st time hit on the following:

https://tools.cisco.com/bugsearch/bug/CSCur95578

CME-SIP call fails when sip bind is applied under voice service voip

CSCur95578

Description

Symptom:
When a voice gateway falls back to the SRST mode, system message that is configured in the “voice register gloal” section is not displayed on SIP phones

Conditions:
– Voice gateway use the loopback IP address as CME source address
– SIP phones lost the communication to Cisco Unified Call Manager and fall back to SRST mode

Workaround:
Downgrade to an IOS without the fix for CSCup30934 Use a physical IP as CME source address.

We upgraded to the recommended IOS version and re-tested – with immediate positive results.

Conclusion:

This defect outlined a very important point regarding SRST/CME.  In non-trivial deployments with multiple LAN interfaces (or if there are WAN-remote registration devices), always source traffic from a bound interface when traffic is destined to internal devices.  In our case, I could have removed the bind, but the gateway was redundantly connected to 2 core switches with Layer 3 links, which was always going to pose a problem.  Almost without fail, a loopback is the preferred option.

However… some may correctly comment that this may break ITSP call flows if a local SIP Trunking solution is in use – it will, and must be accounted for.  In my base the remote site used ISDN technology, but when a SIP Trunking solution is in use, the ITSP-facing dial peers should be referenced with voice-class sip bind commands.

Great links on this topic here:

 

#dontcalltac

Tagged , , , ,

Forcing MTP Killed the Mid-Call

There’s a common misconception with Cisco SIP trunking that the desperate “Forced MTP” will always solve no audio, one-way audio, DTMF inter-working and every other media negotiation failure under the sun. This is unfortunately not always the case.

forced-mtp

On a deployment completed quite a while back, we faced a no-audio media issue in 9.1.x (determined to be due to CSCup07303) where I initially raised the white flag due to time constraints and forced the MTP on the SIP Trunk.  The issue arose due to a UCCX re-direct for an after-hours call flow.  Not the topic for discussion here, but just some background information (more on this later).


Fast forward 5 months, and 3 remote sites were deployed for the same system, following a CBO SIP Trunking solution via the Campus site.  After deploying the 3rd site, the client complained that inbound calls were failing and I was asked to investigate.

I reviewed the call flow to find a classic INVITE/UPDATE/Re-INVITE scenario, with CUCM ending the call with a BYE due to a frustrated end user hanging up (Reason: Q.850;cause=16).

The call flow was as follows:

  1. Inbound INVITE (EO)/200 OK/ACK from Service Provider
  2. Re-INVITE(EO – a=inactive)/200 OK/ACK from CUCM>CUBE>SP
    1. i.e Audio Termination
  3. Re-INVITE(DO)/200 OK/ACK from CUCM>CUBE>SP
    1. A classic CUCM Delayed Offer MOH media negotiation attempt

Unfortunately at this point the call had already failed, with many SIP messages still to follow (for another day) before the final BYE.

So, what is actually going on here?!?  Let’s look at the SIP Ladder:

inactive-media

The offending message is:

May 27 08:57:04.713: //1396205/8DF8940DA2FF/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.1.3:5060;branch=z9hG4bK5C8CBBB5
From: <sip:12341234567@172.16.1.3>;tag=815B2478-2382
To: <sip:22334455667@172.16.1.2>;tag=SDjuthc01-nz5qnrc7wqej3qxa.o
Call-ID: SDjuthc01-780d708b807543c356c407ad79c35b25-a848bn0
CSeq: 101 INVITE
Timestamp: 1432717024
Contact: Anonymous <sip:2345234523@172.16.1.2:5060;transport=udp>
Server: Sippy
Portasip-3264-action: answer 2
Content-Length: 245
Content-Type: application/sdp

v=0
o=Sippy 2031015826430718550 1 IN IP4 172.16.1.2
s=-
t=0 0
m=audio 62848 RTP/AVP 18 96
c=IN IP4 172.16.1.2
b=AS:8
a=inactive
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:96 telephone-event/8000
a=ptime:20
a=maxptime:20

Root cause?

An RFC non-compliant upstream softswitch, sending a=inactive instead of a delayed media offer – in this case not conforming to 14.2 of RFC 3261.

A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) SHOULD construct the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer that updates an existing session, as described in [13] in the case of SDP. Specifically, this means that it SHOULD include as many media formats and media types that the UA is willing to support. The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description. If, however, it is unacceptable to the UAC, the UAC SHOULD generate an answer with a valid session description, and then send a BYE to terminate the session.

I raised a case with the service provider, who simply couldn’t resolve the problem, as the offending device was actually on an upstream inter-connect with another provider.  Chaos ensued explaining this to the client.

Luckily, Cisco has some methods to support this non-compliance – introduce Send sendrecv in Mid-Call INVITE

When Send “sendrecv” in mid call INVITE is enabled, this feature inserts an MTP into the media path between the calling and calling devices, allowing the media connection to be disconnected between the Unified CM device and the MTP, while establishing and maintaining media between the MTP and the held device with a=sendrecv. On call resumption, the MTP is removed from the media path.

Unfortunately, this fix meant I also had to downgrade MOH support to use G729 as well:

This feature addresses the mid-call Delayed Offer INVITE issue for audio direction, but it cannot resolve the issue of a device responding with its last used codec rather than the full list of all supported codecs. This issue can be problematic in cases where a codec change is required on re-establishment of media, such as placing a G.729 call on hold and connecting it to a music on hold source where G711 is preferred.

So.. why am I blaming the forced MTP?

Well, when it’s forced into the call to begin with, yes… it will result in early offer, but its always in the call, and media is therefore always set up and terminated with every mid-call Re-INVITE – via a=inactive SDP.  The end result is that setting Send “sendrecv” in mid call INVITE on the SIP Profile had absolutely no effect – I had to disable MTP on the trunk, set Early Offer from the SIP Profile adn finally set the sendrecv param on the SIP Profile as well.

#dontcalltac

Tagged , , , , ,

DTMF Interworking and the MTP

I came across this a while back when deep diving MTP when preparing for the lab.  I’ve pretty much got it down now, but I keep coming back to it as a reference point.

http://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/118708-technote-dtmf-00.html

I really struggled a lot with this at the CCNP level.  Not sure about MTPs conceptually?  Look no further!

Tagged , , , ,
Collaboration Engineer

All things Collaboration - Posts to save for when you need them

Gerry Keleghan's Blog

A Blog about Cisco Unified Communications

ccieme

my personal journey to ccie collaboration

Striving for greatness

Thoughts on emerging tech, open source, and life

Network Experts Blog

“Knowledge comes by eyes always open and working hands.”

SIP Adventures

A unified communications blog by Andrew Prokop

The Cloverhound Blog

Cloverhound Employees Talk Unified Communications and Contact Center

Warcop

Fog navigator. Get out of the clouds. Down to earth solutions. @Warcop

Cisco Collab Engineering Tips

Michael White - CCIE #26626

Darkroomstory

Photography by Manos,

afterthenumber

Thoughts and experiences of a Cisco Collaboration engineer after clearing the CCIE lab...

Longreads

The best longform stories on the web

The Daily Post

The Art and Craft of Blogging

The WordPress.com Blog

The latest news on WordPress.com and the WordPress community.