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
About Mark Snow, CCIE #14073:

Mark Snow has been actively working with data and traditional telephony as a Network Consulting Engineer since 1995, and has been working with Cisco Call Manager and voice-over technology since 1998. Mark has been actively teaching and developing content for the CCIE Voice track since 2005, and the Security track since 2007. Mark's story with both data and voice technology started out quite young, as he began learning around the age of five from his father who was a patented inventor and a research scientist at AT&T Bell Laboratories. Mark started out on Unix System V and basic analog telephony, and went on from there to large data networking projects with technologies such as Banyan Vines, IPX and of course IP, and large phone systems such as Nortel 61c, Tadiran Coral, Avaya Definity and of course Cisco Unified Communications Manager in both enterprise and 911 PSAP environments across the US and internationally. Mark is also an accomplished pilot and punched his ticket in 2001. When Mark isn't learning, labing, consulting or teaching, he can be found either piloting or possibly jumping out of a perfectly good airplane, hanging off a rock somewhere or else skiing out west. He also might just be enjoying a quiet day at the beach with his wife and two wonderful young kids, Ryleigh and Judah.

Find all posts by Mark Snow, CCIE #14073 | Visit Website


You can leave a response, or trackback from your own site.

6 Responses to “CCIE-V/CCNP-V Trivia Contest – “Strip the 9′s” (More Nice Prizes!)”

 
  1. Nikolay Skachkov says:

    Hello Mark,

    my solution as bellow (first of all let me please modify your voice-translation rule 9 in order to do it easier):

    voice translation-rule 9
    rule 1 /^911$/ // – more specific first
    rule 2 / / /9/ – anything else

    voice translation-profile Prefix_9_DNIS
    translate callled 9

    dial-peer voice 101 voip
    translation-profile incoming Prefix_9_DNIS
    incoming called-number .
    voice-class codec 1

    And then:

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

    Ready.

    Nikolay

  2. Nikolay Skachkov says:

    sorry, i done a mistake in my rule 1:

    rule 1 /^911$/ // – more specific first

  3. Earl Hough says:

    For the H323 Gateway:

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

    For the SIP Gateway:

    voice class sip-profiles 1
    response 183 sip-header Remote-Party-ID modify “(.*):9(.*)” “\1:\2”
    response 200 sip-header Remote-Party-ID modify “(.*):9(.*)” “\1:\2”

    voice service voip
    sip
    sip-profiles 1

    To verify that the “9” is not being re-introduced to the called number display:

    For H323:
    debug cch323 h225
    (look for lack of send_notify_msg messages)

    For SIP:
    debug ccsip messages
    (look for the Remote-Party-ID string)

  4. Earl Hough says:

    This is an ammendment of my previous post. I had to include a second pattern which matched ’11′ and would then replace that with ’911′ in order to maintain 911. At least in the version of IOS I am using – 12.4(20)T2, the sip-profile does not get matched in a top-down or best match fashion. It appeared to continue processing through each line of the profile and if there was a match, it would apply that line to the Remote-Party-ID.

    For the H323 Gateway:

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

    For the SIP Gateway:

    voice class sip-profiles 1
    response 183 sip-header Remote-Party-ID modify “(.*):9(.*)” “\1:\2″
    response 183 sip-header Remote-Party-ID modify “(.*):11(.*)” “\1:911\2″
    response 200 sip-header Remote-Party-ID modify “(.*):9(.*)” “\1:\2″
    response 200 sip-header Remote-Party-ID modify “(.*):11(.*)” “\1:911\2″

    voice service voip
    sip
    sip-profiles 1

    To verify that the “9” is not being re-introduced to the called number display:

    For H323:
    debug cch323 h225
    (look for lack of send_notify_msg messages)

    For SIP:
    debug ccsip messages
    (look for the Remote-Party-ID string)

  5. Gianluca says:

    ! H.323 gateways
    voice service voip
    no supplementary-service h225-notify cid-update

    ! SIP gateways
    voice service voip
    sip
    no update-callerid

  6. Thanks to all that were able to participate in this week’s challenge!
    It seems that many might be on a bit of an early spring break holiday, due to the number of responses compared to last (either that, or my question just scared off too many people :-) ).

    @Nikolay, Interesting idea on the modification of the VTR, though I had mentioned that “Tyrone” was not going to be modifying any of his VTR in any way. Regardless, you did answer the question correctly for the H.323 gateway, however you failed to provide an solution for the SIP gateway – a stated necessary requirement.

    @Earl, You nailed it, and being the only correct answer – you win this week’s challenge! Congratulations! (I’ll unicast you offline to sort the details)

    @Gianluca, You provided a correct answer for the H.323 gateway, and you provided what might seem to work for the SIP gateway, however if you tested this, you would find it does not. The only valid solution would be using a SIP Profile.

    So here is my official answer, and I will update the blog post to correspond with this as well:

    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
    

    BTW, @Earl, you specified running a ‘debug ccsip messages’ to note the lack of the preceeding ’9′ in the Remote-Party-ID header. While this would work fine to show the lack of this, there is a better debug that can be run, one that actually shows the number being modified, and this is ‘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
    

    And that’s the magic were looking for. Regardless, that was part of the extra credit. Just want to help out where I can for folks to not just use what they’ve trusted for years, but in the words of The North Face, to “Never Stop Exploring” ;-) .

    Thanks everyone! See you back in two weeks!
    -Mark

 

Leave a Reply

Categories

CCIE Bloggers