Apr
03

INE is proud to announce a brand new 62+ hours of the latest v8 CCNP Voice bootcamp. Rerecorded completely from scratch using only UC v8 servers, this in-depth video series covers absolutely everything you need to know for the 5 CCNP Voice exams, with each exam clearly indicated by video title in the playlist. Also, don't forget about our Bookmark and Note-taking feature in our streaming playlists, as this will help you in your studies.


 

Related Posts

%RELATEDPOSTS%

Feb
18

I recently finished up recording a brand new CCNA Voice v8 online bootcamp, and it is available for both streaming and download. I also spent a number of hours today revising the extremely popular blog post outlining INE's "CCIE Voice in a Year" study plan.

We are still taking enrollment for our brand new CCNP Voice v8 live online bootcamp, so be sure to register if you haven't already.

 

Related Posts

%RELATEDPOSTS%

Jul
28

We're pleased to announce that our recently announced, highly anticipated CCNP Voice course is available for both streaming and download from our global CDN. Containing everything you need to take and pass the five latest Cisco CCNP Voice exams (642-427 TVOICE v8, 642-437 CVOICE v8, 642-447 CIPT1 v8, 642-457 CIPT2 v8, and 642-467 CAPPS v8), this new course consists of 130 videos totaling over 85 hours of hands down the best CCNP Voice training on the market today. As an All Access Pass subscriber the online streaming version is included at no additional charge. You may also download it now for just $299 or as an All Access Pass subscriber you can download it for only $149.

Each of the 130 videos can be individually downloaded without the need to download the whole class. This will enable you to selectively load them onto any computer or mobile device and watch them at your leisure. Although we do not place any DRM on the files themselves we do limit each purchase to two downloads per video.

Check back often, as we will be adding new labs to our CCIE Voice Volume II Workbook in the upcoming weeks. Also, you may now purchase and schedule your Graded Mock Lab for a proper CCIE Voice assessment of your skills before actually sitting for the actual lab exam.

May
04

As everyone knows we're making a massive push to release more videos and moving over to a new delivery method (HTML5).  With this new solution we can support closed captions.  I've uploaded a sample CCIE Voice Deep Dive video with closed captions enabled to YouTube and wanted to know the community's feedback as to the value it will add.

Click on the "cc" icon in the YouTube player to enable closed captions if they are disabled.

Closed captions will allow us to offer transcripts of the videos and allow every video to be searchable so you can quickly find which video covers a particular topic and the exact part of a video that it's cover in. Additionally we'll be able to link you to that exact part of the video. Let me know what you all think by commenting below.

Mar
24

I am running this week's Voice Trivia Contest a bit early (launching it on Thursday instead of Friday) to try to give more people a chance to win that might not otherwise see this over the weekend, however we will still end the contest on Monday morning, as usual.

Here are the facts for this week's Voice Trivia Contest:

  • Tobias has a phone on which he needs to be able to have two BLF SD buttons that accurately show the presence status of Gob, Buster and Lindsay's primary DNs. This needs to include status updates for when either Gob or Lindsay's primary DN is ringing, but not when Buster's primary DN rings.
  • Gob, Buster and Lindsay's primary DNs are all in the same Partition.
  • Tobias has a SUBSCRIBE Calling Search Space that contains that Partition all three phones' primary DNs are in.
  • Tobias also needs to be able to view Call Lists (Missed Calls, Corporate Directory, etc.), but when he views them, he should only see the BLF status change for Lindsay's DN, and not for Gob or Buster's DNs.
  • To aid in that, two Presence Groups have been setup. One for Tobias and Lindsay which have been assigned to both their Phone devices and their Lines. One for Gob and Buster, which have been assigned to both their Phone devices and their Lines. The Presence Groups both explicitly have Disallow Subscription to each other's group reciprocally.
  • All is good with Tobias's BLF SDs on his phone display, and he can see all of their status changes appropriately - including seeing when Gob or Lindsay's DNs ring, but not Buster's.
  • However, there is an issue. When he pulls up the Corporate Directory and searches for everyone, he sees BLF status updates for both Lindsay and Gob, but not for Buster. Remember that he should not see Gob's BLF status updates either.

