friday afternoon inbound number normalization question!

%3CLINGO-SUB%20id%3D%22lingo-sub-177940%22%20slang%3D%22en-US%22%3Efriday%20afternoon%20inbound%20number%20normalization%20question!%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-177940%22%20slang%3D%22en-US%22%3E%3CP%3ESItuation%3A%26nbsp%3B%20Trying%20to%20get%20sim%20ring%20working%20between%20Cisco%20and%20Skype%20for%20Business%3C%2FP%3E%0A%3CP%3ESfB%202015%20On%20Premise%3C%2FP%3E%0A%3CP%3ECisco%20On%20Premise%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ECisco%20is%20sending%20me%20ten%20digits%20with%205%20pre-arranged%20digits%20prepended%20(don't%20ask%2C%20it's%20just%20how%20it%20has%20to%20work).%26nbsp%3B%20I%20have%20a%20rule%20in%20my%20global%20dial%20plan%20to%20remove%20the%20five%20digits%20and%20normalize%20the%20remaining%20ten%20to%20E.164%20(%2B18245551212).%26nbsp%3B%20The%20LineURI%20on%20the%20account%20I'm%20trying%20to%20call%20is%20tel%3A%2B18245551212%3Bext%3D51212%3Bms-skip-rnl.%26nbsp%3B%20I'm%20adding%20ms-skip-rnl%20because%20I%20want%20all%20dialed%20calls%20from%20Skype%20to%20hit%20Cisco%20first%2C%20then%20sim%20ring%20as%20configured.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EIf%20I%20remove%20the%20ms-skip-rnl%2C%20the%20call%20routes%20correctly%20into%20the%20Skype%20account.%3C%2FP%3E%0A%3CP%3EIf%20I%20add%20the%20ms-skip-rnl%2C%20the%20call%20does%20not%20route%20correctly%20into%20the%20Skype%20account%20and%20fails.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ESince%20ms-skip-rnl%20seems%20to%20be%20the%20issue%2C%20I%20thought%20that%20only%20applied%20when%20the%20dialed%20number%20call%20originates%20within%20the%20Skype%20environment.%26nbsp%3B%20Am%20I%20wrong%20about%20that%3F%26nbsp%3B%20Should%20I%20be%20using%20a%20different%20dial%20plan%20type%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-177940%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EPSTN%20Calling%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-180841%22%20slang%3D%22en-US%22%3ERe%3A%20friday%20afternoon%20inbound%20number%20normalization%20question!%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-180841%22%20slang%3D%22en-US%22%3E%3CP%3EOhhhhh%20Skype%20to%20Skype.%26nbsp%3B%20If%20they%20dial%20the%20number%2C%20then%20that's%20possible%20yes%20they%20could%20use%20up%202%20channels%20on%20the%20trunk%2C%20if%20they%20right-click%20call%20in%20Skype%20then%20no%20it%20would%20be%20P2P%20and%20not%20touch%20Cisco.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EBut%2C%20it's%20a%20SIP%20trunk%20with%20Cisco%2C%20so%20it%20shouldn't%20matter%20much%20if%20an%20extra%20channel%20is%20used%20unless%20you're%20passing%20it%20through%20an%20SBC%20that%20limits%20concurrent%20sessions%20due%20to%20licensing.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-180831%22%20slang%3D%22en-US%22%3ERe%3A%20friday%20afternoon%20inbound%20number%20normalization%20question!%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-180831%22%20slang%3D%22en-US%22%3E%3CP%3EI'm%20sorry%20-%20I%20meant%3A%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3ECalling%20client%20%26gt%3B%20mediation%20server%20%26gt%3B%26nbsp%3B%3CSTRONG%3Etrunk%3C%2FSTRONG%3E%26nbsp%3B%26gt%3B%20pbx%20%26gt%3B%26nbsp%3B%3CSTRONG%3Etrunk%26nbsp%3B%3C%2FSTRONG%3E(forked%20to%20Cisco%20and%20back%20to%20Skype)%20%26gt%3B%20mediation%20server%20%26gt%3B%20answering%20client%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%3EThe%20voice%20guys%20want%20to%20know%20if%20a%20call%20originating%20in%20Skype%20is%20taking%20up%20more%20voice%20resources%20than%20necessary.%3C%2FSPAN%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-180818%22%20slang%3D%22en-US%22%3ERe%3A%20friday%20afternoon%20inbound%20number%20normalization%20question!%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-180818%22%20slang%3D%22en-US%22%3E%3CP%3EThe%20media%20for%20the%20Skype%20client%20will%20connect%20with%20the%20mediation%20server%20on%20the%20Skype%20side.%26nbsp%3B%20It%20won't%20go%20all%20the%20way%20to%20the%20other%20PBX.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-179204%22%20slang%3D%22en-US%22%3ERe%3A%20friday%20afternoon%20inbound%20number%20normalization%20question!%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-179204%22%20slang%3D%22en-US%22%3E%3CP%3EI'll%20give%20it%20a%20try.%26nbsp%3B%20One%20more%20question%20-%20in%20that%20scenario%2C%20once%20the%20call%20is%20set%20up%20when%20the%20receiving%20Skype%20client%20answers%2C%20does%20the%20media%20traffic%20stay%20on%20the%20Skype%20side%2C%20or%20does%20it%20traverse%20the%20PBX%3F%26nbsp%3B%20Media%20bypass%20is%20not%20present.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ECalling%20client%20%26gt%3B%20trunk%20%26gt%3B%20pbx%20%26gt%3B%20trunk%20%26gt%3B%20answering%20client%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3Eor%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3ECalling%20client%20%26gt%3B%20answering%20client%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-178847%22%20slang%3D%22en-US%22%3ERe%3A%20friday%20afternoon%20inbound%20number%20normalization%20question!%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-178847%22%20slang%3D%22en-US%22%3E%3CP%3EI%20don't%20have%20a%20environment%20handy%20where%20I%20can%20test%2C%20but%20if%20it's%20not%20working%20anyway%2C%20I'd%20say%20just%20give%20it%20a%20shot.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-178836%22%20slang%3D%22en-US%22%3ERe%3A%20friday%20afternoon%20inbound%20number%20normalization%20question!%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-178836%22%20slang%3D%22en-US%22%3E%3CBLOCKQUOTE%3E%3CHR%20%2F%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F7965%22%20target%3D%22_blank%22%3E%40Anthony%20Caragol%3C%2FA%3E%20wrote%3A%3CBR%20%2F%3E%3CP%3EIt%20wouldn't%20do%20anything%20different%2C%20but%20the%20global%26nbsp%3Bdial%20plan%20would%20be%20used%20for%20outbound%20normalization%20of%20other%20things%2C%20so%20I%20typically%20keep%20them%20separate.%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EI%20think%20I%20misread%20the%20post%20the%20first%20time%20through%2C%20though%20I%20try%20to%20keep%20the%20normalization%20rule%20as%20close%20to%20the%20LineURI%20as%20possible.%26nbsp%3B%20For%20if%20the%205%20prepended%20digits%20were%2055555%2C%20you%20could%20have%20the%20pattern%20to%20match%20be%26nbsp%3B%5E55555(%5Cd%7B5%7D)(%5Cd%7B5%7D)%24%20and%20the%20translation%20rule%20be%26nbsp%3B%2B1%241%242%3Bext%3D%242%3Bms-skip-rnl%3C%2FP%3E%0A%3CHR%20%2F%3E%3C%2FBLOCKQUOTE%3E%0A%3CP%3EThis%20is%20brilliant.%26nbsp%3B%20I%20envy%20you%20guys%20that%20can%20write%20regex.%26nbsp%3B%20So%20adding%20ms-skip-rnl%20to%20the%20normalized%20LineURI%20means%20it%20won't%20actually%20skip%20the%20number%2C%20like%20it's%20doing%20now%20without%20it%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-178824%22%20slang%3D%22en-US%22%3ERe%3A%20friday%20afternoon%20inbound%20number%20normalization%20question!%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-178824%22%20slang%3D%22en-US%22%3E%3CP%3EIt%20wouldn't%20do%20anything%20different%2C%20but%20the%20global%26nbsp%3Bdial%20plan%20would%20be%20used%20for%20outbound%20normalization%20of%20other%20things%2C%20so%20I%20typically%20keep%20them%20separate.%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EI%20think%20I%20misread%20the%20post%20the%20first%20time%20through%2C%20though%20I%20try%20to%20keep%20the%20normalization%20rule%20as%20close%20to%20the%20LineURI%20as%20possible.%26nbsp%3B%20For%20if%20the%205%20prepended%20digits%20were%2055555%2C%20you%20could%20have%20the%20pattern%20to%20match%20be%26nbsp%3B%5E55555(%5Cd%7B5%7D)(%5Cd%7B5%7D)%24%20and%20the%20translation%20rule%20be%26nbsp%3B%2B1%241%242%3Bext%3D%242%3Bms-skip-rnl%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-178583%22%20slang%3D%22en-US%22%3ERe%3A%20friday%20afternoon%20inbound%20number%20normalization%20question!%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-178583%22%20slang%3D%22en-US%22%3EWould%20normalizing%20using%20a%20pool%20dial%20plans%20do%20something%20differently%20than%20a%20rule%20in%20the%20global%20plan%3F%3CBR%20%2F%3E%3CBR%20%2F%3EI%E2%80%99m%20not%20really%20able%20to%20normalize%20the%20extension.%20I%20didn%E2%80%99t%20think%20I%20would%20need%20that%20in%20the%20rule.%20Can%20ext%3D%20be%20blank%2C%20we%20really%20don%E2%80%99t%20use%20extension%20dialing%20in%20Skype%3F%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-178571%22%20slang%3D%22en-US%22%3ERe%3A%20friday%20afternoon%20inbound%20number%20normalization%20question!%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-178571%22%20slang%3D%22en-US%22%3E%3CP%3EInstead%20of%20the%20global%20dial%20plan%2C%20why%20not%20a%20pool%20dial%20plan%20based%20upon%20the%20IP%20or%20FQDN%20of%20the%20Cisco%20PSTN%20Gateways.%26nbsp%3B%20Also%2C%20when%20you%20normalize%20to%20E.164%2C%20are%20you%20adding%20the%20EXT%3D%20still%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E
Super Contributor

SItuation:  Trying to get sim ring working between Cisco and Skype for Business

SfB 2015 On Premise

Cisco On Premise

 

Cisco is sending me ten digits with 5 pre-arranged digits prepended (don't ask, it's just how it has to work).  I have a rule in my global dial plan to remove the five digits and normalize the remaining ten to E.164 (+18245551212).  The LineURI on the account I'm trying to call is tel:+18245551212;ext=51212;ms-skip-rnl.  I'm adding ms-skip-rnl because I want all dialed calls from Skype to hit Cisco first, then sim ring as configured.

 

If I remove the ms-skip-rnl, the call routes correctly into the Skype account.

If I add the ms-skip-rnl, the call does not route correctly into the Skype account and fails.

 

Since ms-skip-rnl seems to be the issue, I thought that only applied when the dialed number call originates within the Skype environment.  Am I wrong about that?  Should I be using a different dial plan type?

9 Replies

Instead of the global dial plan, why not a pool dial plan based upon the IP or FQDN of the Cisco PSTN Gateways.  Also, when you normalize to E.164, are you adding the EXT= still?

Would normalizing using a pool dial plans do something differently than a rule in the global plan?

I’m not really able to normalize the extension. I didn’t think I would need that in the rule. Can ext= be blank, we really don’t use extension dialing in Skype?

