Re: [cisco-voip] Are there any gotchas to watch out for switching to FQDN server names from IP address server names?

[Nick Barnett]

I forgot to put a smiley face in that email, I wasn't trying to be a jerk
with my Trivial File Transfer Protocol jab :)

On Thu, Dec 1, 2016 at 9:54 PM, Nick Barnett  wrote:

> By definition, TFTP is trivial.
>
> The service either needed deactivated or the server needed to restart.
> Either way, the TFTP server is going down to regenerate the certs.
>
> On Thu, Dec 1, 2016 at 4:41 PM, Ryan Huff  wrote:
>
>> Anthony and James have highlighted one of the greater weaknesses of
>> thinking like an engineer.
>>
>> As an engineer, we look at TFTP service interruption and see all the
>> potential outcomes and things that could happen. We think about a firmware
>> download being interrupted on an endpoint and realize that it's simply a
>> phone reset to fix.
>>
>> That's great, if your end-users think like engineers and know what you
>> know.
>>
>> Although a nuclear power plant sitting in Japan or China is an extreme
>> example in my opinion, it is right on point. There are many, many
>> situations beyond a nuclear power plant where something as minor as a phone
>> firmware download being interrupted would be completely unacceptable to the
>> customer.
>>
>> In an SMB scenario with clearly defined maintenance windows, I can see
>> this not being such a big deal potentially. However if you're dealing with
>> a customer that counts endpoints in the tens of thousands (or even
>> thousands), it stands to reason that more than a few endpoints might be
>> impacted by something as, "trivial" as a TFTP service reset.
>>
>> It may be trivial in the permanency of the impact it could have on an
>> endpoint, but it is not trivial a enough to assume that it would not have
>> any impact to end-user performance, expectations or usability.
>>
>> -Ryan
>>
>> On Dec 1, 2016, at 5:26 PM, James Buchanan 
>> wrote:
>>
>> If the endpoint is 8000 miles away from you and located in a nuclear
>> power plant, that TFTP interruption wasn't so trivial.
>>
>> On Thu, Dec 1, 2016 at 5:10 PM, Ben Amick  wrote:
>>
>>> An endpoint in the middle of an upgrade has already entirely downloaded
>>> the firmware into memory, and would not be affected. If it is mid-download
>>> then it would have no affect other than breaking the operation and perhaps
>>> requiring a manual restart if it is coming off a factory reset
>>>
>>>
>>>
>>> *Ben Amick*
>>>
>>> Telecom Analyst
>>>
>>>
>>>
>>> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On
>>> Behalf Of *Anthony Holloway
>>> *Sent:* Thursday, December 01, 2016 5:08 PM
>>> *To:* Nick Barnett 
>>> *Cc:* Cisco VoIP Group 
>>> *Subject:* Re: [cisco-voip] Are there any gotchas to watch out for
>>> switching to FQDN server names from IP address server names?
>>>
>>>
>>>
>>> Is TFTP really that trivial?  What would happen to an endpoint, which is
>>> in the middle of a firmware upgrade, when you deactivate TFTP?
>>>
>>>
>>>
>>> On Thu, Dec 1, 2016 at 2:51 PM, Nick Barnett 
>>> wrote:
>>>
>>> I figured that a reboot would work, but TAC told me it wouldn't... and
>>> rather than experimenting, I just did what they said to do :)   Besides,
>>> deactivating TFTP is trivial and in a properly laid out deployment should
>>> have 0 impact.
>>>
>>>
>>>
>>> On Wed, Nov 30, 2016 at 8:28 AM, NateCCIE  wrote:
>>>
>>> A reboot does work. What the deal is the new https version of tftp (port
>>> 6972) does not restart with the service restart.  So it continues to use
>>> the old cert. But it does stop and start with a service deactivation and
>>> reactivation.  Before cucm 11 the tftp over http was only plain text (port
>>> 6970)
>>>
>>>
>>>
>>> Sent from my iPhone
>>>
>>>
>>> On Nov 30, 2016, at 1:12 AM, James Buchanan 
>>> wrote:
>>>
>>> Hello,
>>>
>>> If I remember right, it actually has to be deactivated under Service
>>> Management. It's not just restarting the service.
>>>
>>> Thanks,
>>>
>>> James
>>>
>>>
>>>
>>> On Tue, Nov 29, 2016 at 11:36 PM, Derek Andrew 
>>> wrote:
>>>
>>> Would a simple reboot accomplish the same as deactivating and activating?
>>>
>>>
>>>
>>> On Mon, Nov 28, 2016 at 2:19 PM, Nick Barnett 
>>> wrote:
>>>
>>> I just thought I would share what happened with this, even though it is
>>> super old. Changing the node names to FQDN was mostly painless. The one
>>> thing that bit me was bug CSCuy13916. After changing the names of the
>>> nodes, the TFTP service needs to be DEACTIVATED and then re-activated in
>>> order to fully update the certificates.  Before taking those steps, I kept
>>> getting certificate errors from CuciLync, but afterwards, everything worked
>>> as designed.
>>>
>>>
>>>
>>> Other than that, any CTI route points (and any other device as well)
>>> that exist will fall to another node in the CMG. Not a big 

Re: [cisco-voip] Are there any gotchas to watch out for switching to FQDN server names from IP address server names?

[Nick Barnett]

By definition, TFTP is trivial.

The service either needed deactivated or the server needed to restart.
Either way, the TFTP server is going down to regenerate the certs.

On Thu, Dec 1, 2016 at 4:41 PM, Ryan Huff  wrote:

