Re: [cisco-voip] e164 dialplan conversion

[Anthony Holloway]

You remember the big Y2K scare of the late 90s?

Storing only the last 4 digits of an E.164 number is like storing the last
two digits of the Year.

It's not like moving to more digits prevents users from keeping their
existing dialing habits.

I would also recommend you read the Dial Plan section of the Preferred
Architecture (PA) for Collaboration.  It's a quick read, like less than 10
minutes.

https://www.cisco.com/c/dam/en/us/td/docs/solutions/PA/enterprise/11x/clbpa116.pdf

If that excited you, then move on the the PA Cisco Validated Design (CVD)
section on End Point Addressing, and Routing and Normalization.  It's
pretty great.

https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Collaboration/enterprise/11x/116/collbcvd/control.html#pgfId-1179320

On Thu, Sep 21, 2017 at 9:24 AM Ben Amick  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-boun...@puck.nether.net] *On Behalf
> Of *Bernhard Albler
> *Sent:* Thursday, September 21, 2017 10:04 AM
> *To:* Florian Kroessbacher 
> *Cc:* cisco-voip voyp list 
> *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.kroessbac...@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 :
>
> 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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
>
>
>
>
>
> --
>
> 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

Re: [cisco-voip] expressway cluster restart order - E's first, then C's?

[Lelio Fulgenzi]

Thanks. I'm thinking edge first is a good idea too.

Sent from my iPhone

On Sep 21, 2017, at 6:27 PM, Ryan Huff 
mailto:ryanh...@outlook.com>> wrote:

It really doesn’t matter other than the order in which it will impact your 
environment. The “cluster” isn’t a mesh replication like CUCM, it’s more of 
like a master slave relationship.

In theory, you have the same license options on both cluster peers, so one peer 
can function in the same capacity as the other peer.

I would do the Edge first, then the control; especially if you have 
internal-only routing on the control server ... leave that for last.

Thanks,

Ryan

On Sep 21, 2017, at 6:15 PM, Matt Jacobson 
mailto:m4ttjacob...@gmail.com>> wrote:

I've never seen any documentation that is specific about shutdown order etc. 
There are also 3 different restart options for Expressway/VCS -- restart, 
reboot, or power down. There is also series of guides for cluster maintenance 
under deployment guides, which may be helpful for you. 
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-10/Cisco-Expressway-Cluster-Creation-and-Maintenance-Deployment-Guide-X8-10.pdf

Aside from upgrades, the few times I've had to do something like this was 
restarting Expressways to clear software errors. I did the primary, then 
secondary nodes once the primary was back online. This is also the order 
suggested for upgrades. I personally do not see any value in doing one cluster 
before the other, but most of the deployments I see are the simple and 
supported ones.

On Thu, Sep 21, 2017 at 3:32 PM, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

Just wondering what people are doing when they need to restart their expressway 
cluster? Since C is the one initiating the connection to E, and because the 
primary is reaching out to subscribers, I'm thinking:

Shutdown Order

C primary
C subscribers
E primary
E subscribers

(Re)Start Up Order

E subscribers
E primary
C subscribers
C primary

Thoughts?

---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519-824-4120 Ext 56354
le...@uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] expressway cluster restart order - E's first, then C's?

[Lelio Fulgenzi]

Thanks! I'll try to find the maintenance doc for my version.

In this instance, I had to shut down my guests so I could upgrade cimc, bios, 
firmware and esxi drivers.

I restarted C-pri, C-sec, E-pri, E-sec. I waited until the login prompt plus a 
bit before start the subsequent host. I'm not aware of a "utils services list" 
equiv for expressway. But maybe the docs will help.

Anyways, the zone peers would not come up until I restarted the C servers.

Sent from my iPhone

On Sep 21, 2017, at 6:15 PM, Matt Jacobson 
mailto:m4ttjacob...@gmail.com>> wrote:

I've never seen any documentation that is specific about shutdown order etc. 
There are also 3 different restart options for Expressway/VCS -- restart, 
reboot, or power down. There is also series of guides for cluster maintenance 
under deployment guides, which may be helpful for you. 
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-10/Cisco-Expressway-Cluster-Creation-and-Maintenance-Deployment-Guide-X8-10.pdf

Aside from upgrades, the few times I've had to do something like this was 
restarting Expressways to clear software errors. I did the primary, then 
secondary nodes once the primary was back online. This is also the order 
suggested for upgrades. I personally do not see any value in doing one cluster 
before the other, but most of the deployments I see are the simple and 
supported ones.

On Thu, Sep 21, 2017 at 3:32 PM, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

Just wondering what people are doing when they need to restart their expressway 
cluster? Since C is the one initiating the connection to E, and because the 
primary is reaching out to subscribers, I'm thinking:

