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:

• http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/copy_sip_headers.html#task_EC3E238FD5064238A1322178B036507C
• http://www.cisco.com/en/US/docs/ios-xml/ios/voice/cube_sip/configuration/15-2mt/voi-condl-header.html#GUID-E0D6A469-0DA2-4DDF-A23B-B4F397366F38

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