> Anthony and James have highlighted one of the greater weaknesses of
> thinking like an engineer.
>
> As an engineer, we look at TFTP service interruption and see all the
> potential outcomes and things that could happen. We think about a firmware
> download being interrupted on an endpoint and realize that it's simply a
> phone reset to fix.
>
> That's great, if your end-users think like engineers and know what you
> know.
>
> Although a nuclear power plant sitting in Japan or China is an extreme
> example in my opinion, it is right on point. There are many, many
> situations beyond a nuclear power plant where something as minor as a phone
> firmware download being interrupted would be completely unacceptable to the
> customer.
>
> In an SMB scenario with clearly defined maintenance windows, I can see
> this not being such a big deal potentially. However if you're dealing with
> a customer that counts endpoints in the tens of thousands (or even
> thousands), it stands to reason that more than a few endpoints might be
> impacted by something as, "trivial" as a TFTP service reset.
>
> It may be trivial in the permanency of the impact it could have on an
> endpoint, but it is not trivial a enough to assume that it would not have
> any impact to end-user performance, expectations or usability.
>
> -Ryan
>
> On Dec 1, 2016, at 5:26 PM, James Buchanan 
> wrote:
>
> If the endpoint is 8000 miles away from you and located in a nuclear power
> plant, that TFTP interruption wasn't so trivial.
>
> On Thu, Dec 1, 2016 at 5:10 PM, Ben Amick  wrote:
>
>> An endpoint in the middle of an upgrade has already entirely downloaded
>> the firmware into memory, and would not be affected. If it is mid-download
>> then it would have no affect other than breaking the operation and perhaps
>> requiring a manual restart if it is coming off a factory reset
>>
>>
>>
>> *Ben Amick*
>>
>> Telecom Analyst
>>
>>
>>
>> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On
>> Behalf Of *Anthony Holloway
>> *Sent:* Thursday, December 01, 2016 5:08 PM
>> *To:* Nick Barnett 
>> *Cc:* Cisco VoIP Group 
>> *Subject:* Re: [cisco-voip] Are there any gotchas to watch out for
>> switching to FQDN server names from IP address server names?
>>
>>
>>
>> Is TFTP really that trivial?  What would happen to an endpoint, which is
>> in the middle of a firmware upgrade, when you deactivate TFTP?
>>
>>
>>
>> On Thu, Dec 1, 2016 at 2:51 PM, Nick Barnett 
>> wrote:
>>
>> I figured that a reboot would work, but TAC told me it wouldn't... and
>> rather than experimenting, I just did what they said to do :)   Besides,
>> deactivating TFTP is trivial and in a properly laid out deployment should
>> have 0 impact.
>>
>>
>>
>> On Wed, Nov 30, 2016 at 8:28 AM, NateCCIE  wrote:
>>
>> A reboot does work. What the deal is the new https version of tftp (port
>> 6972) does not restart with the service restart.  So it continues to use
>> the old cert. But it does stop and start with a service deactivation and
>> reactivation.  Before cucm 11 the tftp over http was only plain text (port
>> 6970)
>>
>>
>>
>> Sent from my iPhone
>>
>>
>> On Nov 30, 2016, at 1:12 AM, James Buchanan 
>> wrote:
>>
>> Hello,
>>
>> If I remember right, it actually has to be deactivated under Service
>> Management. It's not just restarting the service.
>>
>> Thanks,
>>
>> James
>>
>>
>>
>> On Tue, Nov 29, 2016 at 11:36 PM, Derek Andrew 
>> wrote:
>>
>> Would a simple reboot accomplish the same as deactivating and activating?
>>
>>
>>
>> On Mon, Nov 28, 2016 at 2:19 PM, Nick Barnett 
>> wrote:
>>
>> I just thought I would share what happened with this, even though it is
>> super old. Changing the node names to FQDN was mostly painless. The one
>> thing that bit me was bug CSCuy13916. After changing the names of the
>> nodes, the TFTP service needs to be DEACTIVATED and then re-activated in
>> order to fully update the certificates.  Before taking those steps, I kept
>> getting certificate errors from CuciLync, but afterwards, everything worked
>> as designed.
>>
>>
>>
>> Other than that, any CTI route points (and any other device as well) that
>> exist will fall to another node in the CMG. Not a big deal, just something
>> to be aware of.
>>
>>
>>
>> Thanks,
>>
>> Nick
>>
>>
>>
>> On Wed, Aug 31, 2016 at 3:13 PM, Nick Barnett 
>> wrote:
>>
>> We are on 10.0 and this cluster has been upgraded over the years from 8.0
>> to 8.6 to 10.0.  I know it used to be common practice to rip the host name
>> out of a new 

Re: [cisco-voip] Are there any gotchas to watch out for switching to FQDN server names from IP address server names?

[Ben Amick]

The question I pose in response to that line of thinking is: Why is a client 
pulling TFTP from the server while you're deactivating the services, and why do 
you not have redundant TFTP?

The scenario I mentioned regarding the phone needing a restart would only be 
necessary if the phone was in a factory reset, which would mean an engineer 
would be hands-on with the phone and/or the user at that point in time, in 
which case why would you also be deactivating TFTP at that point in time, and 
even if you do, you already have a contact to resolve the issue with.
In the case of phone configuration files delivered via TFTP - if those fail to 
download, the phone falls back to the last stored configuration, if memory 
serves. In the case of a phone delivering a new update while operational, it 
waits until it finishes downloading (alleviating need for TFTP) before 
executing an upgrade, meaning it should once again be irrelevant to the TFTP 
deactivation.

I mean, there's plenty of "what ifs" but TFTP downloads only ever happen during 
changes - new firmware installation, or new configuration to the phone. Even if 
you don't have clearly defined maintenance windows, I believe you shouldn't be 
making a change as serious as migrating from IP to FQDN at the same time as you 
would be deploying a new firmware image to all your 7900 handsets, for example.

Ben Amick
Telecom Analyst

From: Ryan Huff [mailto:ryanh...@outlook.com]
Sent: Thursday, December 01, 2016 5:41 PM
To: James Buchanan 
Cc: Ben Amick ; Cisco VoIP Group 

Subject: Re: [cisco-voip] Are there any gotchas to watch out for switching to 
FQDN server names from IP address server names?

Anthony and James have highlighted one of the greater weaknesses of thinking 
like an engineer.

As an engineer, we look at TFTP service interruption and see all the potential 
outcomes and things that could happen. We think about a firmware download being 
interrupted on an endpoint and realize that it's simply a phone reset to fix.

That's great, if your end-users think like engineers and know what you know.

Although a nuclear power plant sitting in Japan or China is an extreme example 
in my opinion, it is right on point. There are many, many situations beyond a 
nuclear power plant where something as minor as a phone firmware download being 
interrupted would be completely unacceptable to the customer.