Shutdown Order

C primary
C subscribers
E primary
E subscribers

(Re)Start Up Order

E subscribers
E primary
C subscribers
C primary

Thoughts?

---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519-824-4120 Ext 56354
le...@uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] expressway cluster restart order - E's first, then C's?

[Ryan Huff]

It really doesn’t matter other than the order in which it will impact your 
environment. The “cluster” isn’t a mesh replication like CUCM, it’s more of 
like a master slave relationship.

In theory, you have the same license options on both cluster peers, so one peer 
can function in the same capacity as the other peer.

I would do the Edge first, then the control; especially if you have 
internal-only routing on the control server ... leave that for last.

Thanks,

Ryan

On Sep 21, 2017, at 6:15 PM, Matt Jacobson 
mailto:m4ttjacob...@gmail.com>> wrote:

I've never seen any documentation that is specific about shutdown order etc. 
There are also 3 different restart options for Expressway/VCS -- restart, 
reboot, or power down. There is also series of guides for cluster maintenance 
under deployment guides, which may be helpful for you. 
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-10/Cisco-Expressway-Cluster-Creation-and-Maintenance-Deployment-Guide-X8-10.pdf

Aside from upgrades, the few times I've had to do something like this was 
restarting Expressways to clear software errors. I did the primary, then 
secondary nodes once the primary was back online. This is also the order 
suggested for upgrades. I personally do not see any value in doing one cluster 
before the other, but most of the deployments I see are the simple and 
supported ones.

On Thu, Sep 21, 2017 at 3:32 PM, Lelio Fulgenzi 
mailto:le...@uoguelph.ca>> wrote:

Just wondering what people are doing when they need to restart their expressway 
cluster? Since C is the one initiating the connection to E, and because the 
primary is reaching out to subscribers, I'm thinking:

Shutdown Order

C primary
C subscribers
E primary
E subscribers

(Re)Start Up Order

E subscribers
E primary
C subscribers
C primary

Thoughts?

---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519-824-4120 Ext 56354
le...@uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] expressway cluster restart order - E's first, then C's?

[Matt Jacobson]

I've never seen any documentation that is specific about shutdown order
etc. There are also 3 different restart options for Expressway/VCS --
restart, reboot, or power down. There is also series of guides for cluster
maintenance under deployment guides, which may be helpful for you.
https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-10/Cisco-Expressway-Cluster-Creation-and-Maintenance-Deployment-Guide-X8-10.pdf

Aside from upgrades, the few times I've had to do something like this was
restarting Expressways to clear software errors. I did the primary, then
secondary nodes once the primary was back online. This is also the order
suggested for upgrades. I personally do not see any value in doing one
cluster before the other, but most of the deployments I see are the simple
and supported ones.

On Thu, Sep 21, 2017 at 3:32 PM, Lelio Fulgenzi  wrote:

>
> Just wondering what people are doing when they need to restart their
> expressway cluster? Since C is the one initiating the connection to E, and
> because the primary is reaching out to subscribers, I'm thinking:
>
> Shutdown Order
>
> C primary
> C subscribers
> E primary
> E subscribers
>
> (Re)Start Up Order
>
> E subscribers
> E primary
> C subscribers
> C primary
>
> Thoughts?
>
> ---
> Lelio Fulgenzi, B.A.
> Senior Analyst, Network Infrastructure
> Computing and Communications Services (CCS)
> University of Guelph
>
> 519-824-4120 Ext 56354
> le...@uoguelph.ca
> www.uoguelph.ca/ccs
> Room 037, Animal Science and Nutrition Building
> Guelph, Ontario, N1G 2W1
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] e164 dialplan conversion

[Brian Meade]

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 
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 +1XXXYYY;exten=
> where XXXYYY is the receptionist’s DID and  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= and just sends the +1XXXYYY as outbound
> caller ID.
>
>
>
> For internal 4-digit calling, translations created in Lync convert 
> back into the full +1XXXYYY;exten=.
>
>
>
> 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-boun...@puck.nether.net] *On Behalf
> Of *Bernhard Albler
> *Sent:* September 21, 2017 8:26 AM
> *To:* Ben Amick 
>
> *Cc:* cisco-voip voyp list 
> *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  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-boun...@puck.nether.net] *On Behalf
> Of *Bernhard Albler
> *Sent:* Thursday, September 21, 2017 10:04 AM
> *To:* Florian Kroessbacher 
> *Cc:* cisco-voip voyp list 
> *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.kroessbac...@gmail.com> wrote:
>
> Hy out there,
>
> throug updateLine this is working
>
> use old pattern & partition
> and set newpattern
>
> we have done this for 12000 Li

[cisco-voip] expressway cluster restart order - E's first, then C's?

[Lelio Fulgenzi]