So, your contest question for this weekend is this: What could the problem be that is causing Tobias to be able to see Gob's (but not Buster's) status in BLF Call Lists, when he shouldn't be able to see either of them?

As always, the winner of this contest will have their choice of any one of these items:

  • $100USD Amazon Gift Card
  • $100USD in GradedLabs Tokens (which is 6.5 Voice rack sessions!)
  • $100USD worth of INE.com online store credit - which goes perfectly as a complement to your checkout cart containing INE's all new All Access Pass!

The way we will hold the contest is as follows:

  • You must answer all questions correctly - this means that the solution provided must fully meet the requirement (i.e. If something else breaks, such as normal dialing, or digit appearance is not as requested, as a result of your answer - it will not be counted as a correct answer)
  • You must submit your answers in the comments section of this post along with a valid email address to reach you for your prize (submissions emailed to INE will not be accepted)
  • If there are multiple, correct respondents, then we will place all of the correct respondents names into an online randomizer - the modern day 'hat', if you will
  • We will not allow any of the response comments to be seen here publicly until Monday morning when we choose the winner, so as not to give an unfair advantage to anyone
  • Simply so that we may give a wide range of people chances to win these contests, we have decided that if you have won a previous Voice trivia contest here on this blog, you will only be eligible to be chosen as this contest winner if you happen to have submitted the only correct answer (so try and answer anyway!)

I'll be watching them over the next few days, and I will return on Monday to gather up the winners, choose a random name, and post all of the comments along with some of with my own replies and comments, and of course, the correct solution.

Good Luck!
Mark



Update: We have a winner!

Congratulations Hristos!

Hristos correctly identified that when a user has a Unified Mobility (SNR) shared line, that user will be the exception from the Presence Group properly working. In fact, depending on the restart iteration, the results can be a but undeterministic.

This was specifically demonstrated in one of our four new Voice Deep Dive modules - Unified Presence.

Feb
25

Austin has devised a dial plan that meets the needs of his company (Backyard Adventures, Inc), and one of the core components of it meets a requirement set forth by his company's executive branch - namely, that although people in U.S. offices of his company dial a '9' as a PSTN access code prior to dialing any additional digits for outside public calls, the executive branch dictates that they do not want the IP phones that dialed such a number to see that preliminary '9' on the phone's display, once the call has been placed.
(e.g. If Pablo dialed 9-206-501-5111 for a local call in Seattle, then his display should only show 2065015111 once the call has been placed)

So Austin --knowing that by default, CUCM updates it's phones' Calling Displays at every digit manipulation step along the way that occurs while the call is still in control of CUCM-- decides to make sure that CUCM strips the '9' off of every egress gateway or trunk, before the call is sent onto the actual IOS device providing gateway services between itself and all of the company's PSTN PRI circuits. This actually meets two objectives of his: the first being the desired behavior just discussed, and the second being the execution of a uniform dial plan with regards to digit manipulation for egress gateways and Called Party Transformation Patterns - whether they be to MGCP gateways (where that '9' must be stripped prior to sending to the IOS device), or to H.323 or SIP GW/Trunks all the same.

Now something that he didn't count on was this: While he was in control of the CUCM and its dial plan, he has to work together with Tyrone who is in control of all the IOS devices, whether for routing or for voice services. Tyrone has informed Austin that all outbound dial peers pointing to the PSTN, begin with a '9' (and are displayed just below). Tyrone also informs Austin that it is fine if Austin sends the PSTN-bound calls to his (Tyrone's) IOS gateways without a '9', but just so that Austin is prepared, he will be reintroducing (prepending) all PSTN-bound calls with a '9' for any gateways that are controlled with the H.323 and/or SIP signaling protocols, so as to match the outbound dial peers - and that he will be doing that on the inbound VoIP dial peer from the CUCM, with Voice Translation Rules as follows:

OUTBOUND PSTN DIAL PEERS
!
dial-peer voice 10 pots
destination-pattern 911$
port 0/0/0:23
forward-digits 3
!
dial-peer voice 11 pots
destination-pattern 9[2-9]..[2-9]......$
port 0/0/0:23
forward-digits 10
!
dial-peer voice 12 pots
destination-pattern 91[2-9]..[2-9]......$
port 0/0/0:23
forward-digits 11
!
dial-peer voice 13 pots
destination-pattern 9011T
port 0/0/0:23
prefix 011
!
INBOUND CUCM DIAL PEER & VTR
!
voice translation-rule 9
rule 1 /^[2-9].........$/ /9&/
rule 2 /^1[2-9].........$/ /9&/
rule 3 /^011.*/ /9&/
!
voice translation-profile Prefix_9_DNIS
translate called 9
!
dial-peer voice 101 voip
translation-profile incoming Prefix_9_DNIS
incoming called-number .
voice-class codec 1
session protocol sipv2
dtmf-relay sip-kpml rtp-nte
!

Now Austin knows that both the H.323 and SIP signaling protocols will retroactively inform the CUCM of any changes to the Called Number, and while he tries to persuade Tyrone to change his method of prefixing the '9', he fails to do so.

So, your contest question for this weekend is this (and requires two separate answers, one for H.323 and different for SIP):

  • Given the above outbound dial peers for any H.323-to-PRI/PSTN and/or SIP-to-PRI/PSTN voice gateways in the Backyard Adventures' unified communications network, and given the fact that Tyrone will not be changing the Voice Translation Rules that he already has implemented on his gateways' inbound dial peers in any way: What configuration can Tyrone add to his H.323 & SIP IOS gateways (separately) to prevent the singaling protocol, and therefore CUCM, from reintroducing the '9' back into the Called Number display of users' such as Pablo's phones when they go to place a call?
  • For extra credit, include the best debug command to ensure that what you wish to happen to the Called Number, is indeed what is actually happening to it. The extra prize to go along with the extra credit answer is this: If you get it correct, you will know you are that much closer to answering exam questions properly for either the TVOICE v8 or the CCIE Voice Lab Troubleshooting tasks! ;-)

As always, the winner of this contest will have their choice of any one of these items:

  • $100USD Amazon Gift Card
  • $100USD in GradedLabs Tokens (which is just a bit more than 3 Voice rack sessions)
  • $100USD worth of INE.com online store credit - which goes perfectly as a complement to your checkout cart containing INE's all new All Access Pass!

