[cisco-voip] e164 dialplan conversion

Thu Sep 21 17:49:34 EDT 2017

Just need to get everyone using URI dialing instead :)

CUCM supports speed dials with pauses.  I don't think you can configure a
pause in an Enterprise Alternate Number though.

On Thu, Sep 21, 2017 at 3:57 PM, Norton, Mike <mikenorton at pwsd76.ab.ca>
wrote:

> I haven’t been into CUCM for a while so maybe the answer to this is
> obvious, but do E.164 numbers in CUCM actually have to be entirely numbers?
> In MS Lync, your E.164 number is more of a “tel:” URI than an actual
> number. So for phones with no DID, we set them as +1XXXYYYYYYY;exten=ZZZZ
> where XXXYYYYYYY is the receptionist’s DID and ZZZZ is the phone’s internal
> extension. Apparently this is a valid way of specifying a tel URI, which is
> nice because it preserves global uniqueness without resorting to making up
> fake phone numbers.
>
>
>
> For outbound PSTN calls, the Cisco gateways are smart enough (too stupid?)
> that they ignore the exten=ZZZZ and just sends the +1XXXYYYYYYY as outbound
> caller ID.
>
>
>
> For internal 4-digit calling, translations created in Lync convert ZZZZ
> back into the full +1XXXYYYYYYY;exten=ZZZZ.
>
>
>
> Can CUCM do something like that? If not then maybe I finally just stumbled
> upon one thing I actually like better in Lync than CUCM. ;-)
>
>
>
> -mn
>
>
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On Behalf
> Of *Bernhard Albler
> *Sent:* September 21, 2017 8:26 AM
> *To:* Ben Amick <bamick at humanarc.com>
>
> *Cc:* cisco-voip voyp list <cisco-voip at puck.nether.net>
> *Subject:* Re: [cisco-voip] e164 dialplan conversion
>
>
>
> >What advantage/purpose does switching to an e164 dial plan afford you? Is
> it just more of a flexibility to mate dial plan/DNs to DIDs?
>
> more flexibility, easier deployment of CTI Applications / Jabber.
>
> With e164 i am using a globally unique id for each DN and this resolves a
> lot of issues.
>
> Also these days i expect entries in directories to be e164 because of
> other clients (mobile phones) requiring it.
>
>
>
> >More importantly, how would an e164 dial plan mesh with a system where
> the majority of users do not have DIDs or DIDs that do not match their
> >extension plan?
>
> Non DID:
>
> well, you fake it mostly and create some crazy fake patterns. In that case
> it is certainly not pretty
>
> non matching extensions:
>
> Again, this can be fixed with translations (and automation). Even for the
> non matching extension case i prefer e164, but this is just my personal
> opinion
>
>
>
> >Is any additional overhead generated by going to an e164 dial plan?
>
> Hard to say. There are some disadvantages (e.g. the extra Translations for
> internally dialing) that might limit scale.
>
>
>
>
>
> >Also, from what I understand, 4-5digit dialing is made possible only by
> having proper CSS per site with a translation pattern, not through any
> function of >the DN configuration, correct?
>
> Yes or you use alternate enterprise number and put it into another
> partition. But in that case there are some stupid corner cases with CURRI
> and also CDRs. So translations are kind of the cleanest solution.
>
>
>
> Personally for me flexibility and a clean concept are just easier to
> achieve with e164. but that is just a personal opinion
>
>
>
>
>
> On Thu, Sep 21, 2017 at 4:17 PM, Ben Amick <bamick at humanarc.com> wrote:
>
> Inexperienced person here chiming in with a question:
>
> What advantage/purpose does switching to an e164 dial plan afford you? Is
> it just more of a flexibility to mate dial plan/DNs to DIDs?
>
> More importantly, how would an e164 dial plan mesh with a system where the
> majority of users do not have DIDs or DIDs that do not match their
> extension plan?
>
> Is any additional overhead generated by going to an e164 dial plan?
>
> Also, from what I understand, 4-5digit dialing is made possible only by
> having proper CSS per site with a translation pattern, not through any
> function of the DN configuration, correct?
>
>
>
> Ben Amick
>
> Unified Communications Analyst
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On Behalf
> Of *Bernhard Albler
> *Sent:* Thursday, September 21, 2017 10:04 AM
> *To:* Florian Kroessbacher <florian.kroessbacher at gmail.com>
> *Cc:* cisco-voip voyp list <cisco-voip at puck.nether.net>
> *Subject:* Re: [cisco-voip] e164 dialplan conversion
>
>
>
> ucm:
>
> What Florian says is the correct way to do it.
>
> You can also run a sql update against the numplan table which will do 2
> things:
>
> 1.)I you typoed you are in for a lot of pain
>
> 2.)Ucm will load up on change notification (assuming lots of DNs) and
> might come to halt before recovering
>
>
>
> ccx:
>
> Agent DNs in my experience will reflect automatically. Routepoints and CTI
> ports you will need to change manually.
>
>
>
>
>
> Personally i suggest the SQL route as the adrenaline rush is just
> incredible once you realize you made a mistake.
>
>
>
> On Thu, Sep 21, 2017 at 3:20 PM, Florian Kroessbacher <
> florian.kroessbacher at gmail.com> wrote:
>
> Hy out there,
>
> throug updateLine this is working
>
> use old pattern & partition
> and set newpattern
>
> we have done this for 12000 Lines
>
>
> Am 21. Sep. 2017, 15:13 +0200 schrieb Bill Talley <btalley at gmail.com>:
>
> I know there have been some conversations around this in the past, but I’m
> hoping there are new methods for converting from a 4-digit to full e164
> dialplan.
>
> Is there a way to change dialplan entries on CUCM and UCCX without having
> to either individually touch each dialplan pattern or without deleting and
> reimporting/recreating? Has anyone seen or used AXL/SOAP to automate
> modification of dialplan patterns, or used PCP or some third party product
> to accomplish this?
>
> Thanks for any feedback.
>
> Bill
>
> Sent from a mobile device with very tiny touchscreen input keys. Please
> excude my typtos.
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> <http://cp.mcafee.com/d/1jWVIq3x0Sy_tOZQPhPsQsCXCQkmnSkNMV4QsCQkmnSkNPPX9J55BZVYsY-Urhhsd79EVLuWdPp3lpmawECSHIdzrBPpdJnor6TbCX83HcSd7b_nV55NBxW_nKnjpuLObPdQn1TkhhmKCHt5DBgY-F6lK1FJ4SCrLRQkQSjhPteVEVdTdAVPmEBCbdSaY3ivNU6U9GX33VkDa3JsJaBGBPdpb6XiFqFsPmiNsxlK5LE2BCX5u1FfUY3jqdXFL6MnWhEwdbtFkJkKpH9oQKCy3Qn63h0xbjRzZwq8blwp-d9lwrohdSRHQ>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> <http://cp.mcafee.com/d/avndxNJ5-XBXFCzCVEVdTdEEILIFzxO9EVdEEILIFzDDSjqabbXPUVVZMSyyUqejhPuZQrCO6GOIl1hdJnor6TbCOrqKMSdKndSg7mpIqen-LOabzb3R-LsKCOZvAnCrEK3KEyyJtdmWbfaxVZicHs3jqpJcTvHEFFICzCWtPhOrKr9PCJhbcmrIlU6A_zMdMjlS67OFek7qVqlblbCqOmdSBiRiVCIByV2Hsbvg5bdSaY3ivNU6CQrTjudwLQzh0qmXiFqFsPmiNFtd47EKc6y12mDH7X0QgmH0PYqiH0SMyrgW9o>
>
>
>
>
>
> --
>
> Bernhard Albler, +4369917207384 <+43%20699%2017207384>
> --
> "Was Nachwelt! Wie komm' ich dazu was für die Nachwelt zu tun? Was hat
> denn die Nachwelt für mich getan?"
> --Carl Friedrich Zelter
>
>
> Confidentiality Note: This message is intended for use only by the
> individual or entity to which it is addressed and may contain information
> that is privileged, confidential, and exempt from disclosure under
> applicable law. If the reader of this message is not the intended recipient
> or the employee or agent responsible for delivering the message to the
> intended recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited. If
> you have received this communication in error, please contact the sender
> immediately and destroy the material in its entirety, whether electronic or
> hard copy. Thank you
>
>
>
>
>
> --
>
> Bernhard Albler, +4369917207384 <+43%20699%2017207384>
> --
> "Was Nachwelt! Wie komm' ich dazu was für die Nachwelt zu tun? Was hat
> denn die Nachwelt für mich getan?"
> --Carl Friedrich Zelter
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170921/ffa392b3/attachment.html>