Just wondering what people are doing when they need to restart their expressway 
cluster? Since C is the one initiating the connection to E, and because the 
primary is reaching out to subscribers, I'm thinking:

Shutdown Order

C primary
C subscribers
E primary
E subscribers

(Re)Start Up Order

E subscribers
E primary
C subscribers
C primary

Thoughts?

---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519-824-4120 Ext 56354
le...@uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1

<>___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] e164 dialplan conversion

[Norton, Mike]

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 +1XXXYYY;exten= where XXXYYY is the 
receptionist’s DID and  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= and just sends the +1XXXYYY as outbound caller 
ID.

For internal 4-digit calling, translations created in Lync convert  back 
into the full +1XXXYYY;exten=.

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-boun...@puck.nether.net] On Behalf Of 
Bernhard Albler
Sent: September 21, 2017 8:26 AM
To: Ben Amick 
Cc: cisco-voip voyp list 
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 
mailto:bam...@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-boun...@puck.nether.net]
 On Behalf Of Bernhard Albler
Sent: Thursday, September 21, 2017 10:04 AM
To: Florian Kroessbacher 
mailto:florian.kroessbac...@gmail.com>>
Cc: cisco-voip voyp list 
mailto:cisco-voip@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 
mailto:florian.kroessbac...@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 
mailto:btal...@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 del

Re: [cisco-voip] e164 dialplan conversion

[Bernhard Albler]

>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  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-boun...@puck.nether.net] *On Behalf
> Of *Bernhard Albler
> *Sent:* Thursday, September 21, 2017 10:04 AM
> *To:* Florian Kroessbacher 
> *Cc:* cisco-voip voyp list 
> *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.kroessbac...@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 :
>
> 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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
> 

Re: [cisco-voip] e164 dialplan conversion

[Ben Amick]

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-boun...@puck.nether.net] On Behalf Of 
Bernhard Albler
Sent: Thursday, September 21, 2017 10:04 AM
To: Florian Kroessbacher 
Cc: cisco-voip voyp list 
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 
mailto:florian.kroessbac...@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 
mailto:btal...@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip



--
Bernhard Albler, +4369917207384
--
"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___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] e164 dialplan conversion

[Bernhard Albler]

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.kroessbac...@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 :
>
> 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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>


-- 
Bernhard Albler, +4369917207384
--
"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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] e164 dialplan conversion

[Florian Kroessbacher]

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 :
> 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@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] e164 dialplan conversion

[Bill Talley]

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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] ISR Sizing Guide

[Lelio Fulgenzi]

Here's an interesting data sheet too

https://www.cisco.com/c/en/us/products/collateral/routers/4000-series-integrated-services-routers-isr/data_sheet_c78-728307.html

You can also try dsp calculator.

I also think we'll all be running the 5000 series virtual platform in our 
branches by 2022. :)

Sent from my iPhone

On Sep 21, 2017, at 7:00 AM, Gary Parker 
mailto:g.j.par...@lboro.ac.uk>> wrote:



On 21/09/2017 11:56, Gary Parker wrote:
I just need to know what any limitations are for the platform
regarding call capacity.
*sigh*

...and, of course, as soon as I click  I find it:

https://www.cisco.com/c/en/us/products/collateral/unified-communications/tdm-gateways/data-sheet-c78-729824.html

Gary
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] ISR Sizing Guide

[Gary Parker]

On 21/09/2017 11:56, Gary Parker wrote:

I just need to know what any limitations are for the platform
regarding call capacity.

*sigh*

...and, of course, as soon as I click  I find it:

https://www.cisco.com/c/en/us/products/collateral/unified-communications/tdm-gateways/data-sheet-c78-729824.html

Gary
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] ISR Sizing Guide

[Gary Parker]

Morning all, I'm currently running a pair of 2921 ISRs with 4x E1 on 
each and a small number of voice SIP trunks using CUBE (we do video, 
too, but have epxressways for that). The 2921 series are EOL now and the 
Cisco Router Selector 
(https://www.cisco.com/c/dam/assets/prod/routers/cisco-router-selector/index.html#/branch) 
suggests replacing them with a 4331 ISR. The marketting video suggests 
this is a very powerful and capable piece of equipment, far moreso than 
my current needs demand, and I'd expect it had a price tag (and 
maintenance cost) to match!


I'm sure Cisco used to have a table somewhere for the 2900 series kit 
that simply and concisely showed you how many concurrent connections and 
DSP sessions each model could handle. Is there something similar for the 
4000 series, because I can't find it anywhere!


With two NIM slots and two RJ45 ethernet ports, from a connectivity 
perspective it looks like the 4321 would fit my needs so long as it runs 
CUBE. I just need to know what any limitations are for the platform 
regarding call capacity.


