[OSL | CCIE_Voice] Single Number Reach
Hello, My works but i do not see "In Use Remote" when i pick from the PSTN phone. Also, when i try to use mobility feature, i get this message "you are not a valid mobile phone user" Any with any idea of what could be the cause ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
[OSL | CCIE_Voice] Single Number Reach
I'm having a hard time when an internal extension calls another internal extension that uses SNR, the "From" phone number on the PSTN phone is 4 digits instead of 7. For example, extension 2001 calls 2003, and 2003 simultaneously rings a PSTN phone number. The display on the PSTN phone says HqPh1 (2001) instead of the 7 digit or 10 digit number. I have created PT_SNR which is assigned to CSS_SNR. I have CSS_SNR assigned to the Remote Destination Profile for both CSS and Redirecting CSS. My SNR number is +14086347694 and I have a route pattern that contains \+1408.6347694 which egresses the RL_HQ_ONLY (this is not Standard Local Route Group). I also created a Translation Pattern with PT_SNR and I have checked Use External Phone Number Mask. I was expecting this to take the 4 digit Calling number and insert the External mask instead. I tried following the steps in the Mock Lab guide (I believe it is Lab 6) but I still cannot get it working. Any assistance would be appreciated. Perhaps someone has a blog post? Thanks, Mark ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
[OSL | CCIE_Voice] Single Number Reach
Hello experts, Happy Holidays! I was in a vRack session this morning. I worked on Single Number Reach. Here was my problem: PSTN->Br1(SNR), both Br1 and PSTN rang, SNR worked. HQ1->Br1(SNR), only Br1 rang, PSTN did not ring, but when I chose to push the call out to mobile phone using Mobility softkey, PSTN rang and I could answer the call without drop the connection. Has anyone seen this problem before? I did not understand why SNR would not work when calling from HQ, or Br2 site phones. Thank you in advance. ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Voice] Single Number Reach
Do you have and user account assigned to the IP Phone and does the user account have the 'Enable Mobility' option checked? http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/7_0_1/ccmfeat/f smobmgr.html#wp1221200 Jeff. From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Omotayo Sent: Tuesday, November 10, 2009 2:17 AM To: OSL Group Subject: [OSL | CCIE_Voice] Single Number Reach Hello, My works but i do not see "In Use Remote" when i pick from the PSTN phone. Also, when i try to use mobility feature, i get this message "you are not a valid mobile phone user" Any with any idea of what could be the cause ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Voice] Single Number Reach
Hello, i have added he userid to the phone and now i can use the mobility button but i still do not see "IN Use Remote" Any ideas? Regards On Tue, Nov 10, 2009 at 4:28 PM, Jeff Knuckle wrote: > Do you have and user account assigned to the IP Phone and does the user > account have the ‘Enable Mobility’ option checked? > > > > > http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/7_0_1/ccmfeat/fsmobmgr.html#wp1221200 > > > > Jeff. > > > > *From:* ccie_voice-boun...@onlinestudylist.com [mailto: > ccie_voice-boun...@onlinestudylist.com] *On Behalf Of *Omotayo > *Sent:* Tuesday, November 10, 2009 2:17 AM > *To:* OSL Group > *Subject:* [OSL | CCIE_Voice] Single Number Reach > > > > Hello, > > > My works but i do not see "In Use Remote" when i pick from the PSTN phone. > Also, when i try to use mobility feature, i get this message "you are not a > valid mobile phone user" > > > Any with any idea of what could be the cause > ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Voice] Single Number Reach
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
Re: [OSL | CCIE_Voice] Single Number Reach
If I'm following your example correctly, Mark, then you aren't hitting on the translation pattern. The SNR call is matching the \+1408.6347694 RP, to go out, why would it be hitting the translation pattern? Perhaps you meant to configure this as a Calling Party Transformation? mike On Fri, Oct 1, 2010 at 2:38 AM, Mark Holloway wrote: > I'm having a hard time when an internal extension calls another internal > extension that uses SNR, the "From" phone number on the PSTN phone is 4 > digits instead of 7. For example, extension 2001 calls 2003, and 2003 > simultaneously rings a PSTN phone number. The display on the PSTN phone > says HqPh1 (2001) instead of the 7 digit or 10 digit number. > > I have created PT_SNR which is assigned to CSS_SNR. I have CSS_SNR > assigned to the Remote Destination Profile for both CSS and Redirecting CSS. > My SNR number is +14086347694 and I have a route pattern that contains > \+1408.6347694 which egresses the RL_HQ_ONLY (this is not Standard Local > Route Group). I also created a Translation Pattern with PT_SNR and I > have checked Use External Phone Number Mask. I was expecting this to take > the 4 digit Calling number and insert the External mask instead. I tried > following the steps in the Mock Lab guide (I believe it is Lab 6) but I > still cannot get it working. Any assistance would be appreciated. Perhaps > someone has a blog post? > > Thanks, > Mark > > ___ > 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
Re: [OSL | CCIE_Voice] Single Number Reach
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
Re: [OSL | CCIE_Voice] Single Number Reach
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
Re: [OSL | CCIE_Voice] Single Number Reach
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
Re: [OSL | CCIE_Voice] Single Number Reach
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
Re: [OSL | CCIE_Voice] Single Number Reach
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
Re: [OSL | CCIE_Voice] Single Number Reach
calling party transformation is done without prefix \ On Fri, Oct 1, 2010 at 7:00 PM, Mark Holloway 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
Re: [OSL | CCIE_Voice] Single Number Reach
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 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
Re: [OSL | CCIE_Voice] Single Number Reach
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 XXX on the RL (for RG member). On Fri, Oct 1, 2010 at 7:52 PM, Mark Holloway 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 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
Re: [OSL | CCIE_Voice] Single Number Reach
The only issue with this is you don't know if the calling party is Subscriber, National, or International, so you can't use XXX 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 XXX on the RL (for RG member). > > > > On Fri, Oct 1, 2010 at 7:52 PM, Mark Holloway 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 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 > > __
Re: [OSL | CCIE_Voice] Single Number Reach
Same here , I was beginning to think that no patterns are matched in calling number transformations - but I tested with a pattern of ! and a mask of 12345 and that works. So it would appear that there is a mismatch between \+1480.! and the calling number, which does seem odd as if you leave it alone it gets sent to the PSTN as +1480XXX. It would appear that it should match as the pattern ! with XXX works, but as Mark says this doesn't do what he requires Graham On 1 Oct 2010, at 19:23, Mark Holloway wrote: > The only issue with this is you don't know if the calling party is > Subscriber, National, or International, so you can't use XXX 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 XXX on the RL (for RG member). >> >> >> >> On Fri, Oct 1, 2010 at 7:52 PM, Mark Holloway 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 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 >>> kn
Re: [OSL | CCIE_Voice] Single Number Reach
Remote Destination Profile has a Rerouting Calling Search Space. -Original Message- From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Mark Holloway Sent: Friday, October 01, 2010 3:39 AM To: osl osl Subject: [OSL | CCIE_Voice] Single Number Reach I'm having a hard time when an internal extension calls another internal extension that uses SNR, the "From" phone number on the PSTN phone is 4 digits instead of 7. For example, extension 2001 calls 2003, and 2003 simultaneously rings a PSTN phone number. The display on the PSTN phone says HqPh1 (2001) instead of the 7 digit or 10 digit number. I have created PT_SNR which is assigned to CSS_SNR. I have CSS_SNR assigned to the Remote Destination Profile for both CSS and Redirecting CSS. My SNR number is +14086347694 and I have a route pattern that contains \+1408.6347694 which egresses the RL_HQ_ONLY (this is not Standard Local Route Group). I also created a Translation Pattern with PT_SNR and I have checked Use External Phone Number Mask. I was expecting this to take the 4 digit Calling number and insert the External mask instead. I tried following the steps in the Mock Lab guide (I believe it is Lab 6) but I still cannot get it working. Any assistance would be appreciated. Perhaps someone has a blog post? Thanks, Mark ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com - Disclaimer: This e-mail communication and any attachments may contain confidential and privileged information and is for use by the designated addressee(s) named above only. If you are not the intended addressee, you are hereby notified that you have received this communication in error and that any use or reproduction of this email or its contents is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer. Thank you. ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Voice] Single Number Reach
Is there a specific setting to force the ip phone to display an "in use" message in the event the pstn phone answers the incoming call? On Oct 1, 2010, at 11:42 AM, Graham Hopkins wrote: > Same here , I was beginning to think that no patterns are matched in calling > number transformations - but I tested with a pattern of ! and a mask of > 12345 and that works. > > So it would appear that there is a mismatch between \+1480.! and the calling > number, which does seem odd as if you leave it alone it gets sent to the PSTN > as +1480XXX. It would appear that it should match as the pattern ! with > XXX works, but as Mark says this doesn't do what he requires > > > Graham > > > > On 1 Oct 2010, at 19:23, Mark Holloway wrote: > >> The only issue with this is you don't know if the calling party is >> Subscriber, National, or International, so you can't use XXX 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 XXX on the RL (for RG >>> member). >>> >>> >>> >>> On Fri, Oct 1, 2010 at 7:52 PM, Mark Holloway 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 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 t
Re: [OSL | CCIE_Voice] Single Number Reach
Turn off privacy Roger Källberg CCIE # 26199 (Voice) Unified Communication Consultant Cygate AB From: Mark Holloway [mailto:m...@markholloway.com] Sent: den 2 oktober 2010 06:24 To: Graham Hopkins Cc: CCIE Voice Maillist Subject: Re: [OSL | CCIE_Voice] Single Number Reach Is there a specific setting to force the ip phone to display an "in use" message in the event the pstn phone answers the incoming call? On Oct 1, 2010, at 11:42 AM, Graham Hopkins wrote: Same here , I was beginning to think that no patterns are matched in calling number transformations - but I tested with a pattern of ! and a mask of 12345 and that works. So it would appear that there is a mismatch between \+1480.! and the calling number, which does seem odd as if you leave it alone it gets sent to the PSTN as +1480XXX. It would appear that it should match as the pattern ! with XXX works, but as Mark says this doesn't do what he requires Graham On 1 Oct 2010, at 19:23, Mark Holloway wrote: The only issue with this is you don't know if the calling party is Subscriber, National, or International, so you can't use XXX 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 XXX on the RL (for RG member). On Fri, Oct 1, 2010 at 7:52 PM, Mark Holloway mailto: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 mailto: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 d
Re: [OSL | CCIE_Voice] Single Number Reach
Hmm, for Single Number Reach? If a call comes in to HQ3 and simultaneously rings the PSTN/SNR number, and the PSTN answers the calls, I believe there is a way for the HQ3 phone to display on its screen that it is "in use". Turning off Privacy for HQ3 didn't change that behavior. :/ On Oct 3, 2010, at 4:30 AM, Roger Källberg wrote: > Turn off privacy > > Roger Källberg > CCIE # 26199 (Voice) > Unified Communication Consultant > Cygate AB > > > From: Mark Holloway [mailto:m...@markholloway.com] > Sent: den 2 oktober 2010 06:24 > To: Graham Hopkins > Cc: CCIE Voice Maillist > Subject: Re: [OSL | CCIE_Voice] Single Number Reach > > Is there a specific setting to force the ip phone to display an "in use" > message in the event the pstn phone answers the incoming call? > > > On Oct 1, 2010, at 11:42 AM, Graham Hopkins wrote: > > > Same here , I was beginning to think that no patterns are matched in calling > number transformations - but I tested with a pattern of ! and a mask of > 12345 and that works. > > So it would appear that there is a mismatch between \+1480.! and the calling > number, which does seem odd as if you leave it alone it gets sent to the PSTN > as +1480XXX. It would appear that it should match as the pattern ! with > XXX works, but as Mark says this doesn't do what he requires > > > Graham > > > > On 1 Oct 2010, at 19:23, Mark Holloway wrote: > > > The only issue with this is you don't know if the calling party is > Subscriber, National, or International, so you can't use XXX 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 XXX on the RL (for RG member). > > > > On Fri, Oct 1, 2010 at 7:52 PM, Mark Holloway 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 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. >
Re: [OSL | CCIE_Voice] Single Number Reach
Never mind, I believe I have done it correctly. When the PSTN phone answers an SNR call, then only way I can get HQPH3 to show "In Use Remote" is to actually press the Line 1 button on HQPH3 and then it displays In Use Remote on the phone. On Oct 3, 2010, at 10:18 AM, Mark Holloway wrote: > Hmm, for Single Number Reach? If a call comes in to HQ3 and simultaneously > rings the PSTN/SNR number, and the PSTN answers the calls, I believe there is > a way for the HQ3 phone to display on its screen that it is "in use". > Turning off Privacy for HQ3 didn't change that behavior. :/ > > > > On Oct 3, 2010, at 4:30 AM, Roger Källberg wrote: > >> Turn off privacy >> >> Roger Källberg >> CCIE # 26199 (Voice) >> Unified Communication Consultant >> Cygate AB >> >> >> From: Mark Holloway [mailto:m...@markholloway.com] >> Sent: den 2 oktober 2010 06:24 >> To: Graham Hopkins >> Cc: CCIE Voice Maillist >> Subject: Re: [OSL | CCIE_Voice] Single Number Reach >> >> Is there a specific setting to force the ip phone to display an "in use" >> message in the event the pstn phone answers the incoming call? >> >> >> On Oct 1, 2010, at 11:42 AM, Graham Hopkins wrote: >> >> >> Same here , I was beginning to think that no patterns are matched in calling >> number transformations - but I tested with a pattern of ! and a mask of >> 12345 and that works. >> >> So it would appear that there is a mismatch between \+1480.! and the calling >> number, which does seem odd as if you leave it alone it gets sent to the >> PSTN as +1480XXX. It would appear that it should match as the pattern ! >> with XXX works, but as Mark says this doesn't do what he requires >> >> >> Graham >> >> >> >> On 1 Oct 2010, at 19:23, Mark Holloway wrote: >> >> >> The only issue with this is you don't know if the calling party is >> Subscriber, National, or International, so you can't use XXX 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 XXX on the RL (for RG member). >> >> >> >> On Fri, Oct 1, 2010 at 7:52 PM, Mark Holloway 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 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 di
Re: [OSL | CCIE_Voice] Single Number Reach
Hi Mark Turn off privacy in remote destination profile Rgds Grant On Sunday, October 3, 2010, Mark Holloway wrote: > Never mind, I believe I have done it correctly. When the PSTN phone answers > an SNR call, then only way I can get HQPH3 to show "In Use Remote" is to > actually press the Line 1 button on HQPH3 and then it displays In Use Remote > on the phone. > > On Oct 3, 2010, at 10:18 AM, Mark Holloway wrote: > Hmm, for Single Number Reach? If a call comes in to HQ3 and simultaneously > rings the PSTN/SNR number, and the PSTN answers the calls, I believe there is > a way for the HQ3 phone to display on its screen that it is "in use". > Turning off Privacy for HQ3 didn't change that behavior. :/ > > > On Oct 3, 2010, at 4:30 AM, Roger Källberg wrote: > Turn off privacy Roger Källberg > CCIE # 26199 (Voice) > Unified Communication Consultant > Cygate AB > > From: Mark Holloway [mailto:m...@markholloway.com] > Sent: den 2 oktober 2010 06:24 > To: Graham Hopkins > Cc: CCIE Voice Maillist > Subject: Re: [OSL | CCIE_Voice] Single Number Reach Is there a specific > setting to force the ip phone to display an "in use" message in the event the > pstn phone answers the incoming call? On Oct 1, 2010, at 11:42 AM, Graham > Hopkins wrote: > > Same here , I was beginning to think that no patterns are matched in calling > number transformations - but I tested with a pattern of ! and a mask of > 12345 and that works. -- keep living the dream ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Voice] Single Number Reach
I believe the requirement is not to display on the screen "remote in use". Just the fact that the line turns amber, it means the line status "remote in use" which should be enough. Does it turn amber ? On Sun, Oct 3, 2010 at 3:02 PM, Grant Teague wrote: > Hi Mark > > Turn off privacy in remote destination profile > > Rgds > > Grant > > On Sunday, October 3, 2010, Mark Holloway wrote: > > Never mind, I believe I have done it correctly. When the PSTN phone > answers an SNR call, then only way I can get HQPH3 to show "In Use Remote" > is to actually press the Line 1 button on HQPH3 and then it displays In Use > Remote on the phone. > > > > On Oct 3, 2010, at 10:18 AM, Mark Holloway wrote: > > Hmm, for Single Number Reach? If a call comes in to HQ3 and > simultaneously rings the PSTN/SNR number, and the PSTN answers the calls, I > believe there is a way for the HQ3 phone to display on its screen that it is > "in use". Turning off Privacy for HQ3 didn't change that behavior. :/ > > > > > > On Oct 3, 2010, at 4:30 AM, Roger Källberg wrote: > > Turn off privacy Roger Källberg > > CCIE # 26199 (Voice) > > Unified Communication Consultant > > Cygate AB > > > > From: Mark Holloway [mailto:m...@markholloway.com] > > Sent: den 2 oktober 2010 06:24 > > To: Graham Hopkins > > Cc: CCIE Voice Maillist > > Subject: Re: [OSL | CCIE_Voice] Single Number Reach Is there a specific > setting to force the ip phone to display an "in use" message in the event > the pstn phone answers the incoming call?On Oct 1, 2010, at 11:42 AM, > Graham Hopkins wrote: > > > > Same here , I was beginning to think that no patterns are matched in > calling number transformations - but I tested with a pattern of ! and a > mask of 12345 and that works. > > > -- > keep living the dream > ___ > For more information regarding industry leading CCIE Lab training, please > visit www.ipexpert.com > -- Randall "da ill" Saborio CCIE Voice Wannabe #10054675811 ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Voice] Single Number Reach
Turn off privacy on the RDP. Roger Källberg CCIE #26199 (Voice) Consultant Cygate AB Eric Perssons väg 21, SE-217 62 MALMÖ Direkt: +46108787498 Växel: +46108787400 roger.kallb...@cygate.se<mailto:roger.kallb...@cygate.se> Från: Mark Holloway [...@markholloway.com] Skickat: den 3 oktober 2010 19:18 Till: Roger Källberg Kopia: Graham Hopkins; CCIE Voice Maillist Ämne: Re: [OSL | CCIE_Voice] Single Number Reach Hmm, for Single Number Reach? If a call comes in to HQ3 and simultaneously rings the PSTN/SNR number, and the PSTN answers the calls, I believe there is a way for the HQ3 phone to display on its screen that it is "in use". Turning off Privacy for HQ3 didn't change that behavior. :/ On Oct 3, 2010, at 4:30 AM, Roger Källberg wrote: Turn off privacy Roger Källberg CCIE # 26199 (Voice) Unified Communication Consultant Cygate AB From: Mark Holloway [mailto:m...@markholloway.com] Sent: den 2 oktober 2010 06:24 To: Graham Hopkins Cc: CCIE Voice Maillist Subject: Re: [OSL | CCIE_Voice] Single Number Reach Is there a specific setting to force the ip phone to display an "in use" message in the event the pstn phone answers the incoming call? On Oct 1, 2010, at 11:42 AM, Graham Hopkins wrote: Same here , I was beginning to think that no patterns are matched in calling number transformations - but I tested with a pattern of ! and a mask of 12345 and that works. So it would appear that there is a mismatch between \+1480.! and the calling number, which does seem odd as if you leave it alone it gets sent to the PSTN as +1480XXX. It would appear that it should match as the pattern ! with XXX works, but as Mark says this doesn't do what he requires Graham On 1 Oct 2010, at 19:23, Mark Holloway wrote: The only issue with this is you don't know if the calling party is Subscriber, National, or International, so you can't use XXX 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 XXX on the RL (for RG member). On Fri, Oct 1, 2010 at 7:52 PM, Mark Holloway mailto: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 mailto: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
Re: [OSL | CCIE_Voice] Single Number Reach
Mark, having done some further tests, I now have this working - the key here is that the calling number transformation pattern matches the calling number at the time the route pattern was matched. So this is likely to be 2001 as I presume that the external phone number masked is applied as a transform on the route pattern. Therefore alter your calling party transform pattern to 2XXX ( or whatever the best pattern fro HQ is) and prefix the 555. Other sites will still show the full E.164 number. Graham On 1 Oct 2010, at 18:00, Mark Holloway 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
Re: [OSL | CCIE_Voice] Single Number Reach
Fantastic. Thank you for taking the time to do this and for sharing it with everyone. On Oct 4, 2010, at 10:08 AM, Graham Hopkins wrote: > > Mark, > > having done some further tests, I now have this working - the key here is > that the calling number transformation pattern matches the calling number at > the time the route pattern was matched. So this is likely to be 2001 as I > presume that the external phone number masked is applied as a transform on > the route pattern. > > Therefore alter your calling party transform pattern to 2XXX ( or whatever > the best pattern fro HQ is) and prefix the 555. Other sites will still show > the full E.164 number. > > > > Graham > > > > On 1 Oct 2010, at 18:00, Mark Holloway 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
Re: [OSL | CCIE_Voice] Single Number Reach
Yeah just glad I finally got my head around it. For anyone having issues with how the various patterns are matched and the transformations are applied I suggest that is worth setting up the following: Translation pattern -> RP > RL > Transformation Pattern at the Gateway and then applying changes at different points and monitoring the results to get a good understanding of where patterns are matched and which transformations "overwrite" other ones. Dial Number Analyzer is also pretty handy here if something doesn't match and you think it should Graham On 4 Oct 2010, at 18:41, Mark Holloway wrote: > Fantastic. Thank you for taking the time to do this and for sharing it with > everyone. > > On Oct 4, 2010, at 10:08 AM, Graham Hopkins wrote: > >> >> Mark, >> >> having done some further tests, I now have this working - the key here is >> that the calling number transformation pattern matches the calling number at >> the time the route pattern was matched. So this is likely to be 2001 as I >> presume that the external phone number masked is applied as a transform on >> the route pattern. >> >> Therefore alter your calling party transform pattern to 2XXX ( or whatever >> the best pattern fro HQ is) and prefix the 555. Other sites will still show >> the full E.164 number. >> >> >> >> Graham >> >> >> >> On 1 Oct 2010, at 18:00, Mark Holloway 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
Re: [OSL | CCIE_Voice] Single Number Reach
I created two calling party transformation patterns. 2XXX becomes HQ 7 digit external number 3XXX becomes BR1 10 digit external number No need to touch BR2 since everything else uses E164 anyway. On Oct 4, 2010, at 11:00 AM, Graham Hopkins wrote: > Yeah just glad I finally got my head around it. For anyone having issues > with how the various patterns are matched and the transformations are applied > I suggest that is worth setting up the following: > > Translation pattern -> RP > RL > Transformation Pattern at the Gateway and > then applying changes at different points and monitoring the results to get a > good understanding of where patterns are matched and which transformations > "overwrite" other ones. > > Dial Number Analyzer is also pretty handy here if something doesn't match and > you think it should > > Graham > > > On 4 Oct 2010, at 18:41, Mark Holloway wrote: > >> Fantastic. Thank you for taking the time to do this and for sharing it with >> everyone. >> >> On Oct 4, 2010, at 10:08 AM, Graham Hopkins wrote: >> >>> >>> Mark, >>> >>> having done some further tests, I now have this working - the key here is >>> that the calling number transformation pattern matches the calling number >>> at the time the route pattern was matched. So this is likely to be 2001 as >>> I presume that the external phone number masked is applied as a transform >>> on the route pattern. >>> >>> Therefore alter your calling party transform pattern to 2XXX ( or whatever >>> the best pattern fro HQ is) and prefix the 555. Other sites will still >>> show the full E.164 number. >>> >>> >>> >>> Graham >>> >>> >>> >>> On 1 Oct 2010, at 18:00, Mark Holloway 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
Re: [OSL | CCIE_Voice] Single Number Reach
Did the HQ1 phone have access to the route pattern to call the BR1 SNR Number? On Tue, Dec 28, 2010 at 6:06 PM, study2b ccie wrote: > Hello experts, > > Happy Holidays! > > I was in a vRack session this morning. I worked on Single Number Reach. > Here was my problem: > > PSTN->Br1(SNR), both Br1 and PSTN rang, SNR worked. > > HQ1->Br1(SNR), only Br1 rang, PSTN did not ring, but when I chose to push > the call out to mobile phone using Mobility softkey, PSTN rang and I could > answer the call without drop the connection. > > Has anyone seen this problem before? I did not understand why SNR would > not work when calling from HQ, or Br2 site phones. > > Thank you in advance. > > > > > ___ > 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
Re: [OSL | CCIE_Voice] Single Number Reach
Hi Prashant, After further testing, I found out the problem was caused by standard local route group, somehow it will stop routing out to SNR I set in the remote destination profile. I then created a new, separate RP/RL/RG pointing them to the SNR on SiteB, then it worked. Thank you very much for your help! On Tue, Dec 28, 2010 at 3:34 PM, Prashant Patel wrote: > Did the HQ1 phone have access to the route pattern to call the BR1 SNR > Number? > > On Tue, Dec 28, 2010 at 6:06 PM, study2b ccie > wrote: > >> Hello experts, >> >> Happy Holidays! >> >> I was in a vRack session this morning. I worked on Single Number Reach. >> Here was my problem: >> >> PSTN->Br1(SNR), both Br1 and PSTN rang, SNR worked. >> >> HQ1->Br1(SNR), only Br1 rang, PSTN did not ring, but when I chose to push >> the call out to mobile phone using Mobility softkey, PSTN rang and I could >> answer the call without drop the connection. >> >> Has anyone seen this problem before? I did not understand why SNR would >> not work when calling from HQ, or Br2 site phones. >> >> Thank you in advance. >> >> >> >> >> ___ >> 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
Re: [OSL | CCIE_Voice] Single Number Reach
I ran into this issue as well before in my own testing. My situation was SNR at HQ. Whenever I called the HQ phone I had setup for SNR from another HQ phone, it worked perfectly, but not from BR1, BR2, or the PSTN. I just used the same CSS in the RDP that I used on my unrestricted phone at HQ. So are you saying I should have created a new Route Pattern for my specific number and a new RL/RG or should I create a new CSS/PT as well and use that under the RDP? The Signature Group - A Culture of Excellence An Employee Owned Company Justin Brady Director, Commercial Operations jbr...@tsginc.biz<mailto:jbr...@tsginc.biz> www.tsginc.biz<http://www.tsginc.biz> LinkedIn Profile<http://www.linkedin.com/in/justinmbrady> [Copy of tsg_logo] Cisco: CCVP, CCNP, CCSP, CCIPx2 Cisco IP Contact Center Express Specialist Cisco IP Telephony Express Specialist Cisco Routing and Switch Field Specialist Cisco Data Center Application Support Specialist Cisco Advanced Data Center Networking Infrastructure Support Specialist INFOSEC Professional VMWARE: VSP, VTSP The Signature Group 8229 Boone Boulevard Suite 820 Vienna, VA 22182<http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=8229+Boone+Boulevard&csz=Vienna%2C+VA++22182&country=us> direct: fax: mobile: (703) 748-9534 (703) 287-0689 (703) 282-0690 * Cisco Silver Partner * Microsoft Gold Partner * Follow the Network Operations Center on Twitter: www.twitter.com/TSGSigCare<http://www.twitter.com/TSGSigCare> Follow the Network Operations Center Blog: http://tsgnoc.wordpress.com<http://tsgnoc.wordpress.com/> From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of study2b ccie Sent: Wednesday, December 29, 2010 1:57 PM To: Prashant Patel Cc: OSL Subject: Re: [OSL | CCIE_Voice] Single Number Reach Hi Prashant, After further testing, I found out the problem was caused by standard local route group, somehow it will stop routing out to SNR I set in the remote destination profile. I then created a new, separate RP/RL/RG pointing them to the SNR on SiteB, then it worked. Thank you very much for your help! On Tue, Dec 28, 2010 at 3:34 PM, Prashant Patel mailto:prashantpatel...@gmail.com>> wrote: Did the HQ1 phone have access to the route pattern to call the BR1 SNR Number? On Tue, Dec 28, 2010 at 6:06 PM, study2b ccie mailto:study4ccievo...@gmail.com>> wrote: Hello experts, Happy Holidays! I was in a vRack session this morning. I worked on Single Number Reach. Here was my problem: PSTN->Br1(SNR), both Br1 and PSTN rang, SNR worked. HQ1->Br1(SNR), only Br1 rang, PSTN did not ring, but when I chose to push the call out to mobile phone using Mobility softkey, PSTN rang and I could answer the call without drop the connection. Has anyone seen this problem before? I did not understand why SNR would not work when calling from HQ, or Br2 site phones. Thank you in advance. ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com<http://www.ipexpert.com/> <>___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Voice] Single Number Reach
When BR1 or BR2 phones dial an HQ extension that invokes SNR, the call goes from the local gateway of the Calling Phone ie BR1 or BR2 phone. This BR1 or BR2 phone needs to have a CSS that will allow the call to succeed locally. If not we can create a pt and CSS and apply it to RDP rerouting CSS. This will force the call to go through the rute pattern that has the partition. HTH Prashant On Wed, Dec 29, 2010 at 4:55 PM, Justin Brady wrote: > I ran into this issue as well before in my own testing. > > > > My situation was SNR at HQ. Whenever I called the HQ phone I had setup for > SNR from another HQ phone, it worked perfectly, but not from BR1, BR2, or > the PSTN. I just used the same CSS in the RDP that I used on my > unrestricted phone at HQ. > > > > So are you saying I should have created a new Route Pattern for my specific > number and a new RL/RG or should I create a new CSS/PT as well and use that > under the RDP? > > > > The Signature Group – A Culture of Excellence > > An Employee Owned Company > > > > *Justin Brady* > *Director, Commercial Operations* > > jbr...@tsginc.biz > www.tsginc.biz > > LinkedIn Profile <http://www.linkedin.com/in/justinmbrady> > > [image: Copy of tsg_logo] > > *Cisco: CCVP, CCNP, CCSP, CCIPx2* > > *Cisco IP Contact Center Express Specialist* > > *Cisco IP Telephony Express Specialist* > > *Cisco Routing and Switch Field Specialist* > > *Cisco Data Center Application Support Specialist* > > *Cisco Advanced Data Center Networking* > > *Infrastructure Support Specialist* > > *INFOSEC Professional* > > *VMWARE: VSP, VTSP* > > *The Signature Group* > 8229 Boone Boulevard > Suite 820 > Vienna, VA > 22182<http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=8229+Boone+Boulevard&csz=Vienna%2C+VA++22182&country=us> > > direct: > fax: > mobile: > > (703) 748-9534 > (703) 287-0689 > (703) 282-0690 > > ** Cisco Silver Partner * Microsoft Gold Partner > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Follow the Network Operations Center on Twitter: > www.twitter.com/TSGSigCare > > Follow the Network Operations Center Blog: http://tsgnoc.wordpress.com > > *From:* ccie_voice-boun...@onlinestudylist.com [mailto: > ccie_voice-boun...@onlinestudylist.com] *On Behalf Of *study2b ccie > *Sent:* Wednesday, December 29, 2010 1:57 PM > *To:* Prashant Patel > *Cc:* OSL > *Subject:* Re: [OSL | CCIE_Voice] Single Number Reach > > > > Hi Prashant, > > After further testing, I found out the problem was caused by standard local > route group, somehow it will stop routing out to SNR I set in the remote > destination profile. > > I then created a new, separate RP/RL/RG pointing them to the SNR on SiteB, > then it worked. > > Thank you very much for your help! > > > > On Tue, Dec 28, 2010 at 3:34 PM, Prashant Patel < > prashantpatel...@gmail.com> wrote: > > Did the HQ1 phone have access to the route pattern to call the BR1 SNR > Number? > > On Tue, Dec 28, 2010 at 6:06 PM, study2b ccie > wrote: > > Hello experts, > > Happy Holidays! > > I was in a vRack session this morning. I worked on Single Number Reach. > Here was my problem: > > PSTN->Br1(SNR), both Br1 and PSTN rang, SNR worked. > > HQ1->Br1(SNR), only Br1 rang, PSTN did not ring, but when I chose to push > the call out to mobile phone using Mobility softkey, PSTN rang and I could > answer the call without drop the connection. > > Has anyone seen this problem before? I did not understand why SNR would > not work when calling from HQ, or Br2 site phones. > > Thank you in advance. > > > > > ___ > 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
Re: [OSL | CCIE_Voice] Single Number Reach
My problem was that I had configured PT/CSS correctly, standard local route group was causing problems when routing to PSTN (I still have not figured out why). So if you are using standard local route group, it is better to set up a separate RP/RL/RG for SNR. Hope that helps. On Wed, Dec 29, 2010 at 2:01 PM, Prashant Patel wrote: > When BR1 or BR2 phones dial an HQ extension that invokes SNR, the call goes > from the local gateway of the Calling Phone ie BR1 or BR2 phone. This BR1 or > BR2 phone needs to have a CSS that will allow the call to succeed locally. > If not we can create a pt and CSS and apply it to RDP rerouting CSS. This > will force the call to go through the rute pattern that has the partition. > > HTH > Prashant > > On Wed, Dec 29, 2010 at 4:55 PM, Justin Brady wrote: > >> I ran into this issue as well before in my own testing. >> >> >> >> My situation was SNR at HQ. Whenever I called the HQ phone I had setup >> for SNR from another HQ phone, it worked perfectly, but not from BR1, BR2, >> or the PSTN. I just used the same CSS in the RDP that I used on my >> unrestricted phone at HQ. >> >> >> >> So are you saying I should have created a new Route Pattern for my >> specific number and a new RL/RG or should I create a new CSS/PT as well and >> use that under the RDP? >> >> >> >> The Signature Group – A Culture of Excellence >> >> An Employee Owned Company >> >> >> >> *Justin Brady* >> *Director, Commercial Operations* >> >> jbr...@tsginc.biz >> www.tsginc.biz >> >> LinkedIn Profile <http://www.linkedin.com/in/justinmbrady> >> >> [image: Copy of tsg_logo] >> >> *Cisco: CCVP, CCNP, CCSP, CCIPx2* >> >> *Cisco IP Contact Center Express Specialist* >> >> *Cisco IP Telephony Express Specialist* >> >> *Cisco Routing and Switch Field Specialist* >> >> *Cisco Data Center Application Support Specialist* >> >> *Cisco Advanced Data Center Networking* >> >> *Infrastructure Support Specialist* >> >> *INFOSEC Professional* >> >> *VMWARE: VSP, VTSP* >> >> *The Signature Group* >> 8229 Boone Boulevard >> Suite 820 >> Vienna, VA >> 22182<http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=8229+Boone+Boulevard&csz=Vienna%2C+VA++22182&country=us> >> >> direct: >> fax: >> mobile: >> >> (703) 748-9534 >> (703) 287-0689 >> (703) 282-0690 >> >> ** Cisco Silver Partner * Microsoft Gold Partner >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Follow the Network Operations Center on Twitter: >> www.twitter.com/TSGSigCare >> >> Follow the Network Operations Center Blog: http://tsgnoc.wordpress.com >> >> *From:* ccie_voice-boun...@onlinestudylist.com [mailto: >> ccie_voice-boun...@onlinestudylist.com] *On Behalf Of *study2b ccie >> *Sent:* Wednesday, December 29, 2010 1:57 PM >> *To:* Prashant Patel >> *Cc:* OSL >> *Subject:* Re: [OSL | CCIE_Voice] Single Number Reach >> >> >> >> Hi Prashant, >> >> After further testing, I found out the problem was caused by standard >> local route group, somehow it will stop routing out to SNR I set in the >> remote destination profile. >> >> I then created a new, separate RP/RL/RG pointing them to the SNR on SiteB, >> then it worked. >> >> Thank you very much for your help! >> >> >> >> On Tue, Dec 28, 2010 at 3:34 PM, Prashant Patel < >> prashantpatel...@gmail.com> wrote: >> >> Did the HQ1 phone have access to the route pattern to call the BR1 SNR >> Number? >> >> On Tue, Dec 28, 2010 at 6:06 PM, study2b ccie >> wrote: >> >> Hello experts, >> >> Happy Holidays! >> >> I was in a vRack session this morning. I worked on Single Number Reach. >> Here was my problem: >> >> PSTN->Br1(SNR), both Br1 and PSTN rang, SNR worked. >> >> HQ1->Br1(SNR), only Br1 rang, PSTN did not ring, but when I chose to push >> the call out to mobile phone using Mobility softkey, PSTN rang and I could >> answer the call without drop the connection. >> >> Has anyone seen this problem before? I did not understand why SNR would >> not work when calling from HQ, or Br2 site phones. >> >> Thank you in advance. >> >> >> >> >> ___ >> 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
Re: [OSL | CCIE_Voice] Single Number Reach
What if I had the re-routing CSS set to the HQ-AllCalling CSS. Shouldn't it have used that? I have the system setup to use the re-routing CSS in the service parameter and applied my CSS's on the phone, not the line, so that should have worked right? Or am I missing something? Justin From: Prashant Patel [mailto:prashantpatel...@gmail.com] Sent: Wednesday, December 29, 2010 5:02 PM To: Justin Brady Cc: study2b ccie; OSL Subject: Re: [OSL | CCIE_Voice] Single Number Reach When BR1 or BR2 phones dial an HQ extension that invokes SNR, the call goes from the local gateway of the Calling Phone ie BR1 or BR2 phone. This BR1 or BR2 phone needs to have a CSS that will allow the call to succeed locally. If not we can create a pt and CSS and apply it to RDP rerouting CSS. This will force the call to go through the rute pattern that has the partition. HTH Prashant On Wed, Dec 29, 2010 at 4:55 PM, Justin Brady mailto:jbr...@tsginc.biz>> wrote: I ran into this issue as well before in my own testing. My situation was SNR at HQ. Whenever I called the HQ phone I had setup for SNR from another HQ phone, it worked perfectly, but not from BR1, BR2, or the PSTN. I just used the same CSS in the RDP that I used on my unrestricted phone at HQ. So are you saying I should have created a new Route Pattern for my specific number and a new RL/RG or should I create a new CSS/PT as well and use that under the RDP? From: ccie_voice-boun...@onlinestudylist.com<mailto:ccie_voice-boun...@onlinestudylist.com> [mailto:ccie_voice-boun...@onlinestudylist.com<mailto:ccie_voice-boun...@onlinestudylist.com>] On Behalf Of study2b ccie Sent: Wednesday, December 29, 2010 1:57 PM To: Prashant Patel Cc: OSL Subject: Re: [OSL | CCIE_Voice] Single Number Reach Hi Prashant, After further testing, I found out the problem was caused by standard local route group, somehow it will stop routing out to SNR I set in the remote destination profile. I then created a new, separate RP/RL/RG pointing them to the SNR on SiteB, then it worked. Thank you very much for your help! On Tue, Dec 28, 2010 at 3:34 PM, Prashant Patel mailto:prashantpatel...@gmail.com>> wrote: Did the HQ1 phone have access to the route pattern to call the BR1 SNR Number? On Tue, Dec 28, 2010 at 6:06 PM, study2b ccie mailto:study4ccievo...@gmail.com>> wrote: Hello experts, Happy Holidays! I was in a vRack session this morning. I worked on Single Number Reach. Here was my problem: PSTN->Br1(SNR), both Br1 and PSTN rang, SNR worked. HQ1->Br1(SNR), only Br1 rang, PSTN did not ring, but when I chose to push the call out to mobile phone using Mobility softkey, PSTN rang and I could answer the call without drop the connection. Has anyone seen this problem before? I did not understand why SNR would not work when calling from HQ, or Br2 site phones. Thank you in advance. ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com<http://www.ipexpert.com/> ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
Re: [OSL | CCIE_Voice] Single Number Reach
That was in reference to if you are using a slrg and the device pool of the rdp is used to select the local rg. Otherwise the normal css call routing is used through the rerouting css. In your case it should have worked. HTH Prashant On Wed, Dec 29, 2010 at 9:55 PM, Justin Brady wrote: > What if I had the re-routing CSS set to the HQ-AllCalling CSS. Shouldn’t > it have used that? I have the system setup to use the re-routing CSS in the > service parameter and applied my CSS’s on the phone, not the line, so that > should have worked right? Or am I missing something? > > > > Justin > > > > *From:* Prashant Patel [mailto:prashantpatel...@gmail.com] > *Sent:* Wednesday, December 29, 2010 5:02 PM > *To:* Justin Brady > *Cc:* study2b ccie; OSL > > *Subject:* Re: [OSL | CCIE_Voice] Single Number Reach > > > > When BR1 or BR2 phones dial an HQ extension that invokes SNR, the call goes > from the local gateway of the Calling Phone ie BR1 or BR2 phone. This BR1 or > BR2 phone needs to have a CSS that will allow the call to succeed locally. > If not we can create a pt and CSS and apply it to RDP rerouting CSS. This > will force the call to go through the rute pattern that has the partition. > > > > HTH > > Prashant > > On Wed, Dec 29, 2010 at 4:55 PM, Justin Brady wrote: > > I ran into this issue as well before in my own testing. > > > > My situation was SNR at HQ. Whenever I called the HQ phone I had setup for > SNR from another HQ phone, it worked perfectly, but not from BR1, BR2, or > the PSTN. I just used the same CSS in the RDP that I used on my > unrestricted phone at HQ. > > > > So are you saying I should have created a new Route Pattern for my specific > number and a new RL/RG or should I create a new CSS/PT as well and use that > under the RDP? > > > > *From:* ccie_voice-boun...@onlinestudylist.com [mailto: > ccie_voice-boun...@onlinestudylist.com] *On Behalf Of *study2b ccie > > *Sent:* Wednesday, December 29, 2010 1:57 PM > *To:* Prashant Patel > *Cc:* OSL > *Subject:* Re: [OSL | CCIE_Voice] Single Number Reach > > > > Hi Prashant, > > After further testing, I found out the problem was caused by standard local > route group, somehow it will stop routing out to SNR I set in the remote > destination profile. > > I then created a new, separate RP/RL/RG pointing them to the SNR on SiteB, > then it worked. > > Thank you very much for your help! > > > On Tue, Dec 28, 2010 at 3:34 PM, Prashant Patel < > prashantpatel...@gmail.com> wrote: > > Did the HQ1 phone have access to the route pattern to call the BR1 SNR > Number? > > On Tue, Dec 28, 2010 at 6:06 PM, study2b ccie > wrote: > > Hello experts, > > Happy Holidays! > > I was in a vRack session this morning. I worked on Single Number Reach. > Here was my problem: > > PSTN->Br1(SNR), both Br1 and PSTN rang, SNR worked. > > HQ1->Br1(SNR), only Br1 rang, PSTN did not ring, but when I chose to push > the call out to mobile phone using Mobility softkey, PSTN rang and I could > answer the call without drop the connection. > > Has anyone seen this problem before? I did not understand why SNR would > not work when calling from HQ, or Br2 site phones. > > Thank you in advance. > > > > > ___ > 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
Re: [OSL | CCIE_Voice] Single Number Reach
Very simple troubleshooting for SNR in CUCM. If Br1 Phone is configured for SNR and mobile number configured is 535 and when you are calling Br1 Ph from HQ and mobile phone is not ringing. To troubleshoot try dialing 9.535 from HQ phone and troubleshoot from there. -S _ From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Prashant Patel Sent: Wednesday, December 29, 2010 7:17 PM To: Justin Brady Cc: OSL; study2b ccie Subject: Re: [OSL | CCIE_Voice] Single Number Reach That was in reference to if you are using a slrg and the device pool of the rdp is used to select the local rg. Otherwise the normal css call routing is used through the rerouting css. In your case it should have worked. HTH Prashant On Wed, Dec 29, 2010 at 9:55 PM, Justin Brady wrote: What if I had the re-routing CSS set to the HQ-AllCalling CSS. Shouldn't it have used that? I have the system setup to use the re-routing CSS in the service parameter and applied my CSS's on the phone, not the line, so that should have worked right? Or am I missing something? Justin From: Prashant Patel [mailto:prashantpatel...@gmail.com] Sent: Wednesday, December 29, 2010 5:02 PM To: Justin Brady Cc: study2b ccie; OSL Subject: Re: [OSL | CCIE_Voice] Single Number Reach When BR1 or BR2 phones dial an HQ extension that invokes SNR, the call goes from the local gateway of the Calling Phone ie BR1 or BR2 phone. This BR1 or BR2 phone needs to have a CSS that will allow the call to succeed locally. If not we can create a pt and CSS and apply it to RDP rerouting CSS. This will force the call to go through the rute pattern that has the partition. HTH Prashant On Wed, Dec 29, 2010 at 4:55 PM, Justin Brady wrote: I ran into this issue as well before in my own testing. My situation was SNR at HQ. Whenever I called the HQ phone I had setup for SNR from another HQ phone, it worked perfectly, but not from BR1, BR2, or the PSTN. I just used the same CSS in the RDP that I used on my unrestricted phone at HQ. So are you saying I should have created a new Route Pattern for my specific number and a new RL/RG or should I create a new CSS/PT as well and use that under the RDP? From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of study2b ccie Sent: Wednesday, December 29, 2010 1:57 PM To: Prashant Patel Cc: OSL Subject: Re: [OSL | CCIE_Voice] Single Number Reach Hi Prashant, After further testing, I found out the problem was caused by standard local route group, somehow it will stop routing out to SNR I set in the remote destination profile. I then created a new, separate RP/RL/RG pointing them to the SNR on SiteB, then it worked. Thank you very much for your help! On Tue, Dec 28, 2010 at 3:34 PM, Prashant Patel wrote: Did the HQ1 phone have access to the route pattern to call the BR1 SNR Number? On Tue, Dec 28, 2010 at 6:06 PM, study2b ccie wrote: Hello experts, Happy Holidays! I was in a vRack session this morning. I worked on Single Number Reach. Here was my problem: PSTN->Br1(SNR), both Br1 and PSTN rang, SNR worked. HQ1->Br1(SNR), only Br1 rang, PSTN did not ring, but when I chose to push the call out to mobile phone using Mobility softkey, PSTN rang and I could answer the call without drop the connection. Has anyone seen this problem before? I did not understand why SNR would not work when calling from HQ, or Br2 site phones. Thank you in advance. ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com <http://www.ipexpert.com/> ___ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
