Monthly Archives: March 2016

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.

Advertisements
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 , , ,

Prime Collaboration Provisioning Business Rules

Prime Collaboration Provision has an excellent centralized management of a set of “Business Rules” that really identify a level of system configuration that can be applied to a cluster.

In this example below (using PCP 10.6), the default Unity Connection PIN is set to a trivial value of 123456.

rules

Note:

System-level considerations still apply!   For the example of Unity Connection, one would need to modify the Authentication Rules to accommodate trivial passwords.  This param is called DefaultUnitySubscriberPassword.

This is in fact also referenced in the online documentation:

The DefaultUnitySubscriberPassword rule does not validate the length of the default password entered in the data field. Cisco Unity Connection may have different credential policies configured.

 

Another VERY USEFUL param is LineDisplayString – great for batch provisioning off templates and avoiding messy template updates for a single cluster-wide standard!

Again, from the documentation:

Template string used to construct the Internal Caller ID display format for the phone line. If disabled, the system defaults to FIRSTNAME LASTNAME. This rule does not apply if the Service Area has a Cisco Unified Communications Manager Express as a Call Processor.

The default value for the Display (Internal Caller ID) provisioning attribute is applied from this rule. If you specify CUPM_BLANK or an empty value in batch provisioning or through the Prime Collaboration Provisioning user interface, the value for the Display (Internal Caller ID) provisioning attribute comes from this rule.

Therefore, if you want to set an empty value for the Display (Internal Caller ID) provisioning attribute, you must enable this rule and make sure its value is empty.

Useful Links:

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 , , , ,
Collaboration Engineer

All things Technology - 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...

The Daily Post

The Art and Craft of Blogging

The WordPress.com Blog

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