Re: [cisco-voip] PLM 11.0 issues with CUC 11.5.1 SU3?

2017-08-27 Thread Erick Bergquist
Ok, I was thinking about it being that.  Should have stuck to CUC 11.5.1 SU2.

It was working fine for a week. Weird.

So I wonder if I can rehost the licenses to Unity Connection 11.5 SU3
and have CUCM 11.0 talk to PLM on unity connection 11.5.1 SU3 fine?

PLM is co-located on CUCM 11.0 right now (not standalone PLM server).

Thanks!


On Sun, Aug 27, 2017 at 11:50 PM, Charles Goldsmith
 wrote:
> 11.5.1su3 requires PLM 11.5.1su2, due to the change with the encryption
> license:
> https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/plm/11_5_1_SU2/releasenotes/cplm_b_release-notes-cplm-1151su2/cplm_b_release-notes-cplm-1151su2_chapter_01.html
> Look at the first Note.
>
> YMMV, but I ran into a bug when I upgraded a PLM to su2 recently, it
> wouldn't switch version, even after a reboot, got a vague error about
> locking the database.  After waiting a few hours with no change, booted off
> of the recovery CD and forced the switch.  No issues after that.  I had a
> good backup, so wasn't concerned about forcing it.
>
> On Mon, Aug 28, 2017 at 12:43 AM, Erick Bergquist 
> wrote:
>>
>> Anyone having any issues with CUC 11.5.1 SU3 and PLM on a 11.0.1?
>>
>> (thinking about rehosting licenses to the 11.5.1 SU3 CUC node)
>>
>> It has been working fine for a week since the upgrade and today CUC
>> threw a license error.
>>
>> PLM 11.0 shows a "Application Error" for the Unity Connection instance.
>>
>> I deleted the product instance from PLM, added it back and it picks up
>> correct 11.5 version fine then on Sync gives "Application Error".
>>
>> I've reset the unity servers and call manager acting as PLM and same
>> thing.
>>
>> I reset PLM to default demo mode, deleted the Product instances, and
>> applied the licenses again.  I added Product instances back and it is
>> not liking  Unity still. PLM has all 11.x licenses. PLM detects the
>> unity version 11.5 correct but doesn't sync.
>>
>> Reason we're using CUCM 11.0 over 11.5 is due to phone depreciation in
>> 11.5 with some model phones.
>>
>> Erick
>> ___
>> 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] PLM 11.0 issues with CUC 11.5.1 SU3?

2017-08-27 Thread Charles Goldsmith
11.5.1su3 requires PLM 11.5.1su2, due to the change with the encryption
license:
https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/plm/11_5_1_SU2/releasenotes/cplm_b_release-notes-cplm-1151su2/cplm_b_release-notes-cplm-1151su2_chapter_01.html
  Look at the first Note.

YMMV, but I ran into a bug when I upgraded a PLM to su2 recently, it
wouldn't switch version, even after a reboot, got a vague error about
locking the database.  After waiting a few hours with no change, booted off
of the recovery CD and forced the switch.  No issues after that.  I had a
good backup, so wasn't concerned about forcing it.

On Mon, Aug 28, 2017 at 12:43 AM, Erick Bergquist 
wrote:

> Anyone having any issues with CUC 11.5.1 SU3 and PLM on a 11.0.1?
>
> (thinking about rehosting licenses to the 11.5.1 SU3 CUC node)
>
> It has been working fine for a week since the upgrade and today CUC
> threw a license error.
>
> PLM 11.0 shows a "Application Error" for the Unity Connection instance.
>
> I deleted the product instance from PLM, added it back and it picks up
> correct 11.5 version fine then on Sync gives "Application Error".
>
> I've reset the unity servers and call manager acting as PLM and same thing.
>
> I reset PLM to default demo mode, deleted the Product instances, and
> applied the licenses again.  I added Product instances back and it is
> not liking  Unity still. PLM has all 11.x licenses. PLM detects the
> unity version 11.5 correct but doesn't sync.
>
> Reason we're using CUCM 11.0 over 11.5 is due to phone depreciation in
> 11.5 with some model phones.
>
> Erick
> ___
> 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] PLM 11.0 issues with CUC 11.5.1 SU3?

