The only issue with this is you don't know if the calling party is Subscriber, National, or International, so you can't use XXXXXXX because if BR2 or BR1 calls HQ3 the From number would only show the first 7 digits.
On Oct 1, 2010, at 11:21 AM, sisiaji wrote: > yeah, you are right, I was referring to RP/RL transformations... > > i tested it and i got the same in my lab > > so i guess, as you already mentioned before, the way to do it is to actually > put Calling Party Transform Mask to be XXXXXXX on the RL (for RG member). > > > > On Fri, Oct 1, 2010 at 7:52 PM, Mark Holloway <m...@markholloway.com> wrote: > 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