In an SMB scenario with clearly defined maintenance windows, I can see this not 
being such a big deal potentially. However if you're dealing with a customer 
that counts endpoints in the tens of thousands (or even thousands), it stands 
to reason that more than a few endpoints might be impacted by something as, 
"trivial" as a TFTP service reset.

It may be trivial in the permanency of the impact it could have on an endpoint, 
but it is not trivial a enough to assume that it would not have any impact to 
end-user performance, expectations or usability.

-Ryan

On Dec 1, 2016, at 5:26 PM, James Buchanan 
> wrote:
If the endpoint is 8000 miles away from you and located in a nuclear power 
plant, that TFTP interruption wasn't so trivial.

On Thu, Dec 1, 2016 at 5:10 PM, Ben Amick 
> wrote:
An endpoint in the middle of an upgrade has already entirely downloaded the 
firmware into memory, and would not be affected. If it is mid-download then it 
would have no affect other than breaking the operation and perhaps requiring a 
manual restart if it is coming off a factory reset

Ben Amick
Telecom Analyst

From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of Anthony Holloway
Sent: Thursday, December 01, 2016 5:08 PM
To: Nick Barnett >
Cc: Cisco VoIP Group 
>
Subject: Re: [cisco-voip] Are there any gotchas to watch out for switching to 
FQDN server names from IP address server names?

Is TFTP really that trivial?  What would happen to an endpoint, which is in the 
middle of a firmware upgrade, when you deactivate TFTP?

On Thu, Dec 1, 2016 at 2:51 PM, Nick Barnett 
> wrote:
I figured that a reboot would work, but TAC told me it wouldn't... and rather 
than experimenting, I just did what they said to do :)   Besides, deactivating 
TFTP is trivial and in a properly laid out deployment should have 0 impact.

On Wed, Nov 30, 2016 at 8:28 AM, NateCCIE 
> wrote:
A reboot does work. What the deal is the new https version of tftp (port 6972) 
does not restart with the service restart.  So it continues to use the old 
cert. But it does stop and start with a service deactivation and reactivation.  
Before cucm 11 the tftp over 

Re: [cisco-voip] Are there any gotchas to watch out for switching to FQDN server names from IP address server names?

[Ryan Huff]

Anthony and James have highlighted one of the greater weaknesses of thinking 
like an engineer.

As an engineer, we look at TFTP service interruption and see all the potential 
outcomes and things that could happen. We think about a firmware download being 
interrupted on an endpoint and realize that it's simply a phone reset to fix.

That's great, if your end-users think like engineers and know what you know.

Although a nuclear power plant sitting in Japan or China is an extreme example 
in my opinion, it is right on point. There are many, many situations beyond a 
nuclear power plant where something as minor as a phone firmware download being 
interrupted would be completely unacceptable to the customer.

In an SMB scenario with clearly defined maintenance windows, I can see this not 
being such a big deal potentially. However if you're dealing with a customer 
that counts endpoints in the tens of thousands (or even thousands), it stands 
to reason that more than a few endpoints might be impacted by something as, 
"trivial" as a TFTP service reset.

It may be trivial in the permanency of the impact it could have on an endpoint, 
but it is not trivial a enough to assume that it would not have any impact to 
end-user performance, expectations or usability.

-Ryan

On Dec 1, 2016, at 5:26 PM, James Buchanan 
> wrote:

If the endpoint is 8000 miles away from you and located in a nuclear power 
plant, that TFTP interruption wasn't so trivial.

On Thu, Dec 1, 2016 at 5:10 PM, Ben Amick 
> wrote:
An endpoint in the middle of an upgrade has already entirely downloaded the 
firmware into memory, and would not be affected. If it is mid-download then it 
would have no affect other than breaking the operation and perhaps requiring a 
manual restart if it is coming off a factory reset

Ben Amick
Telecom Analyst

From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of Anthony Holloway
Sent: Thursday, December 01, 2016 5:08 PM
To: Nick Barnett >
Cc: Cisco VoIP Group 
>
Subject: Re: [cisco-voip] Are there any gotchas to watch out for switching to 
FQDN server names from IP address server names?

Is TFTP really that trivial?  What would happen to an endpoint, which is in the 
middle of a firmware upgrade, when you deactivate TFTP?

On Thu, Dec 1, 2016 at 2:51 PM, Nick Barnett 
> wrote:
I figured that a reboot would work, but TAC told me it wouldn't... and rather 
than experimenting, I just did what they said to do :)   Besides, deactivating 
TFTP is trivial and in a properly laid out deployment should have 0 impact.

On Wed, Nov 30, 2016 at 8:28 AM, NateCCIE 
> wrote:
A reboot does work. What the deal is the new https version of tftp (port 6972) 
does not restart with the service restart.  So it continues to use the old 
cert. But it does stop and start with a service deactivation and reactivation.  
Before cucm 11 the tftp over http was only plain text (port 6970)


Sent from my iPhone

On Nov 30, 2016, at 1:12 AM, James Buchanan 
> wrote:
Hello,
If I remember right, it actually has to be deactivated under Service 
Management. It's not just restarting the service.
Thanks,
James

On Tue, Nov 29, 2016 at 11:36 PM, Derek Andrew 
> wrote:
Would a simple reboot accomplish the same as deactivating and activating?

On Mon, Nov 28, 2016 at 2:19 PM, Nick Barnett 
> wrote:
I just thought I would share what happened with this, even though it is super 
old. Changing the node names to FQDN was mostly painless. The one thing that 
bit me was bug CSCuy13916. After changing the names of the nodes, the TFTP 
service needs to be DEACTIVATED and then re-activated in order to fully update 
the certificates.  Before taking those steps, I kept getting certificate errors 
from CuciLync, but afterwards, everything worked as designed.

Other than that, any CTI route points (and any other device as well) that exist 
will fall to another node in the CMG. Not a big deal, just something to be 
aware of.

Thanks,
Nick

On Wed, Aug 31, 2016 at 3:13 PM, Nick Barnett 
> wrote:
We are on 10.0 and this cluster has been upgraded over the years from 8.0 to 
8.6 to 10.0.  I know it used to be common practice to rip the host name out of 
a new node and put in the IP address. That's how we are set up... but now that 
I need to do some work with certs so that jabber and cucilync work properly, 
it's time to fix this.