2017-08-27 Thread Erick Bergquist
Anyone having any issues with CUC 11.5.1 SU3 and PLM on a 11.0.1?

(thinking about rehosting licenses to the 11.5.1 SU3 CUC node)

It has been working fine for a week since the upgrade and today CUC
threw a license error.

PLM 11.0 shows a "Application Error" for the Unity Connection instance.

I deleted the product instance from PLM, added it back and it picks up
correct 11.5 version fine then on Sync gives "Application Error".

I've reset the unity servers and call manager acting as PLM and same thing.

I reset PLM to default demo mode, deleted the Product instances, and
applied the licenses again.  I added Product instances back and it is
not liking  Unity still. PLM has all 11.x licenses. PLM detects the
unity version 11.5 correct but doesn't sync.

Reason we're using CUCM 11.0 over 11.5 is due to phone depreciation in
11.5 with some model phones.

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


Re: [cisco-voip] UCM Upgrade Poll

2017-08-27 Thread Charles Goldsmith
I should have looked at that link a bit closer, it doesn't mention the cop
file:
http://www.cisco.com/web/software/282204704/18582/CleanupCommonCOPfilev1.4.pdf


Which is the 3rd method, but there is a caveat, so read it closely.

On Sun, Aug 27, 2017 at 11:25 PM, Charles Goldsmith 
wrote:

> There is!
>
> http://docwiki.cisco.com/wiki/Unified_CM_L2_Upgrade_Disk_
> Space_issues#Free_Up_Space_for_Unified_CM_L2_Upgrade.C2.A0
>
> That entire page is good reading.
>
>
> On Sun, Aug 27, 2017 at 11:20 PM, Lelio Fulgenzi 
> wrote:
>
>> Are there instructions on how to free up disk space?
>>
>> Sent from my iPhone
>>
>> On Aug 27, 2017, at 11:18 PM, Erick Bergquist  wrote:
>>
>> I've done a few dozen inplace upgrades of CUCM, Unity, UCCX with existing
>> VMs with no real issues over the past few years. Talking 8.x to 10.x  or
>> 11.x or 9.x to 10/11.x.
>>
>> Issues encountered:
>>
>> Freeing up disk space on existing VM for the RU/SU to install on a few
>> upgrades (more of a slow down)
>>
>> Recently had issue with IM 9.x to 11.x where a invalid ntp entry was in
>> the platformcfg.xml XML file that there is a bug ID on that TAC had to get
>> in with root access to remove. After that the IM inplace upgrade went
>> fine.
>>
>> And a few non-upgrade issues involving license matters and getting
>> correct number of licenses.
>>
>> I was reading another post about 12.0 using CentOS now, need to read that
>> over more and see what is changing with upgrade process.
>>
>>
>> My only wish was if these would go faster. Maybe have an incremental
>> patch with just fixes instead of a full size SU/install file and
>> reinstalling every file - especially for SU patches within same major
>> version.
>>
>> YMMV, Erick
>>
>>
>> On Thu, Aug 24, 2017 at 10:34 AM, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>>> Why not just come along with me on my next upgrade.  You can feel the
>>> pain...err excitement, of planning and executing an upgrade in the real
>>> world.  ;)
>>>
>>> On Thu, Aug 24, 2017 at 9:52 AM Ryan Ratliff (rratliff) <
>>> rratl...@cisco.com> wrote:
>>>
 Thanks everyone for the feedback.

 We are looking at ways to make upgrades easier and stories like these
 are very helpful.

 -Ryan

 On Aug 24, 2017, at 10:17 AM, Scott Voll  wrote:

 1. I'm guessing we are 10% True bugs and 90% environment, but I will
 agree with other comments about DNS and NTP being a dumb reason to fail

 2. as for time, over the years we used to spend over 6 months on
 upgrades.. we are down to about 2 months.  in our enviroment we have to
 document all the changes before so it can be communicated to the end user.
 Researching for the answers has moved from Anthony's 100 documents to just
 opening a TAC case.  It has become way to time consuming to find all the
 right doc's to get the correct answer.

 YMMV

 Scott


 On Wed, Aug 23, 2017 at 1:46 PM, Anthony Holloway <
 avholloway+cisco-v...@gmail.com> wrote:

