Ì have written down on my notes from the VoDs I watched and from testing
done that H323 gateways and cosmetic effect in calling device display is
achieved by the following on calls that traverse H323 gateways:
Any digit manipulation performed in:
RP or RL or RG or Inbound dial-peer or Num-Exp will affect the calling
device display whereas manipulation performed in outbouond dial-peer does
not affect the calling device screen.  I think this explains your workaround
and to be honest I think the for you to achieve your requirement you got to
go down this track.  The other option you may have is to do called party
xfoms on the egress BR1 gateway and then use the no supplementary-service
h225-notify CID-update on the H323 gateway or do your H323 DNIS dgt
manipulation on the outbound dial-peer.

I'm unware of any service params for this but sometimes when I am 100% sure
something is correctly configured but does not work I reboot my servers.
Have you given your boxes a kick after attempting the no
supplementary-service h225-notify CID-update config?

I need to try this myself but wanted to provide a suggestion.  let us know
what your findings are.  I'm still a bit far from the lab you are doing.

Cheers
Daniel

On Sat, Jul 24, 2010 at 6:21 AM, Brian Valentine <bkvalent...@gmail.com>wrote:

> "no supplementary-service h225-notify cid-update" doesn't seem to help.
>
> I had an epiphany and figured out a work around to accomplish the
> task.  What the PG suggests seems to work fine, but only on an MGCP
> gateway.   I had to build an additional dial-peer in my BR1 gw with
> destination-pattern 415888.... (forward digits 7).  So, from CUCMs
> perspective, it sends the gateway 4158884343.  If I do the
> manipulation on the H323 gateway, it works. HQ Phone 2 will basically
> send whatever CUCM sends an H323 gateway.
>
> Maybe there is a service param somewhere?
>
> Brian
>
> On Fri, Jul 23, 2010 at 2:15 PM, Matthew Berry <ciscovoiceg...@gmail.com>
> wrote:
> > Voice service voip
> > No supplementary-service h225-notify CID-update
> >
> >
> > Matthew Berry
> >
> > **Sent from my iPhone**
> > Skype/Twitter: ciscovoiceguru
> > Google Voice: +1 612 424 5044
> >
> > On Jul 23, 2010, at 12:31, Brian Valentine <bkvalent...@gmail.com>
> wrote:
> >
> >> I'm working on Vol2 Lab7 Task2.4.  The task involves the following:
> >>
> >> HQ phone 2 dials 914158884343.
> >> Prefer to use TEHO to route the call out BR1.  Local telco expects 7
> >> digits.  BR1 is an H323 gateway, so CUCM sends it 98884343.  The
> >> gateway strips the 9 before sending to telco.
> >> Second choice gateway is the HQ gateway, which is MGCP.  Local telco
> >> will expect 11 digits.  CUCM would send the gateway 14158884343.
> >> Regardless of which gateway the call goes out the HQ Phone 2 display
> >> should say: "To 4158884343".
> >>
> >> Got the call routing and redundancy down fine.  That's works well
> >> enough.  The problem is that no matter what I do, it seems to convert
> >> the display on HQ Phone 2 to match whatever digit manipulation was
> >> required by the egress gateway.  The proctor guide says: "The display
> >> on the Calling phone will be derived from the Route Pattern
> >> manipulation although the actual digits the UCM sends to the gateway
> >> is determined by the Route List/Route Group Called # transformations".
> >> So, I tried that.  I tried doing all my digit manipulation on the RL
> >> details level and use the XXXXXXXXXX as the Called Party
> >> transformation on the Route Pattern level.  Call goes through, but the
> >> HQ Phone 2 still displays "To: 98884343".
> >>
> >> Next I tried setting the RL details to leave it as 415888XXXX and used
> >> a Called Party Transformation Pattern at the gateway level to convert
> >> the call.  I got the same result. Call succeeds.  The display on HQ
> >> Phone 2 shows "To: 98884343".  What am I missing?  Is this task
> >> possible?
> >>
> >> Thanks in advance,
> >>
> >> Brian
> >> _______________________________________________
> >> For more information regarding industry leading CCIE Lab training,
> please visit www.ipexpert.com
> >
> _______________________________________________
> For more information regarding industry leading CCIE Lab training, please
> visit www.ipexpert.com
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to