Is there anything I should watch out for? 

Re: [cisco-voip] Are there any gotchas to watch out for switching to FQDN server names from IP address server names?

[James Buchanan]

If the endpoint is 8000 miles away from you and located in a nuclear power
plant, that TFTP interruption wasn't so trivial.

On Thu, Dec 1, 2016 at 5:10 PM, Ben Amick  wrote:

> An endpoint in the middle of an upgrade has already entirely downloaded
> the firmware into memory, and would not be affected. If it is mid-download
> then it would have no affect other than breaking the operation and perhaps
> requiring a manual restart if it is coming off a factory reset
>
>
>
> *Ben Amick*
>
> Telecom Analyst
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On Behalf
> Of *Anthony Holloway
> *Sent:* Thursday, December 01, 2016 5:08 PM
> *To:* Nick Barnett 
> *Cc:* Cisco VoIP Group 
> *Subject:* Re: [cisco-voip] Are there any gotchas to watch out for
> switching to FQDN server names from IP address server names?
>
>
>
> Is TFTP really that trivial?  What would happen to an endpoint, which is
> in the middle of a firmware upgrade, when you deactivate TFTP?
>
>
>
> On Thu, Dec 1, 2016 at 2:51 PM, Nick Barnett 
> wrote:
>
> I figured that a reboot would work, but TAC told me it wouldn't... and
> rather than experimenting, I just did what they said to do :)   Besides,
> deactivating TFTP is trivial and in a properly laid out deployment should
> have 0 impact.
>
>
>
> On Wed, Nov 30, 2016 at 8:28 AM, NateCCIE  wrote:
>
> A reboot does work. What the deal is the new https version of tftp (port
> 6972) does not restart with the service restart.  So it continues to use
> the old cert. But it does stop and start with a service deactivation and
> reactivation.  Before cucm 11 the tftp over http was only plain text (port
> 6970)
>
>
>
> Sent from my iPhone
>
>
> On Nov 30, 2016, at 1:12 AM, James Buchanan 
> wrote:
>
> Hello,
>
> If I remember right, it actually has to be deactivated under Service
> Management. It's not just restarting the service.
>
> Thanks,
>
> James
>
>
>
> On Tue, Nov 29, 2016 at 11:36 PM, Derek Andrew 
> wrote:
>
> Would a simple reboot accomplish the same as deactivating and activating?
>
>
>
> On Mon, Nov 28, 2016 at 2:19 PM, Nick Barnett 
> wrote:
>
> I just thought I would share what happened with this, even though it is
> super old. Changing the node names to FQDN was mostly painless. The one
> thing that bit me was bug CSCuy13916. After changing the names of the
> nodes, the TFTP service needs to be DEACTIVATED and then re-activated in
> order to fully update the certificates.  Before taking those steps, I kept
> getting certificate errors from CuciLync, but afterwards, everything worked
> as designed.
>
>
>
> Other than that, any CTI route points (and any other device as well) that
> exist will fall to another node in the CMG. Not a big deal, just something
> to be aware of.
>
>
>
> Thanks,
>
> Nick
>
>
>
> On Wed, Aug 31, 2016 at 3:13 PM, Nick Barnett 
> wrote:
>
> We are on 10.0 and this cluster has been upgraded over the years from 8.0
> to 8.6 to 10.0.  I know it used to be common practice to rip the host name
> out of a new node and put in the IP address. That's how we are set up...
> but now that I need to do some work with certs so that jabber and cucilync
> work properly, it's time to fix this.
>
>
>
> Is there anything I should watch out for? Anything that may bite me in
> rare cases? We have CER, CVP, CUC, UCCE and a rarely used IMP.
>
>
>
> I checked that each node has DNS enabled by looking at "show network eth0"
> on each sub. I also then looked up each FQDN from each node and they all
> resolve properly. As far as I know, that's about it.
>
>
>
> Thanks in advance!
>
>
> nick
>
>
>
>
>
>
> --
>
> Copyright 2016 Derek Andrew (excluding quotations)
>
> +1 306 966 4808 <(306)%20966-4808>
>
> Communication and Network Services
>
> Information and Communications Technology
>
> Infrastructure Services
>
> *University of Saskatchewan *Peterson 120; 54 Innovation Boulevard
> Saskatoon,Saskatchewan,Canada. S7N 2V3
> Timezone GMT-6
>
> Typed but not read.
>
>
> ___
> 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] Are there any gotchas to watch out for switching to FQDN server names from IP address server names?

[Ben Amick]

An endpoint in the middle of an upgrade has already entirely downloaded the 
firmware into memory, and would not be affected. If it is mid-download then it 
would have no affect other than breaking the operation and perhaps requiring a 
manual restart if it is coming off a factory reset

Ben Amick
Telecom Analyst

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Anthony Holloway
Sent: Thursday, December 01, 2016 5:08 PM
To: Nick Barnett 
Cc: Cisco VoIP Group 
Subject: Re: [cisco-voip] Are there any gotchas to watch out for switching to 
FQDN server names from IP address server names?

Is TFTP really that trivial?  What would happen to an endpoint, which is in the 
middle of a firmware upgrade, when you deactivate TFTP?

On Thu, Dec 1, 2016 at 2:51 PM, Nick Barnett 
> wrote:
I figured that a reboot would work, but TAC told me it wouldn't... and rather 
than experimenting, I just did what they said to do :)   Besides, deactivating 
TFTP is trivial and in a properly laid out deployment should have 0 impact.

On Wed, Nov 30, 2016 at 8:28 AM, NateCCIE 
> wrote:
A reboot does work. What the deal is the new https version of tftp (port 6972) 
does not restart with the service restart.  So it continues to use the old 
cert. But it does stop and start with a service deactivation and reactivation.  
Before cucm 11 the tftp over http was only plain text (port 6970)


Sent from my iPhone

On Nov 30, 2016, at 1:12 AM, James Buchanan 
> wrote:
Hello,
If I remember right, it actually has to be deactivated under Service 
Management. It's not just restarting the service.
Thanks,
James

On Tue, Nov 29, 2016 at 11:36 PM, Derek Andrew 
> wrote:
Would a simple reboot accomplish the same as deactivating and activating?

On Mon, Nov 28, 2016 at 2:19 PM, Nick Barnett 
> wrote:
I just thought I would share what happened with this, even though it is super 
old. Changing the node names to FQDN was mostly painless. The one thing that 
bit me was bug CSCuy13916. After changing the names of the nodes, the TFTP 
service needs to be DEACTIVATED and then re-activated in order to fully update 
the certificates.  Before taking those steps, I kept getting certificate errors 
from CuciLync, but afterwards, everything worked as designed.

Other than that, any CTI route points (and any other device as well) that exist 
will fall to another node in the CMG. Not a big deal, just something to be 
aware of.

Thanks,
Nick

On Wed, Aug 31, 2016 at 3:13 PM, Nick Barnett 
> wrote:
We are on 10.0 and this cluster has been upgraded over the years from 8.0 to 
8.6 to 10.0.  I know it used to be common practice to rip the host name out of 
a new node and put in the IP address. That's how we are set up... but now that 
I need to do some work with certs so that jabber and cucilync work properly, 
it's time to fix this.

Is there anything I should watch out for? Anything that may bite me in rare 
cases? We have CER, CVP, CUC, UCCE and a rarely used IMP.

I checked that each node has DNS enabled by looking at "show network eth0" on 
each sub. I also then looked up each FQDN from each node and they all resolve 
properly. As far as I know, that's about it.

Thanks in advance!

nick




--
Copyright 2016 Derek Andrew (excluding quotations)

+1 306 966 4808
Communication and Network Services
Information and Communications Technology
Infrastructure Services
University of Saskatchewan
Peterson 120; 54 Innovation Boulevard
Saskatoon,Saskatchewan,Canada. S7N 2V3
Timezone GMT-6

Typed but not read.

[http://homepage.usask.ca/dfa878/uofs.gif]

___
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

Re: [cisco-voip] Are there any gotchas to watch out for switching to FQDN server names from IP address server names?

[Anthony Holloway]

Is TFTP really that trivial?  What would happen to an endpoint, which is in
the middle of a firmware upgrade, when you deactivate TFTP?

On Thu, Dec 1, 2016 at 2:51 PM, Nick Barnett  wrote:

> I figured that a reboot would work, but TAC told me it wouldn't... and
> rather than experimenting, I just did what they said to do :)   Besides,
> deactivating TFTP is trivial and in a properly laid out deployment should
> have 0 impact.
>
> On Wed, Nov 30, 2016 at 8:28 AM, NateCCIE  wrote:
>
>> A reboot does work. What the deal is the new https version of tftp (port
>> 6972) does not restart with the service restart.  So it continues to use
>> the old cert. But it does stop and start with a service deactivation and
>> reactivation.  Before cucm 11 the tftp over http was only plain text (port
>> 6970)
>>
>>
>> Sent from my iPhone
>>
>> On Nov 30, 2016, at 1:12 AM, James Buchanan 
>> wrote:
>>
>> Hello,
>>
>> If I remember right, it actually has to be deactivated under Service
>> Management. It's not just restarting the service.
>>
>> Thanks,
>>
>> James
>>
>> On Tue, Nov 29, 2016 at 11:36 PM, Derek Andrew 
>> wrote:
>>
>>> Would a simple reboot accomplish the same as deactivating and activating?
>>>
>>> On Mon, Nov 28, 2016 at 2:19 PM, Nick Barnett 
>>> wrote:
>>>
 I just thought I would share what happened with this, even though it is
 super old. Changing the node names to FQDN was mostly painless. The one
 thing that bit me was bug CSCuy13916. After changing the names of the
 nodes, the TFTP service needs to be DEACTIVATED and then re-activated in
 order to fully update the certificates.  Before taking those steps, I kept
 getting certificate errors from CuciLync, but afterwards, everything worked
 as designed.

 Other than that, any CTI route points (and any other device as well)
 that exist will fall to another node in the CMG. Not a big deal, just
 something to be aware of.

 Thanks,
 Nick

 On Wed, Aug 31, 2016 at 3:13 PM, Nick Barnett 
 wrote:

> We are on 10.0 and this cluster has been upgraded over the years from
> 8.0 to 8.6 to 10.0.  I know it used to be common practice to rip the host
> name out of a new node and put in the IP address. That's how we are set
> up... but now that I need to do some work with certs so that jabber and
> cucilync work properly, it's time to fix this.
>
> Is there anything I should watch out for? Anything that may bite me in
> rare cases? We have CER, CVP, CUC, UCCE and a rarely used IMP.
>
> I checked that each node has DNS enabled by looking at "show network
> eth0" on each sub. I also then looked up each FQDN from each node and they
> all resolve properly. As far as I know, that's about it.
>
> Thanks in advance!
>
> nick
>


>>>
>>>
>>> --
>>> Copyright 2016 Derek Andrew (excluding quotations)
>>>
>>> +1 306 966 4808 <(306)%20966-4808>
>>> Communication and Network Services
>>> Information and Communications Technology
>>> Infrastructure Services
>>>
>>> *University of Saskatchewan*Peterson 120; 54 Innovation Boulevard
>>> Saskatoon,Saskatchewan,Canada. S7N 2V3
>>> Timezone GMT-6
>>>
>>> Typed but not read.
>>>
>>>
>>>
>>>
>>> ___
>>> 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
>>
>>
>
> ___
> 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] Call Recording with CUCM9.1

[Nick Barnett]

And if you have centralized call ingress/egress, like with enterprise SIP
trunks, you can use media class forking on the CUBE to cut down on WAN
usage.

On Thu, Dec 1, 2016 at 8:22 AM, Ryan Huff  wrote:

> Cisco MediaSense is a great (and admittedly, simple) option for BIB
> recording; just need to purchase the RTU and put it on some virtual
> hardware.
>
> Sent from my iPhone
>
> On Dec 1, 2016, at 9:17 AM, Brian Meade  wrote:
>
> You're probably much better using BIB(built-in bridge)-based/network
> recording instead.  It uses the Built-in-bridge of the phones to send
> duplicate RTP streams to a recording server.  Most recording servers out
> there now prefer this method.
>
> It's technically possible to route the span sessions over the WAN.  ERSPAN
> on your switches would make this a lot easier but I'd really recommend
> getting away from that type of setup.
>
> On Thu, Dec 1, 2016 at 6:24 AM, Michel L. M. B. Perez <
> michelmbpe...@gmail.com> wrote:
>
>> Hi guys,
>>
>> I never did that, so that´s why i am asking for all entire list here. Is
>> it possible to record calls over WAN using CUCM?
>>
>> Today, my scenario is (branches):
>> I have one (old) machine doing the recording of the calls in all branch
>> sites, all Phones that needs to be recorded are using a span session on the
>> switches of Branches, the traffic is routed to the Recorder monitor port.
>> I have the same situation in all sites, HQ and Branches.
>>
>> My desire is to have here just one call recorder over my Vmware
>> infrastructure, and all of this recorded calls being rotued over IP of the
>> virtualized machine.
>>
>> I was reading this document: http://www.cisco.com
>> /c/en/us/td/docs/voice_ip_comm/cucm/admin/7_1_2/ccmfeat/fsgd
>> -712-cm/fsmr.html#wp1048991
>>
>> Do you think that this is possible?
>>
>> Kr.,
>> --
>> Michel Perez
>> Skype: michelmbperez
>> michelmbpe...@gmail.com
>> http://br.linkedin.com/in/michelmbperez
>>
>> ___
>> 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
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] TP Room Endpoints - Name and Number on TV Display

[Anthony Holloway]

This worked  beautifully.  And yes, setting it on other side: codec side or
CM side, forced an update to the opposite side.  Also, no Apply
Config/Reset/Restart required, the display at the top just changes.

Dangso simple.  Well, I guess that's ignorance for you.  I'm new to
Telepresence.  Thanks so much.

On Thu, Dec 1, 2016 at 1:17 PM, Ryan Ratliff (rratliff) 
wrote:

> All the settings on the Device page correspond pretty directly to the
> endpoint’s xconfig equivalent. In later TC code and UCM it will even push
> an update you make on the endpoint up to UCM (for one of those fields).
>
> There used to be an Admin guide for TP Enpoints with CUCM but I don’t know
> if it’s been updated since TC6.
>
> As far as I know just about all TC and CE endpoints share the same
> settings on the Device page (QED, xml, whatever you are used to calling
> them).
>
> -Ryan
>
> On Dec 1, 2016, at 2:13 PM, Anthony Holloway  com> wrote:
>
> Do you have a link you can refer me to which explains how this setting is
> used?  And, do you know if all TP endpoints support that field equally?
>
> I'll give this a try in a few minutes and report back.  Thanks Ryan!
>
> On Thu, Dec 1, 2016 at 12:53 PM, Ryan Ratliff (rratliff) <
> rratl...@cisco.com> wrote:
>
>> I’d recommend setting the System Name on the Device page for the C20.
>> That will sync up with the endpoint’s local setting and avoid any interop
>> issues with the Line value.
>>
>> -Ryan
>>
>> On Dec 1, 2016, at 1:27 PM, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>> Hi All,
>>
>> I am wondering if anyone has solved a certain problem for endpoints which
>> are registered to CUCM.  You know how the system will show a name for the
>> device at the top left of the TV screen?  I'm not talking touch 8 or touch
>> 10 here, but the actual TV or monitor display.
>>
>> I would like to show a combination of the name of the room and the phone
>> number as well, but I'm not finding a very good solution to do this.
>>
>> I did notice that what shows up by default is from CUCM DN Display field,
>> so I edited it.
>>
>> Instead of just this:
>>
>> 
>>
>> I used this:
>>
>> 
>>
>> And that works, but then I face two challenges:
>>
>> 1) Internal Caller ID is really long and redundant, containing the DN in
>> itself
>>
>> Plus, the documentation says you shouldn't put a number in here, probably
>> for the same reason I'm saying (not good practice):
>>
>> 
>>
>> 2) Or the whole thing is just too long and over the character limit, like
>> this (note I cannot fit the rest of the number):
>>
>> 
>>
>> So, that's less than ideal, but atleast it's persistent through reboots
>> of the codec.
>>
>> A non-persistent approach I did try, is changing the Codec's SIP
>> DisplayName, which by default is populated with what's in CUCM's DN Display
>> field:
>>
>> From the default:
>>
>> 
>>
>> To this:
>>
>> 
>>
>>
>> And that works too, but then it's volatile and I have to keep changing
>> them back all the time, and checking up on them, bleh.  No thanks.
>>
>> I did look into the start up script option on a TC7.3 C20 codec, so the
>> system can reconfigure its own DisplayName when booting, but that didn't
>> work with the below simple script, despite working when manually clicking
>> Run. I think it didn't work because of the order of operations: 1) boot
>> codec, 2) run script and update display name, 3) register with CUCM, 4)
>> re-update display name from CUCM
>>
>> 
>>
>> So anyway, I've done some searching, but not really knowing these systems
>> too well or the terminology, I'm kind of stuck.  I suppose I could write a
>> script in Python and have it check the config and update, and set that to
>> run every 10 minutes or whatever, but I don't know.  Maybe.
>>
>> I'll leave it there and see what you all have seen or done.  Thanks much.
>>
>> ___
>> 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] TP Room Endpoints - Name and Number on TV Display

[Ryan Ratliff (rratliff)]

All the settings on the Device page correspond pretty directly to the 
endpoint’s xconfig equivalent. In later TC code and UCM it will even push an 
update you make on the endpoint up to UCM (for one of those fields).

There used to be an Admin guide for TP Enpoints with CUCM but I don’t know if 
it’s been updated since TC6.

As far as I know just about all TC and CE endpoints share the same settings on 
the Device page (QED, xml, whatever you are used to calling them).

-Ryan

On Dec 1, 2016, at 2:13 PM, Anthony Holloway 
> wrote:

Do you have a link you can refer me to which explains how this setting is used? 
 And, do you know if all TP endpoints support that field equally?

I'll give this a try in a few minutes and report back.  Thanks Ryan!

On Thu, Dec 1, 2016 at 12:53 PM, Ryan Ratliff (rratliff) 
> wrote:
I’d recommend setting the System Name on the Device page for the C20.  That 
will sync up with the endpoint’s local setting and avoid any interop issues 
with the Line value.

-Ryan

On Dec 1, 2016, at 1:27 PM, Anthony Holloway 
> 
wrote:

Hi All,

I am wondering if anyone has solved a certain problem for endpoints which are 
registered to CUCM.  You know how the system will show a name for the device at 
the top left of the TV screen?  I'm not talking touch 8 or touch 10 here, but 
the actual TV or monitor display.

I would like to show a combination of the name of the room and the phone number 
as well, but I'm not finding a very good solution to do this.

I did notice that what shows up by default is from CUCM DN Display field, so I 
edited it.

Instead of just this:



I used this:



And that works, but then I face two challenges:

1) Internal Caller ID is really long and redundant, containing the DN in itself

Plus, the documentation says you shouldn't put a number in here, probably for 
the same reason I'm saying (not good practice):



2) Or the whole thing is just too long and over the character limit, like this 
(note I cannot fit the rest of the number):



So, that's less than ideal, but atleast it's persistent through reboots of the 
codec.

A non-persistent approach I did try, is changing the Codec's SIP DisplayName, 
which by default is populated with what's in CUCM's DN Display field:

From the default:



To this:




And that works too, but then it's volatile and I have to keep changing them 
back all the time, and checking up on them, bleh.  No thanks.

I did look into the start up script option on a TC7.3 C20 codec, so the system 
can reconfigure its own DisplayName when booting, but that didn't work with the 
below simple script, despite working when manually clicking Run. I think it 
didn't work because of the order of operations: 1) boot codec, 2) run script 
and update display name, 3) register with CUCM, 4) re-update display name from 
CUCM



So anyway, I've done some searching, but not really knowing these systems too 
well or the terminology, I'm kind of stuck.  I suppose I could write a script 
in Python and have it check the config and update, and set that to run every 10 
minutes or whatever, but I don't know.  Maybe.

I'll leave it there and see what you all have seen or done.  Thanks much.

___
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] TP Room Endpoints - Name and Number on TV Display

[Anthony Holloway]

Do you have a link you can refer me to which explains how this setting is
used?  And, do you know if all TP endpoints support that field equally?

I'll give this a try in a few minutes and report back.  Thanks Ryan!

On Thu, Dec 1, 2016 at 12:53 PM, Ryan Ratliff (rratliff)  wrote:

> I’d recommend setting the System Name on the Device page for the C20.
> That will sync up with the endpoint’s local setting and avoid any interop
> issues with the Line value.
>
> -Ryan
>
> On Dec 1, 2016, at 1:27 PM, Anthony Holloway  com> wrote:
>
> Hi All,
>
> I am wondering if anyone has solved a certain problem for endpoints which
> are registered to CUCM.  You know how the system will show a name for the
> device at the top left of the TV screen?  I'm not talking touch 8 or touch
> 10 here, but the actual TV or monitor display.
>
> I would like to show a combination of the name of the room and the phone
> number as well, but I'm not finding a very good solution to do this.
>
> I did notice that what shows up by default is from CUCM DN Display field,
> so I edited it.
>
> Instead of just this:
>
> 
>
> I used this:
>
> 
>
> And that works, but then I face two challenges:
>
> 1) Internal Caller ID is really long and redundant, containing the DN in
> itself
>
> Plus, the documentation says you shouldn't put a number in here, probably
> for the same reason I'm saying (not good practice):
>
> 
>
> 2) Or the whole thing is just too long and over the character limit, like
> this (note I cannot fit the rest of the number):
>
> 
>
> So, that's less than ideal, but atleast it's persistent through reboots of
> the codec.
>
> A non-persistent approach I did try, is changing the Codec's SIP
> DisplayName, which by default is populated with what's in CUCM's DN Display
> field:
>
> From the default:
>
> 
>
> To this:
>
> 
>
>
> And that works too, but then it's volatile and I have to keep changing
> them back all the time, and checking up on them, bleh.  No thanks.
>
> I did look into the start up script option on a TC7.3 C20 codec, so the
> system can reconfigure its own DisplayName when booting, but that didn't
> work with the below simple script, despite working when manually clicking
> Run. I think it didn't work because of the order of operations: 1) boot
> codec, 2) run script and update display name, 3) register with CUCM, 4)
> re-update display name from CUCM
>
> 
>
> So anyway, I've done some searching, but not really knowing these systems
> too well or the terminology, I'm kind of stuck.  I suppose I could write a
> script in Python and have it check the config and update, and set that to
> run every 10 minutes or whatever, but I don't know.  Maybe.
>
> I'll leave it there and see what you all have seen or done.  Thanks much.
>
> ___
> 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] TP Room Endpoints - Name and Number on TV Display

[Ryan Ratliff (rratliff)]

I’d recommend setting the System Name on the Device page for the C20.  That 
will sync up with the endpoint’s local setting and avoid any interop issues 
with the Line value.

-Ryan

On Dec 1, 2016, at 1:27 PM, Anthony Holloway  
wrote:

Hi All,

I am wondering if anyone has solved a certain problem for endpoints which are 
registered to CUCM.  You know how the system will show a name for the device at 
the top left of the TV screen?  I'm not talking touch 8 or touch 10 here, but 
the actual TV or monitor display.

I would like to show a combination of the name of the room and the phone number 
as well, but I'm not finding a very good solution to do this.

I did notice that what shows up by default is from CUCM DN Display field, so I 
edited it.

Instead of just this:



I used this:



And that works, but then I face two challenges:

1) Internal Caller ID is really long and redundant, containing the DN in itself

Plus, the documentation says you shouldn't put a number in here, probably for 
the same reason I'm saying (not good practice):



2) Or the whole thing is just too long and over the character limit, like this 
(note I cannot fit the rest of the number):



So, that's less than ideal, but atleast it's persistent through reboots of the 
codec.

A non-persistent approach I did try, is changing the Codec's SIP DisplayName, 
which by default is populated with what's in CUCM's DN Display field:

From the default:



To this:




And that works too, but then it's volatile and I have to keep changing them 
back all the time, and checking up on them, bleh.  No thanks.