It wouldn't do anything different, but the global dial plan would be used for outbound normalization of other things, so I typically keep them separate. 

 

I think I misread the post the first time through, though I try to keep the normalization rule as close to the LineURI as possible.  For if the 5 prepended digits were 55555, you could have the pattern to match be ^55555(\d{5})(\d{5})$ and the translation rule be +1$1$2;ext=$2;ms-skip-rnl


@Anthony Caragol wrote:

It wouldn't do anything different, but the global dial plan would be used for outbound normalization of other things, so I typically keep them separate. 

 

I think I misread the post the first time through, though I try to keep the normalization rule as close to the LineURI as possible.  For if the 5 prepended digits were 55555, you could have the pattern to match be ^55555(\d{5})(\d{5})$ and the translation rule be +1$1$2;ext=$2;ms-skip-rnl


This is brilliant.  I envy you guys that can write regex.  So adding ms-skip-rnl to the normalized LineURI means it won't actually skip the number, like it's doing now without it?

I don't have a environment handy where I can test, but if it's not working anyway, I'd say just give it a shot.

I'll give it a try.  One more question - in that scenario, once the call is set up when the receiving Skype client answers, does the media traffic stay on the Skype side, or does it traverse the PBX?  Media bypass is not present.

 

Calling client > trunk > pbx > trunk > answering client

 

or

 

Calling client > answering client

 

The media for the Skype client will connect with the mediation server on the Skype side.  It won't go all the way to the other PBX.

I'm sorry - I meant:

 

Calling client > mediation server > trunk > pbx > trunk (forked to Cisco and back to Skype) > mediation server > answering client

 

The voice guys want to know if a call originating in Skype is taking up more voice resources than necessary.

Ohhhhh Skype to Skype.  If they dial the number, then that's possible yes they could use up 2 channels on the trunk, if they right-click call in Skype then no it would be P2P and not touch Cisco.

 

But, it's a SIP trunk with Cisco, so it shouldn't matter much if an extra channel is used unless you're passing it through an SBC that limits concurrent sessions due to licensing.