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

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