I did look into the start up script option on a TC7.3 C20 codec, so the system 
can reconfigure its own DisplayName when booting, but that didn't work with the 
below simple script, despite working when manually clicking Run. I think it 
didn't work because of the order of operations: 1) boot codec, 2) run script 
and update display name, 3) register with CUCM, 4) re-update display name from 
CUCM



So anyway, I've done some searching, but not really knowing these systems too 
well or the terminology, I'm kind of stuck.  I suppose I could write a script 
in Python and have it check the config and update, and set that to run every 10 
minutes or whatever, but I don't know.  Maybe.

I'll leave it there and see what you all have seen or done.  Thanks much.

___
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] Cisco Webex Meetings Server Error 23

[Anthony Holloway]

I'm not aware of the connection between Verisign and CWMS.  How did you
even think to do that?  Random guess?

I do know that CWMS certs signed by an intermediate CA will require you to
upload the chain in a single file, in order for CWMS to present the chain
to the client machine.  You can click on your cert in CWMS copy the text,
paste it in Notepad++, and search for "Issuer:".  If you're using a chain,
you'll see two or more Issuers, but a root one would only have the single
Issuer, and it would be a root CA, not intermediate CA.  Here's an example
of a GoDaddy two level trust chain from a CWMS system I'm managing.

[image: Inline image 1]

And when I browse to the web interface, I look at the certificate and see
the chain there as well (which means I uploaded it correctly, and the
server is presenting it correctly)

[image: Inline image 2]

Are you using that feature where you use one cert for the whole system, or
two different certs for outside and inside?  If using the two cert option,
are you using a verisgn cert on the inside while geotrust on outside?

If I recall correctly, CWMS can use an Internal cert for both inside and
outside, if you have not uploaded an external cert, but cannot have an
external cert only.


On Wed, Nov 30, 2016 at 7:01 PM, Fachrizal Rifandi Zainuddin <
fachrizal@gmail.com> wrote:

> Hi All,
>
> I'm having a little problem with Cisco Webex Meeting Server a.k.a CWMS.
> Version of my CWMS is 2.7 so that is the latest version.
>
> Everytime a user try to connect from internal the plugin has stopped and
> showing something like "Setup was unsuccessful.Please try again [Error
> 23]". it not affected if we connect it from internet since we are using
> different cert (Geotrust)
>
> I fixed it by installing Verisign certificate manually and install it as
> Intermediate CA certificate on affected PCs. Is there any reason why do i
> have to install those cert ? Why Verisign ? What is the connection between
> Verisign and Webex that installed ?
>
> Regards
>
> Fachrizal
>
> ___
> 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] Call Recording with CUCM9.1

[Ryan Huff]

Cisco MediaSense is a great (and admittedly, simple) option for BIB recording; 
just need to purchase the RTU and put it on some virtual hardware.

Sent from my iPhone

On Dec 1, 2016, at 9:17 AM, Brian Meade 
> wrote:

You're probably much better using BIB(built-in bridge)-based/network recording 
instead.  It uses the Built-in-bridge of the phones to send duplicate RTP 
streams to a recording server.  Most recording servers out there now prefer 
this method.

It's technically possible to route the span sessions over the WAN.  ERSPAN on 
your switches would make this a lot easier but I'd really recommend getting 
away from that type of setup.

On Thu, Dec 1, 2016 at 6:24 AM, Michel L. M. B. Perez 
> wrote:
Hi guys,

I never did that, so that´s why i am asking for all entire list here. Is it 
possible to record calls over WAN using CUCM?

Today, my scenario is (branches):
I have one (old) machine doing the recording of the calls in all branch sites, 
all Phones that needs to be recorded are using a span session on the switches 
of Branches, the traffic is routed to the Recorder monitor port.
I have the same situation in all sites, HQ and Branches.

My desire is to have here just one call recorder over my Vmware infrastructure, 
and all of this recorded calls being rotued over IP of the virtualized machine.

I was reading this document: 
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/7_1_2/ccmfeat/fsgd-712-cm/fsmr.html#wp1048991

Do you think that this is possible?

Kr.,
--
Michel Perez
Skype: michelmbperez
michelmbpe...@gmail.com
http://br.linkedin.com/in/michelmbperez

___
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] Call Recording with CUCM9.1

[Brian Meade]

You're probably much better using BIB(built-in bridge)-based/network
recording instead.  It uses the Built-in-bridge of the phones to send
duplicate RTP streams to a recording server.  Most recording servers out
there now prefer this method.

It's technically possible to route the span sessions over the WAN.  ERSPAN
on your switches would make this a lot easier but I'd really recommend
getting away from that type of setup.

On Thu, Dec 1, 2016 at 6:24 AM, Michel L. M. B. Perez <
michelmbpe...@gmail.com> wrote:

> Hi guys,
>
> I never did that, so that´s why i am asking for all entire list here. Is
> it possible to record calls over WAN using CUCM?
>
> Today, my scenario is (branches):
> I have one (old) machine doing the recording of the calls in all branch
> sites, all Phones that needs to be recorded are using a span session on the
> switches of Branches, the traffic is routed to the Recorder monitor port.
> I have the same situation in all sites, HQ and Branches.
>
> My desire is to have here just one call recorder over my Vmware
> infrastructure, and all of this recorded calls being rotued over IP of the
> virtualized machine.
>
> I was reading this document: http://www.cisco.
> com/c/en/us/td/docs/voice_ip_comm/cucm/admin/7_1_2/ccmfeat/
> fsgd-712-cm/fsmr.html#wp1048991
>
> Do you think that this is possible?
>
> Kr.,
> --
> Michel Perez
> Skype: michelmbperez
> michelmbpe...@gmail.com
> http://br.linkedin.com/in/michelmbperez
>
> ___
> 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] Cisco Unity Data Dump Auto-config

[Ben Amick]

Does anyone know if the Cisco UDD program from UnityTools has any way it can be 
programmed to automatically add new users to the file? It's been set up in our 
environment for ever that we use that program to produce reports that are 
harvested by as SQL script for reporting purposes, but it's agitating to have 
to go in and reconfigure the program every single time we add new users to the 
environment despite the fact that it runs as a scheduled task.

Ben Amick
Telecom Analyst



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