--
/-Gary Parker--f--\
| Unified Communications Service Manager  |
n  Loughborough University, IT Services   |
| tel:+441509635635 sip:g...@lboro.ac.uk  o
| http://delphium.lboro.ac.uk/pubkey.txt  |
\r--d-/

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Jabber/Apple IOS 11 - Push Notification

[Matthew Loraditch]

Apple changed their plans and pushed the code change to IOS 12.

Get Outlook for iOS

From: cisco-voip  on behalf of Jon Fox - 
CISCO IPT 
Sent: Thursday, September 21, 2017 5:15:20 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Jabber/Apple IOS 11 - Push Notification


Hello all

I was under the impression that when users update to version 11 of IOS on 
Ipad/iphone the Jabber app would no longer recieve call/notifcations when the 
app is running in the background?

We only have a handful of users using Jabber on Iphone/ipad so we didnt see the 
point in rushing through an upgrade.

Yesterday, I upgraded to IOS11 (iphone/ipad) and my jabber still works exactly 
as it did before?

The spill i read and was told below.

-Jabber to no longer run in background for an extended period
-Jabber terminated if not running in foreground after some time


Can anyone shed a light on this? Have i missed something?

Thank you.

JF

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Jabber/Apple IOS 11 - Push Notification

[Jon Fox - CISCO IPT]

Thank you Matthew and Ki,

I clearly missed that update. 

Thanks again.

Jon

> On 21 Sep 2017, at 10:52, Matthew Loraditch 
>  wrote:
> 
> Apple changed their plans and pushed the code change to IOS 12.
> 
> Get Outlook for iOS 
> From: cisco-voip  on behalf of Jon Fox - 
> CISCO IPT 
> Sent: Thursday, September 21, 2017 5:15:20 AM
> To: cisco-voip@puck.nether.net
> Subject: [cisco-voip] Jabber/Apple IOS 11 - Push Notification
>  
> 
>> Hello all
>>  
>> I was under the impression that when users update to version 11 of IOS on 
>> Ipad/iphone the Jabber app would no longer recieve call/notifcations when 
>> the app is running in the background?  
>>  
>> We only have a handful of users using Jabber on Iphone/ipad so we didnt see 
>> the point in rushing through an upgrade. 
>> 
>> Yesterday, I upgraded to IOS11 (iphone/ipad) and my jabber still works 
>> exactly as it did before?
>>  
>> The spill i read and was told below.
>>  
>> -Jabber to no longer run in background for an extended period
>> -Jabber terminated if not running in foreground after some time
>>  
>>  
>> Can anyone shed a light on this? Have i missed something?
>>  
>> Thank you.
>>  
>> JF
> 

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Jabber/Apple IOS 11 - Push Notification

[Ki Wi]

The "action" was removed by iOS 11 I guess.

https://communities.cisco.com/community/technology/customer-connection/ccp-private/ccp-collaboration/blog/2017/04/17/important-update-to-jabber-for-ios-push-notifications


You can refer to this website where cisco stated that customers are
recommended to upgrade by june 2018*

*Historical date for WWDC and beta availability of the next major iOS
release.

On Thu, Sep 21, 2017 at 5:15 PM, Jon Fox - CISCO IPT 
wrote:

>
> Hello all
>
> I was under the impression that when users update to version 11 of IOS on
> Ipad/iphone the Jabber app would no longer recieve call/notifcations when
> the app is running in the background?
>
> We only have a handful of users using Jabber on Iphone/ipad so we didnt
> see the point in rushing through an upgrade.
>
> Yesterday, I upgraded to IOS11 (iphone/ipad) and my jabber still works
> exactly as it did before?
>
> The spill i read and was told below.
>
> -Jabber to no longer run in background for an extended period
> -Jabber terminated if not running in foreground after some time
>
>
> Can anyone shed a light on this? Have i missed something?
>
> Thank you.
>
> JF
>
>
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>


-- 
Regards,
Ki Wi
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Jabber/Apple IOS 11 - Push Notification

[Jon Fox - CISCO IPT]

> Hello all
>  
> I was under the impression that when users update to version 11 of IOS on 
> Ipad/iphone the Jabber app would no longer recieve call/notifcations when the 
> app is running in the background?  
>  
> We only have a handful of users using Jabber on Iphone/ipad so we didnt see 
> the point in rushing through an upgrade. 
> 
> Yesterday, I upgraded to IOS11 (iphone/ipad) and my jabber still works 
> exactly as it did before?
>  
> The spill i read and was told below.
>  
> -Jabber to no longer run in background for an extended period
> -Jabber terminated if not running in foreground after some time
>  
>  
> Can anyone shed a light on this? Have i missed something?
>  
> Thank you.
>  
> JF

___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip