When doing it under Call Routing > Transformation Pattern > Calling Party Transformation you have to use \+
When doing it on the Calling Party transform mask on a Route Pattern or Route List you don't use \ On Oct 1, 2010, at 10:44 AM, sisiaji wrote: > calling party transformation is done without prefix \ > > > > > > On Fri, Oct 1, 2010 at 7:00 PM, Mark Holloway <m...@markholloway.com> wrote: > The crazy thing is I tried this but I couldn't get it to work. > > PT_HQ_CALLING_OUT assigned to CSS_HQ_CALLING_OUT assigned to CALLING Number > Transform on the Outbound portion of the HQ gateway. > > Calling Party Transformation: PT_HQ_CALLING_OUT pattern is \+1480.! > (replace 480 with what your HQ area code is) > > Strip Predot > > That should make the outbound From number +14805552001 appear as 5552001 on > the PSTN phone. and I should see 5552001 in the isdn q931 debug output. I'm > still seeing the full E164 number. > > > On Oct 1, 2010, at 9:22 AM, Graham Hopkins wrote: > >> Well I'm just showing the full E.164 as that's what the lab I'm looking at >> looks for. However I guess you could strip the HQ area code at the gateway >> with the calling party transformation. >> >> In the real world (plan to visit that soon) then the remote destination is >> likely to be a mobile phone which isn't really local to any gateway - at >> least not here in the UK so would be a national call from anywhere. >> >> >> >> Graham >> >> >> >> On 1 Oct 2010, at 17:10, Mark Holloway wrote: >> >>> Sorry, I meant Translation Patterns, not Profiles. Still working on the >>> From number presentation. I'm assuming that if HQ1 calls HQ3 the PSTN >>> phone should show a 7 digit From number, but if BR1 calls 2003 the PSTN >>> should show a 10 digit From number. Would you guys agree? >>> >>> >>> >>> On Oct 1, 2010, at 8:56 AM, Mark Holloway wrote: >>> >>>> Graham, same thing here. >>>> >>>> This is a summary of what I've done to get it working correctly. I >>>> eliminated using Translation Profiles as I didn't find them necessary for >>>> this. >>>> >>>> Create PT_SNR which is assigned to CSS_SNR >>>> >>>> Create a Remote Destination Profile and assign CSS_SNR to both Calling >>>> Search Space and Rerouting Calling Search Space. Build/associate your end >>>> user with this Remote Destination Profile. Build a Route List (RL_SNR) >>>> that includes just the HQ gateway and set the Calling Party External Phone >>>> Mask to On. Doing this in the Route Pattern won't work. Set Called Party >>>> to Subscriber (assuming the Remote Destination number is a local number). >>>> Lastly, build a Route Pattern that matches your Remote Destination Profile >>>> external number and assign it to PT_SNR and RL_SNR. >>>> >>>> The only thing about this method is that when calls from 2001 ring 2003 >>>> which rings the PSTN, this method is using the external mask which means >>>> HQ1's external mask is E164. Typically when a Subscriber call egresses the >>>> HQ gateway you would want the From number to be 7 digits. Are you guys >>>> putting a Calling Party Transformation on your HQ gateway to strip off the >>>> HQ area code for Subscriber calls? For all other purposes of presenting >>>> 7, 10, or E164, I have always used the Calling Party Transform in either >>>> the Route Pattern or Route List's Route Group. >>>> >>>> >>>> Thanks, >>>> Mark >>>> >>>> >>>> On Oct 1, 2010, at 7:25 AM, Graham Hopkins wrote: >>>> >>>>> Just hit the same problem in Vol2 Lab4 and I can confirm that this >>>>> doesn't work at the RP level but does work at the RL level. Is this a >>>>> known bug ? >>>>> >>>>> >>>>> >>>>> Graham >>>>> >>>>> >>>>> >>>>> On 1 Oct 2010, at 13:35, Tam Nhu wrote: >>>>> >>>>>> Hi Mark, >>>>>> The EPNM does not work at RP for SNR. Have you try to set EPNM at RL >>>>>> level? >>>>>> >>>>>> TN. >>>>>> _______________________________________________ >>>>>> 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 >>> >> > > > _______________________________________________ > 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
