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 <[email protected]> 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:[email protected]] *On Behalf > Of *Bernhard Albler > *Sent:* September 21, 2017 8:26 AM > *To:* Ben Amick <[email protected]> > > *Cc:* cisco-voip voyp list <[email protected]> > *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 <[email protected]> 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:[email protected]] *On Behalf > Of *Bernhard Albler > *Sent:* Thursday, September 21, 2017 10:04 AM > *To:* Florian Kroessbacher <[email protected]> > *Cc:* cisco-voip voyp list <[email protected]> > *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 < > [email protected]> 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 <[email protected]>: > > 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 > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > <http://cp.mcafee.com/d/1jWVIq3x0Sy_tOZQPhPsQsCXCQkmnSkNMV4QsCQkmnSkNPPX9J55BZVYsY-Urhhsd79EVLuWdPp3lpmawECSHIdzrBPpdJnor6TbCX83HcSd7b_nV55NBxW_nKnjpuLObPdQn1TkhhmKCHt5DBgY-F6lK1FJ4SCrLRQkQSjhPteVEVdTdAVPmEBCbdSaY3ivNU6U9GX33VkDa3JsJaBGBPdpb6XiFqFsPmiNsxlK5LE2BCX5u1FfUY3jqdXFL6MnWhEwdbtFkJkKpH9oQKCy3Qn63h0xbjRzZwq8blwp-d9lwrohdSRHQ> > > > _______________________________________________ > cisco-voip mailing list > [email protected] > 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 > [email protected] > https://puck.nether.net/mailman/listinfo/cisco-voip > >
_______________________________________________ cisco-voip mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-voip