> Wow, it's kind of cool that you're even asking.  Thanks for that.
>
> Already I can see this is going to be a wide gap in responses. Partner
> vs end user, this customer vs that customer, this version vs that version,
> this scenario vs that one, and on, and on, and on.
>
> 1) I feel like it's always a bug (100%), in that, developers should
> code solutions that can work around most issues.  E.g., I had an upgrade
> fail on a CUCM because the ntp was 0.us.pool.ntp.org, despite CUCM
> happily syncing to it in the current version.  OR Common partition not
> having enough space, when devs could just purge old logs to make room, or
> simply make better logs to begin with (I do admit, moving to compress logs
> [TAR/GZ] was sweet)
>
> 2) This is a painful one for me, but I put in a lot of time preparing
> for an upgrade.  A large portion of the time is, in my opinion, wasted
> finding the right documentation and then trying to interpret it.  Here's a
> fun one: there's over 100 documents an Engineer needs to reference in
> preparation for what I would consider a low-medium level environment.  
> I've
> posted this before, but I'll post it again, I have a matrix of documents I
> need to reference during the planning and execution phase of an upgrade:
>
>
>
>
> On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) <
> rratl...@cisco.com> wrote:
>
>> Quick 2 question poll, feel free to unicast or share your response
>> with the group.
>>
>> 1. When you or your customers have a UCM or IMP upgrade fail, what
>> percentage of failures are due to a bug vs something in the environment
>> (user error, db updates, etc)?
>> % bug:
>> % not a bug:
>> Yes it’s a very subjective question but 

Re: [cisco-voip] UCM Upgrade Poll

2017-08-27 Thread Charles Goldsmith
There is!

http://docwiki.cisco.com/wiki/Unified_CM_L2_Upgrade_Disk_Space_issues#Free_Up_Space_for_Unified_CM_L2_Upgrade.C2.A0


That entire page is good reading.


On Sun, Aug 27, 2017 at 11:20 PM, Lelio Fulgenzi  wrote:

> Are there instructions on how to free up disk space?
>
> Sent from my iPhone
>
> On Aug 27, 2017, at 11:18 PM, Erick Bergquist  wrote:
>
> I've done a few dozen inplace upgrades of CUCM, Unity, UCCX with existing
> VMs with no real issues over the past few years. Talking 8.x to 10.x  or
> 11.x or 9.x to 10/11.x.
>
> Issues encountered:
>
> Freeing up disk space on existing VM for the RU/SU to install on a few
> upgrades (more of a slow down)
>
> Recently had issue with IM 9.x to 11.x where a invalid ntp entry was in
> the platformcfg.xml XML file that there is a bug ID on that TAC had to get
> in with root access to remove. After that the IM inplace upgrade went
> fine.
>
> And a few non-upgrade issues involving license matters and getting correct
> number of licenses.
>
> I was reading another post about 12.0 using CentOS now, need to read that
> over more and see what is changing with upgrade process.
>
>
> My only wish was if these would go faster. Maybe have an incremental patch
> with just fixes instead of a full size SU/install file and reinstalling
> every file - especially for SU patches within same major version.
>
> YMMV, Erick
>
>
> On Thu, Aug 24, 2017 at 10:34 AM, Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Why not just come along with me on my next upgrade.  You can feel the
>> pain...err excitement, of planning and executing an upgrade in the real
>> world.  ;)
>>
>> On Thu, Aug 24, 2017 at 9:52 AM Ryan Ratliff (rratliff) <
>> rratl...@cisco.com> wrote:
>>
>>> Thanks everyone for the feedback.
>>>
>>> We are looking at ways to make upgrades easier and stories like these
>>> are very helpful.
>>>
>>> -Ryan
>>>
>>> On Aug 24, 2017, at 10:17 AM, Scott Voll  wrote:
>>>
>>> 1. I'm guessing we are 10% True bugs and 90% environment, but I will
>>> agree with other comments about DNS and NTP being a dumb reason to fail
>>>
>>> 2. as for time, over the years we used to spend over 6 months on
>>> upgrades.. we are down to about 2 months.  in our enviroment we have to
>>> document all the changes before so it can be communicated to the end user.
>>> Researching for the answers has moved from Anthony's 100 documents to just
>>> opening a TAC case.  It has become way to time consuming to find all the
>>> right doc's to get the correct answer.
>>>
>>> YMMV
>>>
>>> Scott
>>>
>>>
>>> On Wed, Aug 23, 2017 at 1:46 PM, Anthony Holloway <
>>> avholloway+cisco-v...@gmail.com> wrote:
>>>
 Wow, it's kind of cool that you're even asking.  Thanks for that.

 Already I can see this is going to be a wide gap in responses. Partner
 vs end user, this customer vs that customer, this version vs that version,
 this scenario vs that one, and on, and on, and on.

 1) I feel like it's always a bug (100%), in that, developers should
 code solutions that can work around most issues.  E.g., I had an upgrade
 fail on a CUCM because the ntp was 0.us.pool.ntp.org, despite CUCM
 happily syncing to it in the current version.  OR Common partition not
 having enough space, when devs could just purge old logs to make room, or
 simply make better logs to begin with (I do admit, moving to compress logs
 [TAR/GZ] was sweet)

 2) This is a painful one for me, but I put in a lot of time preparing
 for an upgrade.  A large portion of the time is, in my opinion, wasted
 finding the right documentation and then trying to interpret it.  Here's a
 fun one: there's over 100 documents an Engineer needs to reference in
 preparation for what I would consider a low-medium level environment.  I've
 posted this before, but I'll post it again, I have a matrix of documents I
 need to reference during the planning and execution phase of an upgrade:




 On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) <
 rratl...@cisco.com> wrote:

> Quick 2 question poll, feel free to unicast or share your response
> with the group.
>
> 1. When you or your customers have a UCM or IMP upgrade fail, what
> percentage of failures are due to a bug vs something in the environment
> (user error, db updates, etc)?
> % bug:
> % not a bug:
> Yes it’s a very subjective question but that’s ok, use your judgement.
>
> 2. When an upgrade goes smoothly with no issues, how much time do you
> put into the planning and preparation for the upgrade (not the execution)?
>
> Thanks,
>
> -Ryan
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

 

Re: [cisco-voip] UCM Upgrade Poll

2017-08-27 Thread Lelio Fulgenzi
Are there instructions on how to free up disk space?

Sent from my iPhone

On Aug 27, 2017, at 11:18 PM, Erick Bergquist 
> wrote:

I've done a few dozen inplace upgrades of CUCM, Unity, UCCX with existing VMs 
with no real issues over the past few years. Talking 8.x to 10.x  or 11.x or 
9.x to 10/11.x.

Issues encountered:

Freeing up disk space on existing VM for the RU/SU to install on a few upgrades 
(more of a slow down)

Recently had issue with IM 9.x to 11.x where a invalid ntp entry was in the 
platformcfg.xml XML file that there is a bug ID on that TAC had to get in with 
root access to remove. After that the IM inplace upgrade went fine.

And a few non-upgrade issues involving license matters and getting correct 
number of licenses.

I was reading another post about 12.0 using CentOS now, need to read that over 
more and see what is changing with upgrade process.


My only wish was if these would go faster. Maybe have an incremental patch with 
just fixes instead of a full size SU/install file and reinstalling every file - 
especially for SU patches within same major version.

YMMV, Erick


On Thu, Aug 24, 2017 at 10:34 AM, Anthony Holloway 
> wrote:
Why not just come along with me on my next upgrade.  You can feel the 
pain...err excitement, of planning and executing an upgrade in the real world.  
;)

On Thu, Aug 24, 2017 at 9:52 AM Ryan Ratliff (rratliff) 
> wrote:
Thanks everyone for the feedback.

We are looking at ways to make upgrades easier and stories like these are very 
helpful.

-Ryan

On Aug 24, 2017, at 10:17 AM, Scott Voll 
> wrote:

1. I'm guessing we are 10% True bugs and 90% environment, but I will agree with 
other comments about DNS and NTP being a dumb reason to fail

2. as for time, over the years we used to spend over 6 months on upgrades.. 
we are down to about 2 months.  in our enviroment we have to document all the 
changes before so it can be communicated to the end user.  Researching for the 
answers has moved from Anthony's 100 documents to just opening a TAC case.  It 
has become way to time consuming to find all the right doc's to get the correct 
answer.

YMMV

Scott


On Wed, Aug 23, 2017 at 1:46 PM, Anthony Holloway 
> wrote:
Wow, it's kind of cool that you're even asking.  Thanks for that.

Already I can see this is going to be a wide gap in responses. Partner vs end 
user, this customer vs that customer, this version vs that version, this 
scenario vs that one, and on, and on, and on.

1) I feel like it's always a bug (100%), in that, developers should code 
solutions that can work around most issues.  E.g., I had an upgrade fail on a 
CUCM because the ntp was 0.us.pool.ntp.org, despite 
CUCM happily syncing to it in the current version.  OR Common partition not 
having enough space, when devs could just purge old logs to make room, or 
simply make better logs to begin with (I do admit, moving to compress logs 
[TAR/GZ] was sweet)

2) This is a painful one for me, but I put in a lot of time preparing for an 
upgrade.  A large portion of the time is, in my opinion, wasted finding the 
right documentation and then trying to interpret it.  Here's a fun one: there's 
over 100 documents an Engineer needs to reference in preparation for what I 
would consider a low-medium level environment.  I've posted this before, but 
I'll post it again, I have a matrix of documents I need to reference during the 
planning and execution phase of an upgrade:

[http://cisco-voip.markmail.org/download.xqy?id=rrs3zlxbamemgodr=1]


On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) 
> wrote:
Quick 2 question poll, feel free to unicast or share your response with the 
group.

1. When you or your customers have a UCM or IMP upgrade fail, what percentage 
of failures are due to a bug vs something in the environment (user error, db 
updates, etc)?
% bug:
% not a bug:
Yes it’s a very subjective question but that’s ok, use your judgement.

2. When an upgrade goes smoothly with no issues, how much time do you put into 
the planning and preparation for the upgrade (not the execution)?

Thanks,

-Ryan

___
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

Re: [cisco-voip] SIP option ping prioritization

2017-08-27 Thread Ki Wi
Hi Saranyan,
thanks! I would like to know how can I compose an access-list to detect SIP
option ping and prioritize it.




On Mon, Aug 28, 2017 at 11:20 AM, saranyan k  wrote:

> Hi Ki Wi,
>
> OPTIONS ping is a SIP message. Ideally the transport mode of the message
> is TCP or UDP based on the configuration done under voice service voip ->
> sip.
> Otherwise, we can configure a keepalive profile so that we can specify the
> mode of transport for the OPTIONS keepalive messages.
>
> !
>
> voice class sip-options-keepalive 1
>
> transport tcp
>
> !
>
> Map the profile to any dial-peer:
>
> !
>
> dial-peer voice 1 voip
>
>  session protocol sipv2
>
>  incoming called-number 299
>
> * voice-class sip options-keepalive profile 1*
>
>  dtmf-relay rtp-nte sip-notify
>
>  codec g711ulaw
>
>  no vad
>
> !
>
> Say if the router is set to use UDP, its worth to give it a try with TCP.
>
> Please let me know if this helps.
>
>
> Regards,
>
> Saranyan
>
>
>
>
>
> On Mon, Aug 28, 2017 at 8:26 AM, Ki Wi  wrote:
>
>> Hi Group,
>> I would like to find out if SIP option ping is a "ping" or a "sip
>> message" ?
>>
>> From the documents, it seems like it is a sip messages.
>>
>> My customer is facing issue with the dial-peers getting busy out during
>> WAN congestion. We would like to prioritize those messages as a WAN
>> provider but they are not able to give us the exact commands for the CE
>> router.
>>
>>  Currently this is the command on all their managed "voice gateway"
>>  * voice-class sip options-keepalive up-interval 120 down-interval 120
>> retry 2
>>
>> This means the "transport" mode is default. This make things more
>> complex, I have no idea it is TCP or UDP or ???
>>
>> With no access to customer network (unable to do wireshark), I would like
>> to see if there's anyone having the experience to prioritize those SIP
>> option ping packets?
>>
>>
>> --
>> Regards,
>> Ki Wi
>>
>> ___
>> 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


Re: [cisco-voip] SIP option ping prioritization

2017-08-27 Thread saranyan k
Hi Ki Wi,

OPTIONS ping is a SIP message. Ideally the transport mode of the message is
TCP or UDP based on the configuration done under voice service voip -> sip.
Otherwise, we can configure a keepalive profile so that we can specify the
mode of transport for the OPTIONS keepalive messages.

!

voice class sip-options-keepalive 1

transport tcp

!

Map the profile to any dial-peer:

!

dial-peer voice 1 voip

 session protocol sipv2

 incoming called-number 299

* voice-class sip options-keepalive profile 1*

 dtmf-relay rtp-nte sip-notify

 codec g711ulaw

 no vad

!

Say if the router is set to use UDP, its worth to give it a try with TCP.

Please let me know if this helps.


Regards,

Saranyan





On Mon, Aug 28, 2017 at 8:26 AM, Ki Wi  wrote:

> Hi Group,
> I would like to find out if SIP option ping is a "ping" or a "sip message"
> ?
>
> From the documents, it seems like it is a sip messages.
>
> My customer is facing issue with the dial-peers getting busy out during
> WAN congestion. We would like to prioritize those messages as a WAN
> provider but they are not able to give us the exact commands for the CE
> router.
>
>  Currently this is the command on all their managed "voice gateway"
>  * voice-class sip options-keepalive up-interval 120 down-interval 120
> retry 2
>
> This means the "transport" mode is default. This make things more complex,
> I have no idea it is TCP or UDP or ???
>
> With no access to customer network (unable to do wireshark), I would like
> to see if there's anyone having the experience to prioritize those SIP
> option ping packets?
>
>
> --
> Regards,
> Ki Wi
>
> ___
> 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] UCM Upgrade Poll

2017-08-27 Thread Erick Bergquist
I've done a few dozen inplace upgrades of CUCM, Unity, UCCX with existing
VMs with no real issues over the past few years. Talking 8.x to 10.x  or
11.x or 9.x to 10/11.x.

Issues encountered:

Freeing up disk space on existing VM for the RU/SU to install on a few
upgrades (more of a slow down)

Recently had issue with IM 9.x to 11.x where a invalid ntp entry was in
the platformcfg.xml XML file that there is a bug ID on that TAC had to get
in with root access to remove. After that the IM inplace upgrade went
fine.

And a few non-upgrade issues involving license matters and getting correct
number of licenses.

I was reading another post about 12.0 using CentOS now, need to read that
over more and see what is changing with upgrade process.


My only wish was if these would go faster. Maybe have an incremental patch
with just fixes instead of a full size SU/install file and reinstalling
every file - especially for SU patches within same major version.

YMMV, Erick


On Thu, Aug 24, 2017 at 10:34 AM, Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Why not just come along with me on my next upgrade.  You can feel the
> pain...err excitement, of planning and executing an upgrade in the real
> world.  ;)
>
> On Thu, Aug 24, 2017 at 9:52 AM Ryan Ratliff (rratliff) <
> rratl...@cisco.com> wrote:
>
>> Thanks everyone for the feedback.
>>
>> We are looking at ways to make upgrades easier and stories like these are
>> very helpful.
>>
>> -Ryan
>>
>> On Aug 24, 2017, at 10:17 AM, Scott Voll  wrote:
>>
>> 1. I'm guessing we are 10% True bugs and 90% environment, but I will
>> agree with other comments about DNS and NTP being a dumb reason to fail
>>
>> 2. as for time, over the years we used to spend over 6 months on
>> upgrades.. we are down to about 2 months.  in our enviroment we have to
>> document all the changes before so it can be communicated to the end user.
>> Researching for the answers has moved from Anthony's 100 documents to just
>> opening a TAC case.  It has become way to time consuming to find all the
>> right doc's to get the correct answer.
>>
>> YMMV
>>
>> Scott
>>
>>
>> On Wed, Aug 23, 2017 at 1:46 PM, Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>>> Wow, it's kind of cool that you're even asking.  Thanks for that.
>>>
>>> Already I can see this is going to be a wide gap in responses. Partner
>>> vs end user, this customer vs that customer, this version vs that version,
>>> this scenario vs that one, and on, and on, and on.
>>>
>>> 1) I feel like it's always a bug (100%), in that, developers should code
>>> solutions that can work around most issues.  E.g., I had an upgrade fail on
>>> a CUCM because the ntp was 0.us.pool.ntp.org, despite CUCM happily
>>> syncing to it in the current version.  OR Common partition not having
>>> enough space, when devs could just purge old logs to make room, or simply
>>> make better logs to begin with (I do admit, moving to compress logs
>>> [TAR/GZ] was sweet)
>>>
>>> 2) This is a painful one for me, but I put in a lot of time preparing
>>> for an upgrade.  A large portion of the time is, in my opinion, wasted
>>> finding the right documentation and then trying to interpret it.  Here's a
>>> fun one: there's over 100 documents an Engineer needs to reference in
>>> preparation for what I would consider a low-medium level environment.  I've
>>> posted this before, but I'll post it again, I have a matrix of documents I
>>> need to reference during the planning and execution phase of an upgrade:
>>>
>>>
>>>
>>>
>>> On Wed, Aug 23, 2017 at 8:38 AM Ryan Ratliff (rratliff) <
>>> rratl...@cisco.com> wrote:
>>>
 Quick 2 question poll, feel free to unicast or share your response with
 the group.

 1. When you or your customers have a UCM or IMP upgrade fail, what
 percentage of failures are due to a bug vs something in the environment
 (user error, db updates, etc)?
 % bug:
 % not a bug:
 Yes it’s a very subjective question but that’s ok, use your judgement.

 2. When an upgrade goes smoothly with no issues, how much time do you
 put into the planning and preparation for the upgrade (not the execution)?

 Thanks,

 -Ryan

 ___
 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] SIP option ping prioritization

2017-08-27 Thread Ki Wi
Hi Group,
I would like to find out if SIP option ping is a "ping" or a "sip message" ?

>From the documents, it seems like it is a sip messages.

My customer is facing issue with the dial-peers getting busy out during WAN
congestion. We would like to prioritize those messages as a WAN
provider but they are not able to give us the exact commands for the CE
router.

 Currently this is the command on all their managed "voice gateway"
 * voice-class sip options-keepalive up-interval 120 down-interval 120
retry 2

This means the "transport" mode is default. This make things more complex,
I have no idea it is TCP or UDP or ???

With no access to customer network (unable to do wireshark), I would like
to see if there's anyone having the experience to prioritize those SIP
option ping packets?


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