The way we will hold the contest is as follows:

  • You must answer all questions correctly - this means that the solution provided must fully meet the requirement (i.e. If something else breaks, such as normal dialing, or digit appearance is not as requested, as a result of your answer - it will not be counted as a correct answer
  • You must submit your answers in the comments section of this post along with a valid email address to reach you for your prize (submissions emailed to INE will not be accepted)
  • If there are multiple, correct respondents, then we will place all of the correct respondents names into an online randomizer - the modern day 'hat', if you will
  • We will not allow any of the response comments to be seen here publicly until Monday morning when we choose the winner, so as not to give an unfair advantage to anyone
  • Also a new one: If you have won a previous contest, you will not be eligable to be in the drawing for this contest, that is unless you happen to be the only correct answer - in which case, we have to give it to someone, don't we? :)

I'll be watching them over the weekend, and I will return on Monday to gather up the winners, choose a random name, and post all of the comments with my own replies and comments.

Again, we will be try to hold these sorts of contests bi-weekly, so check back often to increase your chance of winning!

P.S. Stay tuned at the beginning of next week as we announce an exciting new Non-VPN method of accessing all of our Voice Racks!

Good Luck!
Mark



Congratulations to Earl Hough, the winner of this contest!

As promised below in my comments, here is an updated post with the solution set:
For the H.323 Gateway:

voice service voip
no supplementary-service h225-notify cid-update

... and to verify, run:

debug cch323 h225

For the SIP Gateway:


voice class sip-profiles 1
response 183 sip-header Remote-Party-ID modify "<sip:9([2-9].*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 183 sip-header Remote-Party-ID modify "<sip:9(1[2-9].*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 183 sip-header Remote-Party-ID modify "<sip:9(011.*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 200 sip-header Remote-Party-ID modify "<sip:9([2-9].*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 200 sip-header Remote-Party-ID modify "<sip:9(1[2-9].*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
response 200 sip-header Remote-Party-ID modify "<sip:9(011.*)@177.1.254.1>" "<sip:\1@177.1.254.1>"
!
dial-peer voice 101 voip
voice-class sip profiles 1

... and to verify, run:

debug ccsip info

When running the 'debug ccsip info', we see:


//1554/D0D02EC28E93/SIP/Info/sipSPISendInviteResponse: Associated container=0x4A1DBD58 to Invite Response 183
//-1/xxxxxxxxxxxx/SIP/Info/sip_profiles_application_modify_remove_header: Header before modification : Remote-Party-ID: <sip:92065015111@177.1.254.1>;party=c
alled;screen=no;privacy=off
//-1/xxxxxxxxxxxx/SIP/Info/sip_profiles_application_modify_remove_header: Header after modification : Remote-Party-ID: <sip:2065015111@177.1.254.1>;party=cal
Feb
11

This isn't exactly the latest news, and doesn't effect the CCIE Voice Lab exam (although it very well may effect the new CCNP Voice exams), however I am hearing more and more how people are upgrading their Voice routers with newer 15.x IOS code, and not realizing how existing (working) VoIP calls are being broken due to new, intelligent feature default configurations.

Last July, Cisco decided (wisely, IMHO) to create a new style of Toll-Fraud prevention to keep would-be dishonest people from defrauding a company by placing calls through their misconfigured voice gateway(s), at the company's expense. This new mechanism works by preventing unintended TDM (FXO/CAS/PRI) and VoIP (H.323 & SIP) calls from being able to be placed through a given company's voice gateway(s), by simply blocking all unknown traffic. Beginning in IOS 15.1(2)T, Cisco added a new application to the default IOS stack of apps that compares all source IP address with an explicitly configured list in the IOS running config, and if the IP address(es) or subnets do not match, all VoIP traffic is denied. Also, the new default for all POTS voice-ports is to not allow secondary dial-tone, making direct-inward-dial the default for CAS/PRI, and PLAR necessary for FXO.

We can trust our VoIP sources with a few, very easy commands.
If we wanted to trust only our CUCM Publisher and Subscribers servers on our GradedLabs Voice Racks, we would add:

voice service voip
ip address trusted list
ipv4 177.1.10.10 255.255.255.255
ipv4 177.1.10.20 255.255.255.255





Or possibly if we wanted to trust the entire subnet that our servers were on, we would add:

voice service voip
ip address trusted list
ipv4 177.1.10.0 255.255.255.0



We also have the ability to go back to pre-15.1(2)T behavior by simply doing either this:

voice service voip
ip address trusted list
ipv4 0.0.0.0 0.0.0.0




Or this:

voice service voip
no ip address trusted authenticate





Also, we have the ability to configure the router for pre-15.1(2)T behavior as it relates to inbound POTS calls.
For inbound ISDN calls we would add:

voice service pots
no direct-inward-dial isdn




And for inbound FXO calls we would add:

voice-port 0/0
secondary dialtone



One nice thing is that when booting an IOS router with this toll-fraud functionality, a message is displayed on boot-up, letting us know about it - essentially warning us that we need to configure something if we wish VoIP calls to work.

A link to Cisco's tech note describing this new functionality can be found here.

In summary, when upgrading a previously working H.323 or SIP VoIP gateway to IOS 15.1(2)T or later, until the proper configuration changes have been added to allow the proper VoIP source traffic into your voice gateway, all VoIP calls will cease to function properly. In general, this shouldn't break FXO/CAS/PRI for most configurations out there - as most folks are likely to have their routers configured properly to handle inbound POTS traffic (i.e. PLAR on their FXO ports and DID on their CAS/PRI port - or so we should hope) - I suppose YMMV depending on each unique configuration.

Let me know if you think this is a good thing that Cisco has done.

 

Related Posts

%RELATEDPOSTS%

Feb
04
Pablo is using his Cisco 7961 IP phone. He goes to look at his 'Missed Calls' and sees that he missed a call that had come in from a local PSTN number. The number in his missed call looked exactly like this:
<strong>+12065015111</strong>


He needs the ability to look at this missed call and simply press the 'Dial' softkey --and nothing more-- to return the call immediately - with no inter-digit timeout, and of course successful call routing back to the PSTN caller.


Pablo has the same CSS on his Line, as he does on his Phone Device - which is:
<strong>CSS_CorpHQ-LOCAL</strong>


And the CSS has in it, the Partition of:
CSS_CorpHQ-LOCAL

--> PT_CorpHQ-LOCAL


There is a Route Pattern that points straight to a gateway, that matches his desired return call:
Pattern: \+!

Partition: PT_CorpHQ-LOCAL

Urgent Priority: YES

Gateway: CorpHQ-MGCP-GW


And the MGCP Gateway has a Called Party Transformation CSS:
Gateway: CorpHQ-MGCP-GW

Outbound Called Party Transformation CSS: CSS_CdPTP-CorpHQ-GW


And the CSS with CSS has the PT:
CSS_CdPTP-CorpHQ-GW

--> PT_CdPTP-CorpHQ-GW


And the CdPTP to localize the call egress from the MGCP GW to the carrier (the carrier is expecting 10 DNIS digits) is:
Called Party Transformation Pattern: \+1.206!

Partition: PT_CorpHQ-LOCAL

Urgent Priority: YES!

Discard: PreDot


So as you can see, the call should be returned to the PSTN with no issues.


So Pablo looks at that missed call, and goes to press 'Dial'. No sooner than he has pressed it, his display quickly pulses out the digits '+12065015111' -- then it briefly changes to show only '+1' -- and then the call simply disappears, as the screen returns to a normal, idle state.

He is quite shocked at this, most especially because of the fact that Tom, his cube mate, has the same Cisco 7961 IP phone, with the same dialing permissions (Tom also has the exact same CSS as Pablo, on both his Line and Phone Device), and Tom has absolutely no problem returning this exact same missed call pattern.


There is one small difference between Pablo and Tom's phones -- Tom has a 7961 SCCP phone, while Pablo has a 7961 SIP phone.


BTW, I should probably also note that neither one of them has any trouble placing any sort of normal, local calls when dialing from their keypads.


So, your contest question for the weekend is a three-parter:
  1. Why does Tom's phone work, but Pablo's does not, when attempting to return the very same missed call?
  2. What CUCM entity could you add to this equation to make Pablo's phone work for returning this call (without changing any of the entities or values listed above)?
  3. What would the value be of this newly created entity?
The winner of this contest will have their choice of any one of these items:
  • $100USD Amazon Gift Card
  • $100USD in GradedLabs Tokens (which is just a bit more than 3 Voice rack sessions)
  • $100USD worth of INE.com online store credit
The way we will hold the contest is as follows:
  • You must answer all questions correctly, submitting your answers in the comments section of this post
  • If there are multiple, correct respondents, then we will place all of the correct respondents names into an online randomizer - the modern day 'hat', if you will
  • We will not allow any of the response comments to be seen here publicly until Monday morning when we choose the winner, so as not to give an unfair advantage to anyone
  • It might be good if you posted with a registered email account -- you know, that way we can notify of your glorious prizes should you win? :-)
I'll return on Monday to gather up the winners, choose a random name, and post all of the comments with my own replies and comments.


Also, we will be holding these sorts of contests bi-weekly, so check back often to increase your chance of winning!


Good Luck!
Mark Snow



Congratulations to Roger Carpio, the winner of this contest!


As promised below in my comments, here is an updated post with the screenshot for the SIP Dial Rule to both fix this problem, and avoid a 10 second inter-digit timeout for all other normal keypad dialed calls:

Click to see full-sized image

Jan
22

You will find the answer to today's CVOICE Exam Practice in the comments area of the blog approximately 24 hours after the post. Have fun!

CVOICE-1: Cisco Unified Communications gateways support various VoIP signaling protocols. For each description below, provide the signaling protocol that is described:

A. This protocol specifies the commands and responses to set up and tear down calls. It also details features such as security, proxy, and transport control protocol (TCP or User Datagram Protocol [UDP]) services. It is a text-based protocol that borrows many elements of HTTP, using the same transaction request-and-response model and similar header and response codes.

Answer:___________

B. This protocol definition controls VoIP gateways that are connected to external call control devices, referred to as call agents.

Answer:___________

C. This standard specifies the components, protocols, and procedures that provide multimedia communication services—real-time audio, video, and data communications—over packet networks, including IP networks. The protocol is part of a family of ITU-T recommendations.

Answer:___________

D. This Cisco proprietry protocol is used between Cisco Unified Communications Manager and Cisco Unified IP phones.

Answer:___________

Aug
20

Many businesses globally - large and small alike - have been converting calls from routing over traditional PSTN carrier trunks - such as E1 & T1 PRI or CAS - to much lower cost, yet still high performance, SIP ITSP (Internet Telephony Service Provider) trunks for years now. INE is no different than your business with regard to this - we have been using SIP trunks in lieu some traditional PSTN calling for years now as well. In fact, in response to a US Federal Communications Commission sub-commitee's exploration on "PSTN Evolution" in December 2009, a representative from the US carrier AT&T described the traditional circuit-switched PSTN as "relics of a by-gone era", and said that "Due to technological advances, changes in consumer preference, and market forces, the question is when, not if, POTS service and the PSTN over which it is provided will become obsolete" - source: Reuters [emphasis mine].

The challenge however, becomes that every SIP ITSP carrier has a slightly different way of implementing these sorts of trunks, and each has different provider network equipment that you, the customer, must connect to, and interoperate (properly) with. If you are a large national or multinational business, you may for instance sometimes even connect to two or three different types of provider network equipment, between possibly having multiple contracts with multiple carriers, and even sometimes having to deal with different provider equipment within a single carrier's network.

Now while you both speak the same agreed upon language (namely SIP), it seems more often than not that you don't always seem to speak exactly the same dialect of that language. This presents a major challenge in that calls and supplementary services (such as Hold, Resume, Blind Transfer, Semi-Attended Transfer, Fully-Attended Transfer, Forwarding, Faxing, etc) don't behave as expected, or worse, that some functions don't work at all.

It is not that SIP isn't fully mature yet (it will turn 15 years old next year and has been widely used for over 10 years now), or that it is fully standardized and therefore governed by those IETF standards and working groups, it is simply that - as every one of us in the field for any respectable amount of time now knows - not every equipment vendor chooses to implement every single extension and option defined in every IETF RFC for SIP. I mean, have you ever actually looked at how many RFCs there are that deal with not just the core functions, but describe every option and extension to the SIP protocol? There are well over 100 RFCs! Therein lies the problem.

So what are we to do? Cisco Unified Border Element to the rescue! Today we will cover just a few of CUBE's ability to perform SIP Normalization to allow optimum interoperability with many various SIP ITSPs.

At its base, CUBE consists of allowing both inbound and outbound call legs to be of the type VoIP. Here we first explore a very basic configuration where we have 2 Inbound/Outbound Dial-Peers (depending on which direction the call originates from) To/From the CUCMs in the cluster, and 2 Inbound/Outbound Dial-Peers To/From a fictional AT&T SIP ITSP trunk. We are allowing a codec negotiation and also possibly a DTMF relay internetworking between CUBE  and the CUCMs on Dial-Peer's 101 & 102 (we needed both of these for another utility on this router using the SIP stack), while allowing for the codec of G.729 Annex B on the AT&T carrier side in Dial-Peers 1001 & 1002. We are also load balancing calls between both of the CUCM Subscriber servers and also between both of the SBCs on AT&T's side that they have given us to peer with. We see this here:

!
ip domain retry 0
ip domain timeout 2
ip domain name ine.com
ip name-server 177.1.100.110
!
voice service voip
address-hiding
allow-connections sip to sip
redirect ip2ip
sip
bind control source-interface Loopback0
bind media source-interface Loopback0
header-passing error-passthru
midcall-signaling passthru
g729 annexb-all
!
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
!
!
dial-peer voice 101 voip
description ** TO/FROM CUCM SUBSCRIBER 1 **
destination-pattern 2065011...$
voice-class codec 1
session protocol sipv2
session target ipv4:177.1.10.20
incoming called-number .
dtmf-relay sip-kpml rtp-nte
!
dial-peer voice 102 voip
description ** TO/FROM CUCM SUBSCRIBER 2 **
destination-pattern 2065011...$
voice-class codec 1
session protocol sipv2
session target ipv4:177.1.10.25
dtmf-relay sip-kpml rtp-nte
!
dial-peer voice 1001 voip
description ** TO/FROM SIP ITSP - AT&T SBC 1 **
destination-pattern +T
voice-class sip localhost dns:corphqr1.ine.com
session protocol sipv2
session target dns:sip1.att.com
incoming called-number 2065011...$
dtmf-relay rtp-nte
codec g729br8
!
dial-peer voice 1002 voip
description ** TO/FROM SIP ITSP - AT&T SBC 2 **
destination-pattern +T
voice-class sip localhost dns:corphqr1.ine.com
session protocol sipv2
session target dns:sip2.att.com
incoming called-number 2065011...$
dtmf-relay rtp-nte
codec g729br8
!
dial-peer hunt 1
!
!
voice service voip
allow-connections sip to sip
sip
bind control source-interface Loopback0
bind media source-interface Loopback0
!
voice class codec 1
codec preference 1 g711ulaw
codec preference 2 g729r8
!
!
dial-peer voice 101 voip
description ** TO/FROM CUCM SUBSCRIBER **
destination-pattern 2065011...$
voice-class codec 1
session protocol sipv2
session target ipv4:177.1.10.20
incoming called-number .
dtmf-relay frtp-nte
!
dial-peer voice 102 voip
description ** TO/FROM CUCM PUBLISHER **
preference 1
destination-pattern 2065011...$
voice-class codec 1
session protocol sipv2
session target ipv4:177.1.10.10
dtmf-relay rtp-nte
!
dial-peer voice 1001 voip
description ** TO/FROM SIP ITSP - AT&T SBC 1 **
destination-pattern +T
voice-class sip localhost dns:corphqr1.ine.com
session protocol sipv2
session target dns:sip1.att.com
incoming called-number 2065011...$
dtmf-relay rtp-nte
!
dial-peer voice 1002 voip
description ** TO/FROM SIP ITSP - AT&T SBC 1 **
destination-pattern +T
voice-class sip localhost dns:corphqr1.ine.com
session protocol sipv2
session target dns:sip2.att.com
incoming called-number 2065011...$
dtmf-relay rtp-nte
!
dial-peer hunt 1

Now what if we have a carrier who wants to see our specific domain name (ine.com) after the @ in the Contact header of a SIP INVITE request message (so 2065011001@ine.com   vs.   2065011001@177.1.254.1), possibly for something like compliance with SIP Asserted-Identity? Let's look at what the SIP INVITE might look like prior to any modification to the above configuration:

Sent:
INVITE sip:+12065015111@sip2.att.com:5060 SIP/2.0
Via: SIP/2.0/UDP 177.1.254.1:5060;branch=z9hG4bK2BAFFD
Remote-Party-ID: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;party=calling;screen=yes;privacy=off
From: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;tag=8074E2B0-20E7
To: <sip:+12065015111@sip2.att.com>
Date: Fri, 20 Aug 2010 02:34:27 GMT
Call-ID: 9FE12628-A81511DF-8700FC78-AA8D9DEB@corphqr1.ine.com
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2682052728-2819953119-2264595576-2861407723
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1281926067
Contact: <sip:2065011001@177.1.254.1:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 292

v=0
o=CiscoSystemsSIP-GW-UserAgent 5117 3857 IN IP4 177.1.254.1
s=SIP Call
c=IN IP4 177.1.254.1
t=0 0
m=audio 16532 RTP/AVP 18 100 19
c=IN IP4 177.1.254.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=rtpmap:19 CN/8000
a=ptime:20

So what can CUBE do about this? CUBE can alter the contents of any header in any SIP or SDL header of any request or response (SDL or "Session Description Language" is where things like media, DTMF relay, etc are negotiated - you see a SDL sub-component of the above SIP INVITE  message - which is known as a "SIP Early Offer"). So let's tell CUBE to alter that Contact header of that particular INVITE message, but only out to AT&T. As a preface to our configuration example, it is worth noting that SIP Profiles allow for pattern matching and replacement in a similar (but not exact) method to that of Voice Translation Rules, and like them, are based (loosely) on the GNU SED stream editor. We will use this to match and replace a few possible dynamic values of the string. Like Voice Translation Rules, reference "sets" of matched information in the replacement string with \1 which calls Set 1 from the matched pattern to the replacement pattern. Also like Voice Translation Rules, any part of the string (beginning or end) that we don't match, passes through to the replacement pattern, unaltered.
!
voice class sip-profiles 1
request INVITE sip-header Contact modify "<sip:(.*)@(.*):5060>" "<sip:\1@ine.com:5060>"
!
dial-peer voice 1001 voip
voice-class sip profiles 1
!
dial-peer voice 1002 voip
voice-class sip profiles 1
!

Now let's take a look at what that did to the contents of our Contact header in a new call, and thus a new SIP INVITE message that we send out to AT&T:

Sent:
INVITE sip:+12065015111@sip2.att.com:5060 SIP/2.0
Via: SIP/2.0/UDP 177.1.254.1:5060;branch=z9hG4bK2BAFFD
Remote-Party-ID: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;party=calling;screen=yes;privacy=off
From: "Jack Shepherd" <sip:2065011001@corphqr1.ine.com>;tag=8074E2B0-20E7
To: <sip:+12065015111@sip2.att.com>
Date: Fri, 20 Aug 2010 02:34:27 GMT
Call-ID: 9FE12628-A81511DF-8700FC78-AA8D9DEB@corphqr1.ine.com
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 2682052728-2819953119-2264595576-2861407723
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1281926067
Contact: <sip:2065011001@ine.com:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Session-Expires: 1800
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 292

v=0
o=CiscoSystemsSIP-GW-UserAgent 5117 3857 IN IP4 177.1.254.1
s=SIP Call
c=IN IP4 177.1.254.1
t=0 0
m=audio 16532 RTP/AVP 18 100 19
c=IN IP4 177.1.254.1
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=rtpmap:19 CN/8000
a=ptime:20

Excellent! It did exactly what we asked it to!

There are many other things that the Cisco's UBE can do for us, and we have only covered one small one here in this article. For a lot more great information on this product check out INE's Class-on-Demand CCIE Voice Deep Dive for CUBE. By the way, Cisco's implementation of what others in the industry might label a "SBC" (Session Border Controller), goes far beyond what other industry SBCs are able to offer in terms of both features and scalability (CUBE hardware support ranges from ISRs for SMBs, up through ISR-G2s and ASRs for Enterprises, up to the 12000 series routers for SPs). I will cover many more of the offered features of the CUBE in follow-up postings, so stay tuned!

I will leave you with a great Cisco article describing some basic functionality of CUBE and SIP Normalization, and also a lot of great Cisco configuration examples from live SIP ITSP trunks that Cisco has installed and tested with in their RTP labs, as well as live PBX integrations that they have performed, and subsequently written up these "recommended practice" documents.

Subscribe to INE Blog Updates

New Blog Posts!