Could it be that the predot on the Route Pattern is causing the RG-RL details not too much thus the reason to add 011 as a prefix on the dp.
Have seen where manipulation on a H.323 gateway does show up on the phone. The exception is num-exp, i.e. num-exp 3432143333 90113232143333 RP (9011.!, predot)->RG-RL (nothing)->H.323 GW (num-exp mentioned earlier) -> will match DP as (9011!, prefix 011). Mark Nigh Systems Engineer mn...@netelligent.com (p) 314.392.6926 [cid:image001.gif@01CAA8D1.4D6C60E0]<http://www.netelligent.com/> From: scott carruthers [mailto:scarruthe...@hotmail.com] Sent: Monday, February 08, 2010 3:02 PM To: Mark Nigh; ccie_voice@onlinestudylist.com Subject: RE: [OSL | CCIE_Voice] Manipulating IP Phone Called Number Display Mark, The configuration was on proctorlabs gear and is now gone but I can easily summarize. Recap of goal - after user makes an international call the calling party's IP phone display should be updated and show 3432143333. HQ Phone > dials 90113432143333 > hits route pattern 9011.! > within the route pattern I am stripping predot solely for the purpose of affecting the final display on the calling party phone > call is sent to a route list that contain a single route group that contains the HQ H.323 GW > the route list-route group DNIS manipulation strips predot and prefixes a 9011 - I want to send this as 9011! to the H323 GW so that I only need a single dial peer for CM/SRST functionality > call is sent to the H323 GW. In this flow I would expect the originating IP phone to show the called number of 3432143333 or only the manipulation thru the route pattern. If this worked as I would have expected I would have met the goal. But instead the originating IP phone shows 90113432143333. I can make this work without a problem - I went back and took the DNIS manipulation off of the route pattern - had the route list manipulate it to 3432143333 - and then have a dial peer on the GW prefix 011. But obviously not ideal - need another dial peer for SRST - and this just isn't how I expected it to function. Again I thought the rule was the phone will only reflect the manipulation up to and thru the route pattern but not what is done in the route list. Thanks Scott ________________________________ From: mn...@netelligent.com To: scarruthe...@hotmail.com; ccie_voice@onlinestudylist.com Date: Mon, 8 Feb 2010 14:24:16 -0600 Subject: RE: [OSL | CCIE_Voice] Manipulating IP Phone Called Number Display Can you give us your configuration with regards to the Route Pattern and Route List Details? The behavior you are experiencing isn't what I expect but rather what you expect is what I think I am thinking is correct, also. Mark Nigh From: scott carruthers [mailto:scarruthe...@hotmail.com] Sent: Monday, February 08, 2010 2:06 PM To: Mark Nigh; ccie_voice@onlinestudylist.com Subject: RE: [OSL | CCIE_Voice] Manipulating IP Phone Called Number Display Mark, No - there are no called party transforms. This is 100% traditional call routing. I do not have a single called party transform configured and this is intentional. So not a matter of the called party transform trumping. Thanks Scott ________________________________ From: mn...@netelligent.com To: scarruthe...@hotmail.com; ccie_voice@onlinestudylist.com Date: Mon, 8 Feb 2010 13:38:12 -0600 Subject: RE: [OSL | CCIE_Voice] Manipulating IP Phone Called Number Display Scott, Called Xforms will trump all and match the called number at the point of it matching the route pattern. Do you still have your called xform configured? If so, you are matching on that thus changing the display of the phone. You mention "no transform in play", but wasn't sure if that meant configured? Mark Nigh From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of scott carruthers Sent: Monday, February 08, 2010 6:39 AM To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] Manipulating IP Phone Called Number Display This is the goal: -From an HQ phone a call is placed to an international number -The DNIS is dialed as 90113432143333 -The request is to allow the call to complete and after call completion the calling party's IP phone should be updated so that the access and international codes are stripped -In other words - HQ places a call to 90113432143333 - once the call completes the HQ phone display should be updated to show the called party number as 3432143333 -Using called party transforms on the GW this is simple to do - any manipulation done via the transform will be updated on the originating IP phone -But I want a clean method of accomplishing this goal using traditional call routing. So for the call placed - in my topology - I am routing the call thru a route pattern of 9.011! - this points to a route list in which I am stripping predot - no transforms in play - traditional/old school call routing only. -What I expected to happen was the DNIS manipulation only thru the route pattern would affect the calling party's IP phone display. So if left as I have stated thus far - the display would remain as 90113432143333. Thus I was of the belief if I wanted to accomplish the task I could tweak the route pattern to be 9011.! - strip it predot at the route pattern - solely to affect the display on the IP phone - and then change the route list to strip predot at the route overriding what was done at the route pattern and allowing the correct digits to be sent to the GW. I expected my goal would be accomplished with this methodology - the display would update correctly based on the maniplulation up to and thru the route pattern and would override those manipulations at the route list level for actual call routing. -What I seemed to experience - however - was that the DNIS manipulation at the route list level affected the display on the calling party's phone. So in the above example the IP phone would display 0113432143333 once connected and not 3432143333 as requested. Any thoughts? Have others played around with manipulating the calling party's called number display to reflect a specific requested number of digits without using dialed number transforms? The HQ GW in my example was H323 - during my next lab I want to see if this equation changes if it is instead MGCP and possibly in this scenario the changes only made thru the route pattern level and not thru the route list level would impact the display on the calling party's phone - but I wouldn't have expected there to be a difference in this functionality based on the signaling protocol. I accomplished the task by - in this case - manipulating the DNIS to 3432143333 at the route list level and then dealt with the digits that would be sent to the telco on the H.323 GW but I am trying to ascertain if this is expected behavior and the cleanest method of accomplishing the task. ________________________________ Hotmail: Free, trusted and rich email service. Get it now.<http://clk.atdmt.com/GBL/go/201469228/direct/01/> ________________________________ This transmission and any attached files are privileged, confidential or otherwise the exclusive property of the intended recipient or Netelligent Corporation. If you are not the intended recipient, any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is strictly prohibited. If you have received this transmission in error, please contact us immediately by responding to this message or by telephone (314-392-6900) and promptly destroy the original transmission and its attachments. ________________________________ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now.<http://clk.atdmt.com/GBL/go/201469229/direct/01/> ________________________________ This transmission and any attached files are privileged, confidential or otherwise the exclusive property of the intended recipient or Netelligent Corporation. If you are not the intended recipient, any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is strictly prohibited. If you have received this transmission in error, please contact us immediately by responding to this message or by telephone (314-392-6900) and promptly destroy the original transmission and its attachments. ________________________________ Hotmail: Powerful Free email with security by Microsoft. Get it now.<http://clk.atdmt.com/GBL/go/201469230/direct/01/> ________________________________ This transmission and any attached files are privileged, confidential or otherwise the exclusive property of the intended recipient or Netelligent Corporation. If you are not the intended recipient, any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is strictly prohibited. If you have received this transmission in error, please contact us immediately by responding to this message or by telephone (314-392-6900) and promptly destroy the original transmission and its attachments.
<<inline: image001.gif>>
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
