Re: [cisco-voip] [EXT] Re: Field Notice from Cisco making Secure LDAP mandatory

[Daniel Pagan]

Just a heads up – I spoke w/ TAC who then spoke with the authors of the 
bulletin. They agreed to update the article to better reflect the new timeline 
posted by Microsoft and add clarification that LDAP functionality will not in 
fact break in March due to the patch expected in that month. The update will 
contain something along the lins of:

“This [Microsoft] security update is not expected to become mandatory until 
fall 2020. However, it's recommended that you update your Cisco Collaboration 
deployment to use Secure LDAP as soon as possible. This will both secure your 
LDAP connection and will also ensure that services remain up and running when 
the security update becomes mandatory.”

- Daniel Pagan

From: cisco-voip  On Behalf Of Daniel Pagan
Sent: Tuesday, February 11, 2020 2:36 PM
To: Lelio Fulgenzi ; Matthew Loraditch 

Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) 

Subject: Re: [cisco-voip] [EXT] Re: Field Notice from Cisco making Secure LDAP 
mandatory

Whoops – sent the email a bit prematurely…

Here’s a link to that VMware article with a recent update mentioning that 
defaults will not be changing in March.

https://blogs.vmware.com/vsphere/2020/01/microsoft-ldap-vsphere-channel-binding-signing-adv190023.html

It seems the Cisco article is a bit behind and needs to be updated. Hopefully 
this buys everyone some time, especially for those supporting a number of 
environments.

- Daniel Pagan


From: Daniel Pagan
Sent: Tuesday, February 11, 2020 2:33 PM
To: Lelio Fulgenzi mailto:le...@uoguelph.ca>>; Matthew 
Loraditch 
mailto:mloradi...@heliontechnologies.com>>
Cc: voyp list, cisco-voip 
(cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>) 
mailto:cisco-voip@puck.nether.net>>
Subject: RE: [EXT] Re: [cisco-voip] Field Notice from Cisco making Secure LDAP 
mandatory

It does not appear Microsoft will be enforcing LDAP over TLS with this upcoming 
patch. While the original plan was indeed to tighten this up, it seems this 
requirement is being delayed until after Q2 of the year.

The advisory was updated February 4th and shows:
Windows Updates in March 2020 add new audit events, additional logging, and a 
remapping of Group Policy values that will enable hardening LDAP Channel 
Binding and LDAP Signing. The March 2020 updates do not make changes to LDAP 
signing or channel binding policies or their registry equivalent on new or 
existing domain controllers.
A further future monthly update, anticipated for release the second half of 
calendar year 2020, will enable LDAP signing and channel binding on domain 
controllers configured with default values for those settings.
I found that VMware updated their advisory to reflect this recent change to 
Microsoft’s timeline two days later:
“Update (2/6/2020): On February 4, 2020 Microsoft changed their guidance for 
the March 2020 Windows Updates to indicate that the defaults will NOT be 
changing in that update.”




From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Lelio Fulgenzi
Sent: Sunday, February 9, 2020 6:05 PM
To: Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>>
Cc: voyp list, cisco-voip 
(cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>) 
mailto:cisco-voip@puck.nether.net>>
Subject: [EXT] Re: [cisco-voip] Field Notice from Cisco making Secure LDAP 
mandatory

I believe we had to load two certs.

And, after loading certs, restart tomcat.


Sent from my iPhone

On Feb 9, 2020, at 5:23 PM, Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>> 
wrote:
Interesting. Our root cert is and has been loaded, but I’m still using just the 
IPs so normally that would make the handshake fail.

Get Outlook for iOS<https://aka.ms/o0ukef>

Matthew Loraditch​
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com<http://www.heliontechnologies.com/>
 |
e: mloradi...@heliontechnologies.com<mailto:mloradi...@heliontechnologies.com>
<http://www.heliontechnologies.com/>
<https://facebook.com/heliontech>
<https://twitter.com/heliontech>
<https://www.linkedin.com/company/helion-technologies>


From: Lelio Fulgenzi mailto:le...@uoguelph.ca>>
Sent: Sunday, February 9, 2020 5:15:40 PM
To: Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>>
Cc: James Buchanan 
mailto:james.buchan...@gmail.com>>; voyp list, 
cisco-voip (cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>) 
mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] Field Notice from Cisco making Secure LDAP mandatory

[EXTERNAL]


I couldn’t get secure ldap to work without loading the certificates from the AD 
servers. I also had more luck using the global catalog ports.
Sent from my iPhone

On Feb 9, 2020, at 5:05 PM, Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>> 
wrote:
I was wondering if they were going to p

Re: [cisco-voip] [EXT] Re: Field Notice from Cisco making Secure LDAP mandatory

[Daniel Pagan]

Whoops – sent the email a bit prematurely…

Here’s a link to that VMware article with a recent update mentioning that 
defaults will not be changing in March.

https://blogs.vmware.com/vsphere/2020/01/microsoft-ldap-vsphere-channel-binding-signing-adv190023.html

It seems the Cisco article is a bit behind and needs to be updated. Hopefully 
this buys everyone some time, especially for those supporting a number of 
environments.

- Daniel Pagan


From: Daniel Pagan
Sent: Tuesday, February 11, 2020 2:33 PM
To: Lelio Fulgenzi ; Matthew Loraditch 

Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) 

Subject: RE: [EXT] Re: [cisco-voip] Field Notice from Cisco making Secure LDAP 
mandatory

It does not appear Microsoft will be enforcing LDAP over TLS with this upcoming 
patch. While the original plan was indeed to tighten this up, it seems this 
requirement is being delayed until after Q2 of the year.

The advisory was updated February 4th and shows:
Windows Updates in March 2020 add new audit events, additional logging, and a 
remapping of Group Policy values that will enable hardening LDAP Channel 
Binding and LDAP Signing. The March 2020 updates do not make changes to LDAP 
signing or channel binding policies or their registry equivalent on new or 
existing domain controllers.
A further future monthly update, anticipated for release the second half of 
calendar year 2020, will enable LDAP signing and channel binding on domain 
controllers configured with default values for those settings.
I found that VMware updated their advisory to reflect this recent change to 
Microsoft’s timeline two days later:
“Update (2/6/2020): On February 4, 2020 Microsoft changed their guidance for 
the March 2020 Windows Updates to indicate that the defaults will NOT be 
changing in that update.”




From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
On Behalf Of Lelio Fulgenzi
Sent: Sunday, February 9, 2020 6:05 PM
To: Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>>
Cc: voyp list, cisco-voip 
(cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>) 
mailto:cisco-voip@puck.nether.net>>
Subject: [EXT] Re: [cisco-voip] Field Notice from Cisco making Secure LDAP 
mandatory

I believe we had to load two certs.

And, after loading certs, restart tomcat.


Sent from my iPhone

On Feb 9, 2020, at 5:23 PM, Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>> 
wrote:
Interesting. Our root cert is and has been loaded, but I’m still using just the 
IPs so normally that would make the handshake fail.

Get Outlook for iOS<https://aka.ms/o0ukef>

Matthew Loraditch​
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com<http://www.heliontechnologies.com/>
 |
e: mloradi...@heliontechnologies.com<mailto:mloradi...@heliontechnologies.com>
<http://www.heliontechnologies.com/>
<https://facebook.com/heliontech>
<https://twitter.com/heliontech>
<https://www.linkedin.com/company/helion-technologies>


From: Lelio Fulgenzi mailto:le...@uoguelph.ca>>
Sent: Sunday, February 9, 2020 5:15:40 PM
To: Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>>
Cc: James Buchanan 
mailto:james.buchan...@gmail.com>>; voyp list, 
cisco-voip (cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>) 
mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] Field Notice from Cisco making Secure LDAP mandatory

[EXTERNAL]


I couldn’t get secure ldap to work without loading the certificates from the AD 
servers. I also had more luck using the global catalog ports.
Sent from my iPhone

On Feb 9, 2020, at 5:05 PM, Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>> 
wrote:
I was wondering if they were going to post anything as it’s very unclear if 
ldap over tls was the fix.

Apparently (and amen) it is. Did it on our office system last week to see if it 
would work without any certificate needs. It just worked and during a save it 
will instantly tell you if it worked or not.

Outside of the most regimented environments you should be able to just make the 
change. If it fails talk to your AD team as they would likely have something 
blocked or disabled.

Get Outlook for iOS<https://aka.ms/o0ukef>

Matthew Loraditch​
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com<http://www.heliontechnologies.com/>
 |
e: mloradi...@heliontechnologies.com<mailto:mloradi...@heliontechnologies.com>
<http://www.heliontechnologies.com/>
<https://facebook.com/heliontech>
<https://twitter.com/heliontech>
<https://www.linkedin.com/company/helion-technologies>


From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
on behalf of James Buchanan 
mailto:james.buchan...@gmail.com>>
Sent: Sunday, February 9, 2020 4:57:40 PM
To: voyp list, cisco-voip 
(cisco-voip@p

Re: [cisco-voip] [EXT] Re: Field Notice from Cisco making Secure LDAP mandatory

[Daniel Pagan]

It does not appear Microsoft will be enforcing LDAP over TLS with this upcoming 
patch. While the original plan was indeed to tighten this up, it seems this 
requirement is being delayed until after Q2 of the year.

The advisory was updated February 4th and shows:
Windows Updates in March 2020 add new audit events, additional logging, and a 
remapping of Group Policy values that will enable hardening LDAP Channel 
Binding and LDAP Signing. The March 2020 updates do not make changes to LDAP 
signing or channel binding policies or their registry equivalent on new or 
existing domain controllers.
A further future monthly update, anticipated for release the second half of 
calendar year 2020, will enable LDAP signing and channel binding on domain 
controllers configured with default values for those settings.
I found that VMware updated their advisory to reflect this recent change to 
Microsoft’s timeline two days later:
“Update (2/6/2020): On February 4, 2020 Microsoft changed their guidance for 
the March 2020 Windows Updates to indicate that the defaults will NOT be 
changing in that update.”




From: cisco-voip  On Behalf Of Lelio 
Fulgenzi
Sent: Sunday, February 9, 2020 6:05 PM
To: Matthew Loraditch 
Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) 

Subject: [EXT] Re: [cisco-voip] Field Notice from Cisco making Secure LDAP 
mandatory

I believe we had to load two certs.

And, after loading certs, restart tomcat.


Sent from my iPhone

On Feb 9, 2020, at 5:23 PM, Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>> 
wrote:
Interesting. Our root cert is and has been loaded, but I’m still using just the 
IPs so normally that would make the handshake fail.

Get Outlook for iOS

Matthew Loraditch​
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com
 |
e: mloradi...@heliontechnologies.com






From: Lelio Fulgenzi mailto:le...@uoguelph.ca>>
Sent: Sunday, February 9, 2020 5:15:40 PM
To: Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>>
Cc: James Buchanan 
mailto:james.buchan...@gmail.com>>; voyp list, 
cisco-voip (cisco-voip@puck.nether.net) 
mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] Field Notice from Cisco making Secure LDAP mandatory

[EXTERNAL]


I couldn’t get secure ldap to work without loading the certificates from the AD 
servers. I also had more luck using the global catalog ports.
Sent from my iPhone

On Feb 9, 2020, at 5:05 PM, Matthew Loraditch 
mailto:mloradi...@heliontechnologies.com>> 
wrote:
I was wondering if they were going to post anything as it’s very unclear if 
ldap over tls was the fix.

Apparently (and amen) it is. Did it on our office system last week to see if it 
would work without any certificate needs. It just worked and during a save it 
will instantly tell you if it worked or not.

Outside of the most regimented environments you should be able to just make the 
change. If it fails talk to your AD team as they would likely have something 
blocked or disabled.

Get Outlook for iOS

Matthew Loraditch​
Sr. Network Engineer
p: 443.541.1518
w: www.heliontechnologies.com
 |
e: mloradi...@heliontechnologies.com






From: cisco-voip 
mailto:cisco-voip-boun...@puck.nether.net>> 
on behalf of James Buchanan 
mailto:james.buchan...@gmail.com>>
Sent: Sunday, February 9, 2020 4:57:40 PM
To: voyp list, cisco-voip 
(cisco-voip@puck.nether.net) 
mailto:cisco-voip@puck.nether.net>>
Subject: [cisco-voip] Field Notice from Cisco making Secure LDAP mandatory

[EXTERNAL]

Hello folks,

I know you all needed some more work. I sure did! So here you are!

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/trouble/12_5_1/fieldNotice/cucm_b_fn-secure-ldap-mandatory-ad.html

I'm interested in any early thoughts on other integrations--vCenter, ISE, VPN, 
TACACS, etc. I assume it applies across the board.

Thanks,

James

___
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] [EXT] Re: How to handle expired Phone-VPN-trust, phone-SAST-trust, other certificates

[Daniel Pagan]

In your example, the SERVER2 certificate in phone-vpn-trust is there because 
someone would have placed it there for some reason. Some additional info... 
certificates uploaded to the phone-vpn-trust store can be associated with a VPN 
gateway in /ccmadmin. When assigned to a VPN-enabled phone through a common 
phone profile, a hash of the certificate is provided to the phone in its .cnf 
file. This certificate would/should be the same SSL cert assigned to the VPN 
gateway(s) configured. During the TLS handshake between the phone and the ASA, 
the phone compares the SHA1 hash of the identity certificate it receives with 
the hash contained in its previously downloaded config file.

With that said -
Why is there SERVER2.DER in the phone-vpn-trust store?
DP: Likely someone placed it there.

Is this expected?
DP: Not by default.

Does a phone contact SERVER2 while using the Phone VPN?
DP: Only if SERVER2 is the VPN gateway. The phone uses the VPN gateway URL to 
determine where to connect, then compares the certificate hash during TLS 
negotiation.

Is there by default, or someone added, even by mistake?
DP: Added and (if SERVER2 is a UC server) likely by mistake.

Hope this helps.

- Dan


From: cisco-voip  On Behalf Of ROZA, Ariel
Sent: Tuesday, October 23, 2018 11:52 AM
To: James Andrewartha ; cisco-voip@puck.nether.net
Subject: [EXT] Re: [cisco-voip] How to handle expired Phone-VPN-trust, 
phone-SAST-trust, other certificates

My main issue is not about the deletion process, but about the purpose and 
usefulness of each of those certificates. Being able to judge if it is good to 
delete or not certain certificates (even when expired).

I have this guide:
https://www.cisco.com/c/en/us/support/docs/unified-communications/unified-communications-manager-callmanager/200199-CUCM-Certificate-Regeneration-Renewal-Pr.htm

that gives a description of the purpose of each store, but it does not give 
specifics on why is there a particular  certificate in a store. Ie. Why is 
there SERVER2.DER in the phone-vpn-trust store? Is this expected? Does a phone 
contact SERVER2 while using the Phone VPN? Is there by default, or someone 
added, even by mistake?

And the expired certs that I have are not some that are renewable. All of them 
are in -trust stores.

So I am quite puzzled about them.

De: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] En nombre de James 
Andrewartha
Enviado el: martes, 23 de octubre de 2018 12:39 a.m.
Para: cisco-voip@puck.nether.net
Asunto: Re: [cisco-voip] How to handle expired Phone-VPN-trust, 
phone-SAST-trust, other certificates

And if you have any problems deleting them (I had one that just would not go 
away and gave me alarms for years), just call TAC and they'll take you through 
the SQL to kill them permanently.

On 23/10/18 03:08, NateCCIE wrote:
The expired certs will throw alarms even if they have been superseded by newer 
certs.

So during a maintenance window, renew anything that is expired, and just delete 
all the old ones.  The newer versions of cucm make this easier by being able to 
sort by expiration date.

-Nate

From: cisco-voip 
 
On Behalf Of ROZA, Ariel
Sent: Monday, October 22, 2018 11:52 AM
To: cisco-voip (cisco-voip@puck.nether.net) 

Subject: [cisco-voip] How to handle expired Phone-VPN-trust, phone-SAST-trust, 
other certificates

Hi, guys!

I have a customer that is receiving alarms over some expired certificates, and 
I would like to know which is the best way to handle them.
The certs are loaded in SERVER1 and all named SERVER2.der, except the CAPF ones.
.der in phone-vpn-trust.
 .der in phone-trust
.der in phone-SAST-trust
.der in phone-CTL-trust
And several CAPF-xx.der in Callmanager-trust

So far I have dealt with renewing Callmanager, TFTP and TVS cert, but I always 
kept clear from those other certs
Shoud I delete them, shoud I keep them, even as they are expired and throwing 
alarms?


Regards.


Ariel Roza
Collaboration Support Engineer
t: +54 11 5282-0458
c: +54 9 11 5017-4417 webex: 
http://logicalis-la.webex.com/join/ariel.roza
Av. Belgrano 955 - Piso 20 - CABA - Argentina - C1092AAJ
www.la.logicalis.com
_
Business and technology working as one
[cid:image003.png@01D3894B.346BF840]

[cisco-voip] Expert-Level Cert Renewal

[Daniel Pagan]

Some of you might be interested to hear that Cisco has announced a new method 
of renewing one's expert-level certification. While taking a written exam is 
still an option, those needing to renew their CCIE/CCDE will be allowed to 
enroll themselves in select classes, online and in-person, which will count 
towards renewal credits. Renewal will require 100 credits in total and applies 
to both active and suspended status cert holders.

More information: 
https://learningnetwork.cisco.com/community/certifications/cisco-continuing-education-program

HTH

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

Re: [cisco-voip] CCX and NTP

[Daniel Pagan]

Just adding my experience to this…

I agree and can attest to the stratum-1 server caveat below. After some time, 
the NTP client can get blocked and force you (the general “you”) to update your 
entries in the near future. Of course multiple NTP entries can be configured 
but if you’re doing proactive monitoring of syslog (or specific syslog 
entries), or support multiple UC environments, it can get rather annoying and 
time consuming.

As for pointing UC apps to the UCM publisher… I opened a TAC case a while back 
specifically to determine if this was officially supported. The idea was to 
assigned all UC applications for a customer, per geographic region, to their 
most local UCM publisher for NTP services. The customer wanted to avoid IOS NTP 
servers, avoid using public NTP sources, and didn’t want to spin up a small 
*NIX VM for this purpose either.

Long story short, and after escalating to the CE’s lead, it was determined that 
this configuration would not be supported, and any time synchronization issues 
reported to TAC would first require the configuration be modified before 
continuing forward.

“Cisco Call Manager might work properly as NTP Master but it is not designed 
for that purpose or not even tested by developer. Publisher of CUCM not 
supported to act as NTP Master [for non CUCM applications].”

We ended up using public NTP sources.

Hope this helps

- Dan


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Charles Goldsmith
Sent: Monday, May 8, 2017 10:53 AM
To: Haas, Neal 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CCX and NTP

To expand on this, I would point to your voice gateways with everything 
internal, then the voice gateways would either use an on-prem NTP server that 
is radio sync'd or one that Neal has advised.  That way, everything is synced 
together with the same source.

For UCCX and other apps, I point them to the UCM pub and the pub points to the 
voice gateways.

I've seen a lot of people advise for pool.ntp.org, but 
that has bitten me.  How often does an NTP process refresh from DNS?  I suspect 
only on reboot or a restart of the NTP process.  I've seen too many NTP servers 
go offline when using the pool addresses.  Because of that, I've been sticking 
with .gov based NTP on the voice gateway.

Ryan Huff, one thing about pointing to strata 1 servers, most of them have 
restrictions from what I've seen, while they work, they could block you for not 
being approved if you send too many requests.  
http://support.ntp.org/bin/view/Servers/StratumOneTimeServers has a list, and 
while many have open access listed, if you look at the details, they can still 
have restrictions.

Just food for thought.

On Mon, May 8, 2017 at 9:20 AM, Haas, Neal 
> wrote:
Get an on-prem NTP server, if you cant spend the money, use:

time.nist.gov global address for all servers   
Multiple locations
utcnist.colorado.edu  128.138.140.44  
University of Colorado, Boulder
utcnist2.colorado.edu128.138.141.172  
  University of Colorado, Boulder
time-nw.nist.gov 131.107.13.100  
Microsoft, Redmond, Washington

Really, anything with a GOV, or EDU should be good.

By the way, you should NEVER, EVER, EVER (can’t stress this enough) a Windows 
Based NTP.  Every place that I have went into and removed a Windows Time 
server, everything has worked better! Windows just cant do time. I went into a 
business with windows NTP, and the guy was checking time from about 100 NTP 
servers, his time was off by three minutes. Took it down to 3 and everything 
started to work.

Thank You,

Neal Haas

From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of Ben Amick
Sent: Monday, May 8, 2017 7:12 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] CCX and NTP

What do you guys use for NTP on your CCX hosts? I’ve been informed by TAC that 
“CCX does not support Windows based NTP” so I was thinking about just pointing 
NTP towards my CCM hosts – is that a valid scenario? I figure that since CCM is 
pretty much authoritative on everything for CCX as it is it wouldn’t be a 
problem?

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 

Re: [cisco-voip] cisco 8851 problematic

[Daniel Pagan]

Not sure if you found a solution to this problem, but I've been working on a 
similar issue since my last message. We are thinking the problem is related to 
an existing defect, CSCup16651, only this bug is filed under CIPC instead of 
the 88XX/89XX model. The defect describes the same output we're observing on 
affected IP phones where console logs display "Max TCP connections reached" and 
begin showing delayed processing of SIP transactions.

If, for whatever reason, you have a CUCM node in the CCM group offline in your 
scenario, you might run into this problem. I'm currently pushing for creation 
of a new defect and can share that ID if you feel it would help.

Hope this helps.

Dan


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Thursday, February 9, 2017 10:28 AM
To: cisco.voip <cisco.v...@verizon.net>; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] cisco 8851 problematic

I have heard of this but have yet to see it from a trace perspective. For 
troubleshooting, my first step would be to determine if the problem is CUCM or 
the IP Phones that don't stop ringing. The call is sent to an 8851/61 using 
INVITE, which means CUCM should force them to stop ringing on CANCEL.

>>> INVITE
<<< 100 Trying
<<< 180 Ringing
[[ Answered on other phone ]]
>>> CANCEL
<<< 200 OK CSeq Cancel
<<< 487 Request Terminated CSeq INVITE
>>> ACK

If this transaction occurs without issues, the problem is likely the IP phone 
and not CUCM, but digging in further would likely require review of console 
logs off the phone to determine if the CANCEL was received and handled 
properly. If this transaction does not occur, then further review into SDL 
signaling would be needed depending on where the transaction broke.

Basic way to find SIP signaling to an 88XX is searching CCM SDL traces for "TCP 
message to  on port" or "TCP message from  
on port". Console logs would contain signaling info too and might be easier, 
but SDL of course is not written there.

Curious... what version of firmware are you running?

-Original Message-
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
cisco.voip
Sent: Thursday, February 09, 2017 2:52 AM
To: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: [cisco-voip] cisco 8851 problematic

All, i'm on CucM 10.5.2 using cisco 8851 and 8861.
When several phones share the same number, when that line is picked up by one 
of the phones - all the other phones continue ringing.
Anyone experience this, or have a tshoot method that works,

Thanks,
Ciscovoip


___
cisco-voip mailing list
cisco-voip@puck.nether.net<mailto: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 8851 problematic

[Daniel Pagan]

I have heard of this but have yet to see it from a trace perspective. For 
troubleshooting, my first step would be to determine if the problem is CUCM or 
the IP Phones that don't stop ringing. The call is sent to an 8851/61 using 
INVITE, which means CUCM should force them to stop ringing on CANCEL.

>>> INVITE
<<< 100 Trying
<<< 180 Ringing
[[ Answered on other phone ]]
>>> CANCEL
<<< 200 OK CSeq Cancel
<<< 487 Request Terminated CSeq INVITE
>>> ACK

If this transaction occurs without issues, the problem is likely the IP phone 
and not CUCM, but digging in further would likely require review of console 
logs off the phone to determine if the CANCEL was received and handled 
properly. If this transaction does not occur, then further review into SDL 
signaling would be needed depending on where the transaction broke.

Basic way to find SIP signaling to an 88XX is searching CCM SDL traces for "TCP 
message to  on port" or "TCP message from  
on port". Console logs would contain signaling info too and might be easier, 
but SDL of course is not written there.

Curious... what version of firmware are you running?

-Original Message-
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
cisco.voip
Sent: Thursday, February 09, 2017 2:52 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] cisco 8851 problematic

All, i'm on CucM 10.5.2 using cisco 8851 and 8861.
When several phones share the same number, when that line is picked up by one 
of the phones - all the other phones continue ringing.
Anyone experience this, or have a tshoot method that works,

Thanks,
Ciscovoip


___
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] SIP session timer in IOS gateway

[Daniel Pagan]

I should be more specific... the min-SE specifies the minimum value the UAS is 
willing to accept from the Session-Expires header sent by the UAC. If your 
INVITE has an SE if 1800, and the incoming dial-peer has a min-SE of 3600, then 
CUBE will reply back to the UAC with a 422 final response - this 422 will 
contain its own min-SE header with value of 3600. The UAC should ACK the 422 
and *should* follow-up with another INVITE where the Session-Expires timer 
value is 3600. This is one way to force CUBE to manipulate the incoming SE. I 
felt my previous explanation was missing some information and might have been a 
bit too vague.


"If the response to a session refresh request is a 422 (Session Interval Too 
Small) response message, then the UAC MAY retry the request."



CUCM, if it's the UAC, will retry the INVITE. I can't speak to other 
call-agents though. But I still suggest, if possible, to address the main 
problem of your session expiration.



Hope this helps.

- Dan


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Friday, September 23, 2016 4:12 PM
To: Norton, Mike <mikenor...@pwsd76.ab.ca>; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] SIP session timer in IOS gateway

Adjusting the SE on standard CUBE is not possible from what I've experienced 
and tested. One way around it though is to set your Min-SE timer on the 
incoming dial-peer on CUBE. The UAC sending the INVITE will receive a 422 
response back, from CUBE, and will include an updated min-se timer. The new 
min-SE value in the 422 will then be copied, by the UAC, into the 
Session-Expires header within a second INVITE. The question I feel I should ask 
though... is why try manipulating the SE/minSE timers to get around a failed 
session refresh instead of addressing the session refresh itself? Of course 
this is only masking another problem.

end attach-

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Norton, Mike
Sent: Friday, September 23, 2016 4:01 PM
To: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: [cisco-voip] SIP session timer in IOS gateway

I'd like to adjust IOS's behavior around the SIP session-expires timer. 
Wondering if anybody knows if the command I need exists...

According to RFC 4028:

"If the side not performing refreshes does not receive a session refresh 
request before the session expiration, it SHOULD send a BYE to terminate the 
session, slightly before the session expiration."

My problem stems from the fact that "slightly before" is left open to the 
imagination. The RFC "recommends" not more than 32 seconds but does not have 
any specific "requirement." The default behaviour of IOS seems to use a longer 
value. I.e., it sends the BYE a little too prematurely for my situation. I need 
IOS to let the timer get closer to expiring before it issues the BYE.

I know it's a long-shot, but someone please tell me there is a command for 
adjusting this! Not finding anything in the docs. Hoping to avoid having to 
disable the session timer or crank it up to 11. I love SIP interop, it's so 
much fun! :-(

-mn

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

Re: [cisco-voip] Changing vCPU Quantities

[Daniel Pagan]

I’ve heard of this as well and actually have an open case that will require a 
rebuild of CUC in order to add an additional vCPU. From what I recall, it can 
be done but Unity won’t utilize the additional core unless it’s detected during 
the install process. CUC, from what I know, is the only UC application to which 
this caveat applies.

It turns out there’s a doc that says if you’re using UM features, the servers 
should be spec’ed with more than a single vCPU… but this caveat isn’t mentioned 
in any of the OVA template readme files for some reason.

Here’s the doc:

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/10x/supported_platforms/10xcucspl.html
 -- Search for “Unified Messaging” - you’ll see a chart where a reader has to 
interpret that a single vCPU doesn’t support single inbox. Again, could be 
better documented IMO :)

I personally request our deployment engineers, when possible, to stay away from 
single vCPU UC VMs if they’re coming to managed services, especially for CUCM, 
since we do lots of trace collection and have had issues where the gzip process 
consumes all available CPU cycles. Add CUC UM to this and more reason to avoid 
it for CUCM and CUC in most cases. This one was already built out before it 
came our way, but I still think the caveat of UM features needing 2 or more 
vCPUs should be in the OVA read me.

- Dan
---end attach-

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Anthony Holloway
Sent: Wednesday, July 27, 2016 1:17 PM
To: Cisco VoIP Group 
Subject: [cisco-voip] Changing vCPU Quantities

Hi Everyone,

I have been telling people on this 
list for a while now, 
and for that matter, in person too, that you can just shutdown the VM and 
modify the vCPU count per VM and then power it back on.

In fact, I know I've done this a half a dozen times in the past.  However, for 
CUC, a colleague of mine just uncovered the following bullet point:

"Adding vCPU is supported for all apps except Unity and Unity Connection, but 
requires VM to be shutdown first."

Source: 
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements#Resize_Virtual_Machine

So, with CUC being the exception, it would stand to reason that CUC requires a 
DRS backup, new OVA deployment, then DRS restore to change the vCPU count, 
correct?

To add to the confusion, PDI is even 
stating
 in certain cases online that changing the vCPU count without a DRS 
backup.restore is support.

So, what do you know about this?  Is CUC really different from the other apps, 
or is this a case of bad documentation?

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

Re: [cisco-voip] SIP protocol question

[Daniel Pagan]

According to the RFC, the Allow-Events header is specifically used to convey 
events that a UA can support using the SUBSCRIBE method. Typically we’ll see 
KPML or Presence as a supported Allow-Event value, which makes sense since both 
of those events are initiated through SUBSCRIBE/NOTIFY transactions. I’m 
looking through sets of trace files where I know RTP-NTE is negotiated and have 
found multiple instances where DTMF was negotiated successfully (to RTP-NTE) 
without including telephone-events in the Allow-Events header.

What type of issues are you seeing with ReINVITEs?

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ed 
Leatherman
Sent: Friday, July 08, 2016 9:18 AM
To: Cisco VOIP 
Subject: [cisco-voip] SIP protocol question

Happy Friday!

This is probably a dumb basic question but my google-fu is failing me.

What exactly is the "telephone-event" event package used for in the 
allow-events: header? Must it be present?

I have been assuming it had to do with rtp-nte but that seems wrong since 
that's negotiated in the SDP.

I'm trying to integrate with our associated Medical Center with a SIP Trunk out 
of CUBE (IOS 15.4(3)M3) - they are running a mish-mash of Siemens PBX/SIP/Call 
Center stuff on their end. I'm having some weird stuff happen with reinvites 
when their system(s) transfer the call around and I'm trying to nail down 
everything I find that i'm not sure of... in one of the transactions the 
telephone-event is missing out of the allow-events in the invite.

Thanks!




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

Re: [cisco-voip] Columbia CUBE to Claro outbound issue

[Daniel Pagan]

Personally, I would push back to them and simply provide them with the request 
URI your transmitting, which they should be using for routing purposes.

INVITE sip:1343@10.11.0.9:5060 SIP/2.0

I say push back because a 404 is a very straight forward response and sent for 
one reason. If their equipment can’t route to 1343111 then I would expect this 
behavior, but they should be able to tell you why it’s not being routed based 
on that request URI, regardless if it’s a fault in your configuration or 
theirs. They’re definitely receiving the INVITE request because we see 
provisional responses with the same Call-ID header and From Tag, and then 
acting upon it because we see the Reason header with 404, so any experienced 
technician at their company should be able to tell you the reason for the 183 
with 404 cause in Reason header.

As for the 487 final you see below, that’s expected as well considering the 
call flow. The standard signaling flow for this scenario is…

>> INVITE w/SDP offer
<< 100
<< 183 w/SDP answer

[[ You now have bi-directional media]]
[[ Likely hearing failure recording ]]


** Calling party hangs up **


>> CANCEL [[ The CANCEL requests terminates pending SIP requests. ]]
<<--- 200 OK[[ Acceptance of CANCEL through 200 final response ]]
<<--- 487[[ The 487 is used to terminate the INVITE – all SIP requests 
require a final response – here’s the final response for the INVITE ]]
>> ACK  [[ You send ACK since this transaction was for an INVITE – no other 
requests require to be ACKed ]]

I personally never worked with Claro, but SIP is SIP (for the most part), and 
they should be sending you a 404 specifically because they 1) received the 
INVITE, 2) processed the user portion (1343111) of the request URI, and 3) 
could not find a route to the destination.

Hope you find this helpful.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Hank 
Keleher (AM)
Sent: Saturday, April 02, 2016 11:10 PM
To: Horton, Jamin 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Columbia CUBE to Claro outbound issue

I tried hard coding both UDP and TCP. Setting it to UDP produced the same 
result where as TCP had the same CC disconnect of 53 and SIP disconnect cause 
was 503 (200 with UDP.)

Nice suggestion though!

Thanks!
Hank


From: "Horton, Jamin" 
>
Date: Saturday, April 2, 2016 at 22:11
To: "Hank.Keleher" 
>
Cc: Ryan Huff >, 
"cisco-voip@puck.nether.net" 
>
Subject: Re: [cisco-voip] Columbia CUBE to Claro outbound issue

I just had this same issue yesterday. 2 hours later after banging my head 
against they keyboard I figured out it was my session transport protocol. They 
were expecting UDP and I was using TCP.

Try playing around with it. I believe you can do it under "voice service / sip" 
as well as the individual dial peer.

Hope it helps!

Sent from my iPhone forgive any typos

On Apr 2, 2016, at 11:43 AM, Hank Keleher (AM) 
> wrote:
I remember seeing that and I changed the outbound local calls to 9+7 digits 
instead of the 9+1+7 digits that Claro says we should use. When I dial 9+7 
digits I don’t get the 404 error but I do when dialing 9+1+7 digits as well as 
9+00+any for international (that’s all I tested so far.)

All calls still get CC disconnect cause of 38.

Inbound works fine.

Thanks!
Hank

From: Ryan Huff >
Date: Saturday, April 2, 2016 at 13:30
To: "Hank.Keleher" 
>
Cc: "cisco-voip@puck.nether.net" 
>
Subject: Re: [cisco-voip] Columbia CUBE to Claro outbound issue



Are you always getting the same 404 "unallocated number" response?

Thanks,

Ryan

> On Apr 2, 2016, at 1:05 PM, Hank Keleher (AM) 
> > wrote:
>
> Greetings!
>
> Does anyone have a CUBE configuration that works with Claro based in Columbia 
> you can share with me? I have inbound working just fine but oubound keeps 
> getting rejected. Below is an example of the config and relevant debug. They 
> are saying that it should work even though I’ve pointed out that we are 
> getting network out of order and request terminated disconnect causes from 
> them. They are using a Huawei switch on their side (which is why we are using 
> payload type 97.)
>
> Thanks!
> Hank
>
> ———
>
> voice service voip
> no ip address trusted authenticate
> dtmf-interworking rtp-nte
> mode 

Re: [cisco-voip] VCS Checker

[Daniel Pagan]

Had no idea this XML generator was available. I’ve been grabbing sample scripts 
off Github and customizing them in the lab for testing purposes so this should 
supplement that setup very well. I just tested it for a few minutes and it 
seems like it replaces device-specific fields (via, contact header, 
request-uri, connection info field in the SDP, etc.) with SIPp-specific 
variables…

Very neat. Thanks for the heads up.

In case you’re into (or getting into) SIPp, here’s a list of scripts I 
reference whenever I needed a SIPp call-flow that are not difficult to 
customize.

https://github.com/saghul/sipp-scenarios

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Tim 
Smith
Sent: Wednesday, December 09, 2015 6:45 PM
To: Matthew Loraditch ; Ryan Huff 
; cisco voip 
Subject: Re: [cisco-voip] VCS Checker

They are pretty much all under
http://www.cisco.com/c/en/us/support/web/tools-catalog.html

SIPp XML generator looks good

Cheers,

Tim

From: cisco-voip 
> 
on behalf of Matthew Loraditch 
>
Date: Thursday, 10 December 2015 at 08:18
To: Ryan Huff >, cisco voip 
>
Subject: Re: [cisco-voip] VCS Checker

Awesome, I wonder what else is hiding on this site... they have 
https://cway.cisco.com/sncheck/  (check smartnet and eol info) and 
https://cway.cisco.com/csc (upload attachments to tac cases via html5) as well

Seems to be the place for neat little tools…

Matthew G. Loraditch – CCNP-Voice, CCNA-R, CCDA
Network Engineer
Direct Voice: 443.541.1518


Facebook | 
Twitter | 
LinkedIn 
| G+

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Huff
Sent: Wednesday, December 9, 2015 4:13 PM
To: cisco voip >
Subject: [cisco-voip] VCS Checker


Not sure when Cisco made this tool public but it is a welcomed edition! I knew 
TAC had it but didn't realize Cisco opened it up.



https://cway.cisco.com/tools/SrvRecord


= Ryan =





Email: ryanthomash...@outlook.com

Spark: ryanthomash...@outlook.com

Twitter: @ryanthomashuff

LinkedIn: ryanthomashuff

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

Re: [cisco-voip] advice on upgrading large CUCM cluster with CoW from 8.6 to 10.5

[Daniel Pagan]

Comments below. Hope this helps.

- Danend attach-

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Dave 
Goodwin
Sent: Tuesday, December 01, 2015 8:41 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] advice on upgrading large CUCM cluster with CoW from 8.6 
to 10.5

Has anyone performed an upgrade of a large cluster that uses Clustering over 
the WAN from 8.6 to 10.5 that can share any lessons learned with that specific 
type of scenario? The cluster is already virtual, has 16 nodes, and is spread 
across 3 geographic areas. There is already a standalone PLM on the network 
that will be loaded with the licenses prior to the upgrade. I am trying to 
decide whether to do a standard upgrade, or utilize PCD to perform a Migration 
task.

DPagan: Yes - I would say largest would have been a 20 node cluster and I 
decided not to use PCD for the task for a handful of reasons. First, I (and my 
colleagues on the support team) feel more comfortable upgrading UC platforms 
manually - not only because we have full control over the process but we’re 
also staffed 24/7, so scheduling an upgrade for afterhours isn’t an 
inconvenience that would otherwise be handled by a scheduled PCD task. Second, 
due to the sensitivity of PCD, recovering from a failed automated upgrade on a 
~20 node cluster is much more difficult compared to a smaller cluster (2-5 
nodes for example). Third, we upgrade UC platforms by hand pretty often and are 
very comfortable with the manual process. So, for these reasons, I decided 
against using PCD for an upgrade of this size.

For the standard upgrade, I know there are a handful of things that need to be 
done to prepare, like installing the necessary COP files. After the initial RU 
has been completed to 10.5, I know that I would feel the need to 
backup/reimage/restore, because I want the new VMs to have the ext4 filesystem, 
utilize the proper NIC driver for 10.5, and have the new partition sizing.

DPagan: No concerns here and it’s a valid desire to restore your 10.5 cluster 
to new virtual machines. You might want to consider restoring while on 8.6 
though for two reasons: 1) avoid having to re-license again after going to 10.5 
and 2) there are no problems installing 8.6 on a 10.5 spec VM… but it’s your 
call. Personally I would schedule a restore of 8.6 to 10.5 spec virtual 
machines one week before the major upgrade.

For a PCD Migration, I have had a few issues trying to use it in the past for 
other tasks. It seems to have gotten incrementally better and less fussy over 
the past year or more, but it can still be somewhat fragile. I see in the 
latest version of PCD 11.0 that it supports the use of remote SFTP servers for 
servers that are remote from the PCD running the task. Assuming it works as 
advertised, that should take out the significant performance issues that would 
happen without that feature. The appeal here is I know the VMs made by PCD are 
freshly installed machines with all the right 10.5 traits I mentioned above, 
with data imported from the source cluster. I do would not have to worry about 
the time required (and chance of missing one of the many steps) to do all the 
manual tasks on a 16 node cluster.

DPagan: Unfortunately the remote SFTP server feature does not apply to 
migrations, only to stand-alone upgrades, so this won’t be an option for you on 
this task. However, this should work without issues if you restore to 10.5 spec 
VMs while still on 8.6, then upgrade in-place using PCD and the remote SFTP 
server option… but then this means using PCD. Some of my coworkers on the 
deployment team swear by it, but I *personally* would avoid it for large scale 
migrations/upgrades like this (then again, we’ve perform upgrades by hand for 
years so there’s a level of comfort that comes along with that).

The remote SFTP feature would allow you to avoid issues resulting from ISO and 
DB data transfer over low bandwidth connections. PCD has built in timers that 
aren’t configurable, and when these timers expire prematurely (due to a slow 
ISO transfer for example) you can encounter false positives where PCD thinks 
the upgrade failed while it’s actually still running in the background. It does 
this through AXL calls for CUCM’s active version - if the upgrade is still 
running, and Tomcat/AXL has yet to start up, it’s flagged as failed.

My suggestion, if you migrate before restore, is to upgrade manually using ISOs 
mounted on local datastores as opposed to sources remotely from PCD.

Finally, since this is a megacluster with CoW on top of that, I am sensitive to 
the issues that can happen with DB replication after an upgrade where it can 
take many hours to complete. Is there a way, either manually or via PCD, to 
speed that up? For example, I would like to consider running 'utils 
dbreplication setprocess 40' after the 10.5 publisher is up and running. Would 
that be the best way to handle it, and it will it affect 

Re: [cisco-voip] Jabber phone mode outbound calls issue

[Daniel Pagan]

Looking at the SIP transactions in a parser that doesn't display header fields 
(it doesn't even have the start-line) really limits how much information one 
can gather from the output. The REFER should have either a Replaces: header 
field or, most likely, a Refer-To: header field, which should give you an idea 
what the UAC is attempting to accomplish with that request. Seeing as how it's 
coming in after the UPDATE request, I would imagine the REFER might be related 
but I personally haven't seen that association before for a blind or consult 
transfer using SIP.

CCM SDL traces would help because not only would it display the SIP start-line, 
message header, and message body, but also SDI/SDL signals that would help 
explain the source of the UPDATE request and possibly the REFER if its 
associated. I'm assuming the 183 with SDP is for playing out the Annunciator, 
but again impossible to tell without the message body of the 183. Everything 
else before that looks normal (INVITE for the first digit, SUBSCRIBE for KPML, 
NOTIFY for additional digits, etc.). Detailed SDL traces from all nodes would 
have much more information. I personally would be more interested in the digit 
analysis process than anything else.

Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of abbas 
wali
Sent: Tuesday, November 24, 2015 12:13 PM
To: 'Ryan Huff' ; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Jabber phone mode outbound calls issue

Hi Ryan,

Thanks for the detailed response.

Yes the issue is with Jabber clients and not the IP phones.

The line itself which is shared with many devices, can make calls on any other 
device but fails when made from Jabber.

I ran all the below Utils and all came out without any significant alarms
The NTP, though is at stratum 4. But again that's for both the clusters and one 
of them can make calls with jabber.


Have ran some traces as below
These are multiple failed calls.
Not sure why there are so many REFER messages !!

Thank s

[cid:image001.png@01D126B9.B08386B0]

From: Ryan Huff [mailto:ryanh...@outlook.com]
Sent: 24 November 2015 15:32
To: abbas wali >; 
cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Jabber phone mode outbound calls issue


I assume this is only with the Jabber clients and not IP phones as well?



The annunciation message you're getting from Call Manager is typically reserved 
for when the calling device does not have access to the called device (or 
pattern). If you're confident that you're CSS/Partitions are correct you may 
need to look at OS level items.



I recently assisted someone who presented with similar symptoms; everything 
worked fine except Jabber client egress and the solution there was NTP 
(incorrect/unsupported NTP can cause very, very strange behavior in UCOS).



I would give the cluster a quick health check (performed from the CLI of the 
publisher);



  *   utils dbreplication runtimestate

 *   Looking for everything to come back with a (2) Setup Completedi 
message in the Replication Setup column

  *   utils diagnose module validate_network

 *   Looking for it to come back with Passed (anything fails like reverse 
DNS ... etc and it will explain)

  *   utils ntp status

 *   Looking for it to show synchronized and a stratum 3 (or lower)

*   Windows servers (SNTP) are unsupported for NTP and may cause issues 
even if it shows synchronized

  *   utils ntp server list

 *   Looking for any ntp servers referenced by hostname/FQDN rather than IP 
address (you should reference ntp servers by IP address)

If everything comes back healthy, I would setup a test call scenario and pull 
traces off of CCM and follow the call flow. If one of the health checks fail, I 
would resolve that and then you may have to schedule a cluster restart (if 
possible).


= Ryan =





Email: ryanthomash...@outlook.com

Spark: ryanthomash...@outlook.com

Twitter: @ryanthomashuff

LinkedIn: ryanthomashuff

Web ryanthomashuff.com


From: cisco-voip 
> 
on behalf of abbas wali >
Sent: Tuesday, November 24, 2015 9:58 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Jabber phone mode outbound calls issue


Hi all,



Jabber phone only mode (10.5.2) is unable to make any outbound calls including 
any internal calls even to reach the voicemail.

Inbound calls are working.



This is happening in CUCM 9.1



When dial anything , I get  the "your call cannt be completed as dialled please 
consult..."



I have checked via the DNA and the line 

Re: [cisco-voip] Call to Huntgroup drop when Group only contains csf

[Daniel Pagan]

Just a heads up, the Use Forward Settings of Line Group Member should use the 
forward no coverage settings of the DN forwarding to the Hunt Pilot. No need to 
have an active line member in the LG. Just ran a quick test to confirm - the 
only member of a LG was logged out with the device unregistered and no coverage 
continued to work.

Not sure why this feature got renamed to "of Line Group Member" - it should 
have kept its original name instead ("use personal prefs") considering how much 
confusion it caused when it was first changed.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Huff
Sent: Sunday, November 22, 2015 7:19 PM
To: rschukne...@gmx.de; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Call to Huntgroup drop when Group only contains csf


For the "Forward Hunt No Answer" setting on the hunt pilot did you select "Use 
Forward Settings of Line Group Member" or "Forward Unanswered Calls to 
Destination"? If you've selected "Use Forward Settings of Line Group Member", 
then an active line member will need to be present in the line group.


= Ryan =





Email: ryanthomash...@outlook.com

Spark: ryanthomash...@outlook.com

Twitter: @ryanthomashuff

LinkedIn: ryanthomashuff

Web ryanthomashuff.com


From: cisco-voip 
> 
on behalf of rschukne...@gmx.de 
>
Sent: Sunday, November 22, 2015 4:40 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Call to Huntgroup drop when Group only contains csf




I am facing a strange Problem with Huntgroups which are containing only CSF 
(Client Services Framework) devices.

The huntpilot is configured to forward calls on busy and no Answer to a 
voicemail-Pilot. Which is working when at least one csf device is registered. 
It does not work when no csf device is registered. Then a call for the 
Huntgroup is silently dropped. No busy tone or announcement.

We are using CUCM Version 10.5.2 SU2.

Any Hints See welcome!





Regards,

Robert

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

Re: [cisco-voip] Call to Huntgroup drop when Group only contains csf

[Daniel Pagan]

Hey Ryan. Hope things are going well over in your neighborhood. I think the 
confusion comes from the name. It made more sense when it was called “Use 
Personal Preferences” before CUCM 9x.

For Use Personal Preferences (which is now Use Fwd Settings of LG Member):

“Use this check box to enable the Call Forward No Coverage (CFNC) settings for 
the original called number that forwarded the call to this hunt pilot.”

- Dan

From: Ryan Huff [mailto:ryanh...@outlook.com]
Sent: Monday, November 23, 2015 11:38 AM
To: Daniel Pagan <dpa...@fidelus.com>; rschukne...@gmx.de; 
cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Call to Huntgroup drop when Group only contains csf


Hi Dan!



Thanks for correcting me. For some reason I remembered it working differently? 
Anyway, my apologies to the list, I will work to improve [] .


= Ryan =




From: Daniel Pagan <dpa...@fidelus.com<mailto:dpa...@fidelus.com>>
Sent: Monday, November 23, 2015 9:39 AM
To: Ryan Huff; rschukne...@gmx.de<mailto:rschukne...@gmx.de>; 
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: RE: [cisco-voip] Call to Huntgroup drop when Group only contains csf


Just a heads up, the Use Forward Settings of Line Group Member should use the 
forward no coverage settings of the DN forwarding to the Hunt Pilot. No need to 
have an active line member in the LG. Just ran a quick test to confirm - the 
only member of a LG was logged out with the device unregistered and no coverage 
continued to work.



Not sure why this feature got renamed to “of Line Group Member” - it should 
have kept its original name instead (“use personal prefs”) considering how much 
confusion it caused when it was first changed.



- Dan



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Huff
Sent: Sunday, November 22, 2015 7:19 PM
To: rschukne...@gmx.de<mailto:rschukne...@gmx.de>; 
cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] Call to Huntgroup drop when Group only contains csf



For the "Forward Hunt No Answer" setting on the hunt pilot did you select "Use 
Forward Settings of Line Group Member" or "Forward Unanswered Calls to 
Destination"? If you've selected "Use Forward Settings of Line Group Member", 
then an active line member will need to be present in the line group.



= Ryan =





Email: ryanthomash...@outlook.com<mailto:ryanthomash...@outlook.com>

Spark: ryanthomash...@outlook.com<mailto:ryanthomash...@outlook.com>

Twitter: @ryanthomashuff<http://twitter.com/ryanthomashuff>

LinkedIn: ryanthomashuff<http://linkedin.com/in/ryanthomashuff>

Web ryanthomashuff.com<http://ryanthomashuff.com>





From: cisco-voip 
<cisco-voip-boun...@puck.nether.net<mailto:cisco-voip-boun...@puck.nether.net>> 
on behalf of rschukne...@gmx.de<mailto:rschukne...@gmx.de> 
<rschukne...@gmx.de<mailto:rschukne...@gmx.de>>
Sent: Sunday, November 22, 2015 4:40 PM
To: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: [cisco-voip] Call to Huntgroup drop when Group only contains csf





I am facing a strange Problem with Huntgroups which are containing only CSF 
(Client Services Framework) devices.

The huntpilot is configured to forward calls on busy and no Answer to a 
voicemail-Pilot. Which is working when at least one csf device is registered. 
It does not work when no csf device is registered. Then a call for the 
Huntgroup is silently dropped. No busy tone or announcement.

We are using CUCM Version 10.5.2 SU2.

Any Hints See welcome!





Regards,

Robert


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

Re: [cisco-voip] System Call Handlers: Message forwarding after recording

[Daniel Pagan]

Set the call handler to send voice messages to a specific user with mailbox. 
Configure that CUC user to relay voice messages (not accept and relay) to an 
SMTP address in the Message Actions config page. This assumes you have an SMTP 
server configured in the SMTP Smart Host page. Also the user will consume an 
additional messaging license being that it'll have a mailbox, regardless if 
it's a "forward all" type of setup.

-Original Message-
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Isamar Maia
Sent: Monday, November 23, 2015 5:10 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] System Call Handlers: Message forwarding after recording

Dear Folks,

Just need to confirm if it is possible to, through Unity's System Call 
handlers, record a voice message from an user simulating a simple IVR and 
forward this audio message to an email(SMTP) destination.

--
Isamar Maia
Cel. VIVO SSA:  (55) 71-9146-8575
Cel. TIM   SSA:  (55) 71-9289-5128
Fixo:  (55) 71-4062-8688
Skype ID: isamar.maia
"A vida é muito curta para ser pequena" (Benjamin Disraeli) 
___
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] Restart CUIC

[Daniel Pagan]

Not to mention further impact caused by a “can’t break what’s broken” approach 
without having full knowledge of additional dependencies. I would add a third 
to your list:

3) Do I understand all the dependencies of this service I’m restarting, trunk 
I’m resetting, server I’m rebooting, or configuration pool I’m restarting? 
Further, am I certain the work I’m about to perform will have either a positive 
or, at least, a neutral effect on the impacted device or software. If not, 
repeat questions #1 and #2.

;)

- Dan


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Huff
Sent: Friday, November 20, 2015 3:34 PM
To: jcolon...@gmail.com
Cc: Cisco VOIP 
Subject: Re: [cisco-voip] Restart CUIC

Amendment:

Well, You can break almost broke; at that point I would level it against 
business impact with two questions.

1.) Is this impacting the business (or capacity to do business) in a manner 
that dictates immediate resolution or can it wait till a scheduled maintenance 
window?

2.) What is the impact if I do nothing and the problem progresses, will there 
be other things impacted that will change my answer to question #1?

Thanks,

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

Re: [cisco-voip] CUCM Upgrade failure...

[Daniel Pagan]

On the topic of NTP and upgrades/migrations, I would advise to also watch out 
for CSCur94973.

https://tools.cisco.com/bugsearch/bug/CSCur94973

- Dan
-

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Anthony Holloway
Sent: Monday, November 16, 2015 11:20 AM
To: Jonathan Charles 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CUCM Upgrade failure...

Looks like you're all good now, but as a heads up to everyone else, don't stop 
at checking NTP with "utils ntp status".  You will fail to upgrade if your NTP 
configuration has an FQHN for the NTP server which begins with a digit.

E.g., 0.pool.ntp.org

You will not see the hostname in the output of "utils ntp status", as it will 
only show you the resolved IP address.  So, you will also need to issue a 
"utils ntp config" to see what value was entered by the administrator.

This is the only defect reference I found, though my upgrade I hit it on was an 
8.6 to 10.5 Refresh Upgrade (RU) (Not PCD).

https://tools.cisco.com/bugsearch/bug/CSCtj07817

On Sun, Nov 15, 2015 at 10:43 PM, Jonathan Charles 
> wrote:
OK, a reboot of CPCD got it passed that error...


Jonathan

On Sun, Nov 15, 2015 at 9:40 PM, Jonathan Charles 
> wrote:
Yeah, the error I am getting is:

1 nodes(s) in Export task action ID #1127... on the Publisher...

I will try rebooting everything...



Jonathan

On Sun, Nov 15, 2015 at 9:35 PM, Ryan Huff 
> wrote:
Looks healthy ...

I recall trying PCD once and I hit really strange issues too. For that upgrade, 
I ultimately abandoned PCD and built new VMs with the Answer File Generator 
then a DRS backup/restore.

Not sure where you are in your timeline or if it is that important but it is 
definitely something I would consider. Sometimes you can spend more time trying 
to get the silly tools to work, than to just do the work yourself.

Google is littered with PCD weirdness; great idea of an application, just not 
there yet IMO.

-Ryan



Sent from my iPad
On Nov 15, 2015, at 10:19 PM, Jonathan Charles 
> wrote:
Everything looks good


admin:utils ntp status
ntpd (pid 19674) is running...

 remote   refid  st t when poll reach   delay   offset  jitter
==
 127.127.1.0 .LOCL.  10 l   21   64  3770.0000.000   0.001
 10.0.31.2   10.0.31.33 u  175 1024  3770.635   -5.771   2.042
*10.0.31.3   129.6.15.29  2 u  970 1024  3770.510  -11.340   0.449
 10.1.31.2   10.0.31.33 u  490 1024  3770.850   -9.114   4.881
+10.1.31.3   129.6.15.29  2 u  184 1024  3770.817   -4.085   5.355


synchronised to NTP server (10.0.31.3) at stratum 3
   time correct to within 68 ms
   polling server every 1024 s

Current time in UTC is : Mon Nov 16 03:16:14 UTC 2015
Current time in America/Chicago is : Sun Nov 15 21:16:14 CST 2015
admin:

admin:utils diagnose module validate_network

Log file: platform/log/diag1.log

Starting diagnostic test(s)
===
test - validate_network: Passed

Diagnostics Completed

admin:#

admin:utils dbreplication runtimestate

DB and Replication Services: ALL RUNNING

Cluster Replication State: Replication repair command started at: 
2014-06-20-23-22
 Replication repair command COMPLETED 541 tables processed out of 541
 Errors or Mismatches Were Found:

 Use 'file view activelog 
cm/trace/dbl/sdi/ReplicationRepair.2014_06_20_23_22_51.out' to see the details

DB Version: ccm8_6_2_2_2
Number of replicated tables: 541

Cluster Detailed View from PUB (5 Servers):

PINGREPLICATION REPL.   DBver&  
REPL.   REPLICATION SETUP
SERVER-NAME IP ADDRESS  (msec)  RPC?STATUS  QUEUE   TABLES  
LOOP?   (RTMT) & details
--- --  --- -   --- 
-   -
IPTCMS02  10.0.126.12 0.196   Yes Connected   0   match   Yes   
  (2) Setup Completed
IPTCMS01  10.0.126.11 0.151   Yes Connected   0   match   Yes   
  (2) Setup Completed
IPTCMP10.0.126.10 0.065   Yes Connected   0   match   Yes   
  (2) PUB Setup Completed
IPTCMS03  10.1.126.13 0.545   Yes Connected   0   match   Yes   
  (2) Setup Completed
IPTCMS04  10.1.126.14 0.527   Yes Connected   0   match   Yes   
  (2) Setup Completed

admin:

On Sun, Nov 15, 2015 at 9:14 PM, Ryan Huff 
> wrote:
Also worth noting that if CCM NTP is synchronized to a Windows server (even if 
it shows Stratum 3 or better); that is a problem you'll need to correct as 

Re: [cisco-voip] call tracking question

[Daniel Pagan]

Sreekanth: Really enjoyed your LUA scripting video.

Ahmed: Adding to this, you can use the Call-ID header for identifying a 
specific SIP call flow in the output of debug ccsip messages. The Call-ID 
header field is a unique identifier for the SIP dialog, which means the Call-ID 
header field for the incoming call-leg will be different from the outgoing 
call-leg, but persistent for the duration of the dialog (not guaranteed to be 
the entire call, but more than likely the entire call). There are other unique 
headers fields within SIP, all helpful and used in their own way, but the 
Call-ID header is very useful for a high-level view of transactions involved in 
a dialog. For information on SIP signaling, I suggest starting with online 
articles by Andrew Prokop (google his name...). He talks on Avaya platforms but 
focuses heavily on RFC concepts.

Hope this helps.
- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ahmed 
Abd EL-Rahman
Sent: Sunday, November 15, 2015 6:27 AM
To: Sreekanth Narayanan (sreenara) ; 
cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] call tracking question

Many thanks Sreekanth, really appreciated.



Best Regards

Ahmed Abd EL-Rahman
Senior Network Engineer - KSA
From: Sreekanth Narayanan (sreenara) [mailto:sreen...@cisco.com]
Sent: Sunday, November 15, 2015 2:11 PM
To: Ahmed Abd EL-Rahman 
>; 
cisco-voip@puck.nether.net
Subject: RE: call tracking question

You'll firstly need to find the call using the called or calling number, and 
then you can track it using the Global call identifier in the CCAPI logs.
For example, in this line:
8261462: Sep 29 14:31:10.720: //640449/14CF2490BDF1/CCAPI/cc_api_call_connected:
   Call Entry(Connected=TRUE, Responsed=TRUE, Retry Count=0)

14CF2490BDF1 is the GCID. This will remain constant on the call, and you will 
see 2 different legs (if it is a simple call, and doesn't include conference).
640449 is the leg ID. There will be one matching the incoming side, and the 
other for the outgoing side.
You can use Notepad++ or Jedit to highlight the GCID and the leg numbers to 
track the call then.
I'd suggest logging all the debugs to the buffer so you don't lose any 
information. This is a usual template you can use.

Router(config)#service timestamps debug datetime msec
Router(config)#logging buffered  debugging
Router(config)#service sequence
Router(config)#no logging rate-limit
Router#term no mon

Then output all the logs using show logging command

Thanks
Sreekanth


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ahmed 
Abd EL-Rahman
Sent: Sunday, November 15, 2015 4:30 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] call tracking question

Hi Gents,

If I'm executing debug commands like debug voice ccapi inout and debug csip 
messages on a voice router and I need to track a certain call among a lot of 
calls passing through the VGW at the same moment, how can I do that ?




Best Regards

Ahmed Abd EL-Rahman
Senior Network Engineer - KSA
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] called party hears music on hold

[Daniel Pagan]

If you’re certain the hold request is coming from IM, and the hold request is 
in reference to the call reference (CI) associated with the call in question, 
then my suggestion would be to open a TAC case. At this point, assuming this 
finding is applicable to the problem at hand, and end-user intervention isn’t 
the cause, then it’s possibly a new or existing defect. The only thing I could 
add here would be to provide TAC with the CI numbers and process IDs associated 
with the call-leg being placed on hold to speed up the process. There’s 
probably some information they can dig up in Topic Search if there’s history to 
this issue…

But I still wonder if these events are actually applicable to the problem 
you’re facing.  Providing this information to TAC might only prolong RCA if it 
isn’t related to the problem at hand. One thing I would certainly confirm is 
the hold request coming into CCM from CTIDeviceLineMgr to StationD (or 
SIPStationD) should contain the IP address of the device sourcing the request. 
In this case it should be IM More importantly, I would also ensure the hold 
request is for the correct CI - if this isn’t confirmed then further 
troubleshooting could involve lots of wheel spinning with no progress. My 
experience w/ Lync is limited but SIP transactions off the Lync server should 
help you determine if the hold request is sourcing from there, passed to IM, 
then sent to CUCM via QBE/CTI. Either way, this should help determine the 
source of this hold request (assuming it’s related of course).

I wasn’t able to find any public defects related to this.

Sorry this isn’t a root cause but hope you find it helpful regardless.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Reto 
Gassmann
Sent: Tuesday, November 10, 2015 11:17 AM
To: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] called party hears music on hold


I looked at the log files (SDL Trace) and found a CtiLineCallHoldReq that comes 
from the IM server. It looks like RCC with Lync has something to do with it. 
I found something similar in the Cisco Support Community:
https://supportforums.cisco.com/discussion/10576466/being-placed-hold

It says that is has something to do with the status of the previous call did 
not clear the "In a call" status from CUPS in OCS.

However, I could not find out, when there is a problem with clearing the In a 
call status.

Regards Reto

Am Donnerstag, 5. November 2015 schrieb Wes Sisk (wsisk) :
I tracked one of these down once several years back:

a calls b
a puts call on hold
b transfers call to c
c answers and hears MoH

when a, b, and c are all phones registered on the same node/cluster this 
shouldn’t happen. However, if the call from a to b traverses a trunk 
(SIP/H.323/MGCP) then there is no “hold” state/communication/update in the 
signaling stream to prevent the transfer from b to c.

Just a thought.

-w

On Nov 5, 2015, at 10:57 AM, Reto Gassmann > wrote:

Hello Group

we have a strange problem on our UCM 10.5, that sometime happens.

If someone calls my IP Phone (7961) and I pick up the call, I hear music on 
hold. The caller then puts the call on hold and then gets back to the call. Now 
music on hold is gone and we can talk.

Has anyone had this issue before?

Regards Reto
___
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] CUCM 10.5 and Exchange 2013 voicemail setup.

[Daniel Pagan]

Adding to list of possibilities, it could also be an unaccepted transport 
type... E.g. CUCM now sending SIP requests via TCP when UDP inbound is 
configured on Exchange.

Also if require MTP is configured but none are available, in which case I’d 
check MRM in SDL traces.

But my guess would be OPTIONS. If the SIP trunk is configured for OPTIONS PING 
and Exchange isn’t responding with anything outside a 408 Request Timeout or 
503 Service Unavailable. Route List Control will not route the call and a fast 
busy will be experienced immediately if no backup points of egress are 
available. If I had to bet, it would be on this scenario considering the jump 
from 6.x to 10.x will most definitely introduce SIP trunk status (Full Service, 
No Service, Unknown) and call setup requests will not be routed to No Service 
trunk.

Hope this helps.

Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Huff
Sent: Tuesday, October 13, 2015 7:29 PM
To: Terry Oakley ; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CUCM 10.5 and Exchange 2013 voicemail setup.

Terry,

Sounds like you have a lot going on there!

How did you move into the 10.5 environment?  Did you do a bridge migration or a 
'stare and compare'?

A fast busy could be a few different things (css, partition ... etc) or dns 
based since you mentioned fqdn or resource based.

What codec are you trying using?

Have you pulled traces?

What is the disconnect cause code for one of the failed calls into the hunt 
pilot?

If you can reproduce a failed call and then send me the traces or the sip 
messages I can give you a much better answer.

Thanks,

Ryan


Sent from my T-Mobile 4G LTE Device


 Original message 
From: Terry Oakley
Date:10/13/2015 6:24 PM (GMT-05:00)
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] CUCM 10.5 and Exchange 2013 voicemail setup.
We currently are moving from Exchange 2007 to Exchange 2013.   We have three 
CAS servers and 3 Mailbox servers, all virtualized.   In our test environment, 
before we moved from CUCM 6.1 to 10.5 we are able to at least get Exchange 2013 
to answer a SIP trunk request from CUCM 6.1.   Now in CUCM 10.5 we just get a 
fast busy when we dial the VM pilot number.   Does anyone have experience with 
this and have a guide that we could follow?We have followed a number of 
guides from Microsoft and they have not proven to be the magic answer.

We have a SIP trunk set to the CAS servers with all three individual servers 
listed in the Destination section (all FQDN) port 5060
We have three separate SIP trunks to the three mailbox servers with all three 
having the ports 5062 through 5068 listed and again FQDN for the destination 
address.
The VM pilot (route pattern) is associated with the CAS trunk.
Do we need a route list and hence a route group?

Thank you for your knowledge and wiliness to share.  And especially thanks to 
this forum for providing us the access.

Cheers

Terry

Terry Oakley
Telecommunications Coordinator | Information Technology Services
Red Deer College |100 College Blvd. | Box 5005 | Red Deer | Alberta | T4N 5H5
work (403) 342-3521   |  FAX (403) 343-4034

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

Re: [cisco-voip] strange shared line behavior on 88XX phones

[Daniel Pagan]

Hey Anthony – very valid points. I assumed the delayed 487 final response Erick 
mentioned was in reference to phones continuing to ring past the answer, and 
not stopping the ringer when the call is answered elsewhere.

Based on console logs, the 487 seems to be a prerequisite to disabling the 
local ringer, but if the issue is a delay in *starting* the ringer, then I 
agree this 487 certainly shouldn’t be applicable.

Dan

From: avhollo...@gmail.com [mailto:avhollo...@gmail.com] On Behalf Of Anthony 
Holloway
Sent: Wednesday, September 30, 2015 11:27 PM
To: Erick Wellnitz
Cc: Daniel Pagan; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] strange shared line behavior on 88XX phones

Having the 487 delayed would not impact when the phone starts ringing though.  
In fact, the phones should start ringing at the sending of the 180 back to 
CUCM.  In Daniel's diagram that would be this one:

cucm <-- 180 <-- phoneA (one response per phone)

So, if anything, there should be a delay in the CUCM sending of the INVITE to 
the delayed ringing phone(s), or the delayed ringing phone(s) should delay 
their 180 back to CUCM.  If none of this is delayed on the wire, then I would 
think it's some internal firmware bug on the phone.  Have you tried an older or 
newer firmware?  Granted, you had the same firmware on the 8.6(2), but since 
we're grasping for ideas, why not give it a shot?

Also, have you looked in bug search tool yet?  I only found this one closely 
related bug, but as with all filed defects, you can never really be 100% sure.

https://tools.cisco.com/bugsearch/bug/CSCur10651

Good luck.  Also, you should be on 10.5(2)SU2a.  ;)  Just say'n.



On Wed, Sep 30, 2015 at 4:38 PM, Erick Wellnitz 
<ewellnitzv...@gmail.com<mailto:ewellnitzv...@gmail.com>> wrote:
The 200 comes relatively quickly and the CM sends the ACK back quickly.  It's 
only the 487 that is delayed and not all the time.  The time frame in the 
console logs matches the CM traces so it doesn't look like any funny business 
on the network.

This one is a head scratcher for sure.

On Wed, Sep 30, 2015 at 3:08 PM, Daniel Pagan 
<dpa...@fidelus.com<mailto:dpa...@fidelus.com>> wrote:
Interesting… Out of curiosity, there should first be a CANCEL to the IP phones 
where the call wasn’t answered. The phones should then 200 that CANCEL request, 
and then send the 487 final response to the original INVITE for the call. Do 
you see the 487 final response six seconds after the CANCEL/200 exchange? I ask 
only because this should help you determine where the delay is coming from - 
the phone or CUCM.

- Dan

From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net<mailto:cisco-voip-boun...@puck.nether.net>]
 On Behalf Of Erick Wellnitz
Sent: Wednesday, September 30, 2015 3:51 PM
To: Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] strange shared line behavior on 88XX phones

Finally had the behavior repeat.

Found in the console logs and the CM traces that a couple of the phones are, 
for some reason, delaying their 487 - Request Cancelled response for up to 6 
seconds from when the call is answered.

Sent to TAC to see what they have to say.

On Wed, Sep 30, 2015 at 11:09 AM, Lelio Fulgenzi 
<le...@uoguelph.ca<mailto:le...@uoguelph.ca>> wrote:
turns out it is written.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/7_1_2/ccmsys/accm-712-cm/a03dn.html#wp1100362


Shared Line Restrictions

The following restrictions apply to shared lines:


•Do not configure shared-line appearances on the primary lines of the phones; 
for example, if two phones have a shared-line appearance, only one of the 
phones should have the primary line configured as shared (the other phone 
should have the secondary line configured as shared).




In version 10 it becomes a suggestion though. Interesting.



http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmsys/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100_chapter_010001.html#CUCM_RF_S05975F9_00

Shared Line Suggestions
Do not configure shared line appearances on primary lines as certain feature 
interactions are impacted. Settings of the primary line are applicable to the 
shared line. For example: if two phones have a shared-line appearance, only one 
phone should have the primary line configured as shared to avoid unexplained 
post configuration behavior.

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

519‐824‐4120 Ext 56354<tel:519%E2%80%90824%E2%80%904120%20Ext%2056354>
le...@uoguelph.ca<mailto:le...@uoguelph.ca>
www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs>
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1


From: &

Re: [cisco-voip] strange shared line behavior on 88XX phones

[Daniel Pagan]

Interesting… Out of curiosity, there should first be a CANCEL to the IP phones 
where the call wasn’t answered. The phones should then 200 that CANCEL request, 
and then send the 487 final response to the original INVITE for the call. Do 
you see the 487 final response six seconds after the CANCEL/200 exchange? I ask 
only because this should help you determine where the delay is coming from - 
the phone or CUCM.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Erick 
Wellnitz
Sent: Wednesday, September 30, 2015 3:51 PM
To: Lelio Fulgenzi 
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] strange shared line behavior on 88XX phones

Finally had the behavior repeat.

Found in the console logs and the CM traces that a couple of the phones are, 
for some reason, delaying their 487 - Request Cancelled response for up to 6 
seconds from when the call is answered.

Sent to TAC to see what they have to say.

On Wed, Sep 30, 2015 at 11:09 AM, Lelio Fulgenzi 
> wrote:
turns out it is written.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/7_1_2/ccmsys/accm-712-cm/a03dn.html#wp1100362


Shared Line Restrictions

The following restrictions apply to shared lines:


•Do not configure shared-line appearances on the primary lines of the phones; 
for example, if two phones have a shared-line appearance, only one of the 
phones should have the primary line configured as shared (the other phone 
should have the secondary line configured as shared).




In version 10 it becomes a suggestion though. Interesting.



http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmsys/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100_chapter_010001.html#CUCM_RF_S05975F9_00

Shared Line Suggestions
Do not configure shared line appearances on primary lines as certain feature 
interactions are impacted. Settings of the primary line are applicable to the 
shared line. For example: if two phones have a shared-line appearance, only one 
phone should have the primary line configured as shared to avoid unexplained 
post configuration behavior.

---
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


From: "Erick Wellnitz" >
To: "Lelio Fulgenzi" >
Cc: cisco-voip@puck.nether.net
Sent: Wednesday, September 30, 2015 12:20:51 PM
Subject: Re: [cisco-voip] strange shared line behavior on 88XX phones

It is on a fair number of them.  They didn't have the issue on 8.6.2 with the 
same firmware.

We're waiting on the next occurrence to gather traces.

On Wed, Sep 30, 2015 at 10:04 AM, Lelio Fulgenzi 
> wrote:

I recall there being an (un)written rule where shared lines should not be the 
primary line. It could cause issues.

Are the shared lines the first DN on the phone?

Lelio

---
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


From: "Erick Wellnitz" >
To: cisco-voip@puck.nether.net
Sent: Wednesday, September 30, 2015 12:00:20 PM
Subject: [cisco-voip] strange shared line behavior on 88XX phones

anyone seen issues with the 88xx phones on firmware 10.3(1) and CUCM 10.5.2 SU1 
where the line starts ringing on some phones right away and some start ringing 
up to 15 seconds later.  Some also experience ringing after the call is 
answered up to 15 seconds after answered.

88xx phones are the only ones exhibiting this behavior.  Another consideration 
is that this shared line is on 17 devices.

Thanks for any insight!

___
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] strange shared line behavior on 88XX phones

[Daniel Pagan]

Also, if you’re not sure of which 200 final response belongs to the INVITE vs 
CANCEL, check out the CSeq header of the 200 message body. Typical call flow 
should be:

::Call is placed to phone::

cucm --> INVITE --> phoneA
cucm --> INVITE --> phoneB
cucm --> INVITE --> phoneC
cucm <-- 100 <-- phoneA (one response per phone)
cucm <-- 180 <-- phoneA (one response per phone)

::Call is answered::

cucm <-- 200 with CSeq: 101 INVITE <-- phoneA
cucm --> ACK --> phoneA
 this exchange can occur before or after the CANCEL requests. Dependent on 
how quickly CUCM can collect and exchange media information between 
calling/called phones.

::Call is cancelled on remaining phones::

cucm --> CANCEL --> phoneB
cucm --> CANCEL --> phoneC
cucm <-- 200 with CSeq: 101 CANCEL <-- phoneB   (one response per 
phone)
cucm <-- 487 with CSeq: 101 INVITE <-- phoneB  (one response per 
phone)
cucm --> ACK --> phoneB
cucm --> ACK --> phoneC

Hope this helps. I’m pretty interested in knowing what you or TAC finds.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Wednesday, September 30, 2015 5:09 PM
To: Erick Wellnitz <ewellnitzv...@gmail.com>; Lelio Fulgenzi <le...@uoguelph.ca>
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] strange shared line behavior on 88XX phones

Interesting… Out of curiosity, there should first be a CANCEL to the IP phones 
where the call wasn’t answered. The phones should then 200 that CANCEL request, 
and then send the 487 final response to the original INVITE for the call. Do 
you see the 487 final response six seconds after the CANCEL/200 exchange? I ask 
only because this should help you determine where the delay is coming from - 
the phone or CUCM.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Erick 
Wellnitz
Sent: Wednesday, September 30, 2015 3:51 PM
To: Lelio Fulgenzi <le...@uoguelph.ca<mailto:le...@uoguelph.ca>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] strange shared line behavior on 88XX phones

Finally had the behavior repeat.

Found in the console logs and the CM traces that a couple of the phones are, 
for some reason, delaying their 487 - Request Cancelled response for up to 6 
seconds from when the call is answered.

Sent to TAC to see what they have to say.

On Wed, Sep 30, 2015 at 11:09 AM, Lelio Fulgenzi 
<le...@uoguelph.ca<mailto:le...@uoguelph.ca>> wrote:
turns out it is written.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/7_1_2/ccmsys/accm-712-cm/a03dn.html#wp1100362


Shared Line Restrictions

The following restrictions apply to shared lines:


•Do not configure shared-line appearances on the primary lines of the phones; 
for example, if two phones have a shared-line appearance, only one of the 
phones should have the primary line configured as shared (the other phone 
should have the secondary line configured as shared).




In version 10 it becomes a suggestion though. Interesting.



http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/10_0_1/ccmsys/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100/CUCM_BK_SE5FCFB6_00_cucm-system-guide-100_chapter_010001.html#CUCM_RF_S05975F9_00

Shared Line Suggestions
Do not configure shared line appearances on primary lines as certain feature 
interactions are impacted. Settings of the primary line are applicable to the 
shared line. For example: if two phones have a shared-line appearance, only one 
phone should have the primary line configured as shared to avoid unexplained 
post configuration behavior.

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

519‐824‐4120 Ext 56354<tel:519%E2%80%90824%E2%80%904120%20Ext%2056354>
le...@uoguelph.ca<mailto:le...@uoguelph.ca>
www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs>
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1


From: "Erick Wellnitz" <ewellnitzv...@gmail.com<mailto:ewellnitzv...@gmail.com>>
To: "Lelio Fulgenzi" <le...@uoguelph.ca<mailto:le...@uoguelph.ca>>
Cc: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Sent: Wednesday, September 30, 2015 12:20:51 PM
Subject: Re: [cisco-voip] strange shared line behavior on 88XX phones

It is on a fair number of them.  They didn't have the issue on 8.6.2 with the 
same firmware.

We're waiting on the next occurrence to gather traces.

On Wed, Sep 30, 2015 at 10:04 AM, Lelio Fulgenzi 
<le...@uoguelph.ca<mailto:le...@uoguelph.ca>> wrote:

I recall there being an (un)written rule where shared lines should not be the 
primary line. It could cause issues.

Are the shared lines the first DN on the phone?

Lelio

---

Re: [cisco-voip] Analog ports on a 2901

[Daniel Pagan]

I would also suggest debugging the signaling protocol being used for calls 
to/from this analog port or reviewing CCM SDI/SDL traces. If these are MGCP 
controlled, try to determine if CUCM transmitted a DLCX without first receiving 
a NTFY for the on-hook event (O: L/hu). Seeing a NTFY with O: (observed event) 
L/hu (line package/on-hook transition) come into CUCM from the gateway for your 
analog endpoint hung up -- if a DLCX to the gateway follows that event, then 
the disconnect was initiated from the analog endpoint.

Hope this helps.

Dan


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Sreekanth Narayanan
Sent: Tuesday, September 22, 2015 1:19 PM
To: norm.nichol...@kitchener.ca; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Analog ports on a 2901

You could switch on 'debug vpm signal' and log the debugs to a syslog server or 
to the buffer. You'll need to increase the buffer size.

Another trace that you can use after the call completes is 'show voice trace 
a/b/c'


Thanks
Sreekanth

From: norm.nichol...@kitchener.ca
Sent: Tuesday, 22 September 2015 16:32
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Analog ports on a 2901



I have some analog ports that keep dropping calls and I was wondering if there 
was a way to turn on a log file to record specific analog ports so I can see if 
Cisco is disconnecting them or the device attached to the analog port is 
causing the disconnect.



Thanks






Norm Nicholson
Telecom Analyst
City of Kitchener
(519) 741-2200 x 7000




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

Re: [cisco-voip] UCx 9 - email notifications

[Daniel Pagan]

No problem. The solution you used was described in option #2 of my email.

- Dan
end attach-

From: abbas Wali [mailto:abba...@gmail.com]
Sent: Monday, September 14, 2015 8:36 AM
To: Daniel Pagan <dpa...@fidelus.com>
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] UCx 9 - email notifications

thanks Dan,
found another way
do it via the CH and in the message settings, set the Message Recipient to 
either another user with Mailbox or a DL.
thanks

On 9 September 2015 at 17:44, Daniel Pagan 
<dpa...@fidelus.com<mailto:dpa...@fidelus.com>> wrote:
Accomplish this with the Accept and Relay option for user message actions for 
VM1 and specify VM2’s SMTP address. This should keep the message available for 
VM1 while forwarding a copy to VM2. You’ll need to setup CUC with a SMTP smart 
host in order to relay messages, and will likely need to make changes to ensure 
SMTP connections are accepted from your Unity Connection server but I can’t 
provide much assistance on Office 365. Keep in mind this solution *won’t* 
provide any MWI or TUI feedback for VM1 when VM2 reads/deletes the message or 
marks it unread.

As for the DL question, two things I can think of…


1.   Configure VM1 to Accept and Relay to a SMTP address that resolves to a 
distribution list in Office 365 instead of going directly to VM2.



Or


2.   Design the call flow so that voicemail calls to VM1 are *not* routed 
to a VM1 user and greeting, but rather to a Call Handler with message delivery 
to a Distribution List. This Call Handler’s greeting sounds like VM1 (have the 
user record the greeting), but it sends all messages to a DL where the VM1 user 
account is also a member. There’s a few ways to set this up, and it’s far from 
perfect, but it’s one way to accomplish this.

Depending on the privacy requirements of VM1, you a 3rd option might be to 
configure a 2nd extension on VM2’s phone in CUCM and then add this new 
extension as an alternate extension to the CUC user account for VM1. This 
allows VM2 to dial into CUC and access VM1’s mailbox. For MWI, just add a 2nd 
MWI extension for VM1 referencing the new line you added for VM2’s IP phone. I 
know this doesn’t give a voicemail attachment to VM2 user, but I figured the 
outcome this provides might meet the requirements of the user.

Dan


From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net<mailto:cisco-voip-boun...@puck.nether.net>]
 On Behalf Of abbas Wali
Sent: Wednesday, September 09, 2015 10:57 AM
To: cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>
Subject: [cisco-voip] UCx 9 - email notifications

Hi all,
basic question
how to send email notifications (O365 is setup already) to another subscriber 
who already has got their own VM box.
so e.g.
VM1: 12345
VM2: 98765
both are setup with mailbox. VM1 when receives a VM, needs to send notification 
via email to VM2 email box with the attachment.

​also, VM1 receives VM and can send it to a group of users's email
I have tried to create a system Distribution list and add the memebers into it 
but then how to link VM1 to that DL?
thanks ​

--




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

Re: [cisco-voip] CUCM Shared Line Appearance (SIP phones)

[Daniel Pagan]

The request-URI in this case is the PKID of the DN followed by the IP address 
of the phone. Check it out:

https://10.10.13.100/ccmadmin/directoryNumberEdit.do?key=ae97ba4b-2397-4b52-5ddc-07589fb380ab

^^^URL of a test DN.
Key= ae97ba4b-2397-4b52-5ddc-07589fb380ab

INVITE sip:ae97ba4b-2397-4b52-5ddc-07589fb380ab@10.10.31.6:50926;transport=tcp 
SIP/2.0

^^^ Check out the request URI above.

Hope this helps.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Mark 
Holloway
Sent: Saturday, September 12, 2015 8:39 AM
To: voip puck 
Subject: [cisco-voip] CUCM Shared Line Appearance (SIP phones)

Hi all. When CUCM sends a SIP Invite to shared lines on SIP phones the user 
portion contains some sort of (what appears to b) a randomly calculated 
alpha-numeric string. Is there any information or documentation available on 
how Cisco actually calculates what this string will be?

Here is an example of a SIP Invite going to two SIP phones sharing the same 
phone number

INVITE 
sip:8cc951b7-86b6-0c74-1e4d-c0108c268dc2@10.232.50.81:49422;transport=tcp 
SIP/2.0
INVITE 
sip:8cc951b7-86b6-0c74-1e4d-c0108c268dc2@10.232.50.91:51945;transport=tcp 
SIP/2.0


Thanks,
Mark

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

Re: [cisco-voip] CUCM Shared Line Appearance (SIP phones)

[Daniel Pagan]

Adding to this... This is also the URI contained in the Contact header for SIP 
requests transmitted *from* the IP phone, allowing CUCM to send future requests 
to the phone within the same dialog using the PKID URI you're seeing. The PKID 
for the DN is obtained by the phone via TFTP configuration file:

ae97ba4b-2397-4b52-5ddc-07589fb380ab

Hope this helps.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Monday, September 14, 2015 10:44 AM
To: Mark Holloway <m...@markholloway.com>; voip puck 
<cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] CUCM Shared Line Appearance (SIP phones)

The request-URI in this case is the PKID of the DN followed by the IP address 
of the phone. Check it out:

https://10.10.13.100/ccmadmin/directoryNumberEdit.do?key=ae97ba4b-2397-4b52-5ddc-07589fb380ab

^^^URL of a test DN.
Key= ae97ba4b-2397-4b52-5ddc-07589fb380ab

INVITE sip:ae97ba4b-2397-4b52-5ddc-07589fb380ab@10.10.31.6:50926;transport=tcp 
SIP/2.0

^^^ Check out the request URI above.

Hope this helps.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Mark 
Holloway
Sent: Saturday, September 12, 2015 8:39 AM
To: voip puck <cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>>
Subject: [cisco-voip] CUCM Shared Line Appearance (SIP phones)

Hi all. When CUCM sends a SIP Invite to shared lines on SIP phones the user 
portion contains some sort of (what appears to b) a randomly calculated 
alpha-numeric string. Is there any information or documentation available on 
how Cisco actually calculates what this string will be?

Here is an example of a SIP Invite going to two SIP phones sharing the same 
phone number

INVITE 
sip:8cc951b7-86b6-0c74-1e4d-c0108c268dc2@10.232.50.81:49422;transport=tcp 
SIP/2.0
INVITE 
sip:8cc951b7-86b6-0c74-1e4d-c0108c268dc2@10.232.50.91:51945;transport=tcp 
SIP/2.0


Thanks,
Mark

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

Re: [cisco-voip] Cisco Unity 9

[Daniel Pagan]

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/8x/gui_reference/guide/8xcucgrgx/8xcucgrg060.html#pgfId-1052219

Check out table 6-9, specifically the “Callers Hear” section. This doc talks 
about Call Handlers but the “Callers Hear” section is applicable to CUC users 
and should help you out with this. Make sure to have a personal greeting 
recorded.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of abbas 
Wali
Sent: Monday, September 14, 2015 8:34 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Cisco Unity 9

how to NOT play the
Sorry "user" is not avalible, record your message at the tone...
just want to play a personal recording OR a recorded name and take a message
this is for a system call handler
and have tried the untick [ Play the "Record Your Message at the Tone" Prompt]
but it doesn't work.
any ideas,
thanks

--

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

Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

[Daniel Pagan]

I don’t know why this failed to connected when reading the release notes. Quite 
the brain fart… No OS = no SFTP = local mounting of ISO.

- Dan

From: NateCCIE [mailto:natec...@gmail.com]
Sent: Monday, September 14, 2015 4:42 PM
To: Daniel Pagan <dpa...@fidelus.com>
Cc: Justin Steinberg <jsteinb...@gmail.com>; Adam Frankel (afrankel) 
<afran...@cisco.com>; Cisco VoIP Group <cisco-voip@puck.nether.net>
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

I believe the installs have to be on a NFS share for VMware.

Upgrades are just sftp from the cucm side.

Sent from my iPhone.

On Sep 14, 2015, at 1:37 PM, Daniel Pagan 
<dpa...@fidelus.com<mailto:dpa...@fidelus.com>> wrote:
I’m digging up this old thread once again.

With PCD v11 released, it’s great to see that remote SFTP sources can now be 
used, but it’s also disappointing to see it restricted to upgrades only. Does 
anyone know if there are plans to support migrations using a remote SFTP 
server? Is the issue of not supporting migrations that PCD can’t source an ISO 
from an external source while simultaneously storing and exporting UFF and DB 
data locally?

Thanks ahead of time.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Justin Steinberg
Sent: Monday, April 20, 2015 2:25 PM
To: Adam Frankel (afrankel) <afran...@cisco.com<mailto:afran...@cisco.com>>
Cc: Cisco VoIP Group 
<cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>>
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

Hi Adam,

Can you elaborate on this yet ?  :)I never see any PCD software posted to 
cisco.com<http://cisco.com>, it always seems to require E-delivery download.
 I'm not sure why that is, since all the other Prime Collaboration 
(Provisioning & Assurance) can be downloaded from cisco.com<http://cisco.com>

Thanks,

Justin

On Mon, Apr 13, 2015 at 11:54 AM, Adam Frankel (afrankel) 
<afran...@cisco.com<mailto:afran...@cisco.com>> wrote:
“Maybe an ability to leverage ISOs on VMWare datastores instead of from the PCD 
server. “

…check cisco.com<http://cisco.com> later this week or early next week ☺

--
Adam

From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net<mailto:cisco-voip-boun...@puck.nether.net>]
 On Behalf Of Heim, Dennis
Sent: Monday, March 30, 2015 9:16 AM
To: Matthew Collins; Haas, Neal; 'Andrew Grech'; Nick

Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

PCD is a great tool for single-site installs or upgrades in a lab environment. 
Biggest limitation of PCD when multisites are involved, since it pushes all 
ISOs from the PCD server. Maybe an ability to leverage ISOs on VMWare 
datastores instead of from the PCD server.

Dennis Heim | Emerging Technology Architect (Collaboration)
World Wide Technology, Inc. | +1 314-212-1814<tel:%2B1%20314-212-1814>
[twitter]<https://twitter.com/CollabSensei>
[Phone]<tel:+13142121814>
"Innovation happens on project squared" -- 
http://www.projectsquared.com<http://www.projectsquared.com/>

Click here to join me in my Collaboration Meeting 
Room<https://wwt.webex.com/meet/dennis.heim>



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Matthew Collins
Sent: Monday, March 30, 2015 6:08 AM
To: Haas, Neal; 'Andrew Grech'; Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

Just a note on this.

I have just completed a direct Hardware 8.5 to VM 10.5 with network changes 
using Prime collaboration deployment. No Cop files need to be installed, No 
jump upgrades, No restoring from backup. Really was a simple process.

If you haven’t used PCD I would strongly suggest taking a look next time you 
upgrade or install a new build.

Regards

Matthew Collins


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Haas, 
Neal
Sent: 27 March 2015 14:41
To: 'Andrew Grech'; Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

10.5 is VM only, 8.6.1 usually was MCS hardware.

To upgrade you will need to 8.6.1 upgrade to 9.1 on MCS. Then 9.1 MCS to VM, 
the upgrade 9.1 to 10.5(2)SU1.


Neal Haas

From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]<mailto:[mailto:cisco-voip-boun...@puck.nether.net]>
 On Behalf Of Andrew Grech
Sent: Friday, March 27, 2015 7:30 AM
To: Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5


Supported vs the system will upgrade are two different things.
On 27/03/2015 1:51 AM, "Nick" 
<csv...@googlemail.com<mailto:csv...@googlemail.com>> wrote:
Hi All

Just checking through documentation for CUCM 10.5 for an upgrade, the 
compatibility guide states that a direct upgrade is from 8.6.1 onwards as shown 
below.

Upgrade Paths for Cisco Unified Communications Manager Release 10.5(2)SU1

[http://www.cisco

Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

[Daniel Pagan]

I’m digging up this old thread once again.

With PCD v11 released, it’s great to see that remote SFTP sources can now be 
used, but it’s also disappointing to see it restricted to upgrades only. Does 
anyone know if there are plans to support migrations using a remote SFTP 
server? Is the issue of not supporting migrations that PCD can’t source an ISO 
from an external source while simultaneously storing and exporting UFF and DB 
data locally?

Thanks ahead of time.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Justin Steinberg
Sent: Monday, April 20, 2015 2:25 PM
To: Adam Frankel (afrankel) 
Cc: Cisco VoIP Group 
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

Hi Adam,

Can you elaborate on this yet ?  :)I never see any PCD software posted to 
cisco.com, it always seems to require E-delivery download.
 I'm not sure why that is, since all the other Prime Collaboration 
(Provisioning & Assurance) can be downloaded from cisco.com

Thanks,

Justin

On Mon, Apr 13, 2015 at 11:54 AM, Adam Frankel (afrankel) 
> wrote:
“Maybe an ability to leverage ISOs on VMWare datastores instead of from the PCD 
server. “

…check cisco.com later this week or early next week ☺

--
Adam

From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of Heim, Dennis
Sent: Monday, March 30, 2015 9:16 AM
To: Matthew Collins; Haas, Neal; 'Andrew Grech'; Nick

Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

PCD is a great tool for single-site installs or upgrades in a lab environment. 
Biggest limitation of PCD when multisites are involved, since it pushes all 
ISOs from the PCD server. Maybe an ability to leverage ISOs on VMWare 
datastores instead of from the PCD server.

Dennis Heim | Emerging Technology Architect (Collaboration)
World Wide Technology, Inc. | +1 314-212-1814
[twitter]
[chat][Phone][video]
"Innovation happens on project squared" -- 
http://www.projectsquared.com

Click here to join me in my Collaboration Meeting 
Room



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Matthew Collins
Sent: Monday, March 30, 2015 6:08 AM
To: Haas, Neal; 'Andrew Grech'; Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

Just a note on this.

I have just completed a direct Hardware 8.5 to VM 10.5 with network changes 
using Prime collaboration deployment. No Cop files need to be installed, No 
jump upgrades, No restoring from backup. Really was a simple process.

If you haven’t used PCD I would strongly suggest taking a look next time you 
upgrade or install a new build.

Regards

Matthew Collins


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Haas, 
Neal
Sent: 27 March 2015 14:41
To: 'Andrew Grech'; Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

10.5 is VM only, 8.6.1 usually was MCS hardware.

To upgrade you will need to 8.6.1 upgrade to 9.1 on MCS. Then 9.1 MCS to VM, 
the upgrade 9.1 to 10.5(2)SU1.


Neal Haas

From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of Andrew Grech
Sent: Friday, March 27, 2015 7:30 AM
To: Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5


Supported vs the system will upgrade are two different things.
On 27/03/2015 1:51 AM, "Nick" 
> wrote:
Hi All

Just checking through documentation for CUCM 10.5 for an upgrade, the 
compatibility guide states that a direct upgrade is from 8.6.1 onwards as shown 
below.

Upgrade Paths for Cisco Unified Communications Manager Release 10.5(2)SU1

[http://www.cisco.com/c/dam/en/us/td/i/templates/note.gif]
Note



If your release is not listed in the following table, find the upgrade path 
from your current release to a listed release in Cisco Unified Communications 
Manager Software Compatibility Matrix for Release 9.X and Earlier at 
http:/​/​www.cisco.com/​en/​US/​docs/​voice_ip_comm/​cucm/​compat/​ccmcompmatr1.pdf.




Table 15 Export Restricted Supported Cisco Unified Communications Manager 
Upgrades for Release 10.5(2)SU1


10.5(2)SU1


10.5.2.11900-3


Active


February 24, 2015


Direct Upgrade:

10.5(2), 10.5(1)SU1a, 10.5(1)SU1, 10.5(1), 10.0(1)SU2, 10.0(1)SU1, 10.0(1), 
9.1(2)SU2a, 9.1(2)SU2, 9.1(2)SU1, 9.1(2), 9.1(1a), 9.1(1), 9.0(1),

8.6(2a)SU5, 8.6(2a)SU4a, 8.6(2a)SU4, 8.6(2a)SU3, 8.6(2a)SU2, 8.6(2a)SU1, 

Re: [cisco-voip] UCx 9 - email notifications

[Daniel Pagan]

Accomplish this with the Accept and Relay option for user message actions for 
VM1 and specify VM2’s SMTP address. This should keep the message available for 
VM1 while forwarding a copy to VM2. You’ll need to setup CUC with a SMTP smart 
host in order to relay messages, and will likely need to make changes to ensure 
SMTP connections are accepted from your Unity Connection server but I can’t 
provide much assistance on Office 365. Keep in mind this solution *won’t* 
provide any MWI or TUI feedback for VM1 when VM2 reads/deletes the message or 
marks it unread.

As for the DL question, two things I can think of…


1.   Configure VM1 to Accept and Relay to a SMTP address that resolves to a 
distribution list in Office 365 instead of going directly to VM2.



Or


2.   Design the call flow so that voicemail calls to VM1 are *not* routed 
to a VM1 user and greeting, but rather to a Call Handler with message delivery 
to a Distribution List. This Call Handler’s greeting sounds like VM1 (have the 
user record the greeting), but it sends all messages to a DL where the VM1 user 
account is also a member. There’s a few ways to set this up, and it’s far from 
perfect, but it’s one way to accomplish this.

Depending on the privacy requirements of VM1, you a 3rd option might be to 
configure a 2nd extension on VM2’s phone in CUCM and then add this new 
extension as an alternate extension to the CUC user account for VM1. This 
allows VM2 to dial into CUC and access VM1’s mailbox. For MWI, just add a 2nd 
MWI extension for VM1 referencing the new line you added for VM2’s IP phone. I 
know this doesn’t give a voicemail attachment to VM2 user, but I figured the 
outcome this provides might meet the requirements of the user.

Dan


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of abbas 
Wali
Sent: Wednesday, September 09, 2015 10:57 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] UCx 9 - email notifications

Hi all,
basic question

how to send email notifications (O365 is setup already) to another subscriber 
who already has got their own VM box.
so e.g.
VM1: 12345
VM2: 98765
both are setup with mailbox. VM1 when receives a VM, needs to send notification 
via email to VM2 email box with the attachment.

​also, VM1 receives VM and can send it to a group of users's email
I have tried to create a system Distribution list and add the memebers into it 
but then how to link VM1 to that DL?
thanks ​

--

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

Re: [cisco-voip] Service Provider SIP Trunks

[Daniel Pagan]

My first step would be to find out the direction of the 500 final response. I 
would run a ccsip messages debug on CUBE and recreate the issue for determining 
where the 500 final response is being generated. The User-Agent header should 
tell you what device is generating it. My second step would be to determine 
where in the call flow this 500 is being generated. The 500 is a final 
response, so it's likely going to be after the INVITE and 100 TRYING - but you 
shouldn't see a 200 OK since that would give you two final responses. Do you 
see a 180 or 183? If so then I would try to find out if there's an SDP offer or 
answer in the 1XX provisional.. perhaps the remote SBC doesn't like your offer 
or answer. Is there a Require: 100rel in the 100, 180 or 183? If so then is 
your equipment sending a PRACK?

Just a few thoughts that come to mind. Like you, I would also be skeptical of 
the provider's findings until reviewing the SIP transactions and making sure 
for myself.

Use the request URI (i.e. INVITE 
sip:dialed_num@dest-ipsip:%3cdialed_num%3e@%3cdest-ip-or-fqdn) for 
finding your call and the Call-ID header to track your two call-legs in CUBE.

Feel free to send me SIP debugs off your CUBE outside the email list and after 
recreating the issue - I can take a few minutes to review them offline.

Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Aaron 
Banks
Sent: Friday, August 28, 2015 3:35 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Service Provider SIP Trunks


I have a strange problem with SIP trunks.  Let me preface this with the service 
provider moved the SIP trunks to a different device and that's what certain 
calls stopped working.  Before this move, everything was tested and working for 
6 weeks.  Read on, someone might have had the same experience.

Post SIP trunk move, callers inside of the organization cannot call 911 or a 
mobile phone (ANY mobile phone).  When they dial the number, let's use 911 for 
example, the call rings once, the calling line ID is delivered to 911 and then 
the call goes to busy.  So 911 knows that organization called.  The same thing 
happens with mobile phones.  All other call types (local, LD, international) 
work.  If I call forward a phone from inside of the organization to a mobile 
phone and call that forwarded phone (from outside or inside), the call is 
redirected to the mobile, call is answered and then the call drops.  If I 
forward that same phone inside of the organization to an outside land line 
((either local or LD), the call is successful.

For 911 or the mobile calls that fail, the SIP trace reveals a 500 (internal 
server error), a BYE message with reason Q.850; cause=16.  The SIP call 
messages show the state of the call is DEAD.

My question is why would the number make any difference at all?  Has anyone 
ever seen this type of issue before?  The provider says it is CUCM 10.5/Voice 
GW 2901 that is rejecting the call.  I disagree.

Many thanks

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

Re: [cisco-voip] Service Provider SIP Trunks

[Daniel Pagan]

Hey Ryan! Hope you’re well ☺

Just wanted to add here that not supporting early offer should result in one of 
two things – either local ring back would be generated on the calling device 
and/or there will be no audio in scenarios where audio cut-through is required 
before the 200 final response (sometimes experienced with toll-free numbers). 
But in terms of call failure and complete disconnect, I’m unaware of any true 
requirement built into SIP for early offer or early media.

By “no requirement” I’m referring to the lack of built-in specific SIP headers 
that call for early offer or early media. The offer/answer model for SDP states 
that an SDP answer must be included in a 200 if the offer is in an INVITE, or 
must be in the ACK for the 200 if the offer is in the 200 final response. These 
types of requirements ensure that media turn-up has a way to be established 
regardless if early media is successful or early offer is supported. More on 
this in RFC 3261 section 13.2.1.

Hope this helps anyone reading.

Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Huff
Sent: Friday, August 28, 2015 3:39 PM
To: amichaelba...@hotmail.com; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Service Provider SIP Trunks


Sounds like a codec/media issue. Are you supporting early offer?

Thanks,

Ryan


 Original Message 
From: Aaron Banks amichaelba...@hotmail.commailto:amichaelba...@hotmail.com
Sent: Friday, August 28, 2015 03:35 PM
To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: [cisco-voip] Service Provider SIP Trunks

I have a strange problem with SIP trunks.  Let me preface this with the service 
provider moved the SIP trunks to a different device and that's what certain 
calls stopped working.  Before this move, everything was tested and working for 
6 weeks.  Read on, someone might have had the same experience.

Post SIP trunk move, callers inside of the organization cannot call 911 or a 
mobile phone (ANY mobile phone).  When they dial the number, let's use 911 for 
example, the call rings once, the calling line ID is delivered to 911 and then 
the call goes to busy.  So 911 knows that organization called.  The same thing 
happens with mobile phones.  All other call types (local, LD, international) 
work.  If I call forward a phone from inside of the organization to a mobile 
phone and call that forwarded phone (from outside or inside), the call is 
redirected to the mobile, call is answered and then the call drops.  If I 
forward that same phone inside of the organization to an outside land line 
((either local or LD), the call is successful.

For 911 or the mobile calls that fail, the SIP trace reveals a 500 (internal 
server error), a BYE message with reason Q.850; cause=16.  The SIP call 
messages show the state of the call is DEAD.

My question is why would the number make any difference at all?  Has anyone 
ever seen this type of issue before?  The provider says it is CUCM 10.5/Voice 
GW 2901 that is rejecting the call.  I disagree.

Many thanks

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

Re: [cisco-voip] Question about Local Route Group feature

[Daniel Pagan]

“If a device pool doesn't have anything setup for Standard Local Route Group, 
when someone from that pool calls a route pattern referencing this Route List 
will it just smoothly go to option #2 or is there some gotcha i'm not grasping?”

Yes - CUCM attempts to get information on the SLRG once the call reaches 
RouteListControl. Once it fails to find the SLRG entry, RouteListCdrc sends the 
call to members of the next RG without any delay.

Hope this helps.

Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ed 
Leatherman
Sent: Thursday, August 27, 2015 3:15 PM
To: Cisco VOIP cisco-voip@puck.nether.net
Subject: [cisco-voip] Question about Local Route Group feature

Hello!

I actually haven't had to make significant dial plan/gateway changes since 
local route group feature got introduced, starting to plan some bigger changes 
and think this might be a good tool for me to use.

Right now i'm thinking migration strategies for moving folks onto SIP trunk 
from PRI.

If I have a Route List that has:
1. Standard Local Route Group
2. Existing Route Group #1
3. Existing Route Group #2

If a device pool doesn't have anything setup for Standard Local Route Group, 
when someone from that pool calls a route pattern referencing this Route List 
will it just smoothly go to option #2 or is there some gotcha i'm not grasping?

My thoughts are to migrate folks by device pool and reuse my existing dial plan 
with new SIP trunks added using standard local route group feature and placed 
into existing Route Lists as the first option. Folks that have nothing set for 
standard local route group just flow through to the existing options.

This way I don't have as many weird transition route patterns/dial plans/etc. 
Eventually I'd get rid of the legacy route groups referencing PRI's and then 
i'd be smoothly (mostly) onto local route group paradigm, which appears to be 
the way to go anyway.


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

Re: [cisco-voip] SIP analog gateways

[Daniel Pagan]

I personally can't speak to 3rd party FXS gateways, but I've worked with 
customers in the past whose VG224s were integrated w/ CUCM via SIP trunk. The 
two caveats that immediately come to mind are applicable to a non-Cisco FXS 
gateway using SIP as well:


1)  Lack of SCCP supplementary services

http://www.cisco.com/c/en/us/td/docs/ios/voice/fxs/configuration/guide/15_1/fxs_15_1_cg_book/fxssccpsplmft.html

2)  Unable to use shared line appearances between the VG2XX and non-VG2XX 
device.

Just two things to keep in mind. I've seen this sometimes act as a deal breaker 
w/ SIP to the FXS gateway. Hope this helps in some way.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
norm.nichol...@kitchener.ca
Sent: Tuesday, August 18, 2015 7:10 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] SIP analog gateways


Anyone using a SIP FXS gateway instead of a VG224. Just trying to compare costs 
and ease of use.

Thanks



Norm Nicholson
Telecom Analyst
City of Kitchener
(519) 741-2200 x 7000


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

Re: [cisco-voip] SIP analog gateways

[Daniel Pagan]

Definitely a valid point on ECM -  it can help with a few errors detected on 
transmitted page, but consistent errors will simply cause ECM to retransmit 
again, and again, until the fax fails, redials, detects more errors and repeats 
the retransmissions, fax failure, redial, repeat again, etc.
Adding to this, you can disable ECM from a Cisco voice gateway when using fax 
relay. When using pass-through, this can’t be done in IOS and must be done on 
the fax machine itself, but fax relay has the capability to the ECM 
“advertisement” from the destination fax machine’s DIS, which is basically a 
series of tones communicating its capabilities (ECM being one of them). If this 
gets stripped from the DIS, the originating fax machine will simply think ECM 
isn’t supported and will never negotiate it when sending its DCS.

This done on the terminating gateway:

For SIP/H.323
  voice service voip
   fax-relay ecm disable

For MGCP
  no mgcp fax t38 ecm

Hope this helps.

- Dan

From: Ryan Huff [mailto:ryanh...@outlook.com]
Sent: Wednesday, August 19, 2015 10:53 AM
To: nh...@co.fresno.ca.us; Daniel Pagan dpa...@fidelus.com; 
norm.nichol...@kitchener.ca; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] SIP analog gateways


My experince is that analog faxing over SIP is sometimes a dance.

What I have found to work consistently is to disable SuperG3 and ECM on the fax 
modem and restrict the rx/tx of the modem to 14.4 Kbps.

Thanks,

Ryan


 Original Message 
From: Haas, Neal nh...@co.fresno.ca.usmailto:nh...@co.fresno.ca.us
Sent: Wednesday, August 19, 2015 10:31 AM
To: 'Daniel Pagan' 
dpa...@fidelus.commailto:dpa...@fidelus.com,'norm.nichol...@kitchener.ca' 
norm.nichol...@kitchener.camailto:norm.nichol...@kitchener.ca,'cisco-voip@puck.nether.net'
 cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] SIP analog gateways
We tried to put our faxes all on SIP, best solution was to move 200 DID’s back 
to PRI, sad day…….

Thank you,
Neal Haas


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Wednesday, August 19, 2015 5:52 AM
To: norm.nichol...@kitchener.camailto:norm.nichol...@kitchener.ca; 
cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] SIP analog gateways

I personally can’t speak to 3rd party FXS gateways, but I’ve worked with 
customers in the past whose VG224s were integrated w/ CUCM via SIP trunk. The 
two caveats that immediately come to mind are applicable to a non-Cisco FXS 
gateway using SIP as well:


1)  Lack of SCCP supplementary services

http://www.cisco.com/c/en/us/td/docs/ios/voice/fxs/configuration/guide/15_1/fxs_15_1_cg_book/fxssccpsplmft.html

2)  Unable to use shared line appearances between the VG2XX and non-VG2XX 
device.

Just two things to keep in mind. I’ve seen this sometimes act as a deal breaker 
w/ SIP to the FXS gateway. Hope this helps in some way.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
norm.nichol...@kitchener.camailto:norm.nichol...@kitchener.ca
Sent: Tuesday, August 18, 2015 7:10 PM
To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: [cisco-voip] SIP analog gateways


Anyone using a SIP FXS gateway instead of a VG224. Just trying to compare costs 
and ease of use.

Thanks



Norm Nicholson
Telecom Analyst
City of Kitchener
(519) 741-2200 x 7000


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

Re: [cisco-voip] CUCM 10.x and RightFax SR140 v10

[Daniel Pagan]

there’s no way to inject the CNG tone

Sorry - I should be more specific. What I mean to say is that there's no way to 
inject the tone from a Cisco device, but don't know of the capabilities of the 
RightFax server. 

I'm curious to know if you find an option for generating a CNG tone on RightFax.

Hope this helps.

- Dan



 On Aug 18, 2015, at 5:43 PM, Daniel Pagan dpa...@fidelus.com wrote:
 
 there’s no way to inject the CNG tone

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

Re: [cisco-voip] CUCM 10.x and RightFax SR140 v10

[Daniel Pagan]

That can be a possibility for Ed, assuming RightFax is playing the CNG. 
However, I would add that PRACK doesn't automatically grant early media. The 
only time PRACK helps with establishing early media is in a call flow with an 
outbound delayed offer INVITE and an inbound 183 provisional that contains an 
SDP offer. In that scenario, the only way to send an SDP answer to the offer 
before the 200 OK is through PRACK, but again it requires a specific flow for 
PRACK to accomplish it. I would also imagine the call would need to progress 
past the connected stage in order for the fax to be successful. Without being 
in a connected state, the OGW and TGW involved the fax call wouldn't be able 
initiate fax protocol switchover, making me think that early media wouldn't 
resolve the issue in this case. 

Perhaps SuperG3 is involved here, and the terminating fax machine is attempting 
to switch to SG3. Technically it should timeout and revert back to G3 but I've 
seen this cause issues. If the issue is with SG3 destinations, one could try 
suppressing the ANSAM using the sg3-to-g3 command in IOS. Here's how you 
quickly identify SG3 - it's an audio file from pcap off a SG3 fax machine 
connected to a VG2XX.

SuperG3 ANSAM:
https://www.dropbox.com/s/20xhtyc1qcrku4r/ANSam%20Phase%20Reversal.mp3?dl=0

That clicking you hear is the phase reversal - standard G3 doesn't contain that 
clicking. If you hear this, you can give ANSAM suppression a shot.

Finally, if anyone needs a recording of a full fax transmission to use as sort 
of a baseline, here you go:

Originating GW - Audio From PCAP:
https://www.dropbox.com/s/am0lpwsfai8nq6y/FaxCapture%20-%20OGW%20-%20DPagan.mp3?dl=0

Terminating GW - Audio From PCAP:
https://www.dropbox.com/s/j9tqahjfaxqf29r/FaxCapture%20-%20TGW%20-%20DPagan.mp3?dl=0

Open both audio files in Audacity to play both the sending and receiving fax 
machine tones for a single page fax. This was recorded while using modem 
pass-through and, when played in Audacity, you can track the entire exchange at 
your own pace (CNG to CED, DIS to DCS, etc). Note that you won't get the same 
results using any type of fax relay since PCM audio isn't being transmitted, 
but the flow remains the same.

Hope this helps.

- Dan

-Original Message-
From: NateCCIE [mailto:natec...@gmail.com] 
Sent: Tuesday, August 18, 2015 6:45 PM
To: Daniel Pagan dpa...@fidelus.com
Cc: Countryman, Edward edward.country...@presencehealth.org; 
cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CUCM 10.x and RightFax SR140 v10

I wonder if you have prack enabled if it is a SIP trunk so that early media can 
be cut through before the connect. 

Sent from my iPhone

 On Aug 18, 2015, at 3:52 PM, Daniel Pagan dpa...@fidelus.com wrote:
 
 there’s no way to inject the CNG tone
 
 Sorry - I should be more specific. What I mean to say is that there's no way 
 to inject the tone from a Cisco device, but don't know of the capabilities of 
 the RightFax server. 
 
 I'm curious to know if you find an option for generating a CNG tone on 
 RightFax.
 
 Hope this helps.
 
 - Dan
 
 
 
 On Aug 18, 2015, at 5:43 PM, Daniel Pagan dpa...@fidelus.com wrote:
 
 there’s no way to inject the CNG tone
 
 ___
 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] CUCM 10.x and RightFax SR140 v10

[Daniel Pagan]

That “pre-tone” you’re referring to is called the CNG tone, assuming you hear 
it every 3 seconds on your calling fax machine. It’s basically what tells the 
remote end “I’m a fax machine” but many devices no long wait to hear this 
before attempting to start negotiating capabilities. However, it seems like 
these few destinations you’re having issues with do in fact rely on the CNG 
tone before sending its CED and DIS.

I don’t have a ton of experience administering RightFax, but in my experience 
with FoIP on Cisco platforms, there’s no way to inject the CNG tone. Are you 
sure the RightFax server isn’t playing the CNG tone? You won’t be able to hear 
it unless you either:


1.   Call yourself from the RF server, answer, and listen… or…

2.   Pull a pcap for the RTP media streamed from the RF server.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Countryman, Edward
Sent: Tuesday, August 18, 2015 1:52 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] CUCM 10.x and RightFax SR140 v10

We’ve gone live with the new RF SR140 F0Ip environment a couple of months ago.  
For the most part, things are working great.

There are a couple of destinations however that we don’t seem to be able to 
successfully send to, even though I can send from the standalone fax machine in 
my office every time.

One difference we noted was that my standalone fax machine starts to beep 
immediately after dialing and even before the remote end answers.  The RF SR140 
doesn’t do this.  Without this beeping the remote side seems to not want to 
talk to us.

Does anyone know what this pre-tone is called and if it can be enabled in the 
RF 10.x ??


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

Re: [cisco-voip] Ldap

[Daniel Pagan]

In 8.6 and 9.x it’s five. Limit of sync agreements was increased to 20 in CUCM 
10.5.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Techguy
Sent: Thursday, August 13, 2015 1:27 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Ldap


Is there a cap on the number of ldap integrations you can have in a standard 
cucm cluster. 8.x and above.
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] RTMT question CUCM ver 8.6.2

[Daniel Pagan]

Use the timestamp from audit logs and review CCM SDI detailed traces. If set to 
detailed, there should be an entry for the DB change notification mentioning 
what was changed. It'll either give you a before  after PKID or a before  
after numerical value depending on what was modified.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of James 
Dust
Sent: Monday, August 10, 2015 12:09 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] RTMT question CUCM ver 8.6.2

Afternoon all,

I am trying to find details of a specific phone that had a change made on one 
of its shared lines, and I am doing this via the collection of audit logs on 
RTMT.

I can find the event within the logs, but it doesn't give me any detail of the 
actual device which had the change made.

Is there any way I can find this out?

Any help appreciated.

Regards

James

Consider the environment - Think before you print

The contents of this email are confidential to the intended recipient and may 
not be disclosed. Although it is believed that this email and any attachments 
are virus free, it is the responsibility of the recipient to confirm this.

You are advised that urgent, time-sensitive communications should not be sent 
by email. We hereby give you notice that a delivery receipt does not constitute 
acknowledgement or receipt by the intended recipient(s).

Details of Charles Stanley group companies and their regulators (where 
applicable), can be found at this URL 
http://www.charles-stanley.co.uk/contact-us/disclosure/
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Prompt change on unsuccessful transfer from Call handler

[Daniel Pagan]

Most if not all of the system default prompts are stored in the local 
filesystem and can’t be accessed without root permission. These prompts (two 
different files play to form that message) are two of those /PHGreet/ .wav 
files and cannot be changed. Unfortunately I’m unware of any method for 
changing this specific behavior aside from replacing the files by hand with a 
file using the same name via root - a request I worked on for a customer once…. 
Once ☺ Of course the files are overwritten after a patch or upgrade and I doubt 
TAC would assist with this again (but I can be wrong…)

Daniel

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Matthew Collins
Sent: Wednesday, August 05, 2015 8:40 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Prompt change on unsuccessful transfer from Call handler

Hi all,

CUC 10.5.1.1-7

I have a system call handler and have enabled the during greeting option of 
Allow Transfers to Numbers Not Associated with Users or Call Handlers

[cid:image001.png@01D0CF62.8CD1D1D0]

The problem we are experiencing is when the caller enters a extension number 
during the prompt that is engaged/busy and they don’t have a voicemail box the 
caller is played the prompt “You cannot be transferred to this number, check 
the number and try again”. So the end users keep trying the same number. I 
can’t seem to find out where that specific prompt is recorded to amend to a 
custom recording stating the number could be busy.

Thanks in advance



Regards

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

Re: [cisco-voip] Enable/Disable SSO Logs

[Daniel Pagan]

On occasion I’ll also review the Tomcat logs for identifying who accessed a 
specific portion of CCMAdmin, then use that information to begin digging deeper 
in other trace files. You can try collecting Tomcat logs off all nodes (because 
we don’t know which node was accessed via HTTP), and search for 
“samlSingleSignOn”. The localhost_access files collected should tell you where 
the HTTP GET request came from by source IP address and authenticated user.

Sample from a lab server:

[04/Aug/2015:10:42:41 -0700] 192.168.100.101 192.168.100.101 ccmadministrator - 
443 GET /ccmadmin/samlSingleSignOn.do HTTP/1.1 200 75654 8910

While it doesn’t give you specific detail on what change was made, it will show 
you if and when someone accessed the SSO configuration page. You can then use 
the timestamp for that localhost_access file and begin a deeper inspection in 
Audit or CLI logs. If someone made a change (and this might not apply to the 
SSO page), then you’ll see the typical Save.do POST. Again, just something 
to give you basic information for starting a more aggressive investigation.

Hope this helps.

Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Matthew Loraditch
Sent: Tuesday, August 04, 2015 12:55 PM
To: Matthew Loraditch mloradi...@heliontechnologies.com; Brian Meade 
bmead...@vt.edu
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Enable/Disable SSO Logs

Odd I’m not seeing much of anything. The Audit logs don’t appear to show me 
turning SSO back on today either… Wonder if it’s logged differently.

Matthew G. Loraditch – CCNP-Voice, CCNA-RS, CCDA
Network Engineer
Direct Voice: 443.541.1518
Facebookhttps://www.facebook.com/heliontech?ref=hl | 
Twitterhttps://twitter.com/HelionTech | 
LinkedInhttps://www.linkedin.com/company/helion-technologies?trk=top_nav_home 
| G+https://plus.google.com/+Heliontechnologies/posts

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Matthew Loraditch
Sent: Tuesday, August 4, 2015 12:22 PM
To: Brian Meade bmead...@vt.edumailto:bmead...@vt.edu
Cc: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Enable/Disable SSO Logs

Thanks! Checking both.

Matthew G. Loraditch – CCNP-Voice, CCNA-RS, CCDA
Network Engineer
Direct Voice: 443.541.1518
Facebookhttps://www.facebook.com/heliontech?ref=hl | 
Twitterhttps://twitter.com/HelionTech | 
LinkedInhttps://www.linkedin.com/company/helion-technologies?trk=top_nav_home 
| G+https://plus.google.com/+Heliontechnologies/posts

From: bmead...@gmail.commailto:bmead...@gmail.com [mailto:bmead...@gmail.com] 
On Behalf Of Brian Meade
Sent: Tuesday, August 4, 2015 12:10 PM
To: Matthew Loraditch 
mloradi...@heliontechnologies.commailto:mloradi...@heliontechnologies.com
Cc: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Enable/Disable SSO Logs

If it was SAML SSO disabled from CM Administration, you should be able to find 
it in the normal Audit Logs under activelog audit/AuditApp/* or download 
Audit Logs via RTMT.

On Tue, Aug 4, 2015 at 12:06 PM, Brian Meade 
bmead...@vt.edumailto:bmead...@vt.edu wrote:
If it was done via CLI, you can do this on the publisher:

file search activelog /platform/log/cli* utils sso disable

You'll get something like this:
/var/log/active//platform/log/cli00045.log:2015-08-04 12:00:46,842 INFO [main] 
sdMain.main - running command - [utils sso disable]

You can then do file view activelog platform/log/cli00045.log and find who 
logged in at the beginning of the file:
2015-08-04 12:00:16,918 INFO [main] sdMain.main - Startup of CLI
Getting Platform XML interface file
2015-08-04 12:00:16,949 INFO [main] sdMain.main - name = admin, privilege = 4


On Tue, Aug 4, 2015 at 11:30 AM, Matthew Loraditch 
mloradi...@heliontechnologies.commailto:mloradi...@heliontechnologies.com 
wrote:
Does anyone know what exactly to look for to see when this was done? We have 
one customer where we share admin with the client and SSO got “disabled” during 
a “power outage”.
It’d be really awesome if it said what login did this as well…

Matthew G. Loraditch – CCNP-Voice, CCNA-RS, CCDA
Network Engineer
Direct Voice: 443.541.1518tel:443.541.1518
Facebookhttps://www.facebook.com/heliontech?ref=hl | 
Twitterhttps://twitter.com/HelionTech | 
LinkedInhttps://www.linkedin.com/company/helion-technologies?trk=top_nav_home 
| G+https://plus.google.com/+Heliontechnologies/posts


___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] Nortel 81C / CS1000 SIP Trunk to CUCM 10.5.2

[Daniel Pagan]

Michael T. Voity
Network Engineer
University of Vermont
(802) 656-8112

On 7/14/2015 9:29 AM, Daniel Pagan wrote:

Is your Nortel PBX sending a FQDN in the Contact header? This is important 
because in 10.5(2) CUCM performs a SRV and A Record lookup on FQDNs contained 
in a SIP Contact header. If this lookup fails, then expect to see a CANCEL 
followed by a BYE. I encountered this a few times over the past few months and 
ended up creating a defect against it. Check out CSCuu84269. If you want, I 
wouldn't mind taking a quick look at your detailed CCM SDL traces offline and 
letting you know if you're experiencing this defect. If you are, I'll send you 
a sample LUA script to use for converting the FQDN to IP address as a 
workaround which you can use for testing and workaround purposes (... and I 
can't guarantee this will work for you).

Hope this helps.

- Dan
  -Original Message-
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Michael T. Voity
Sent: Monday, July 13, 2015 9:56 AM
To: voip puck
Subject: [cisco-voip] Nortel 81C / CS1000 SIP Trunk to CUCM 10.5.2

Hello,

Before we installed our Cisco CM 10.5.2 system everything here at the
University is fed from a Nortel Avaya 81c / CS1000 system.   The Telcom
group has a bunch of systems on it that support SIP and SIP gateways.
We setup a SIP trunk between the two systems from a guide that Avaya
provided.   It works fine like 99% of the time.

I am finding that I have to reset the SIP trunk every couple of days because it 
looks like the Nortel is busying out all the channels and it
can only pass certain traffic.   Example is that someone from Nortel
land dials a 5 digit extension that has been routed to CUCM, the line on CUCM 
rings once and then discos the call.

Looking at RTMT on the SIP traffic I can tell that the Nortel is sending
the BYE message on the trunk right when the CUCM sends the RINGING
The only way that I have found to correct this is to reset the SIP trunk from 
CUCM.

Has anyone see an issue like this and or heard of this?

Any ideas would be helpful!

-Mike

--
Michael T. Voity
Network Engineer
University of Vermont

___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] Nortel 81C / CS1000 SIP Trunk to CUCM 10.5.2

[Daniel Pagan]

Is your Nortel PBX sending a FQDN in the Contact header? This is important 
because in 10.5(2) CUCM performs a SRV and A Record lookup on FQDNs contained 
in a SIP Contact header. If this lookup fails, then expect to see a CANCEL 
followed by a BYE. I encountered this a few times over the past few months and 
ended up creating a defect against it. Check out CSCuu84269. If you want, I 
wouldn't mind taking a quick look at your detailed CCM SDL traces offline and 
letting you know if you're experiencing this defect. If you are, I'll send you 
a sample LUA script to use for converting the FQDN to IP address as a 
workaround which you can use for testing and workaround purposes (... and I 
can't guarantee this will work for you).

Hope this helps.

- Dan
 
-Original Message-
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Michael T. Voity
Sent: Monday, July 13, 2015 9:56 AM
To: voip puck
Subject: [cisco-voip] Nortel 81C / CS1000 SIP Trunk to CUCM 10.5.2

Hello,

Before we installed our Cisco CM 10.5.2 system everything here at the 
University is fed from a Nortel Avaya 81c / CS1000 system.   The Telcom 
group has a bunch of systems on it that support SIP and SIP gateways.   
We setup a SIP trunk between the two systems from a guide that Avaya 
provided.   It works fine like 99% of the time.

I am finding that I have to reset the SIP trunk every couple of days because it 
looks like the Nortel is busying out all the channels and it 
can only pass certain traffic.   Example is that someone from Nortel 
land dials a 5 digit extension that has been routed to CUCM, the line on CUCM 
rings once and then discos the call.

Looking at RTMT on the SIP traffic I can tell that the Nortel is sending 
the BYE message on the trunk right when the CUCM sends the RINGING   
The only way that I have found to correct this is to reset the SIP trunk from 
CUCM.

Has anyone see an issue like this and or heard of this?

Any ideas would be helpful!

-Mike

--
Michael T. Voity
Network Engineer
University of Vermont

___
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] Nortel 81C / CS1000 SIP Trunk to CUCM 10.5.2

[Daniel Pagan]

Sounds good. 

I should mention the FQDN in the Contact header is completely independent from 
your SIP trunk destination settings, so there's a high probability this defect 
was being triggered, especially if you have no issues post upgrade and patch. 
I've seen customers using IP addresses on their trunks and their PBX will still 
include an FQDN in the SIP Contact header. A working integration becoming a 
broken integration upon upgrading from pre 10.5(2) to 10.5(2) with no changes 
to the SIP trunk.

Also... since we're on this topic... There's a related defect where CUCM strips 
the maddr= field if it's found in a SIP Contact header as well, leading to 
immediate call failure. Found this issue in a CUCM 10.5(2)ES integration with a 
Nortel environment. This would be CSCus47768. The defect mentions IPv6 but IPv4 
applies to this as well. You also might not see a DNS lookup in SDL traces, but 
rather CUCM will simply fail to include the maddr= field found in the Contact 
header into the request URI. Example:

CUCMNortel
INVITE--
100 
180 Require 100rel --  (Contact header contains maddr= field)
PRACK --   (Request URI doesn't contain the maddr= field)
500    (Destination Unreachable)
CANCEL --
200 

This also applies to SIP trunks where the destination is an IP address.

Hope this helps.

- Dan

-Original Message-
From: Michael T. Voity [mailto:mvo...@uvm.edu] 
Sent: Tuesday, July 14, 2015 9:49 AM
To: Daniel Pagan; voip puck
Subject: Re: [cisco-voip] Nortel 81C / CS1000 SIP Trunk to CUCM 10.5.2

Hi Dan,


Last night I migrated to 10.5.2.SU2 and then this morning applied the 
ciscocm.FQDNwithDNS-v1.0.k3.cop.sgn patch.

On both CUCM and CS1000 we are using straight IP address and not a FQDN 
for comm.Since I did this patch's I am going to let things bake and 
see if the error(s) returns.

I will keep my eyes on RTMT too see how things behave.

-Mike





Michael T. Voity
Network Engineer
University of Vermont
(802) 656-8112

On 7/14/2015 9:29 AM, Daniel Pagan wrote:
 Is your Nortel PBX sending a FQDN in the Contact header? This is important 
 because in 10.5(2) CUCM performs a SRV and A Record lookup on FQDNs contained 
 in a SIP Contact header. If this lookup fails, then expect to see a CANCEL 
 followed by a BYE. I encountered this a few times over the past few months 
 and ended up creating a defect against it. Check out CSCuu84269. If you want, 
 I wouldn't mind taking a quick look at your detailed CCM SDL traces offline 
 and letting you know if you're experiencing this defect. If you are, I'll 
 send you a sample LUA script to use for converting the FQDN to IP address as 
 a workaround which you can use for testing and workaround purposes (... and I 
 can't guarantee this will work for you).

 Hope this helps.

 - Dan
   
 -Original Message-
 From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf 
 Of Michael T. Voity
 Sent: Monday, July 13, 2015 9:56 AM
 To: voip puck
 Subject: [cisco-voip] Nortel 81C / CS1000 SIP Trunk to CUCM 10.5.2

 Hello,

 Before we installed our Cisco CM 10.5.2 system everything here at the
 University is fed from a Nortel Avaya 81c / CS1000 system.   The Telcom
 group has a bunch of systems on it that support SIP and SIP gateways.
 We setup a SIP trunk between the two systems from a guide that Avaya
 provided.   It works fine like 99% of the time.

 I am finding that I have to reset the SIP trunk every couple of days because 
 it looks like the Nortel is busying out all the channels and it
 can only pass certain traffic.   Example is that someone from Nortel
 land dials a 5 digit extension that has been routed to CUCM, the line on CUCM 
 rings once and then discos the call.

 Looking at RTMT on the SIP traffic I can tell that the Nortel is 
 sending the BYE message on the trunk right when the CUCM sends the RINGING
 The only way that I have found to correct this is to reset the SIP trunk from 
 CUCM.

 Has anyone see an issue like this and or heard of this?

 Any ideas would be helpful!

 -Mike

 --
 Michael T. Voity
 Network Engineer
 University of Vermont

 ___
 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] LDAP Authentication when CUCM publisher is down.

[Daniel Pagan]

LDAP authentication is used by Tomcat and isn’t just restricted to the 
Publisher server - Subscriber nodes handle this as well. DirSync is specific to 
synchronization of LDAP attributes and only runs on the Pub, so synchronization 
would definitely be affected if the Publisher is offline. I suggest to check 
out the Tomcat Security logs off CUCM for more info on user authentication 
against LDAP and your source of failure.

So to answer your question, LDAP authentication should still work when the 
Publisher is offline.

For the UCCX agent concern, authentication of agents occur over AXL to CUCM, so 
if the AXL server is the Publisher, and that’s offline or experiencing issue w/ 
Tomcat during an authentication attempt by the UCCX agent, then I would imagine 
seeing a failure. AXL and Tomcat Security logs off the UCM side should shed 
some light on that problem

As for SSO, I checked w/ my teammate and, in his experience, SSO can be handled 
by Subscriber nodes assuming the metadata was imported to those servers - 
authentication occurs against the IdP and not CUCM so this seems logical to me 
as well.

Hope this helps.

- Dan


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Lelio 
Fulgenzi
Sent: Monday, July 06, 2015 9:16 AM
To: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] LDAP Authentication when CUCM publisher is down.


This has been our experience as well. Glad you started this thread. It's seems 
like a huge single point of failure to me for such an integral part of the 
process. I suspect hunt group login would also be affected.

Sent from my iPhone

On Jul 6, 2015, at 5:02 AM, Matthew Collins 
mcoll...@block.co.ukmailto:mcoll...@block.co.uk wrote:
Hi All,

CUCM 10.5

Just trying to get some conformation, When LDAP Synchronization and 
authentication is enabled this is performed by the DirSync process that only 
runs on the CUCM Publisher. So If we lose the CUCM Publisher for whatever 
reason it would seem that the Authentication also fails due to the single point 
of failure of DirSync. Should LDAP authentication still work if the CUCM 
Publisher is still down.

So for LDAP users this would stop them signing in to Jabber clients and UCCX 
agents who are ldap’ed synced logging into the finesse webpages. Does anyone 
know is SSO is resilient on the CUCM publisher or would SSO still work in a 
Publisher outage.

Regards

Matthew Collins

___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] LDAP Authentication when CUCM publisher is down.

[Daniel Pagan]

FYI - Just ran a quick test in a lab environment - LDAP user authentication 
against a Subscriber node while the Publisher’s network adapter is 
disconnected. Works as expected. Also running CUCM 10.5 but this (DirSync 
Synchronization vs. Tomcat Security authentication) also applies going back to 
7.x as far as I recall.

Hope this helps

- Dan


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Monday, July 06, 2015 9:45 AM
To: Lelio Fulgenzi; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] LDAP Authentication when CUCM publisher is down.

LDAP authentication is used by Tomcat and isn’t just restricted to the 
Publisher server - Subscriber nodes handle this as well. DirSync is specific to 
synchronization of LDAP attributes and only runs on the Pub, so synchronization 
would definitely be affected if the Publisher is offline. I suggest to check 
out the Tomcat Security logs off CUCM for more info on user authentication 
against LDAP and your source of failure.

So to answer your question, LDAP authentication should still work when the 
Publisher is offline.

For the UCCX agent concern, authentication of agents occur over AXL to CUCM, so 
if the AXL server is the Publisher, and that’s offline or experiencing issue w/ 
Tomcat during an authentication attempt by the UCCX agent, then I would imagine 
seeing a failure. AXL and Tomcat Security logs off the UCM side should shed 
some light on that problem

As for SSO, I checked w/ my teammate and, in his experience, SSO can be handled 
by Subscriber nodes assuming the metadata was imported to those servers - 
authentication occurs against the IdP and not CUCM so this seems logical to me 
as well.

Hope this helps.

- Dan


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Lelio 
Fulgenzi
Sent: Monday, July 06, 2015 9:16 AM
To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] LDAP Authentication when CUCM publisher is down.


This has been our experience as well. Glad you started this thread. It's seems 
like a huge single point of failure to me for such an integral part of the 
process. I suspect hunt group login would also be affected.

Sent from my iPhone

On Jul 6, 2015, at 5:02 AM, Matthew Collins 
mcoll...@block.co.ukmailto:mcoll...@block.co.uk wrote:
Hi All,

CUCM 10.5

Just trying to get some conformation, When LDAP Synchronization and 
authentication is enabled this is performed by the DirSync process that only 
runs on the CUCM Publisher. So If we lose the CUCM Publisher for whatever 
reason it would seem that the Authentication also fails due to the single point 
of failure of DirSync. Should LDAP authentication still work if the CUCM 
Publisher is still down.

So for LDAP users this would stop them signing in to Jabber clients and UCCX 
agents who are ldap’ed synced logging into the finesse webpages. Does anyone 
know is SSO is resilient on the CUCM publisher or would SSO still work in a 
Publisher outage.

Regards

Matthew Collins

___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] Strange Number

[Daniel Pagan]

I know it's not an exact match but it's very similar to a dialing forest dump 
procedure off a SCCP handset:

https://supportforums.cisco.com/document/97751/how-dump-ccm-memoryimdb-diagnostic-information-traces

I personally haven't used the **##**32 you mentioned though.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Pawlowski, Adam
Sent: Thursday, June 25, 2015 11:44 AM
To: 'cisco-voip@puck.nether.net'
Subject: [cisco-voip] Strange Number

Does anyone here know what **##**32 is supposed to be? It seems I can dial 
this but it is not actually ... anything ? It just clears out and goes away.

This is from SCCP sets anyways to UCM.

Adam

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

Re: [cisco-voip] Cisco live

[Daniel Pagan]

I'm also attending.

Anthony: Nice! I'll be sure to do my best to stop by and check it out.

Stephen: Looking forward to checking out the applications on demo.

- Dan

Sent from my mobile device.

On Jun 8, 2015, at 12:10 PM, Anthony Holloway 
avholloway+cisco-v...@gmail.commailto:avholloway+cisco-v...@gmail.com wrote:

I am. Come see me compete in Engineering Deathmatch on Wednesday at 11:00am in 
the 2Ring booth of World of Solutions.
On Mon, Jun 8, 2015 at 11:12 AM Heim, Dennis 
dennis.h...@wwt.commailto:dennis.h...@wwt.com wrote:
who all is in San Diego for Cisco Live?

Sent from my iPhone
___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] CUCM - MOH Silence

[Daniel Pagan]

Do you see a StartMediaTransmission being sent to your MOH server? Look for 
MohDControl for SCCP signals to the MOH server - one process instance is 
created per MOH server. But first, before sending the StartMediaTransmission 
signal to MohDControl, CCM will first attempt to get media information from the 
remote end, and I would first take a look at this call-leg and (at a high 
level) make sure the OLC/OLCack is exchanged with no issues. What signaling 
protocol is being used on the opposite call-leg? If that exchange fails then 
you won’t see a StartMediaTransmission to MohDControl. If you do see a 
StartMediaTransmission to MohDControl then is it ACK’ing that signal?

Just some quick thoughts. If you want, and if you can, feel free to forward a 
collection of SDI/SDL traces from all nodes covering this failure. I’ll take a 
few minutes to see what I can find.

Hope this helps.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Anthony Holloway
Sent: Friday, May 15, 2015 9:57 AM
To: Ryan Huff; Roger Wiklund
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] CUCM - MOH Silence

Thanks Ryan.  The region relationships is fine as the MOH is in a special MOH 
region which is 64kbps to every other region, including the one in question.  
All traces indicate that the media caps are a match at g711ulaw.
On Thu, May 14, 2015 at 6:45 PM Ryan Huff 
ryanh...@outlook.commailto:ryanh...@outlook.com wrote:
Another common source of this is codec mismatch.

So if your ingress region isn't related to the region that MoH is in with the 
G.711/G.722 bandwidth profile, you'll get this issue. If you get tone-on-hold 
then it is usally partition/css/tftp related but dead silence is usually codec 
related.

Thanks,

-r





Date: Thu, 14 May 2015 23:13:40 +0200
From: roger.wikl...@gmail.commailto:roger.wikl...@gmail.com
To: avholloway+cisco-v...@gmail.commailto:avholloway%2bcisco-v...@gmail.com
Subject: Re: [cisco-voip] CUCM - MOH Silence
CC: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net

Not sure about the trace but I would start with basic config 
check/troubleshooting.

Are you running unicast or multicast MOH?
Is the IP Voice Media Streaming App running on all nodes? (If yes try 
restarting the service)
Is the MOH resource in the MRG/MRGL?
Are all devices using that MRGL?
Is MOH selected for your codec? (System, Service Parameters, server, IP Voice 
Media Streaming App)
Have you uploaded a new MOH file? If so try with the default.

I would start there, or try basic ip-phone to ip-phone calls, exclude voice 
gateways etc and work my way forward.

On Thu, May 14, 2015 at 10:50 PM, Anthony Holloway 
avholloway+cisco-v...@gmail.commailto:avholloway+cisco-v...@gmail.com wrote:
All,

So, I'm a bit rusty this year on trace analysis and I need a second opinion.

From the below screenshot snippets out of TranslatorX, it would appear as 
though the MOH_3 gets selected, then an AuConnectRequest gets issued, and not 
but a few seconds later, I see an AuDisconnectRequest.  The caller experience 
is simply silence on the line while the call is connected (or not connected) to 
MOH.

If there was another key piece of information I could look for to help myself 
understand why it disconnected so quickly, what should I look for?  Thanks.

[Inline image 1]

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


___ cisco-voip mailing list 
cisco-voip@puck.nether.netmailto: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] CUCM - MOH Silence

[Daniel Pagan]

Also… IPVMSapp traces might help if the issue is related to the MOH server’s 
inability to allocate the proper audio source file from the local filesystem. 
Not common in my experience but can happen. If set to detailed, you should see 
the StartMediaTransmission and StartMediaTransmissionACK being logged in the 
trace in addition to its ability or inability to allocate and play the selected 
MOH audio source file.

For example:

CMOHMgr::PlayStream PlayStream: 
asID=1,codec=0,file=/usr/local/cm/moh/ringback.ulaw.wav,userBuffer=4000,repeat=1

CMohPlayWav::Play (9,2,0) Play () I(0) (/usr/local/cm/moh/ringback.ulaw.wav)

Of course CUCM won’t get to this point if the issue resides at the signaling 
protocol and media setup aspect of the call. Regardless, hope this helps.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Friday, May 15, 2015 12:50 PM
To: Anthony Holloway
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CUCM - MOH Silence

Do you see a StartMediaTransmission being sent to your MOH server? Look for 
MohDControl for SCCP signals to the MOH server - one process instance is 
created per MOH server. But first, before sending the StartMediaTransmission 
signal to MohDControl, CCM will first attempt to get media information from the 
remote end, and I would first take a look at this call-leg and (at a high 
level) make sure the OLC/OLCack is exchanged with no issues. What signaling 
protocol is being used on the opposite call-leg? If that exchange fails then 
you won’t see a StartMediaTransmission to MohDControl. If you do see a 
StartMediaTransmission to MohDControl then is it ACK’ing that signal?

Just some quick thoughts. If you want, and if you can, feel free to forward a 
collection of SDI/SDL traces from all nodes covering this failure. I’ll take a 
few minutes to see what I can find.

Hope this helps.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Anthony Holloway
Sent: Friday, May 15, 2015 9:57 AM
To: Ryan Huff; Roger Wiklund
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] CUCM - MOH Silence

Thanks Ryan.  The region relationships is fine as the MOH is in a special MOH 
region which is 64kbps to every other region, including the one in question.  
All traces indicate that the media caps are a match at g711ulaw.
On Thu, May 14, 2015 at 6:45 PM Ryan Huff 
ryanh...@outlook.commailto:ryanh...@outlook.com wrote:
Another common source of this is codec mismatch.

So if your ingress region isn't related to the region that MoH is in with the 
G.711/G.722 bandwidth profile, you'll get this issue. If you get tone-on-hold 
then it is usally partition/css/tftp related but dead silence is usually codec 
related.

Thanks,

-r





Date: Thu, 14 May 2015 23:13:40 +0200
From: roger.wikl...@gmail.commailto:roger.wikl...@gmail.com
To: avholloway+cisco-v...@gmail.commailto:avholloway%2bcisco-v...@gmail.com
Subject: Re: [cisco-voip] CUCM - MOH Silence
CC: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net

Not sure about the trace but I would start with basic config 
check/troubleshooting.

Are you running unicast or multicast MOH?
Is the IP Voice Media Streaming App running on all nodes? (If yes try 
restarting the service)
Is the MOH resource in the MRG/MRGL?
Are all devices using that MRGL?
Is MOH selected for your codec? (System, Service Parameters, server, IP Voice 
Media Streaming App)
Have you uploaded a new MOH file? If so try with the default.

I would start there, or try basic ip-phone to ip-phone calls, exclude voice 
gateways etc and work my way forward.

On Thu, May 14, 2015 at 10:50 PM, Anthony Holloway 
avholloway+cisco-v...@gmail.commailto:avholloway+cisco-v...@gmail.com wrote:
All,

So, I'm a bit rusty this year on trace analysis and I need a second opinion.

From the below screenshot snippets out of TranslatorX, it would appear as 
though the MOH_3 gets selected, then an AuConnectRequest gets issued, and not 
but a few seconds later, I see an AuDisconnectRequest.  The caller experience 
is simply silence on the line while the call is connected (or not connected) to 
MOH.

If there was another key piece of information I could look for to help myself 
understand why it disconnected so quickly, what should I look for?  Thanks.

[Inline image 1]

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


___ cisco-voip mailing list 
cisco-voip@puck.nether.netmailto: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] 10.5.2 No Call Park Numbers Available

[Daniel Pagan]

Don't think it does but rather the other way around. In this scenario, the 
called phone pressing park is going to need CSS access to a call park range 
sitting on the node where the gateway is registered, but I don't think the 
gateway CSS gets used to allocate that park DN. That's assuming clusterwide 
call park isn't enabled.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Jason 
Aarons (AM)
Sent: Saturday, April 11, 2015 2:04 PM
To: cisco-voip (cisco-voip@puck.nether.net)
Subject: [cisco-voip] 10.5.2 No Call Park Numbers Available

Inbound call I'm seeing No Call Park Number available on phone.

Doesn't the Gateway CSS need to include the Call Park Number partition?I 
see the phone's CSS includes the Call Park Number partition.

http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-communications-manager-version-70/112043-ucm-callpark-00.html
This guide discusses the Phone CSS but not a gateway CSS.

-jason




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

Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

[Daniel Pagan]

I’m digging up an old thread here (perhaps because of tender pain points) but 
the point you made about multi-site is spot on, Dennis… especially if the 
remote location’s connectivity to the PCD’s site is less than ideal. In this 
type of scenario, one can encounter issues with PCD where a migration task 
incorrectly reports failure on the installation step for a migration due to 
delays in the CUCM installation and PCDs built-in timers (e.g. a 60m wait time 
before determining a migrated host is unreachable).

When granular control is needed in a large cluster spanning multiple locations, 
PCD starts to show its limitations but I’m hoping additional features are added 
that focus on how PCD recovers from certain failures when multiple nodes are 
grouped within individual install/migrate steps.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Heim, 
Dennis
Sent: Monday, March 30, 2015 9:16 AM
To: Matthew Collins; Haas, Neal; 'Andrew Grech'; Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

PCD is a great tool for single-site installs or upgrades in a lab environment. 
Biggest limitation of PCD when multisites are involved, since it pushes all 
ISOs from the PCD server. Maybe an ability to leverage ISOs on VMWare 
datastores instead of from the PCD server.

Dennis Heim | Emerging Technology Architect (Collaboration)
World Wide Technology, Inc. | +1 314-212-1814
[twitter]https://twitter.com/CollabSensei
[chat]xmpp:dennis.h...@wwt.com[Phone]tel:+13142121814[video]sip:dennis.h...@wwt.com
Innovation happens on project squared -- 
http://www.projectsquared.comhttp://www.projectsquared.com/

Click here to join me in my Collaboration Meeting 
Roomhttps://wwt.webex.com/meet/dennis.heim



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Matthew Collins
Sent: Monday, March 30, 2015 6:08 AM
To: Haas, Neal; 'Andrew Grech'; Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

Just a note on this.

I have just completed a direct Hardware 8.5 to VM 10.5 with network changes 
using Prime collaboration deployment. No Cop files need to be installed, No 
jump upgrades, No restoring from backup. Really was a simple process.

If you haven’t used PCD I would strongly suggest taking a look next time you 
upgrade or install a new build.

Regards

Matthew Collins


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Haas, 
Neal
Sent: 27 March 2015 14:41
To: 'Andrew Grech'; Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

10.5 is VM only, 8.6.1 usually was MCS hardware.

To upgrade you will need to 8.6.1 upgrade to 9.1 on MCS. Then 9.1 MCS to VM, 
the upgrade 9.1 to 10.5(2)SU1.


Neal Haas

From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]mailto:[mailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of Andrew Grech
Sent: Friday, March 27, 2015 7:30 AM
To: Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5


Supported vs the system will upgrade are two different things.
On 27/03/2015 1:51 AM, Nick 
csv...@googlemail.commailto:csv...@googlemail.com wrote:
Hi All

Just checking through documentation for CUCM 10.5 for an upgrade, the 
compatibility guide states that a direct upgrade is from 8.6.1 onwards as shown 
below.

Upgrade Paths for Cisco Unified Communications Manager Release 10.5(2)SU1

[http://www.cisco.com/c/dam/en/us/td/i/templates/note.gif]
Note



If your release is not listed in the following table, find the upgrade path 
from your current release to a listed release in Cisco Unified Communications 
Manager Software Compatibility Matrix for Release 9.X and Earlier at 
http:/​/​www.cisco.com/​en/​US/​docs/​voice_ip_comm/​cucm/​compat/​ccmcompmatr1.pdfhttp://www.cisco.com/en/US/docs/voice_ip_comm/cucm/compat/ccmcompmatr1.pdf.




Table 15 Export Restricted Supported Cisco Unified Communications Manager 
Upgrades for Release 10.5(2)SU1


10.5(2)SU1


10.5.2.11900-3


Active


February 24, 2015


Direct Upgrade:

10.5(2), 10.5(1)SU1a, 10.5(1)SU1, 10.5(1), 10.0(1)SU2, 10.0(1)SU1, 10.0(1), 
9.1(2)SU2a, 9.1(2)SU2, 9.1(2)SU1, 9.1(2), 9.1(1a), 9.1(1), 9.0(1),

8.6(2a)SU5, 8.6(2a)SU4a, 8.6(2a)SU4, 8.6(2a)SU3, 8.6(2a)SU2, 8.6(2a)SU1, 
8.6(2a),

8.6(2), 8.6(1a), 8.6(1)


Supported: (Consult the Cisco Unified Communications Manager Upgrade Guide for 
details)

8.5.(1)SU7, 8.5.(1)SU6, 8.5(1)SU5, 8.5(1)SU4, 8.5(1)SU3, 8.5(1)SU2,

8.5(1)SU1, 8.5(1), 8.0(3a)SU3, 8.0(3a)SU2, 8.0(3a)SU1, 8.0(3a),

8.0(3), 8.0(2c)SU1, 8.0(2c), 8.0(2b), 8.0(2a), 8.0(2), 8.0(1),

7.1(5b)SU6(restricted), 7.1(5b)SU5(restricted), 7.1(5b)SU4(restricted),

7.1(5b)SU3(restricted), 7.1(5b)SU2(restricted), 7.1(5b)(restricted),

7.1(5a)(restricted), 7.1(5)SU1a(restricted), 7.1(5)SU1(restricted),

7.1(5)(restricted), 7.1(3b)SU2, 7.1(3b)SU1, 7.1(3b), 7.1(3a)SU1a,

7.1(3a)SU1, 

Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

[Daniel Pagan]

Same. Check out the UCMap logs – lots of useful information on what PCD is 
doing behind the scenes in these logs. You’ll find them stored under the 
/tomcat/logs/ucmap/ directory via CLI. I’ve been able to gather lots of 
detailed info on the steps being taken for migration tasks. Combine that with a 
WinSCP session into PCD (browse through /export sub directories…) and a person 
can really get more detailed information than what’s offered in documentation.

- Dan

From: Jason Aarons (AM) [mailto:jason.aar...@dimensiondata.com]
Sent: Saturday, April 11, 2015 11:49 AM
To: Daniel Pagan; Heim, Dennis; Matthew Collins; Haas, Neal; 'Andrew Grech'; 
Nick
Cc: Cisco VoIP Group
Subject: RE: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

I just want to see what is going on.  I like having a window knowing exactly 
what it’s doing under the covers.  Sort of like Java.  In Java you can pull up 
the console if you really want to know.

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Saturday, April 11, 2015 11:44 AM
To: Heim, Dennis; Matthew Collins; Haas, Neal; 'Andrew Grech'; Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5


I’m digging up an old thread here (perhaps because of tender pain points) but 
the point you made about multi-site is spot on, Dennis… especially if the 
remote location’s connectivity to the PCD’s site is less than ideal. In this 
type of scenario, one can encounter issues with PCD where a migration task 
incorrectly reports failure on the installation step for a migration due to 
delays in the CUCM installation and PCDs built-in timers (e.g. a 60m wait time 
before determining a migrated host is unreachable).

When granular control is needed in a large cluster spanning multiple locations, 
PCD starts to show its limitations but I’m hoping additional features are added 
that focus on how PCD recovers from certain failures when multiple nodes are 
grouped within individual install/migrate steps.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Heim, 
Dennis
Sent: Monday, March 30, 2015 9:16 AM
To: Matthew Collins; Haas, Neal; 'Andrew Grech'; Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

PCD is a great tool for single-site installs or upgrades in a lab environment. 
Biggest limitation of PCD when multisites are involved, since it pushes all 
ISOs from the PCD server. Maybe an ability to leverage ISOs on VMWare 
datastores instead of from the PCD server.

Dennis Heim | Emerging Technology Architect (Collaboration)
World Wide Technology, Inc. | +1 314-212-1814
[twitter]https://twitter.com/CollabSensei
[chat]xmpp:dennis.h...@wwt.com[Phone]tel:+13142121814[video]sip:dennis.h...@wwt.com
Innovation happens on project squared -- 
http://www.projectsquared.comhttp://www.projectsquared.com/

Click here to join me in my Collaboration Meeting 
Roomhttps://wwt.webex.com/meet/dennis.heim



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Matthew Collins
Sent: Monday, March 30, 2015 6:08 AM
To: Haas, Neal; 'Andrew Grech'; Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

Just a note on this.

I have just completed a direct Hardware 8.5 to VM 10.5 with network changes 
using Prime collaboration deployment. No Cop files need to be installed, No 
jump upgrades, No restoring from backup. Really was a simple process.

If you haven’t used PCD I would strongly suggest taking a look next time you 
upgrade or install a new build.

Regards

Matthew Collins


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Haas, 
Neal
Sent: 27 March 2015 14:41
To: 'Andrew Grech'; Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

10.5 is VM only, 8.6.1 usually was MCS hardware.

To upgrade you will need to 8.6.1 upgrade to 9.1 on MCS. Then 9.1 MCS to VM, 
the upgrade 9.1 to 10.5(2)SU1.


Neal Haas

From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.net]mailto:[mailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of Andrew Grech
Sent: Friday, March 27, 2015 7:30 AM
To: Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5


Supported vs the system will upgrade are two different things.
On 27/03/2015 1:51 AM, Nick 
csv...@googlemail.commailto:csv...@googlemail.com wrote:
Hi All

Just checking through documentation for CUCM 10.5 for an upgrade, the 
compatibility guide states that a direct upgrade is from 8.6.1 onwards as shown 
below.

Upgrade Paths for Cisco Unified Communications Manager Release 10.5(2)SU1

[http://www.cisco.com/c/dam/en/us/td/i/templates/note.gif]
Note



If your release is not listed in the following table, find the upgrade path 
from your current release to a listed release in Cisco Unified Communications 
Manager Software Compatibility Matrix for Release 9.X and Earlier at 
http

Re: [cisco-voip] Temp Fail since upgrade

[Daniel Pagan]

Adding to Ryan’s suggestion re: ACKs - I took a snip of some internal 
documentation I wrote re: MGCP debugs that might help. The MGCP transaction ID, 
in a CCM SDL trace or MGCP packet debug output, would look similar to this: 
http://i.imgur.com/O1YGnUO.png. Just showing the transaction ID matching 
between the MGCP command and 200 response. The observed event and Line package 
/hd (off-hook) highlighted can be ignored.

It might also be helpful to debug MGCP packets on the voice router… just make 
sure to disable console logging before leaving something like that running and 
increase the buffer size so you capture a failure. Seeing a missing 200 MGCP 
response in SDL traces doesn’t mean the router didn’t send one, and same the 
other way around where seeing an MGCP command sent from CUCM doesn’t mean it 
arrived at the router. In any case MGCP debugs off the router would come in 
handy in tandem with CCM traces.

Hope this helps.

- Dan


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Ratliff (rratliff)
Sent: Monday, April 06, 2015 10:37 AM
To: Jason Aarons (AM)
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] Temp Fail since upgrade

The first place to look is MGCP packets being lost.  Search for “Retry” in the 
ccm traces similar to:
CCM|MGCPHandler TransId: 1476004 Timeout. Retry#1

That example is from a case in 2008 so what you see may not look exactly the 
same.  This type of message is an indicator that CCM is resending an MGCP 
message that wasn’t Ack’d by the gateway.  After 3 or so of those CCM will 
unregister the gateway and any phones talking to it will get Temp Fail.

Aside from lost messages it could be a RSIP or something that is gateway 
initiated causing the reset.

-Ryan

On Apr 5, 2015, at 10:15 AM, Jason Aarons (AM) 
jason.aar...@dimensiondata.commailto:jason.aar...@dimensiondata.com wrote:

Nothing has changed with MGCP for a long time…Cisco just doesn’t test older IOS.

Pull normal debugs and traces, RTMT alerts, etc.

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Kevin 
Przybylowski
Sent: Monday, March 30, 2015 5:10 PM
To: Lisa Notarianni; Ryan Huff; 
cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Temp Fail since upgrade


Are the mgcp gateways on a supported IOS for 10.5?

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Lisa 
Notarianni
Sent: Monday, March 30, 2015 5:02 PM
To: Ryan Huff; cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Temp Fail since upgrade

2 PRIs one each Communication Media Module– MGCP gateways. 2 Call Managers set 
up as redundant.

Cisco TAC looked at RTMT  with me today.  They want us to set up packet 
captures and try to duplicate the problem tomorrow.  I am just wondering if 
this is an upgrade issue that anyone else may be experiencing since we had no 
problems before the upgrade.



From: Ryan Huff [mailto:ryanh...@outlook.com]
Sent: Monday, March 30, 2015 4:52 PM
To: Lisa Notarianni; 
cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Temp Fail since upgrade

Lisa,
SIP or TDM/PRI?
Have you gandered into RTMT and taken a look at any active / recent alerts?
Thanks,
Ryan


 Original Message 
From: Lisa Notarianni 
lisa.notaria...@scranton.edumailto:lisa.notaria...@scranton.edu
Sent: Monday, March 30, 2015 04:48 PM
To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: [cisco-voip] Temp Fail since upgrade
A few weeks ago we upgraded Call Manager and Unity Connection from 8.6.2 to 
10.5.1.

We have experienced 2 intermittent outbound calling issues:


1.   “Temp Fail” shows on phone display and only option on phone button is 
“End Call”

2.   Outbound callers dial a number and hear nothing but notice the phone 
display says “Connected”.  Caller cannot hear anything.  Person they called 
cannot hear anything.
***These issues are only intermittent.***

We had no issues before the upgrade.

Is anyone experiencing the similar issues?

Thank you in advance.





itevomcid
___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] Temp Fail since upgrade

[Daniel Pagan]

But to answer your specific question, I haven't seen this issue being directly 
related to a 10.5 upgrade.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Tuesday, March 31, 2015 9:43 AM
To: Adam Frankel (afrankel); Lisa Notarianni; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Temp Fail since upgrade

Adding to Adams email...  During an active call, when the remote endpoint 
unregisters with UCM, the endpoint still registered will display Temp Fail. 
Example would be if you're on an active call and the remote endpoint is an MGCP 
controlled PRI - that PRI endpoint unregisters with CUCM - your phone will 
display Temp Fail.

My first step would be reviewing SDL traces. Use WinGrep and search for 
'temporary failure' - this should be in a DisplayPromptStatus SCCP message to 
the IP phone (assuming you're using SCCP endpoints). Use that timestamp to 
search for unregistered endpoints or SDL OOS events as Adam mentioned. Using 
the TCP handle of the phone gathered from the DisplayPromptStatus, you can 
backtrack a bit and locate the StartMediaTransmission signal to the phone - 
this will give you the IP address of the remote device - it might help with 
your troubleshooting depending on the actual root cause. There's also CDR 
records if you need the remote endpoint name and address.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Adam 
Frankel (afrankel)
Sent: Monday, March 30, 2015 7:21 PM
To: Lisa Notarianni; 
cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Temp Fail since upgrade

Do you have any SDL Links going out of services?  Are you clustering over a WAN?

Temp Fail could be the result of two devices registered to different nodes on 
an active call when the SDL Link (tcp 8002) between those nodes goes down.

file view activelog syslog/CiscoSyslog

HTH,
-
Adam

From: Lisa Notarianni 
lisa.notaria...@scranton.edumailto:lisa.notaria...@scranton.edu
Date: Monday, March 30, 2015 at 4:48 PM
To: Cisco List cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: [cisco-voip] Temp Fail since upgrade

A few weeks ago we upgraded Call Manager and Unity Connection from 8.6.2 to 
10.5.1.

We have experienced 2 intermittent outbound calling issues:


1.  Temp Fail shows on phone display and only option on phone button is 
End Call

2.  Outbound callers dial a number and hear nothing but notice the phone 
display says Connected.  Caller cannot hear anything.  Person they called 
cannot hear anything.
***These issues are only intermittent.***

We had no issues before the upgrade.

Is anyone experiencing the similar issues?

Thank you in advance.


[LNsignatureFile]



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

Re: [cisco-voip] ParkingLotD and SNR | Leaked Calls on StationD

[Daniel Pagan]

Folks:

Wrapping up on this thread. BU created three new defects for this issue:

CSCut60329
Misconfigured Mobile Connect-SNR causes call leak in StationD

CSCut60376
Misconfigured Mobile Connect-SNR causes call leak in StationD part2

CSCut60641
Race condition at LBM Interface between LBM res and Cc signals

Some more detail on this issue in my previous messages.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Tuesday, January 13, 2015 12:10 PM
To: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] ParkingLotD and SNR | Leaked Calls on StationD

I set this up in a lab and it looks like the issue can be recreated in CUCM 
10.x as well...


1.   Enable and setup SNR for a user

2.   Configure the Remote Destination to an invalid number - force DA for 
SNRD to fail.

3.   Configure the Remote Destination for User Control voicemail policy

4.   Call the user's DN x number of times, where x equals your busy trigger 
value.

Can't seem to find a matching, publicly available defect for this so I opened a 
TAC case. The problem cannot be recreated when the Remote Destination's 
voicemail policy is Timer Control instead of User Control, and I fail to 
see ParkingLotD or ParkingLotCdpc when I'm not using User Control so it must 
be related.

The original call sends CcSetup to SNRD which results in a DA request. Although 
the request fails, we still invoke ParkingLotD/Cdpc and perform another DA 
request but to the user's DN instead of the Remote Destination. This seems to 
create another set of CIs and extends another CcSetup to StationD. Run this 
call flow a few times till the busy trigger is hit and the user-facing symptoms 
are:


1.   Inbound calls route immediately to VM since the busy trigger is reached

2.   Potentially user sees Error Pass Limit if Max Calls are reached - 
user cannot activate the line or place a call.

Resetting the phone associated to the StationD process leaking the call appears 
to be a workaround. Permanent solution is correct the Remote Destination so DA 
is successful or set the voicemail policy to Timer Control.

- Dan


From: Daniel Pagan
Sent: Tuesday, January 13, 2015 11:53 AM
To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: ParkingLotD and SNR | Leaked Calls on StationD

Folks:

Hoping someone can tell me if and how ParkingLotD and ParkingLotCdpc are 
related to outbound SNR calls. I'm looking at an SNR call and in SDL traces I'm 
seeing DA for CellProxy followed by a InitiateCallWithFeatureReq from Cc to 
ParkingLotD. I'm wondering what this event is for because I suspect it's 
related to a series of stuck/stale CI's. Both processes seem to be related to 
SNR when User Control is enabled at the Remote Destination. I'm familiar with 
CSCub55072 and it doesn't appear to be related.

There's an issue where calls seem to be leaking in the following call flow:


1.   Inbound call to DN over SIP trunk

2.   DN associated to Remote Destination

3.   CcSetup to the associated SNRD results in a rejection due to the 
remote destination failing on DA - the remote destination itself was configured 
incorrectly.

4.   Even though DA failed for SNRD, we have a 2nd successful DA to the 
called DN which appears to be related to ParkingLotCdpc. StationD receives this 
2nd CcSetup while stating it's a VMA call.

The user answers the inbound call and eventually disconnects. Later, another 
call arrives to his DN, LineControl reports ZERO active calls, but the StationD 
process reports ONE active call. Later, StationD will report TWO active calls 
while LineControl accurately reports ZERO. I'm familiar with CSCub55072 and it 
doesn't appear to be related.
Should we expect to see ParkingLotD and ParkingLotCdpc involved when DA fails 
to the remote destination? I'm setting this up in a lab environment now and 
fairly certain the call shouldn't extend this far when SNRD's DA fails, causing 
a 2nd DA to the called DN for no reason, which might explain the call leakage 
to StationD since CCM is sending it a 2nd VMA call for a failed SNR.

- Dan


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

Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

[Daniel Pagan]

Adding to Neal’s comments, you might find the following documentation helpful:

Cisco Live: Best Practices for Migrating to CUCM 10.5
https://clnv.s3.amazonaws.com/2014%2Fusa%2Fpdf%2FBRKUCC-2011.pdf?Expires=1427481707AWSAccessKeyId=AKIAJO3XQSJMRXKWDHZQSignature=ZqJonKRBn4Tlw9mXHoxg7d9RUUY%3D

The first few sections in this doc might be helpful as well.
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/ucmapMigrate/10_5_1/CUCM_BK_M24251C0_00_migrate-procedure-for-cucm_1051/CUCM_BK_M24251C0_00_migrate-procedure-for-cucm_1051_chapter_01.html

As Neal mentioned, you have to keep in mind that 10.5 is VM only and, while a 
direct RU upgrade from 8.5 to 10.5 is possible, you also need to consider the 
hardware requirements of 10.5 as well. Check out the 10.5 OVA specifications 
here:

http://www.cisco.com/web/software/283088407/112975/cucm.ova.README.txt

But to the steps mentioned below, this description sounds more like a Jump 
Upgrade procedure, which I understand is only required when upgrading from CUCM 
6.x/7.1(5), not CUCM 8.5.

So for the 8.5 to 10.5 upgrade – It seems the most straight forward method, 
assuming you’re on an MCS server, would be to


1)  DRS restore your 8.5 cluster to a virtualized environment built out on 
a v8.5 OVA template.

++ I’ve read that 8.5 won’t install on a v10 OVA template. Have I tried this 
myself? No. Should easy enough to test though. If it doesn’t, I’d imagine it’s 
due to disk sizing requirements for the user node specs.

2)  Use LCU to gather your license information pre-upgrade

3)  Refresh Upgrade from virtual 8.5 on UCS directly to 10.5 manually 
without PCD – requires the keys.cop and refresh_upgrade files. Last I checked 
you cannot upgrade from 8.5 to 10.5 via PCD.

++ I’d suggest reviewing the v10 OVA readme file and make sure you’re virtual 
machine specs and reservations are sufficient for the upgrade. Update if 
necessary – careful with disk resizing – there’s a recent thread on this topic 
alone.

4)  Submit a license request gathered from PLM – you’ll have a 60 day grace 
period.

++ At this point you should be on 10.5 with proper CPU and memory 
specifications and reservations, but your virtual disks will still be the 8.5 
provisioned specs. Having 2x80GB drives on CUCM 10.5 is supported and it runs 
just fine.

My suggestion would be to review all the migration and upgrade documentation 
you can find and review it. This might also help:

MCS to UCS – Slides 70 and higher might be most helpful:
http://stor.balios.net/Live2012/BRKUCC-2011.pdf

Also keep in mind that live MOH audio sources via USB are not supported in 10.5 
– you’ll need an alternate, IOS based solution for this.

Another caveat to keep in mind is Unity Connection and AXL synchronization – 
this will break unless you’re on Unity Connection 8.6 SU5 or a higher ES. If 
you patch to 8.6SU5 then be aware of CSCuq63776 – it’s pretty critical and 
you’re pretty much guaranteed to hit this after a SU5 patch. The latest CUC ES 
is 163 and includes a fix for this defect in addition to the BASH vulnerability 
patch and the fix for AXL.

I hope someone corrects any mistakes I made above and hope this helps.

- Dan



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Haas, 
Neal
Sent: Friday, March 27, 2015 10:41 AM
To: 'Andrew Grech'; Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

10.5 is VM only, 8.6.1 usually was MCS hardware.

To upgrade you will need to 8.6.1 upgrade to 9.1 on MCS. Then 9.1 MCS to VM, 
the upgrade 9.1 to 10.5(2)SU1.


Neal Haas

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Andrew Grech
Sent: Friday, March 27, 2015 7:30 AM
To: Nick
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5


Supported vs the system will upgrade are two different things.
On 27/03/2015 1:51 AM, Nick 
csv...@googlemail.commailto:csv...@googlemail.com wrote:
Hi All

Just checking through documentation for CUCM 10.5 for an upgrade, the 
compatibility guide states that a direct upgrade is from 8.6.1 onwards as shown 
below.

Upgrade Paths for Cisco Unified Communications Manager Release 10.5(2)SU1

[http://www.cisco.com/c/dam/en/us/td/i/templates/note.gif]
Note



If your release is not listed in the following table, find the upgrade path 
from your current release to a listed release in Cisco Unified Communications 
Manager Software Compatibility Matrix for Release 9.X and Earlier at 
http:/​/​www.cisco.com/​en/​US/​docs/​voice_ip_comm/​cucm/​compat/​ccmcompmatr1.pdfhttp://www.cisco.com/en/US/docs/voice_ip_comm/cucm/compat/ccmcompmatr1.pdf.




Table 15 Export Restricted Supported Cisco Unified Communications Manager 
Upgrades for Release 10.5(2)SU1


10.5(2)SU1


10.5.2.11900-3


Active


February 24, 2015


Direct Upgrade:

10.5(2), 10.5(1)SU1a, 10.5(1)SU1, 10.5(1), 10.0(1)SU2, 10.0(1)SU1, 10.0(1), 

Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

[Daniel Pagan]

Hmmm… Subject line says “from 8.5” but message body says “from 8.6”. Perhaps 
he’s referring to 8.5?

If you are then keep in mind the upgrade will require not only the 
version3-keys.cop file, but you’ll need to install the refresh_upgrade file as 
well. See the ReadMe:

http://www.cisco.com/web/software/282204704/18582/ciscocm.refresh_upgrade_v1.5.pdf
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Anthony Holloway
Sent: Thursday, March 26, 2015 12:45 PM
To: Nick; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Upgrading CUCM from 8.5 to 10.5

I don't understand your question/concern.

Both documents are saying the same thing: you can direct upgrade from 8.6(1).



On Thu, Mar 26, 2015 at 10:51 AM Nick 
csv...@googlemail.commailto:csv...@googlemail.com wrote:
Hi All

Just checking through documentation for CUCM 10.5 for an upgrade, the 
compatibility guide states that a direct upgrade is from 8.6.1 onwards as shown 
below.

Upgrade Paths for Cisco Unified Communications Manager Release 10.5(2)SU1

[http://www.cisco.com/c/dam/en/us/td/i/templates/note.gif]
Note



If your release is not listed in the following table, find the upgrade path 
from your current release to a listed release in Cisco Unified Communications 
Manager Software Compatibility Matrix for Release 9.X and Earlier at 
http:/​/​www.cisco.com/​en/​US/​docs/​voice_ip_comm/​cucm/​compat/​ccmcompmatr1.pdfhttp://www.cisco.com/en/US/docs/voice_ip_comm/cucm/compat/ccmcompmatr1.pdf.



Table 15 Export Restricted Supported Cisco Unified Communications Manager 
Upgrades for Release 10.5(2)SU1


10.5(2)SU1


10.5.2.11900-3


Active


February 24, 2015


Direct Upgrade:

10.5(2), 10.5(1)SU1a, 10.5(1)SU1, 10.5(1), 10.0(1)SU2, 10.0(1)SU1, 10.0(1), 
9.1(2)SU2a, 9.1(2)SU2, 9.1(2)SU1, 9.1(2), 9.1(1a), 9.1(1), 9.0(1),

8.6(2a)SU5, 8.6(2a)SU4a, 8.6(2a)SU4, 8.6(2a)SU3, 8.6(2a)SU2, 8.6(2a)SU1, 
8.6(2a),

8.6(2), 8.6(1a), 8.6(1)


Supported: (Consult the Cisco Unified Communications Manager Upgrade Guide for 
details)

8.5.(1)SU7, 8.5.(1)SU6, 8.5(1)SU5, 8.5(1)SU4, 8.5(1)SU3, 8.5(1)SU2,

8.5(1)SU1, 8.5(1), 8.0(3a)SU3, 8.0(3a)SU2, 8.0(3a)SU1, 8.0(3a),

8.0(3), 8.0(2c)SU1, 8.0(2c), 8.0(2b), 8.0(2a), 8.0(2), 8.0(1),

7.1(5b)SU6(restricted), 7.1(5b)SU5(restricted), 7.1(5b)SU4(restricted),

7.1(5b)SU3(restricted), 7.1(5b)SU2(restricted), 7.1(5b)(restricted),

7.1(5a)(restricted), 7.1(5)SU1a(restricted), 7.1(5)SU1(restricted),

7.1(5)(restricted), 7.1(3b)SU2, 7.1(3b)SU1, 7.1(3b), 7.1(3a)SU1a,

7.1(3a)SU1, 7.1(3a), 7.1(3), 6.1(5)SU3, 6.1(5)SU2, 6.1(5)SU1,

6.1(5), 6.1(4a)SU2, 6.1(4a), 6.1(4)SU1, 6.1(4)


However in the Read Me notes for 10.5.2 Su1 it states the following


　

Version and Description

This SU is a cumulative update that incorporates all of the fixes and changes 
from Cisco Unified Communications Manager 10.5(2) along with additional changes 
that are specific to this SU.

Note

You can only install this SU on Cisco Unified Communications Manager Release 
6.1(4x), 6.1(5x), 7.1(3x), 7.1(5x), 8.0(x), 8.5(1x), 8.6(x), 9.0(x), 9.1(x), 
10.0(1), 10.5(1), or 10.5(2) This SU will not install over any 10.5(2)ES’s. 
Upgrades from 6x, 7x, 8.x, and 9.x need to be requested via PUT 
(www.cisco.com/upgradehttp://www.cisco.com/upgrade) to obtain the necessary 
license. This SU should not be installed on a Business Edition 3000 server.

I would normally always go with what is says in the compatibility matrix, 
however my colleague has just done an upgrade albeit in a lab from 8.5.1 direct 
to 10.5.2 SU1.

Anyone know if he just got lucky or if that is now supported?

Regards

Nick



___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] CUCM Cluster Redundancy

[Daniel Pagan]

Agreed – To add to Brian’s message, the only benefit to having this powered 
down standby IMO would be minimizing time to restore should the Publisher ever 
need to be rebuilt in a DR situation. If you had a VM sharing the same IP 
address/hostname/cert information as the existing Publisher and running the 
same release (obviously not part of the production cluster and shut down), then 
your rebuild process skips the installation tasks and goes straight to 
restoring from DRS backup or a subscriber’s DB.

Have I seen customers do this? No… but in theory it can cut the rebuild time 
since the installation is already completed. Would I recommend this to a 
customer? Probably not as well. What if you patch the production cluster to an 
ES or SU and forget to update the standby? What if someone powers up that VM 
and now you have a duplicate address and hostname on the network? Even with the 
time it saves, that’s only about an hour or two at max and, as Brian said, you 
shouldn’t be relying on the Publisher for anything besides DB replication 
anyway. Seems more of an administrative burden than anything else IMO.

Hope that helps.

Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Brian 
Meade
Sent: Friday, March 20, 2015 10:16 AM
To: Ahmed Abd EL-Rahman
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CUCM Cluster Redundancy

Ahmed,

I don't think this is a good route to go.  Really you should have no dependence 
on the publisher besides configuration updates so it shouldn't be anything that 
affects operation.

I would be concerned that the subscribers would have a more updated version of 
the database than the cold-standby publisher.

Brian

On Fri, Mar 20, 2015 at 10:03 AM, Ahmed Abd EL-Rahman 
ahmed.rah...@bmbgroup.commailto:ahmed.rah...@bmbgroup.com wrote:
Hi All,
  I have a UC cluster V10.5 on 2 UCS Blade servers having 1 Pub and 4 
Subs, and I’d like to ask if there is any need or benefit from having a cold 
standby virtual machine for the Pub server (a replicated VM for the Pub which 
is turned off to backup Pub functionality in case of Pub failure), and also if 
the license will be valid on this cold standby VM for the Pub so that if the 
main Pub fails and we turned on the cold standby Pub VM everything will be fine 
and the operation continues normally.

Waiting your feedback.


Best Regards

Ahmed Abd EL-Rahman
Senior Network Engineer

___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] Extension that hangs up on the user?

[Daniel Pagan]

Goal was to answer and then disconnect instead of a call rejection before the 
connected state - said it was so that callers don't get a recorded error from 
the call agent or provider.

I've tested this HL/Queue option recently with no available LG members and UCM 
immediately attempts to re-route the call based on the When no hunt members 
answer, are logged in, or registered rules. The call isn't accepted unless the 
destination for this setting routes to an endpoint that accepts the CcSetupReq 
for this call.

 For the ingress side, at least from a SIP perspective, the INVITE to CUCM 
never receives a 200 Final Response, nor is there a 183 w/ SDP for early media, 
I would imagine because we never reached the alerting state in CUCM.

Dan

-Original Message-
From: gen...@ucpenguin.com [mailto:gen...@ucpenguin.com] 
Sent: Thursday, March 19, 2015 3:18 PM
To: Daniel Pagan
Cc: cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Extension that hangs up on the user?

I thought the goal was to disconnect the call, when there were no logged in 
members?

The options for the hunt list would seem to provide this.  It is probably worth 
checking to see how the call is disconnected, similar to be failed call from a 
translation pattern or a normally cleared call.

With the self service IVR and the queuing features added to UCM, I'm curious 
what these features are built on UCCX/CUC something else entirely?

If its based on UCCX, perhaps there is a way to introduce a custom UCCX script. 
 Of course, probably not a great idea for a production environment.  I know we 
will probably never see something like this added to UCM anytime soon (as 
protection for UCCX BU), but it would be a powerful feature to have out of the 
box.

On 2015-03-19 13:55, Daniel Pagan wrote:
 But perhaps if James didn't mind using an unused, registered IP phone 
 with a inaccessible DN whose sole purpose was to be a logged in LG 
 member.
 
 Set the maximum queue time for the lowest possible value and network 
 hold audio to a silent file. But the lowest value would be 10s which 
 seems like a long time for a disconnect IMO.
 
 - Dan
 
 -Original Message-
 From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf 
 Of Daniel Pagan
 Sent: Thursday, March 19, 2015 2:50 PM
 To: gen...@ucpenguin.com; cisco-voip@puck.nether.net
 Subject: Re: [cisco-voip] Extension that hangs up on the user?
 
 Unfortunately, in this scenario, this doesn't answer the call unless a 
 destination is configured for answering. The call hits the HP and 
 immediately no LG members are detected - it ends up not being answered 
 or queued and, instead, attempts to route to the destination 
 specified.
 
 This would be different if LG members were found and logged in, but 
 otherwise the call immediately uses the When no hunt members answer, 
 are logged in, or registered rules which will either drop the call or 
 re-route to another destination.
 
 - Dan
 
 -Original Message-
 From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf 
 Of gen...@ucpenguin.com
 Sent: Thursday, March 19, 2015 2:39 PM
 To: cisco-voip@puck.nether.net
 Subject: Re: [cisco-voip] Extension that hangs up on the user?
 
 Are you using a version of UCM with native call queuing?
 
 Instead of routing the call to CUC you could try sending it to a hunt 
 list with queuing enable, that has no logged in members that is set to 
 disconnect the call.
 
 On 2015-03-18 01:33, James Andrewartha wrote:
 Hi list,
 
 Is there a way in CUCM to make an extension that hangs up on the 
 other end? Currently we have a Unity Connection AA that does that, 
 but it's literally the only thing CUC is being used for and I want to 
 get rid of it. Currently we have our AAs (and voicemail) in Exchange 
 2007, which is being upgraded to 2013 soon, but as far as I can tell 
 there's no way to have it hang up on the caller, so I transfer to the 
 AA in Unity.
 
 Thanks,
 ___
 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] Extension that hangs up on the user?

[Daniel Pagan]

The main question I have... if CUC is being used simply to hang-up on the 
calling party, what's the purpose of needing this migrated to CUCM instead of 
simply leaving the number unallocated? Correct me if I'm wrong, but it seems to 
me that you're specifically looking for a method in CUCM where the call is 
answered and then disconnected.

Is this true? Are you hoping to have the call actually connected before the 
disconnect? Or does a simple rejection of the call work fine for you? Only 
situation I can think of where this is needed would be not wanting callers to 
hear a rejection or error recording due to unallocated number.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Huff
Sent: Wednesday, March 18, 2015 10:23 AM
To: James Andrewartha; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Extension that hangs up on the user?

So if the CUC AA IS NOT playing a greeting and the AA is doing NOTHING but the 
after action of hang-up; you could just create a translation pattern that 
matches the called number (presumably, the called number is currently a CTI 
route point/DN that is forwarding to CUC, you would need to remove it before 
creating the translation).

In the translation pattern, set block this pattern, call rejected.

You can also explore CCM ANI based call blocking; I discuss it here. 
http://ryanthomashuff.com/2014/11/call-blocking-by-caller-id/

Thanks,

Ryan
 From: jandrewar...@ccgs.wa.edu.aumailto:jandrewar...@ccgs.wa.edu.au
 To: ryanh...@outlook.commailto:ryanh...@outlook.com; 
 cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
 Date: Wed, 18 Mar 2015 22:10:36 +0800
 Subject: RE: [cisco-voip] Extension that hangs up on the user?

 Yeah, CUC has Callers Hear: Nothing then After Greeting/Call Action: Hang Up. 
 How would I dump the call? Select Route Option/Block this pattern: Call 
 Rejected in the translation pattern?

 Thanks,

 James Andrewartha
 Network  Projects Engineer
 Christ Church Grammar School
 Claremont, Western Australia
 Ph. (08) 9442 1757
 Mob. 0424 160 877
 
 From: Ryan Huff [ryanh...@outlook.com]
 Sent: Wednesday, 18 March 2015 8:12 PM
 To: James Andrewartha; 
 cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
 Subject: Re: [cisco-voip] Extension that hangs up on the user?

 So is CUC just so you can use the after action hang up technique or are you 
 playing a greeting first?

 If your just hanging up and not playing a greeting, could you just catch the 
 ingress call on a translation then just dump the call (or play the reorder 
 tone)?

 Thanks,

 Ryan


  Original Message 
 From: James Andrewartha 
 jandrewar...@ccgs.wa.edu.aumailto:jandrewar...@ccgs.wa.edu.au
 Sent: Wednesday, March 18, 2015 02:34 AM
 To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
 Subject: [cisco-voip] Extension that hangs up on the user?


 Hi list,

 Is there a way in CUCM to make an extension that hangs up on the other
 end? Currently we have a Unity Connection AA that does that, but it's
 literally the only thing CUC is being used for and I want to get rid of
 it. Currently we have our AAs (and voicemail) in Exchange 2007, which is
 being upgraded to 2013 soon, but as far as I can tell there's no way to
 have it hang up on the caller, so I transfer to the AA in Unity.

 Thanks,

 --
 James Andrewartha
 Network  Projects Engineer
 Christ Church Grammar School
 Claremont, Western Australia
 Ph. (08) 9442 1757
 Mob. 0424 160 877
 ___
 cisco-voip mailing list
 cisco-voip@puck.nether.netmailto: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] Extension that hangs up on the user?

[Daniel Pagan]

Definitely makes sense and what I thought you were trying to achieve. If this 
is the case, then rejecting the call via xlate or route patterns won't do - the 
call will be rejected instead of connecting and then being disconnected. You'll 
more than likely receive the standard recording from your call agent or 
provider for a non-working number.

I can't think of anything native to CUCM that would answer and then disconnect 
the call. At the end of the day, for this to happen, the call would not only 
need to be routed to some endpoint whether its SIP, SCCP, CTI, H.323, or MGCP, 
but also accepted by the endpoint and only then disconnected... this is 
basically what CUC is doing for you. In other words, the call would need to go 
somewhere :) I was thinking maybe call queueing on a hunt pilot with no logged 
in HG members but even that won't help.

Do you have UCCX? Is CUBE part of the call-flow? You can do something creative 
here like Tim Smith mentioned (TCL script in IOS). If UCCX, simply route the 
call to a trigger, accept it, add a delay step for two seconds, and then 
disconnect it.

- Dan

-Original Message-
From: James Andrewartha [mailto:jandrewar...@ccgs.wa.edu.au] 
Sent: Wednesday, March 18, 2015 11:38 AM
To: Daniel Pagan; Ryan Huff; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Extension that hangs up on the user?

Hi Dan,

This is to transfer to from an Exchange UM AA where we want to hang up on the 
caller after playing a message (it's summer holidays and there's no-one to 
answer the call is the one that comes to mind). I want it to be a silent 
hangup, not give the caller a this extension could not be found message.

Thanks,

James Andrewartha
Network  Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

From: Daniel Pagan [dpa...@fidelus.com]
Sent: Wednesday, 18 March 2015 11:16 PM
To: Ryan Huff; James Andrewartha; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Extension that hangs up on the user?

The main question I have... if CUC is being used simply to hang-up on the 
calling party, what's the purpose of needing this migrated to CUCM instead of 
simply leaving the number unallocated? Correct me if I'm wrong, but it seems to 
me that you're specifically looking for a method in CUCM where the call is 
answered and then disconnected.

Is this true? Are you hoping to have the call actually connected before the 
disconnect? Or does a simple rejection of the call work fine for you? Only 
situation I can think of where this is needed would be not wanting callers to 
hear a rejection or error recording due to unallocated number.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Huff
Sent: Wednesday, March 18, 2015 10:23 AM
To: James Andrewartha; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Extension that hangs up on the user?

So if the CUC AA IS NOT playing a greeting and the AA is doing NOTHING but the 
after action of hang-up; you could just create a translation pattern that 
matches the called number (presumably, the called number is currently a CTI 
route point/DN that is forwarding to CUC, you would need to remove it before 
creating the translation).

In the translation pattern, set block this pattern, call rejected.

You can also explore CCM ANI based call blocking; I discuss it here. 
http://ryanthomashuff.com/2014/11/call-blocking-by-caller-id/

Thanks,

Ryan
 From: jandrewar...@ccgs.wa.edu.aumailto:jandrewar...@ccgs.wa.edu.au
 To: ryanh...@outlook.commailto:ryanh...@outlook.com; 
 cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
 Date: Wed, 18 Mar 2015 22:10:36 +0800
 Subject: RE: [cisco-voip] Extension that hangs up on the user?

 Yeah, CUC has Callers Hear: Nothing then After Greeting/Call Action: Hang Up. 
 How would I dump the call? Select Route Option/Block this pattern: Call 
 Rejected in the translation pattern?

 Thanks,

 James Andrewartha
 Network  Projects Engineer
 Christ Church Grammar School
 Claremont, Western Australia
 Ph. (08) 9442 1757
 Mob. 0424 160 877
 
 From: Ryan Huff [ryanh...@outlook.com]
 Sent: Wednesday, 18 March 2015 8:12 PM
 To: James Andrewartha; 
 cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
 Subject: Re: [cisco-voip] Extension that hangs up on the user?

 So is CUC just so you can use the after action hang up technique or are you 
 playing a greeting first?

 If your just hanging up and not playing a greeting, could you just catch the 
 ingress call on a translation then just dump the call (or play the reorder 
 tone)?

 Thanks,

 Ryan


  Original Message 
 From: James Andrewartha 
 jandrewar...@ccgs.wa.edu.aumailto:jandrewar...@ccgs.wa.edu.au
 Sent: Wednesday, March 18, 2015 02:34 AM
 To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
 Subject: [cisco-voip] Extension that hangs up

Re: [cisco-voip] Translation Profile out on voice port

[Daniel Pagan]

Ahmed -

Not sure if I completely follow but are you concerned about the order of 
operations for digit manipulation in IOS? If you are then I would say your 
expectation would be correct with digit manipulation in IOS occurring in the 
following steps and in the following order:

incoming voice-port
incoming dial-peer
num-exp
outgoing dial-peer
egress voice-port

But after reading your email again it looks like you're more referring to the 
digit stripping that's inherent to POTS DPs... I'd have to test this to confirm 
but I would imagine the digit stripping would also occur first at the POTS 
outbound dial-peer level once matched, then voice translation would apply to 
the [potentially] stripped called party number. Are you saying the dial-peer 
digit stripping is occurring *after* the voice-port-level voice translation is 
applied?

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ahmed 
Elnagar
Sent: Wednesday, March 18, 2015 5:28 PM
To: 'VOIP Group '
Cc: 'ahmed ellboudy'
Subject: [cisco-voip] Translation Profile out on voice port

Hi all;

It has been a very long time since I posted to the mailing list but you are 
always the gateway of last resort to find an expert reply :)

I was testing voice translation rules on a VGW with the below setup

I want someone to be able to call extensions 1XXX from a site connected back 
to back to another site using E1 0/3/0 H323 GW with CUCM in each site...I 
know I could do it with a simple forward-digits all under the pots dial-peer in 
order for the router to send 1XXX in the ISDN setup insetead of sending XXX.

I am trying to verify the concept of translation profiles but I am having a 
strange issue, for the below call the pots dial-peer is matched as an outgoing 
dial-peer but as soon as this happens the debugs shows that the router check if 
there is a tx profile on the voice port before making the digit strip and 
translate the number and then make a dial-peer match again and then go out of 
the voice port...is that a normal behavior? My expectation is that the 
dial-peer should be matched first then apply digit strip and at the exit from 
the E1 interface translation profile to be applied.

I cannot find any document that explains this part or document this 
approach...any ideas?

Below is my configuration

Voice translation rule 1
Rule 1 /^0../ /1\0/

Voice translation profile PSTN_OUT
translate called 1

voice-port 0/3/0:15
translation-profile outgoing PSTN_OUT


dial-peer voice 1 pots
destination-pattern 1...
port 0/3/0:15



Regards,
Ahmed Elnagar | Networking Consultant | CCIE #24697, Voice
[Description: Description: Description: Description: MS Green]



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

Re: [cisco-voip] Transcoding question

[Daniel Pagan]

For clarity, by “higher bandwidth codec” I meant to say higher bit-rate codec, 
or codec of higher bandwidth consumption.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Monday, March 16, 2015 9:08 PM
To: Ryan Huff; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Transcoding question

Hey Ryan how’s it going? Transcoder allocated by CUCM comes from the side using 
a higher bandwidth codec, regardless if it’s the calling or called party, with 
the intention to avoid streaming a high bandwidth consuming codec over a WAN 
connection – keeping it local to the LAN. Of course, this isn’t always true, 
such as due to a local transcoding resource being entirely nonexistent or a 
misconfiguration of the MRG/MRGLs.

Hope this helps answer your question.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Huff
Sent: Monday, March 16, 2015 8:11 PM
To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: [cisco-voip] Transcoding question


When xcoding is required in the call setup, which side is transcoded? The 
called party or the calling party?

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

Re: [cisco-voip] Transcoding question

[Daniel Pagan]

Hey Ryan how’s it going? Transcoder allocated by CUCM comes from the side using 
a higher bandwidth codec, regardless if it’s the calling or called party, with 
the intention to avoid streaming a high bandwidth consuming codec over a WAN 
connection – keeping it local to the LAN. Of course, this isn’t always true, 
such as due to a local transcoding resource being entirely nonexistent or a 
misconfiguration of the MRG/MRGLs.

Hope this helps answer your question.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Huff
Sent: Monday, March 16, 2015 8:11 PM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Transcoding question


When xcoding is required in the call setup, which side is transcoded? The 
called party or the calling party?

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

Re: [cisco-voip] vMotion w/o Shared Storage

[Daniel Pagan]

Hey how’s it going, Anthony – The confusion I had was mostly with VMware/ESX 
terminology behind migration methods. The Cisco documentation I was reading for 
supported vMotion methods all said “when shared storage is available”… and my 
question was “well… what if you have no shared storage and need to migrate 
between such datastores and hosts? Is this supported?”

The steps I was interested in taking to migrate the virtual machine is 
documented as “Enhanced vMotion”: http://vmdamentals.com/?p=4222

But here’s why I say I was confusing VMware terms… the vMotion (or Enhanced 
vMotion) process applies to live/powered-up virtual machines. For a powered 
down machine it’s simply considered a cold migration:

https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.vcenterhost.doc_50%2FGUID-326DEC3C-3EFC-4DA0-B1E9-0B2D4698CBCC.html

Since I plan on having the machine powered off anyway, and Cisco fully supports 
a cold migration, then it seems I should have no concerns for my specific 
scenario…

… but on the topic of vMotion on a powered on UC VM, since documentation states 
that regardless of the UC app, the “VM must be installed on shared storage” and 
“source and destination servers must be connected to same SAN” – which tells me 
that Enhanced vMotion on a powered up UC VM between unshared storage is not 
supported.

^^^ The confusion of a non-VCP :)

- Dan

From: Anthony Holloway [mailto:avholloway+cisco-v...@gmail.com]
Sent: Wednesday, March 11, 2015 2:01 AM
To: Daniel Pagan; Dave Goodwin
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] vMotion w/o Shared Storage

Daniel,
Could you give a little more detail about your experience with this process?  
The confusion you faced is likely the same confusion many of us would face.

Which document(s) did you follow?  Which files did you copy?  What were the 
high level steps? etc.

On Tue, Mar 10, 2015 at 9:02 PM Daniel Pagan 
dpa...@fidelus.commailto:dpa...@fidelus.com wrote:
Thanks Dave. I also came across these details, but it too states shared storage:

“A Virtual Machine (VM) file on network/shared storage can be booted on any 
physical server hosting ESXi that has access to that network shared storage.”

But perhaps my confusion was vMotion vs cold migration. My original thought was 
using Enhanced vMotion since the objective was to bring the VM config and disk 
to another host and unshared datastore.

http://www.vladan.fr/vmware-enhanced-vmotion/
http://www.ntpro.nl/blog/archives/2118-Enhanced-vMotion-with-vSphere-5.1.html

I wasn’t sure if this was Cisco supported since all mention of vMotion 
migrations in the VMware requirements document state shared storage, but it 
seems this doesn’t quite fit the process of vMotion (Enhanced or not) since the 
virtual machine is powered off anyway. This would certainly fall under the 
category of cold migration, which is definitely Cisco supported.

Some confusion on my part between the two migration methods but all is clear.

Thanks!

- Dan


From: Dave Goodwin 
[mailto:dave.good...@december.netmailto:dave.good...@december.net]
Sent: Tuesday, March 10, 2015 8:47 PM
To: Daniel Pagan
Cc: Ryan Huff; cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net

Subject: Re: [cisco-voip] vMotion w/o Shared Storage

Keep in mind that moving a VM from one host to another (whether the VM's 
storage is being moved or not) is not considered a vMotion. That is why you can 
do it even without enabling any NICs on the host for the vMotion feature. 
Therefore, the VMWare feature you'd want to look for in the matrix is probably 
Restart Virtual Machine on Different ESXi Host and not vMotion.
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements

On Tue, Mar 10, 2015 at 6:18 PM, Daniel Pagan 
dpa...@fidelus.commailto:dpa...@fidelus.com wrote:
Thanks - that’s what I figured and just tested with no issues. Seems the 
non-shared storage caveat for vMotion is a non-issue in ESXi 5.1 and higher.

http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.vcenterhost.doc%2FGUID-9F1D4A3B-3392-46A3-8720-73CBFA000A3C.html

I was also concerned of partition alignment but I guess that would be a 
non-issue as well since the vmdk is already provisioned. The move to the 
stand-alone datastore is nearing completion so I’ll double check the start 
block size once it’s done just to be sure!

- Dan


From: Ryan Huff [mailto:ryanh...@outlook.commailto:ryanh...@outlook.com]
Sent: Tuesday, March 10, 2015 5:08 PM
To: Daniel Pagan; cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] vMotion w/o Shared Storage


Shutdown, yes. Running, no.

Thanks,

Ryan


 Original Message 
From: Daniel Pagan dpa...@fidelus.commailto:dpa...@fidelus.com
Sent: Tuesday, March 10, 2015 05:06 PM
To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: [cisco-voip] vMotion w/o Shared Storage
Quick question…

vMotion of a shut down UCM between two hosts

Re: [cisco-voip] vMotion w/o Shared Storage

[Daniel Pagan]

Thanks - that’s what I figured and just tested with no issues. Seems the 
non-shared storage caveat for vMotion is a non-issue in ESXi 5.1 and higher.

http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.vcenterhost.doc%2FGUID-9F1D4A3B-3392-46A3-8720-73CBFA000A3C.html

I was also concerned of partition alignment but I guess that would be a 
non-issue as well since the vmdk is already provisioned. The move to the 
stand-alone datastore is nearing completion so I’ll double check the start 
block size once it’s done just to be sure!

- Dan


From: Ryan Huff [mailto:ryanh...@outlook.com]
Sent: Tuesday, March 10, 2015 5:08 PM
To: Daniel Pagan; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] vMotion w/o Shared Storage


Shutdown, yes. Running, no.

Thanks,

Ryan


 Original Message 
From: Daniel Pagan dpa...@fidelus.commailto:dpa...@fidelus.com
Sent: Tuesday, March 10, 2015 05:06 PM
To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: [cisco-voip] vMotion w/o Shared Storage
Quick question…

vMotion of a shut down UCM between two hosts without shared storage using 
vCenter. Is this supported? The virtualization document for UC platforms says 
vMotion is supported on shared storage, so I figured to ask. Is this migration 
method supported?

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

Re: [cisco-voip] vMotion w/o Shared Storage

[Daniel Pagan]

Thanks Dave. I also came across these details, but it too states shared storage:

“A Virtual Machine (VM) file on network/shared storage can be booted on any 
physical server hosting ESXi that has access to that network shared storage.”

But perhaps my confusion was vMotion vs cold migration. My original thought was 
using Enhanced vMotion since the objective was to bring the VM config and disk 
to another host and unshared datastore.

http://www.vladan.fr/vmware-enhanced-vmotion/
http://www.ntpro.nl/blog/archives/2118-Enhanced-vMotion-with-vSphere-5.1.html

I wasn’t sure if this was Cisco supported since all mention of vMotion 
migrations in the VMware requirements document state shared storage, but it 
seems this doesn’t quite fit the process of vMotion (Enhanced or not) since the 
virtual machine is powered off anyway. This would certainly fall under the 
category of cold migration, which is definitely Cisco supported.

Some confusion on my part between the two migration methods but all is clear.

Thanks!

- Dan


From: Dave Goodwin [mailto:dave.good...@december.net]
Sent: Tuesday, March 10, 2015 8:47 PM
To: Daniel Pagan
Cc: Ryan Huff; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] vMotion w/o Shared Storage

Keep in mind that moving a VM from one host to another (whether the VM's 
storage is being moved or not) is not considered a vMotion. That is why you can 
do it even without enabling any NICs on the host for the vMotion feature. 
Therefore, the VMWare feature you'd want to look for in the matrix is probably 
Restart Virtual Machine on Different ESXi Host and not vMotion.
http://docwiki.cisco.com/wiki/Unified_Communications_VMware_Requirements

On Tue, Mar 10, 2015 at 6:18 PM, Daniel Pagan 
dpa...@fidelus.commailto:dpa...@fidelus.com wrote:
Thanks - that’s what I figured and just tested with no issues. Seems the 
non-shared storage caveat for vMotion is a non-issue in ESXi 5.1 and higher.

http://pubs.vmware.com/vsphere-51/index.jsp?topic=%2Fcom.vmware.vsphere.vcenterhost.doc%2FGUID-9F1D4A3B-3392-46A3-8720-73CBFA000A3C.html

I was also concerned of partition alignment but I guess that would be a 
non-issue as well since the vmdk is already provisioned. The move to the 
stand-alone datastore is nearing completion so I’ll double check the start 
block size once it’s done just to be sure!

- Dan


From: Ryan Huff [mailto:ryanh...@outlook.commailto:ryanh...@outlook.com]
Sent: Tuesday, March 10, 2015 5:08 PM
To: Daniel Pagan; cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] vMotion w/o Shared Storage


Shutdown, yes. Running, no.

Thanks,

Ryan


 Original Message 
From: Daniel Pagan dpa...@fidelus.commailto:dpa...@fidelus.com
Sent: Tuesday, March 10, 2015 05:06 PM
To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: [cisco-voip] vMotion w/o Shared Storage
Quick question…

vMotion of a shut down UCM between two hosts without shared storage using 
vCenter. Is this supported? The virtualization document for UC platforms says 
vMotion is supported on shared storage, so I figured to ask. Is this migration 
method supported?

- Dan

___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] Forwarding an inbound caller straight to Voicemail 8.0

[Daniel Pagan]

HAH! Slick and cool... Two things I'm far, far from :) Unfortunately it took my 
email below a full hour to be posted!

That's tricky if the desired behavior is to dial a UCCX trigger and, if the ANI 
contains area code 519, only then should CUCM route the call to a specific 
voicemail box. If this is correct, then I think routing based on calling-number 
in CUCM is certainly going to be required along with dialed number based 
routing... if scripting isn't desired...

But since it seems they're dialing a UCCX trigger anyway, assuming it's not 
just an unregistered CTI RP and calls are actually routing to UCCX, why not 
just edit the existing script to read the calling number and redirect the call 
to a predetermined DN that's configured for CFWD all into voicemail?

Something straight forward like...

If calling number begins with 516
  True
 Call Redirect -- 56789
  False
  continue

In CUCM... DN 56789 - CFwdAll to Voicemail - Unity CH or User w/ mailbox

Add the partition of 56789 to the CSS of the UCCX CTI ports performing the 
redirect.

- Dan


From: Ryan Huff [mailto:ryanh...@outlook.com]
Sent: Tuesday, March 10, 2015 12:23 PM
To: Daniel Pagan; norm.nichol...@kitchener.ca; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Forwarding an inbound caller straight to Voicemail 8.0

Daniel,

There you go trying to make things slick and cool, lol! I like that approach!

So, it seems his need is that if only 1 particular DNIS dialed one particular 
DN (a uccx trigger from my understanding) in ccm, that it then route the call 
to a specific VM account; but that it would also allow that DNIS to dial any 
other DN in the cluster without going to that specific VM account..

Being that I love to learn new things constantly; in your approach, is there a 
way to accomplish that requirement?

Thanks,

Ryan


From: dpa...@fidelus.commailto:dpa...@fidelus.com
To: norm.nichol...@kitchener.camailto:norm.nichol...@kitchener.ca; 
cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Date: Tue, 10 Mar 2015 15:09:32 +
Subject: Re: [cisco-voip] Forwarding an inbound caller straight to Voicemail 8.0
For routing based on ANI, Ryan Huff's suggestion will certainly help from the 
perspective of CUCM. You can use this alongside CUC routing rules - route calls 
from the 519 area code to a specific mailbox. If you know these callers from 
area code 519 are dialing the same DNIS, then routing by ANI in CUCM won't be 
needed - simply route the DNIS to voicemail, add a routing rule matching the 
519 calls, and route to a mailbox.

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
norm.nichol...@kitchener.camailto:norm.nichol...@kitchener.ca
Sent: Tuesday, March 10, 2015 8:43 AM
To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: [cisco-voip] Forwarding an inbound caller straight to Voicemail 8.0


I have been asked to send an outside caller to a voicemail box so when the DNIS 
or ANI shows 519-XXX- I want that caller to go to a specific mailbox. Is 
this possible ?




Thanks







Norm Nicholson
Telecom Analyst
City of Kitchener
(519) 741-2200 x 7000



___ cisco-voip mailing list 
cisco-voip@puck.nether.netmailto: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] Forwarding an inbound caller straight to Voicemail 8.0

[Daniel Pagan]

Doc on ANI-based call routing in UCCX:

http://www.scribd.com/doc/197424933/Cisco-UCCX-ANI-Based-Call-Routing#scribd

Norm can use this as a starting point assuming the call is routing into UCCX 
already. But use the call redirect step instead of the set step specified in 
the article. Use call redirect to send the call (which returned TRUE based on 
the previous IF step looking at calling party) to a DN in CUCM configured for 
CFwdAll to Unity Connection. Then have a dedicated voice mailbox for these 
calls with a matching DN.

What I'm not sure of is whether CUC will match the voicemail user based on 
first redirecting number, which might use the CTI port performing the 
redirect... Not sure... would need to test... but it's probably the cleanest 
solution IMO.

From: Daniel Pagan
Sent: Tuesday, March 10, 2015 1:11 PM
To: 'Ryan Huff'; norm.nichol...@kitchener.ca; cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Forwarding an inbound caller straight to Voicemail 8.0

HAH! Slick and cool... Two things I'm far, far from :) Unfortunately it took my 
email below a full hour to be posted!

That's tricky if the desired behavior is to dial a UCCX trigger and, if the ANI 
contains area code 519, only then should CUCM route the call to a specific 
voicemail box. If this is correct, then I think routing based on calling-number 
in CUCM is certainly going to be required along with dialed number based 
routing... if scripting isn't desired...

But since it seems they're dialing a UCCX trigger anyway, assuming it's not 
just an unregistered CTI RP and calls are actually routing to UCCX, why not 
just edit the existing script to read the calling number and redirect the call 
to a predetermined DN that's configured for CFWD all into voicemail?

Something straight forward like...

If calling number begins with 516
  True
 Call Redirect -- 56789
  False
  continue

In CUCM... DN 56789 - CFwdAll to Voicemail - Unity CH or User w/ mailbox

Add the partition of 56789 to the CSS of the UCCX CTI ports performing the 
redirect.

- Dan


From: Ryan Huff [mailto:ryanh...@outlook.com]
Sent: Tuesday, March 10, 2015 12:23 PM
To: Daniel Pagan; 
norm.nichol...@kitchener.camailto:norm.nichol...@kitchener.ca; 
cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: RE: [cisco-voip] Forwarding an inbound caller straight to Voicemail 8.0

Daniel,

There you go trying to make things slick and cool, lol! I like that approach!

So, it seems his need is that if only 1 particular DNIS dialed one particular 
DN (a uccx trigger from my understanding) in ccm, that it then route the call 
to a specific VM account; but that it would also allow that DNIS to dial any 
other DN in the cluster without going to that specific VM account..

Being that I love to learn new things constantly; in your approach, is there a 
way to accomplish that requirement?

Thanks,

Ryan

From: dpa...@fidelus.commailto:dpa...@fidelus.com
To: norm.nichol...@kitchener.camailto:norm.nichol...@kitchener.ca; 
cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Date: Tue, 10 Mar 2015 15:09:32 +
Subject: Re: [cisco-voip] Forwarding an inbound caller straight to Voicemail 8.0
For routing based on ANI, Ryan Huff's suggestion will certainly help from the 
perspective of CUCM. You can use this alongside CUC routing rules - route calls 
from the 519 area code to a specific mailbox. If you know these callers from 
area code 519 are dialing the same DNIS, then routing by ANI in CUCM won't be 
needed - simply route the DNIS to voicemail, add a routing rule matching the 
519 calls, and route to a mailbox.

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
norm.nichol...@kitchener.camailto:norm.nichol...@kitchener.ca
Sent: Tuesday, March 10, 2015 8:43 AM
To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: [cisco-voip] Forwarding an inbound caller straight to Voicemail 8.0


I have been asked to send an outside caller to a voicemail box so when the DNIS 
or ANI shows 519-XXX- I want that caller to go to a specific mailbox. Is 
this possible ?




Thanks







Norm Nicholson
Telecom Analyst
City of Kitchener
(519) 741-2200 x 7000



___ cisco-voip mailing list 
cisco-voip@puck.nether.netmailto: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] Forwarding an inbound caller straight to Voicemail 8.0

[Daniel Pagan]

For routing based on ANI, Ryan Huff's suggestion will certainly help from the 
perspective of CUCM. You can use this alongside CUC routing rules - route calls 
from the 519 area code to a specific mailbox. If you know these callers from 
area code 519 are dialing the same DNIS, then routing by ANI in CUCM won't be 
needed - simply route the DNIS to voicemail, add a routing rule matching the 
519 calls, and route to a mailbox.

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
norm.nichol...@kitchener.ca
Sent: Tuesday, March 10, 2015 8:43 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] Forwarding an inbound caller straight to Voicemail 8.0


I have been asked to send an outside caller to a voicemail box so when the DNIS 
or ANI shows 519-XXX- I want that caller to go to a specific mailbox. Is 
this possible ?




Thanks







Norm Nicholson
Telecom Analyst
City of Kitchener
(519) 741-2200 x 7000




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

[cisco-voip] vMotion w/o Shared Storage

[Daniel Pagan]

Quick question...

vMotion of a shut down UCM between two hosts without shared storage using 
vCenter. Is this supported? The virtualization document for UC platforms says 
vMotion is supported on shared storage, so I figured to ask. Is this migration 
method supported?

- Dan


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

Re: [cisco-voip] DNIS Question

[Daniel Pagan]

But this doesn’t provide the logic required for the call acceptance rule of 
“accept only the first (regardless of ToD), reject all others, reset after 24 
hours”. Aside from using some form of UCCX scripting or using a custom app 
integrated through the JTAPI or Routing Rules API, I too don’t see CUCM 
natively accomplishing this.

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Ryan 
Huff
Sent: Friday, March 06, 2015 9:23 AM
To: dennis.h...@wwt.com; norm.nichol...@kitchener.ca; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] DNIS Question


If youre on a modern version of ccm you could use a combo of route to next hop 
with calling party I'd and hunts.

That would be a fun one to play around with.

Thanks,

Ryan


 Original Message 
From: Heim, Dennis dennis.h...@wwt.commailto:dennis.h...@wwt.com
Sent: Friday, March 6, 2015 09:13 AM
To: 
norm.nichol...@kitchener.ca,cisco-voip@puck.nether.netmailto:norm.nichol...@kitchener.ca,cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] DNIS Question
Out of the box no. You could leverage the Routing Rules API to build a policy 
and database lookup.

Dennis Heim | Emerging Technology Architect (Collaboration)
World Wide Technology, Inc. | +1 314-212-1814
[twitter]https://twitter.com/CollabSensei
[chat]xmpp:dennis.h...@wwt.com[Phone]tel:+13142121814[video]sip:dennis.h...@wwt.com
Innovation happens on project squared -- 
http://www.projectsquared.comhttp://www.projectsquared.com/

Click here to join me in my Collaboration Meeting 
Roomhttps://wwt.webex.com/meet/dennis.heim



From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
norm.nichol...@kitchener.camailto:norm.nichol...@kitchener.ca
Sent: Friday, March 06, 2015 6:07 AM
To: cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: [cisco-voip] DNIS Question


I have a user request for the following:


We are having an issue with a nuisance caller calling dispatch 20-30 times a 
day for the past month.  Can we set up the phone system to only allow the 
following number to call once a day on our   and  extension numbers ?

519 XXX 

After the one call is used for that day, the following call goes to this 
message:
“If this is an emergency, please hang up and call 911 (hang up)”




The question is it possible to accept one call a day then route them to a 
message or is it all or nothing ?







Thanks






Norm Nicholson
Telecom Analyst
City of Kitchener
(519) 741-2200 x 7000


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

Re: [cisco-voip] CUCM 11.0 Release Date?

[Daniel Pagan]

Adding to Dennis's question below, is CUCM v11 going to be discussed at Cisco 
Live in June? I see no sessions or breakouts about this. There's a few sessions 
on CUC and UCCX roadmaps but nothing similar with regards to UCM.

Thanks!

- Dan

-Original Message-
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Heim, 
Dennis
Sent: Wednesday, March 04, 2015 10:05 AM
To: gen...@ucpenguin.com; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CUCM 11.0 Release Date?

When does Cisco usually release their new versions of all their stuff?

Dennis Heim | Emerging Technology Architect (Collaboration) World Wide 
Technology, Inc. | +1 314-212-1814


Innovation happens on project squared -- http://www.projectsquared.com

Click here to join me in my Collaboration Meeting Room



-Original Message-
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
gen...@ucpenguin.com
Sent: Tuesday, March 03, 2015 8:41 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] CUCM 11.0 Release Date?

Anyone have any guesses for the date when CUCM 11.0 hits CCO?

Its starting to show as the latest version in some places:

http://www.cisco.com/c/en/us/support/unified-communications/unified-communications-manager-version-11-0/model.html


___
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] Errors 18 and 19 on incoming call only through subscriber

[Daniel Pagan]

I’d also say a similar defect would be CSCul71689 – a defect I came across 
quite often on 8.6(2). Like Brian said, hunt lists use RouteListControl which 
creates HuntListCdrc for call distribution to your line group members. With 
either defect, I’d say another possible workaround would be to register the 
hunt list to another call processing server so that this particular instance of 
RouteListControl runs on a different node. Aside from a reset of the HL and 
registering it to another server, my last option would be to reset the CCM 
service if one of these is indeed a defect you’re hitting.

Also, as Robert mentioned, detailed CCM SDI  SDL traces would confirm which 
one you’re hitting (if any of them of course).

The one you found appears to be an issue where RouteListControl itself rejects 
the call since (I’m assuming) it cannot locate the process instance for your 
LG/RG member, whereas the defect I listed above results in RouteListControl and 
RouteListCdrc locating the the LG/RG member but will detect and print them as 
“DOWN” despite their availability.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of ROZA, 
Ariel
Sent: Thursday, March 05, 2015 5:36 PM
To: Brian Meade
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] Errors 18 and 19 on incoming call only through 
subscriber

Thanks. So, the short term workaround would be to restart the CCM Service, 
until I can apply the latest service release. Right?

From: bmead...@gmail.commailto:bmead...@gmail.com [mailto:bmead...@gmail.com] 
On Behalf Of Brian Meade
Sent: jueves, 05 de marzo de 2015 07:15 p.m.
To: ROZA, Ariel
Cc: Ryan Ratliff (rratliff); cisco-voip voyp list
Subject: Re: [cisco-voip] Errors 18 and 19 on incoming call only through 
subscriber

Hunt Lists use the RouteListControl process as well so definitely could be the 
issue.

On Thu, Mar 5, 2015 at 5:13 PM, ROZA, Ariel 
ariel.r...@la.logicalis.commailto:ariel.r...@la.logicalis.com wrote:
I think I may be hitting this bug:

https://tools.cisco.com/bugsearch/bug/CSCtr83193

It applies to Route Lists instead of Hunt Lists, but the symptoms look similar, 
and the CUCM version matches..

What do you think?

Regards,
Ariel Roza
Service Delivery Consultant  / Argentina
Logicalis
Tel: +54 11 5282 - 0458tel:%2B54%2011%205282%20-%200458
ariel.r...@la.logicalis.commailto:ariel.r...@la.logicalis.com
Peru 327 – CABA – Argentina – C1067AAG
www.la.logicalis.comhttp://www.la.logicalis.com/
_
Business and technology working as one

Síguenos en: [Description: Descripción: Descripción: Descripción: Descripción: 
Descripción: Descripción: tw] http://twitter.com/LogicalisLatam  
[Description: Descripción: Descripción: Descripción: Descripción: Descripción: 
Descripción: fb] http://es-es.facebook.com/pages/Logicalis-Latam/234648439078 
 [Description: Descripción: Descripción: Descripción: Descripción: Descripción: 
Descripción: yt] http://www.youtube.com/logicalislatam  
[cid:image004.jpg@01D05791.9C966200] http://www.slideshare.net/logicalis  
[Description: Descripción: cid:image005.jpg@01CCDC0C.A5297E60] 
http://www.cxounplugged.com/
[Description: Descripción: Descripción: Descripción: 
http://www.estudioponzo.com.ar/firma.gif]



From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.netmailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of ROZA, Ariel
Sent: jueves, 05 de marzo de 2015 06:56 p.m.
To: Ryan Ratliff (rratliff); Brian Meade
Cc: cisco-voip voyp list

Subject: Re: [cisco-voip] Errors 18 and 19 on incoming call only through 
subscriber

Hi, Guys…

I restarted RIS on both nodes and did not do a thing, so I guess Ryan might be 
right. What´s the alternative? Restarting the Callmanager Service? Rebooting 
the whole sub? Both Sub and Pub?

I have h225, h245 and full ccm traces if there´s any use for them.

Regards,

Ariel.

From: Ryan Ratliff (rratliff) [mailto:rratl...@cisco.com]
Sent: miércoles, 11 de febrero de 2015 11:23 a.m.
To: Brian Meade
Cc: ROZA, Ariel; cisco-voip voyp list
Subject: Re: [cisco-voip] Errors 18 and 19 on incoming call only through 
subscriber

RIS shouldn’t be involved in that flow, though it does read from the same 
shared memory segment that the ccm process does so unless RIS itself is screwed 
I’d expect if ccm doesn’t know a remote phone’s registration status RIS on that 
node won’t either.

-Ryan

On Feb 10, 2015, at 5:19 PM, Brian Meade 
bmead...@vt.edumailto:bmead...@vt.edu wrote:

Right, could be an SDL link down.  I've seen this caused by RIS issues where 
the node receiving the call doesn't think the phone is registered (can't find 
the LineControl process).  Restarting RISDC usually fixes it.

On Tue, Feb 10, 2015 at 4:26 PM, Ryan Ratliff (rratliff) 
rratl...@cisco.commailto:rratl...@cisco.com wrote:
How would this be RIS?

More like an SDL connection that’s down, or leaked a call on the sub.  Register 
a phone to the sub and see if you can call to/from another phone registered 

Re: [cisco-voip] 79xx and the ITL, without access to the existing phone system

[Daniel Pagan]

Jonathan:

I’ll zip and email a copy to you directly. What I don’t have however is 
documentation on the tool. I was given a wiki URL that doesn’t work.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Jonathan Charles
Sent: Thursday, March 05, 2015 12:07 PM
To: Ryan Ratliff (rratliff)
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] 79xx and the ITL, without access to the existing 
phone system

Can you share the file?


Thanks!


Jonathan

On Mon, Mar 2, 2015 at 10:18 AM, Ryan Ratliff (rratliff) 
rratl...@cisco.commailto:rratl...@cisco.com wrote:
If the phones will register and have settings access enabled you can use the 
Cisco EraseITL utility to wipe them.  You can get it from TAC if you don’t have 
a copy handy.

-Ryan

On Mar 2, 2015, at 9:48 AM, Ryan Huff 
ryanh...@outlook.commailto:ryanh...@outlook.com wrote:

About 1K of 79xx phones on a ccm 8.X going to ccm 10.5. So CTL/ITL is an issue. 
There are lots of ways to solve this with access to the previous phone system, 
I know.

The catch for me is, I DO NOT have access to the previous phone system or the 
previous phone certificates (would be so much easier if I did, I know).

Anyone have any dark magic I can script though the SSH / Web Server client on 
the phone that doesn't require me to bind to a valid ccm user from the previous 
system or in any other way, reference the previous system?

Any other ideas?

Thanks,

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


___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] Errors 18 and 19 on incoming call only through subscriber

[Daniel Pagan]

Final thing to mention is that while I've come across that defect numerous 
times, I've never seen it impact Hunt Lists so I'd be more inclined to suspect 
CSCtr83193 but CCM SDI/SDL traces should help regardless. Place a test call and 
search your traces for dd=dialed-digits... Further down digit analysis 
results (assuming the HL is registered to the same node as your calling phone) 
find RouteListControl followed by HuntListCdrc for more detail on the issue 
from the perspective of your line group members and hunt list.

Hope this helps.

- Dan



Sent from my mobile device.

On Mar 5, 2015, at 10:18 PM, Daniel Pagan 
dpa...@fidelus.commailto:dpa...@fidelus.com wrote:

I’d also say a similar defect would be CSCul71689 – a defect I came across 
quite often on 8.6(2). Like Brian said, hunt lists use RouteListControl which 
creates HuntListCdrc for call distribution to your line group members. With 
either defect, I’d say another possible workaround would be to register the 
hunt list to another call processing server so that this particular instance of 
RouteListControl runs on a different node. Aside from a reset of the HL and 
registering it to another server, my last option would be to reset the CCM 
service if one of these is indeed a defect you’re hitting.

Also, as Robert mentioned, detailed CCM SDI  SDL traces would confirm which 
one you’re hitting (if any of them of course).

The one you found appears to be an issue where RouteListControl itself rejects 
the call since (I’m assuming) it cannot locate the process instance for your 
LG/RG member, whereas the defect I listed above results in RouteListControl and 
RouteListCdrc locating the the LG/RG member but will detect and print them as 
“DOWN” despite their availability.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of ROZA, 
Ariel
Sent: Thursday, March 05, 2015 5:36 PM
To: Brian Meade
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] Errors 18 and 19 on incoming call only through 
subscriber

Thanks. So, the short term workaround would be to restart the CCM Service, 
until I can apply the latest service release. Right?

From: bmead...@gmail.commailto:bmead...@gmail.com [mailto:bmead...@gmail.com] 
On Behalf Of Brian Meade
Sent: jueves, 05 de marzo de 2015 07:15 p.m.
To: ROZA, Ariel
Cc: Ryan Ratliff (rratliff); cisco-voip voyp list
Subject: Re: [cisco-voip] Errors 18 and 19 on incoming call only through 
subscriber

Hunt Lists use the RouteListControl process as well so definitely could be the 
issue.

On Thu, Mar 5, 2015 at 5:13 PM, ROZA, Ariel 
ariel.r...@la.logicalis.commailto:ariel.r...@la.logicalis.com wrote:
I think I may be hitting this bug:

https://tools.cisco.com/bugsearch/bug/CSCtr83193

It applies to Route Lists instead of Hunt Lists, but the symptoms look similar, 
and the CUCM version matches..

What do you think?

Regards,
Ariel Roza
Service Delivery Consultant  / Argentina
Logicalis
Tel: +54 11 5282 - 0458tel:%2B54%2011%205282%20-%200458
ariel.r...@la.logicalis.commailto:ariel.r...@la.logicalis.com
Peru 327 – CABA – Argentina – C1067AAG
www.la.logicalis.comhttp://www.la.logicalis.com/
_
Business and technology working as one

Síguenos en: image001.pnghttp://twitter.com/LogicalisLatam 
image002.pnghttp://es-es.facebook.com/pages/Logicalis-Latam/234648439078 
image003.pnghttp://www.youtube.com/logicalislatam 
image004.jpghttp://www.slideshare.net/logicalis 
image005.jpghttp://www.cxounplugged.com/
image006.jpg



From: cisco-voip 
[mailto:cisco-voip-boun...@puck.nether.netmailto:cisco-voip-boun...@puck.nether.net]
 On Behalf Of ROZA, Ariel
Sent: jueves, 05 de marzo de 2015 06:56 p.m.
To: Ryan Ratliff (rratliff); Brian Meade
Cc: cisco-voip voyp list

Subject: Re: [cisco-voip] Errors 18 and 19 on incoming call only through 
subscriber

Hi, Guys…

I restarted RIS on both nodes and did not do a thing, so I guess Ryan might be 
right. What´s the alternative? Restarting the Callmanager Service? Rebooting 
the whole sub? Both Sub and Pub?

I have h225, h245 and full ccm traces if there´s any use for them.

Regards,

Ariel.

From: Ryan Ratliff (rratliff) [mailto:rratl...@cisco.com]
Sent: miércoles, 11 de febrero de 2015 11:23 a.m.
To: Brian Meade
Cc: ROZA, Ariel; cisco-voip voyp list
Subject: Re: [cisco-voip] Errors 18 and 19 on incoming call only through 
subscriber

RIS shouldn’t be involved in that flow, though it does read from the same 
shared memory segment that the ccm process does so unless RIS itself is screwed 
I’d expect if ccm doesn’t know a remote phone’s registration status RIS on that 
node won’t either.

-Ryan

On Feb 10, 2015, at 5:19 PM, Brian Meade 
bmead...@vt.edumailto:bmead...@vt.edu wrote:

Right, could be an SDL link down.  I've seen this caused by RIS issues where 
the node receiving the call doesn't think the phone is registered (can't find 
the LineControl process).  Restarting RISDC usually fixes it.

On Tue, Feb 10, 2015 at 4:26

Re: [cisco-voip] Add new vCPU of CUCM server

[Daniel Pagan]

Just to add to Anthony’s email, I suggest making sure to add to the vCPU socket 
count, not number of vCPU cores per socket. Also note that you can increase 
your vCPU socket count but should *not* decrease it – this is not supported.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Anthony Holloway
Sent: Monday, February 23, 2015 6:51 PM
To: Claiton Campos; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Add new vCPU of CUCM server

Yes.  You would need to shutdown the VM first, and then just add the new vCPU 
count under Edit Settings of the VM.  It's the disks which you cannot simply 
increase from within VMWare.

This is something I did recently during an upgrade of CUCM from 8x to 10x on a 
C210M2 which was using the 2500 user OVA.

This is what I read which prompted me to change mine:

“The 2500 user VM configuration with one vcpu may exhibit performance issues 
during CPU/IO-intensive operations (such as installs, upgrades, backups and CDR 
writes), or if your deployment has certain characteristics such as a large 
quantity of TFTP files. Changing the VM config to 2 vcpu is recommended as a 
prevention strategy.”

Source: 
http://docwiki.cisco.com/wiki/Virtualization_for_Cisco_Unified_Communications_Manager_(CUCM)#Notes_on_2500_user_VM_configurations

On Mon Feb 23 2015 at 5:42:14 PM Claiton Campos 
claitoncam...@gmail.commailto:claitoncam...@gmail.com wrote:

Hello , someone has come to change the amount of vCPU a CUCM server in 
production? Recently 'm having problems with high throughput publisher server 
and as directed by the TAC is suggested to add a new vCPU to the server. My 
question is whether the server recognizes this new vCPU .
___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] CUBE SIP TCP connection timeout

[Daniel Pagan]

After re-reading my email, perhaps my words were a bit harsh on that section of 
the SRND :) but I do think the timer statement might need to be revisited and 
possibly rewritten.

Good weekend to all!

- Dan


On Feb 6, 2015, at 5:38 PM, Daniel Pagan 
dpa...@fidelus.commailto:dpa...@fidelus.com wrote:

Thanks Anthony :)

That’s interesting that it’s suggested to use ICMP for monitoring CUCM up/down 
state from the perspective of a SIP gateway. I’m surprised and was honestly 
expecting the doc to be old and certainly not a 10.x SRND since this method 
doesn’t provide the SIP UA with application-layer-related state information for 
UCM.

Also… whoever wrote “up to 3 seconds” with default settings should run that in 
a lab scenario with a stopwatch.

- Dan

From: Anthony Holloway [mailto:avholloway+cisco-v...@gmail.com]
Sent: Friday, February 06, 2015 1:26 AM
To: Daniel Pagan; cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CUBE SIP TCP connection timeout

Great writeup Daniel!

I found it interesting that the CUCM 10.x SRND states:

SIP Gateway
Redundancy with Cisco IOS SIP gateways can be achieved similarly to H.323. If 
the SIP gateway cannot establish a connection to the primary Unified CM, it 
tries a second Unified CM defined under another dial-peer statement with a 
higher preference.

By default the Cisco IOS SIP gateway transmits the SIP INVITE request 6 times 
to the Unified CM IP address configured under the dial-peer. If the SIP gateway 
does not receive a response from that Unified CM, it will try to contact the 
Unified CM configured under the other dial-peer with a higher preference.

Cisco IOS SIP gateways wait for the SIP 100 response to an INVITE for a period 
of 500 ms. By default, it can take up to 3 seconds for the Cisco IOS SIP 
gateway to reach the backup Unified CM. You can change the SIP INVITE retry 
attempts under the sip-ua configuration by using the command retry invite 
number. You can also change the period that the Cisco IOS SIP gateway waits 
for a SIP 100 response to a SIP INVITE request by using the command timers 
trying time under the sip-ua configuration.

One other way to speed up the failover to the backup Unified CM is to configure 
the command monitor probe icmp-ping under the dial-peer statement. If Unified 
CM does not respond to an Internet Control Message Protocol (ICMP) echo message 
(ping), the dial-peer will be shut down. This command is useful only when the 
Unified CM is not reachable. ICMP echo messages are sent every 10 seconds.

Source: 
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab10/collab10/gateways.html#pgfId-1044200

I found this interesting, because it says, By default, it can take up to 3 
seconds for the Cisco IOS SIP gateway to reach the backup Unified CM.  Maybe 
they meant to drop a 2 in there for 32 seconds?  Well, in the paragraph 
preceding that statement, they mention the default INVITE retry value of 6; and 
6 * 500ms = 3 seconds.  I think they forgot the interval doubling.

Actually, I found it interesting for a second reason as well: they recommend 
ICMP to monitor the peer, instead of SIP OPTIONS.  I'm not certain if this is a 
best practice recommendation, an error, or them simply listing one of several 
possible ways to monitor a SIP peer.

On Thu Feb 05 2015 at 3:54:56 PM Daniel Pagan 
dpa...@fidelus.commailto:dpa...@fidelus.com wrote:
Since we're on the topic of SIP timers, timeouts, etc., I figured why not share 
some additional information with the list. Below is a write-up of SIP timers T1 
and Timer-B I wrote some time ago. Hopefully someone will this useful at some 
point.

This isn’t mentioned in CUCM service parameter descriptions, but really the SIP 
TRYING timer represents what’s called the SIP T1 timer. T1 is a baseline value 
used by another timer called Timer-A, and it’s what controls the intervals 
which our INVITEs are sent when no response is received. There's also Timer-B, 
which determines how long to wait, in total, before the request itself should 
expire, and is calculated by 64 * T1. So if our T1 (TRYING) timer is 500ms, 
then our Timer-B value is 32 seconds. Note this does not impact SIP over TCP 
when the TCP socket itself fails to establish since a three-way handshake would 
first be required.

The important part about the SIP T1 timer and INVITE requests is that T1 does 
not exactly define how long to wait between re-transmissions. Instead, we 
multiply T1 to determine how long to wait between INVITE retry attempts. Here’s 
an excerpt from RFC 3261 describing this:

If an unreliable transport is being used, the client transaction MUST start 
timer A with a value of T1. If a reliable transport is being used, the client 
transaction SHOULD NOT start timer A (Timer A controls request 
retransmissions).  For any transport, the client transaction MUST start timer B 
with a value of 64*T1 seconds (Timer B controls transaction timeouts). When 
timer

Re: [cisco-voip] CUBE SIP TCP connection timeout

[Daniel Pagan]

Since we're on the topic of SIP timers, timeouts, etc., I figured why not share 
some additional information with the list. Below is a write-up of SIP timers T1 
and Timer-B I wrote some time ago. Hopefully someone will this useful at some 
point.

This isn’t mentioned in CUCM service parameter descriptions, but really the SIP 
TRYING timer represents what’s called the SIP T1 timer. T1 is a baseline value 
used by another timer called Timer-A, and it’s what controls the intervals 
which our INVITEs are sent when no response is received. There's also Timer-B, 
which determines how long to wait, in total, before the request itself should 
expire, and is calculated by 64 * T1. So if our T1 (TRYING) timer is 500ms, 
then our Timer-B value is 32 seconds. Note this does not impact SIP over TCP 
when the TCP socket itself fails to establish since a three-way handshake would 
first be required.

The important part about the SIP T1 timer and INVITE requests is that T1 does 
not exactly define how long to wait between re-transmissions. Instead, we 
multiply T1 to determine how long to wait between INVITE retry attempts. Here’s 
an excerpt from RFC 3261 describing this:

If an unreliable transport is being used, the client transaction MUST start 
timer A with a value of T1. If a reliable transport is being used, the client 
transaction SHOULD NOT start timer A (Timer A controls request 
retransmissions).  For any transport, the client transaction MUST start timer B 
with a value of 64*T1 seconds (Timer B controls transaction timeouts). When 
timer A fires [expires], the client transaction MUST retransmit the request by 
passing it to the transport layer, and MUST reset the timer with a value of 
2*T1.  ……. 

When timer A fires [expires] 2 x T1 seconds later, the request MUST be 
retransmitted again. This process MUST continue so that the request is 
retransmitted with intervals that double after each transmission. These 
retransmissions SHOULD only be done while the client transaction is in the 
calling state.

The default value for T1 is 500 ms.  T1 is an estimate of the RTT between the 
client and server transactions.

What does this mean? Let’s use the default of 500 msecs TRYING and retry INVITE 
value of 6 as an example:

Time: 0 msecs passed | Start Timer-A (or… Trying timer) – value 500 msecs
INVITE --
No response received and Trying timer expires.

Time: 500 msecs passed | Start Trying timer – new value 1000 msecs
INVITE --
No response received and Trying timer expires.

Time: 1500 msecs passed | Start Trying timer – new value 2000 msecs
INVITE --
No response received and Trying timer expires.

Time: 3500 msecs passed | Start Trying timer – new value 4000 msecs
INVITE --
No response received and Trying timer expires.

Time: 7500 msecs passed | Start Trying timer – new value 8000 msecs
INVITE --
No response received and Trying timer expires.

Time: 15500 msecs passed | Start Trying timer – new value 16000 msecs
INVITE --
No response received and Trying timer expires.
Time required for time-out of our INVITE attempts = 31500 msecs 

In other words, the Trying timer will double again and again until either the 
INVITE retry value is reached or Timer-B expires. With a default of six INVITE 
retries and a T1/Trying timer of 500 msecs, our total time required until our 
INVITE retries are exhausted is ~32 seconds. It’s at this point that 
RouteListControl attempts to route the call through our next Route Group member 
or Route Group (assuming we're talking about CUCM). If CUBE, then the next 
preference dial-peer.

Note that SIP over TCP transport still uses these timers, but a reliable 
transport protocol ensures that a 3-way handshake is performed before 
delivering the request to the transport layer. CUCM still uses these timers 
even for SIP requests over TCP despite RFC 3261 saying that Timer-A should not 
be used for TCP but it’s okay – it doesn’t say it must not be used so it's fair 
game.

You can read more about this in sections 17.1.1.1 and 17.1.1.2 in RFC 3261 here:
http://www.ietf.org/rfc/rfc3261.txt 

In addition to the RFC, there’s an easy to follow article that also describes 
this process in detail: 
http://andrewjprokop.wordpress.com/2013/07/02/understanding-sip-timers-part-i/

Hope this helps.

- Dan

-Original Message-
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Thursday, February 05, 2015 2:33 PM
To: gen...@ucpenguin.com; cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CUBE SIP TCP connection timeout

If we're talking about transport level timeout, it looks like the command is 
available in CUBE SP Edition:

In addition to the SIP protocol-level timers, Cisco Unified Border Element (SP 
Edition) also allows modification of transport-related timer commands: 
tcp-connect-timeout (how long TCP SYN will wait for the reply) and 
tcp-idle-timeout (how long TCP connection should stay active while idle). 
Although these timers are transport

Re: [cisco-voip] CUBE SIP TCP connection timeout

[Daniel Pagan]

If we're talking about transport level timeout, it looks like the command is 
available in CUBE SP Edition:

In addition to the SIP protocol-level timers, Cisco Unified Border Element (SP 
Edition) also allows modification of transport-related timer commands: 
tcp-connect-timeout (how long TCP SYN will wait for the reply) and 
tcp-idle-timeout (how long TCP connection should stay active while idle). 
Although these timers are transport-level values, Cisco IOS XE Release 2.4 
supports these timers in SIP only, but not in H.323, nor H.248

For the tcp-connect-timeout command: Configures the time (in milliseconds) 
that SBC waits for a SIP TCP connection to a remote peer to complete before 
failing that connection. The default timeout interval is 1000 milliseconds.

In practice, specifically at UCM, I wouldn't expect to see a transmitted INVITE 
in situations where the TCP socket cannot be established, so I'm not sure how 
well the sip-ua timers below would help. 

If it's an option, perhaps using UDP and modifying the retry invite value and 
TRYING timer as  ucpenguin mentioned below. I'm sure you know of the options 
keepalive method. One last thing would be to mention the TRYING timer doubles 
for each INVITE sent without a response until the retry INVITE value is reached 
(I've seen this cause up to 32 seconds of delay with default values). 

Hope this helps.

- Dan

-Original Message-
From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
gen...@ucpenguin.com
Sent: Thursday, February 05, 2015 1:49 PM
To: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] CUBE SIP TCP connection timeout

Not sure why this didn't hit the list the first time I sent it, maybe its just 
slow.

Anyways:

sip-ua
  retry invite 2
  timers trying 100

On 2015-02-05 12:32, Brian Meade wrote:
 Hey all,
 
 Does anyone know a SIP equivalent of h225 timeout tcp establish?
 
 The default SIP TCP timeout is 5 seconds:
 
 001306: Feb  4 20:44:34.164: %VOICE_IEC-3-GW: SIP: Internal Error 
 (Socket error): IEC=1.1.186.7.7.4 on callID 3254
 GUID=5BBD7EFBAC0F11E4997499045654EBE2
 001307: Feb  4 20:44:39.167: %VOICE_IEC-3-GW: SIP: Internal Error 
 (Socket error): IEC=1.1.186.7.7.4 on callID 3255
 GUID=5BBD7EFBAC0F11E4997499045654EBE2
 
 This results in failover to a 3rd dial-peer taking 10 seconds when our 
 main DC is down.
 
 There's nothing under the sip-ua configuration that will change the 
 TCP timeout.  It looks like this may not be configurable.
 
 Anyone have any ideas?
 
 Thanks,
 Brian Meade
 ___
 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] Changing DNS entries in Call Manager 8.6.2

[Daniel Pagan]

The DNS assignments make up part of the hash used to generate the license MAC 
address in UCM 8.x. If you need to  update the DNS entries, my recommendation 
would be to simply:


1.   Document the current license MAC address. Would also be helpful to to 
have your Cisco TAC support contract number (if needed).

2.   Update the DNS entries

3.   Document the new license MAC address

4.   Open a TAC case to request for a new license based on the new license 
MAC. Provide them with the old and new MAC addresses.

Useful Link - describes the license MAC in CUCM 8.x
https://supportforums.cisco.com/discussion/11634991/cucm-86-license-mac-changes-when-modifying-ntp-server

Changing any of these (DNS, NTP, IP Address, etc.) on a UCM 8.x Publisher will 
require installing a new license, but getting this done and license updated is 
a pretty simple and straight forward task assuming you have the right info 
handy for TAC. Worst case, if you have issues getting a new license file would 
be to revert back to your previous DNS entries - putting it back to previous 
configurations (assuming nothing else was changed) will generate your old 
license MAC address, validating the license file that was just previously 
invalidated. This entire process changed in CUCM 9.x and higher using Cisco 
ELM/PLM.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Gyrion, Larry
Sent: Monday, January 26, 2015 5:39 PM
To: Cisco-voip (cisco-voip@puck.nether.net)
Subject: [cisco-voip] Changing DNS entries in Call Manager 8.6.2

Looking for some guidance on updating the DNS entries on our CUCM cluster.  A 
colleague went through the process, but upon entering the command received a 
warning stating that the change would invalidate our licenses.  Has anybody 
come across this before, and if so, what was the proper course of action to 
ensure license preservation?
CUCM 8.6.2


Thank you,
Larry Gyrion | Telecommunications Analyst | Information Technology
Dean Clinic - Corporate offices
1800 W. Beltline Hwy
Madison WI. 53713
Phone 608.294.6201 | 5406201| Fax 608.280.6852
larry.gyr...@deancare.commailto:larry.gyr...@deancare.com | 
www.deancare.comhttp://www.deancare.com/
Partners who care


The information contained in this e-mail message and any attachments may be 
proprietary and is intended only for the confidential use of the designated 
recipient named above. If the reader of this message is not the intended 
recipient or an agent responsible for delivering it to the intended recipient, 
you are hereby notified that you have received this document in error and that 
any review, dissemination, distribution or copying of this message is strictly 
prohibited. If you have received this communication in error please notify us 
immediately at the e-mail address listed above. Thank you.


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

Re: [cisco-voip] Changing DNS entries in Call Manager 8.6.2

[Daniel Pagan]

Quick correction - I should have said the primary DNS server assignment and 
not simply DNS assignments, which after reading my message a 2nd time might 
imply that any DNS entry change would regenerate a new license MAC.

Hope this helps.

- Dan

From: Daniel Pagan
Sent: Monday, January 26, 2015 6:01 PM
To: 'Gyrion, Larry'; Cisco-voip (cisco-voip@puck.nether.net)
Subject: RE: Changing DNS entries in Call Manager 8.6.2

The DNS assignments make up part of the hash used to generate the license MAC 
address in UCM 8.x. If you need to  update the DNS entries, my recommendation 
would be to simply:


1.   Document the current license MAC address. Would also be helpful to to 
have your Cisco TAC support contract number (if needed).

2.   Update the DNS entries

3.   Document the new license MAC address

4.   Open a TAC case to request for a new license based on the new license 
MAC. Provide them with the old and new MAC addresses.

Useful Link - describes the license MAC in CUCM 8.x
https://supportforums.cisco.com/discussion/11634991/cucm-86-license-mac-changes-when-modifying-ntp-server

Changing any of these (DNS, NTP, IP Address, etc.) on a UCM 8.x Publisher will 
require installing a new license, but getting this done and license updated is 
a pretty simple and straight forward task assuming you have the right info 
handy for TAC. Worst case, if you have issues getting a new license file would 
be to revert back to your previous DNS entries - putting it back to previous 
configurations (assuming nothing else was changed) will generate your old 
license MAC address, validating the license file that was just previously 
invalidated. This entire process changed in CUCM 9.x and higher using Cisco 
ELM/PLM.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Gyrion, Larry
Sent: Monday, January 26, 2015 5:39 PM
To: Cisco-voip (cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net)
Subject: [cisco-voip] Changing DNS entries in Call Manager 8.6.2

Looking for some guidance on updating the DNS entries on our CUCM cluster.  A 
colleague went through the process, but upon entering the command received a 
warning stating that the change would invalidate our licenses.  Has anybody 
come across this before, and if so, what was the proper course of action to 
ensure license preservation?
CUCM 8.6.2


Thank you,
Larry Gyrion | Telecommunications Analyst | Information Technology
Dean Clinic - Corporate offices
1800 W. Beltline Hwy
Madison WI. 53713
Phone 608.294.6201 | 5406201| Fax 608.280.6852
larry.gyr...@deancare.commailto:larry.gyr...@deancare.com | 
www.deancare.comhttp://www.deancare.com/
Partners who care


The information contained in this e-mail message and any attachments may be 
proprietary and is intended only for the confidential use of the designated 
recipient named above. If the reader of this message is not the intended 
recipient or an agent responsible for delivering it to the intended recipient, 
you are hereby notified that you have received this document in error and that 
any review, dissemination, distribution or copying of this message is strictly 
prohibited. If you have received this communication in error please notify us 
immediately at the e-mail address listed above. Thank you.


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

Re: [cisco-voip] ParkingLotD and SNR | Leaked Calls on StationD

[Daniel Pagan]

I set this up in a lab and it looks like the issue can be recreated in CUCM 
10.x as well...


1.   Enable and setup SNR for a user

2.   Configure the Remote Destination to an invalid number - force DA for 
SNRD to fail.

3.   Configure the Remote Destination for User Control voicemail policy

4.   Call the user's DN x number of times, where x equals your busy trigger 
value.

Can't seem to find a matching, publicly available defect for this so I opened a 
TAC case. The problem cannot be recreated when the Remote Destination's 
voicemail policy is Timer Control instead of User Control, and I fail to 
see ParkingLotD or ParkingLotCdpc when I'm not using User Control so it must 
be related.

The original call sends CcSetup to SNRD which results in a DA request. Although 
the request fails, we still invoke ParkingLotD/Cdpc and perform another DA 
request but to the user's DN instead of the Remote Destination. This seems to 
create another set of CIs and extends another CcSetup to StationD. Run this 
call flow a few times till the busy trigger is hit and the user-facing symptoms 
are:


1.   Inbound calls route immediately to VM since the busy trigger is reached

2.   Potentially user sees Error Pass Limit if Max Calls are reached - 
user cannot activate the line or place a call.

Resetting the phone associated to the StationD process leaking the call appears 
to be a workaround. Permanent solution is correct the Remote Destination so DA 
is successful or set the voicemail policy to Timer Control.

- Dan


From: Daniel Pagan
Sent: Tuesday, January 13, 2015 11:53 AM
To: cisco-voip@puck.nether.net
Subject: ParkingLotD and SNR | Leaked Calls on StationD

Folks:

Hoping someone can tell me if and how ParkingLotD and ParkingLotCdpc are 
related to outbound SNR calls. I'm looking at an SNR call and in SDL traces I'm 
seeing DA for CellProxy followed by a InitiateCallWithFeatureReq from Cc to 
ParkingLotD. I'm wondering what this event is for because I suspect it's 
related to a series of stuck/stale CI's. Both processes seem to be related to 
SNR when User Control is enabled at the Remote Destination. I'm familiar with 
CSCub55072 and it doesn't appear to be related.

There's an issue where calls seem to be leaking in the following call flow:


1.   Inbound call to DN over SIP trunk

2.   DN associated to Remote Destination

3.   CcSetup to the associated SNRD results in a rejection due to the 
remote destination failing on DA - the remote destination itself was configured 
incorrectly.

4.   Even though DA failed for SNRD, we have a 2nd successful DA to the 
called DN which appears to be related to ParkingLotCdpc. StationD receives this 
2nd CcSetup while stating it's a VMA call.

The user answers the inbound call and eventually disconnects. Later, another 
call arrives to his DN, LineControl reports ZERO active calls, but the StationD 
process reports ONE active call. Later, StationD will report TWO active calls 
while LineControl accurately reports ZERO. I'm familiar with CSCub55072 and it 
doesn't appear to be related.
Should we expect to see ParkingLotD and ParkingLotCdpc involved when DA fails 
to the remote destination? I'm setting this up in a lab environment now and 
fairly certain the call shouldn't extend this far when SNRD's DA fails, causing 
a 2nd DA to the called DN for no reason, which might explain the call leakage 
to StationD since CCM is sending it a 2nd VMA call for a failed SNR.

- Dan


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

[cisco-voip] H245Interface Related Processes

[Daniel Pagan]

Folks:

Hoping to get some insight on SDL process creation for H245...

Scenario is three CUCM clusters communicating over ICTs. Call is routed from 
Cluster-1 to Cluster-2... then Cluster-2 to Cluster-3. Cluster-3 sends the H245 
address  port info via H225 ALERTING to Cluster-2, which then sends its own to 
Cluster-1. Issue is Cluster-1 never establishes the H245 session with 
Cluster-2. The H245 address and port is received on Cluster-1 but no H245 
processes are being created for the MSD/TCS exchange. According to SDL traces 
on Cluster-2, the latest state of H245 on the node *sending* the ALERTING 
message is waitForTransportEstablishment. On Cluster-1, the H245Interface 
process is never created according to SDL traces, so we never even reach the 
opportunity for TCS media caps exchange. MXTimeout occurs shortly after.

Question is... For a node receiving an H245 address  port info via H225 (the 
calling cluster...), is creation of the H245Interface and/or related H245 
process dependent on CUCM *first* establishing the new, 2nd TCP socket with the 
remote H.323 endpoint that advertised the H.245 port. In other words, at an SDL 
level, is H245Interface created only after the 2nd TCP session is successfully 
established at the transport level for H245 TCP communication? Knowing this 
would help me assess the likelihood of the issue being related to issues at the 
TCP level.

Thanks!

- Dan


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

Re: [cisco-voip] H245Interface Related Processes

[Daniel Pagan]

Thanks Ryan - that's what I was hoping to hear. I'll try to set this up in a 
lab to confirm with some simple ACLs.

- Dan

From: Ryan Ratliff (rratliff) [mailto:rratl...@cisco.com]
Sent: Monday, December 01, 2014 5:33 PM
To: Daniel Pagan
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] H245Interface  Related Processes

Short answer without confirming in the lab is yes, when I send you my H245 
address I expect you to start a TCP connection to me on that port so we can 
start H245.


-Ryan

On Dec 1, 2014, at 5:12 PM, Daniel Pagan 
dpa...@fidelus.commailto:dpa...@fidelus.com wrote:

Folks:

Hoping to get some insight on SDL process creation for H245...

Scenario is three CUCM clusters communicating over ICTs. Call is routed from 
Cluster-1 to Cluster-2... then Cluster-2 to Cluster-3. Cluster-3 sends the H245 
address  port info via H225 ALERTING to Cluster-2, which then sends its own to 
Cluster-1. Issue is Cluster-1 never establishes the H245 session with 
Cluster-2. The H245 address and port is received on Cluster-1 but no H245 
processes are being created for the MSD/TCS exchange. According to SDL traces 
on Cluster-2, the latest state of H245 on the node *sending* the ALERTING 
message is waitForTransportEstablishment. On Cluster-1, the H245Interface 
process is never created according to SDL traces, so we never even reach the 
opportunity for TCS media caps exchange. MXTimeout occurs shortly after.

Question is... For a node receiving an H245 address  port info via H225 (the 
calling cluster...), is creation of the H245Interface and/or related H245 
process dependent on CUCM *first* establishing the new, 2nd TCP socket with the 
remote H.323 endpoint that advertised the H.245 port. In other words, at an SDL 
level, is H245Interface created only after the 2nd TCP session is successfully 
established at the transport level for H245 TCP communication? Knowing this 
would help me assess the likelihood of the issue being related to issues at the 
TCP level.

Thanks!

- Dan
___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] H245Interface Related Processes

[Daniel Pagan]

Hey Brian – hope you’re doing well. This is a difficult issue to reproduce so a 
pcap would be tricky to obtain.

I’ll try and recreate the issue in a lab and see what results I get from an SDL 
process creation standpoint.

Thanks!

- Dan


From: bmead...@gmail.com [mailto:bmead...@gmail.com] On Behalf Of Brian Meade
Sent: Monday, December 01, 2014 5:51 PM
To: Ryan Ratliff (rratliff)
Cc: Daniel Pagan; cisco-voip voyp list
Subject: Re: [cisco-voip] H245Interface  Related Processes

Also should be fairly easy to capture via a packet capture on Cluster 1 if this 
is easily reproducible for the call flow.

Brian

On Mon, Dec 1, 2014 at 5:32 PM, Ryan Ratliff (rratliff) 
rratl...@cisco.commailto:rratl...@cisco.com wrote:
Short answer without confirming in the lab is yes, when I send you my H245 
address I expect you to start a TCP connection to me on that port so we can 
start H245.


-Ryan

On Dec 1, 2014, at 5:12 PM, Daniel Pagan 
dpa...@fidelus.commailto:dpa...@fidelus.com wrote:

Folks:

Hoping to get some insight on SDL process creation for H245…

Scenario is three CUCM clusters communicating over ICTs. Call is routed from 
Cluster-1 to Cluster-2… then Cluster-2 to Cluster-3. Cluster-3 sends the H245 
address  port info via H225 ALERTING to Cluster-2, which then sends its own to 
Cluster-1. Issue is Cluster-1 never establishes the H245 session with 
Cluster-2. The H245 address and port is received on Cluster-1 but no H245 
processes are being created for the MSD/TCS exchange. According to SDL traces 
on Cluster-2, the latest state of H245 on the node *sending* the ALERTING 
message is “waitForTransportEstablishment”. On Cluster-1, the H245Interface 
process is never created according to SDL traces, so we never even reach the 
opportunity for TCS media caps exchange. MXTimeout occurs shortly after.

Question is… For a node receiving an H245 address  port info via H225 (the 
calling cluster…), is creation of the H245Interface and/or related H245 process 
dependent on CUCM *first* establishing the new, 2nd TCP socket with the remote 
H.323 endpoint that advertised the H.245 port. In other words, at an SDL level, 
is H245Interface created only after the 2nd TCP session is successfully 
established at the transport level for H245 TCP communication? Knowing this 
would help me assess the likelihood of the issue being related to issues at the 
TCP level.

Thanks!

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


___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] 7945 more button does nothing under ITL (can't delete the ITL)

[Daniel Pagan]

Funny it certainly is.  Reminds me of a quirky issue we found a while back. Had 
a customer who opened a case saying his phone was a vampire. The customer said 
his phone calls were being disconnected by sunlight. His phone was positioned 
on a desk where direct sunlight would hit the phone at around lunch time, and 
his calls would start disconnected every day at this time. It was hard to 
believe at first until we received a video showing the issue occur… it was 
unexpected to say the least.

Resulted in creating https://tools.cisco.com/bugsearch/bug/CSCtf65633

Turned out the optical hook-switch was being triggered by sunlight.

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Jason 
Aarons (AM)
Sent: Wednesday, October 01, 2014 1:13 PM
To: Jeffrey Girard; Ryan Ratliff (rratliff)
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] 7945 more button does nothing under ITL (can't delete 
the ITL)

This is too funny.  Yeah the button on the phone is broke. I can’t believe it!! 
 We will have the customer RMA this phone….



From: Jeffrey Girard [mailto:jeffrey.gir...@girardinc.com]
Sent: Wednesday, October 01, 2014 12:36 PM
To: Jason Aarons (AM); Ryan Ratliff (rratliff)
Cc: cisco-voip voyp list
Subject: RE: [cisco-voip] 7945 more button does nothing under ITL (can't delete 
the ITL)


Jason –
I just watched your video.  Could it possibly be/have you 
checked mechanical?  Have you confirmed that the mechanical aspects of the 
physical button is actually working?  For example, at the beginning of your 
video with the phone onhook, have you tried to press the “More” button at that 
point to confirm that the physical button is actually working?

--
Dr. Jeffrey T. Girard (Jeff), PhD
Colonel, United States Army (Retired)
Senior Network Engineer / VoIP Engineer - WireMeHappy.com
(607) 835-0406 (home office)
(845) 764-1661 (mobile)
(607) 835-0458 (fax)

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Jason 
Aarons (AM)
Sent: Wednesday, October 01, 2014 12:07 PM
To: Ryan Ratliff (rratliff)
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] 7945 more button does nothing under ITL (can't delete 
the ITL)

The More button doesn’t work to erase the ITL when it’s showing unlocked.

Video Demo
https://www.youtube.com/watch?v=LRmVNPqLGtw

From: Ryan Ratliff (rratliff) [mailto:rratl...@cisco.com]
Sent: Wednesday, October 01, 2014 12:01 PM
To: Jason Aarons (AM)
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] 7945 more button does nothing under ITL (can't delete 
the ITL)

Looks like a timing issue that you should easily be able to work around. If you 
are seeing a lock icon then this isn't your bug.

1. Navigate to Trust List -- ITL file, we can see a secure lock icon ahead of 
the ITL file item name.

2. Unlock and erase ITL file. Menu will automatically closed and phone start to 
download ITL file again.

3. Before phone finishing restarting, navigate to Trust List -- ITL file 
again, we can see ITL file has already been downloaded again. But no secure 
lock icon displayed ahead of ITL file.

4. No matter how long waited, this display will not change, unless exit Trust 
List and enter again.

If in doubt factory reset the phone.
-Ryan

On Oct 1, 2014, at 10:01 AM, Jason Aarons (AM) 
jason.aar...@dimensiondata.commailto:jason.aar...@dimensiondata.com wrote:

CSCti99770

I have a 7945 SCCP 9.1.1SR1S  that I can’t press the More button in the ITL (it 
shows unlocked) to delete the ITL.  Is the above my bug?  What is the fix?  It 
shows insufficient permissions in Bug Tooklit.

We hit CSCtn50405 CUCM DRF Backup does not backup certificates with a same 
version hardware replacement.
___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto:cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip



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

Re: [cisco-voip] 7945 more button does nothing under ITL (can't delete the ITL)

[Daniel Pagan]

I noticed the defect details mention 8.5(2) as well. Old case notes shows the 
problem was resolved with an RMA a few months after it was discovered, and 
turned out being the result of a hardware re-design leading to sunlight leaking 
into the hook-switch. This was in early 2010 and the replacements were ready a 
few months after that.

But watching the customer activating a line appearance by blocking his phone 
from the sun via Jedi mind trick gestures… that was rather interesting ☺

- Dan

From: Heim, Dennis [mailto:dennis.h...@wwt.com]
Sent: Wednesday, October 01, 2014 2:23 PM
To: Daniel Pagan; Jason Aarons (AM); Jeffrey Girard; Ryan Ratliff (rratliff)
Cc: cisco-voip voyp list
Subject: RE: [cisco-voip] 7945 more button does nothing under ITL (can't delete 
the ITL)

So the sunlight only happens with CUCM 8.5(2).

Dennis Heim | Collaboration Solutions Architect
World Wide Technology, Inc. | +1 314-212-1814
[twitter]https://twitter.com/CollabSensei
[chat]xmpp:dennis.h...@wwt.com[Phone]tel:+13142121814[video]sip:dennis.h...@wwt.com


From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Daniel Pagan
Sent: Wednesday, October 01, 2014 10:49 AM
To: Jason Aarons (AM); Jeffrey Girard; Ryan Ratliff (rratliff)
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] 7945 more button does nothing under ITL (can't delete 
the ITL)

Funny it certainly is.  Reminds me of a quirky issue we found a while back. Had 
a customer who opened a case saying his phone was a vampire. The customer said 
his phone calls were being disconnected by sunlight. His phone was positioned 
on a desk where direct sunlight would hit the phone at around lunch time, and 
his calls would start disconnected every day at this time. It was hard to 
believe at first until we received a video showing the issue occur… it was 
unexpected to say the least.

Resulted in creating https://tools.cisco.com/bugsearch/bug/CSCtf65633

Turned out the optical hook-switch was being triggered by sunlight.

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Jason 
Aarons (AM)
Sent: Wednesday, October 01, 2014 1:13 PM
To: Jeffrey Girard; Ryan Ratliff (rratliff)
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] 7945 more button does nothing under ITL (can't delete 
the ITL)

This is too funny.  Yeah the button on the phone is broke. I can’t believe it!! 
 We will have the customer RMA this phone….



From: Jeffrey Girard [mailto:jeffrey.gir...@girardinc.com]
Sent: Wednesday, October 01, 2014 12:36 PM
To: Jason Aarons (AM); Ryan Ratliff (rratliff)
Cc: cisco-voip voyp list
Subject: RE: [cisco-voip] 7945 more button does nothing under ITL (can't delete 
the ITL)


Jason –
I just watched your video.  Could it possibly be/have you 
checked mechanical?  Have you confirmed that the mechanical aspects of the 
physical button is actually working?  For example, at the beginning of your 
video with the phone onhook, have you tried to press the “More” button at that 
point to confirm that the physical button is actually working?

--
Dr. Jeffrey T. Girard (Jeff), PhD
Colonel, United States Army (Retired)
Senior Network Engineer / VoIP Engineer - WireMeHappy.com
(607) 835-0406 (home office)
(845) 764-1661 (mobile)
(607) 835-0458 (fax)

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Jason 
Aarons (AM)
Sent: Wednesday, October 01, 2014 12:07 PM
To: Ryan Ratliff (rratliff)
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] 7945 more button does nothing under ITL (can't delete 
the ITL)

The More button doesn’t work to erase the ITL when it’s showing unlocked.

Video Demo
https://www.youtube.com/watch?v=LRmVNPqLGtw

From: Ryan Ratliff (rratliff) [mailto:rratl...@cisco.com]
Sent: Wednesday, October 01, 2014 12:01 PM
To: Jason Aarons (AM)
Cc: cisco-voip voyp list
Subject: Re: [cisco-voip] 7945 more button does nothing under ITL (can't delete 
the ITL)

Looks like a timing issue that you should easily be able to work around. If you 
are seeing a lock icon then this isn't your bug.

1. Navigate to Trust List -- ITL file, we can see a secure lock icon ahead of 
the ITL file item name.

2. Unlock and erase ITL file. Menu will automatically closed and phone start to 
download ITL file again.

3. Before phone finishing restarting, navigate to Trust List -- ITL file 
again, we can see ITL file has already been downloaded again. But no secure 
lock icon displayed ahead of ITL file.

4. No matter how long waited, this display will not change, unless exit Trust 
List and enter again.

If in doubt factory reset the phone.
-Ryan

On Oct 1, 2014, at 10:01 AM, Jason Aarons (AM) 
jason.aar...@dimensiondata.commailto:jason.aar...@dimensiondata.com wrote:

CSCti99770

I have a 7945 SCCP 9.1.1SR1S  that I can’t press the More button in the ITL (it 
shows unlocked) to delete the ITL.  Is the above my bug?  What is the fix?  It 
shows

Re: [cisco-voip] Delete Log Files

[Daniel Pagan]

If you absolutely can't have any log files older than seven days on disk, one 
option would be to configure and schedule trace archiving for all services and 
applications, but make sure the delete log files from the server option is 
enabled.

This would provide you with two things:


1.   Log files collected off CUCM will be deleted permanently. This won't 
only include CCM but other services and applications as well such as CTI Mgr, 
LBM, Tomcat Security, syslogs, etc.



2.   The log files you archive to a separate disk and, more importantly, 
the length of time they're stored on disk, can be managed on the archive server 
via the example provided by Wes below (if a *nix OS) or the forfiles command I 
mentioned in a previous email (if a Windows OS).

Keep in mind this has the potential to put the customer into a situation where 
reported issues might go nowhere due to missing trace information since only 
seven days are retained. I'd also keep in mind the disk space required on your 
trace archiving server and overhead placed on CUCM -  older version of CUCM 
don't automatically zip trace files on disk and, depending on specs, gzip can 
and has contributed to higher-than-expected CPU utilization. It will likely 
also include a very large number of log files needing to be transferred over 
FTP or SFTP, so there's that to consider as well. You can minimize these two 
factors by scheduling it to occur once a day and during an after-hours window 
while avoiding an overlap of any backup jobs. You can also try to avoid large 
LDAP sync jobs or the 3:15 AM garbage collection task but it's probably 
unnecessary.

I personally have never seen or configured CUCM trace and log archiving that 
encompassed so many services so I can't really recommend it or speak from 
experience, but it, in theory, would most certainly accomplish the goal of 
managing the duration of all CUCM log files on disk, not just CCM SDI/SDL.

Hope this helps

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Martin Schmuker
Sent: Tuesday, September 23, 2014 5:15 PM
To: Wes Sisk (wsisk)
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files

Guys, thank you very much for your answers.

Sorry that I did not explain, why we want to delete old files. The reason is 
stupid German law regarding protection of privacy. Customer asks to delete 
files after of 7 days. In this case it's not really a law, but client feels 
better :-(

From: Wes Sisk (wsisk) [mailto:ws...@cisco.com]
Sent: Tuesday, September 23, 2014 5:04 PM
To: Martin Schmuker
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files

onbox logging is circular. It will consume as much space as allocated and then 
loop over that. If something goes awry then Log Partition Manager (LPM) will 
auto-delete files as necessary.

For Scheduled Trace Collection, 
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/8_6_1/rtmt/rtmt/rttlc.html#wp1048184

No, there is nothing built into CUCM to manage the consumed disk space on the 
trace archive server. If using a *nix box a cron'd 'find' command does pretty 
well.

some possible examples:
# find files modified in the last 1 day
find . -type f -mtime -1d

-1d within 1 day -mtime n[smhdw]

-Wes

On Sep 23, 2014, at 6:13 AM, Martin Schmuker 
m...@bilobit.commailto:m...@bilobit.com wrote:

Guys,

is there any way to delete CUCM log files (aka traces) after x days?

Thanks,  Martin
___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] Delete Log Files

[Daniel Pagan]

Adding to Wes's comments for managing consumed disk space on an archive 
server... For a Windows OS server, the forfiles command with a few options can 
help with the disk space cleanup as well:

http://stackoverflow.com/questions/51054/batch-file-to-delete-files-older-than-n-days

But to the original question, I think it comes down to what needs to be 
accomplished.

If reducing utilized space on the activelog partition, simply adjusting the 
total number of files and max file size for specific trace settings would help.

If you need to free disk space for an upcoming upgrade, in addition to what 
Ryan mention, another approach can be to collect all CCM SDI/SDL files off the 
cluster via RTMT followed by deleting them from the activelog partition via 
file delete activelog cm/trace/ccm/sdl *.txt and again for sdi traces. 
Whether or not this helps is of course dependent on your trace settings, but 
I've taken this approach a handful of times in the past (when in a pinch) to 
make space for upgrade media. By doing this you make space by removing traces 
in bulk without actually losing anything. If issues occurring pre-upgrade need 
to be troubleshooted post-upgrade, the collected/offloaded CCM traces coupled 
with additional trace files found on the inactivelog partition should be more 
than sufficient.

Hope this helps.

- Daniel

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Wes 
Sisk (wsisk)
Sent: Tuesday, September 23, 2014 11:04 AM
To: Martin Schmuker
Cc: Cisco VoIP Mailing List
Subject: Re: [cisco-voip] Delete Log Files

onbox logging is circular. It will consume as much space as allocated and then 
loop over that. If something goes awry then Log Partition Manager (LPM) will 
auto-delete files as necessary.

For Scheduled Trace Collection, 
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/service/8_6_1/rtmt/rtmt/rttlc.html#wp1048184

No, there is nothing built into CUCM to manage the consumed disk space on the 
trace archive server. If using a *nix box a cron'd 'find' command does pretty 
well.

some possible examples:
# find files modified in the last 1 day
find . -type f -mtime -1d

-1d within 1 day -mtime n[smhdw]

-Wes

On Sep 23, 2014, at 6:13 AM, Martin Schmuker 
m...@bilobit.commailto:m...@bilobit.com wrote:

Guys,

is there any way to delete CUCM log files (aka traces) after x days?

Thanks,  Martin
___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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] no Ringback on 7940-SCCP when calls are going over SIP

[Daniel Pagan]

Few questions I would try to answer here:

Is CUCM negotiating Early Media successfully on these problem calls?
Do I see a StationD event for AlertingTone to the IP Phone?

CUCM should instruct the SCCP phone to play local ring back via AlertingTone 
event when early media cannot be negotiated. For example, if you send an INVITE 
with early offer but receive no SDP answer in a 180/183 response... or if your 
call goes out with delayed office, you receive an SDP offer in a 180/183 but 
PRACK is disabled.

Also, is the SIP trunk destination pointing to a CUBE device where the egress 
call is also SIP?
You specifically mentioned 7940's - are other phone models not experiencing 
this issue?

- Daniel

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of 
Nathan Reeves
Sent: Wednesday, September 17, 2014 4:15 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] no Ringback on 7940-SCCP when calls are going over SIP

Anyone come across anything like 7940's not playing Ringback to the user when 
an external call is made out externally over a SIP trunk.

CUCM is V10.  Firmware on the 7940's is as up to date as possible.  Calls 
proceeded normally on CUCM 8.5 normally.  Only noticed this on the move to V10.

Thanks

Nathan


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

Re: [cisco-voip] UC bulk export VM from user box

[Daniel Pagan]

This isn’t bulk export, but Message Archiver allows you to export voice 
messages for a Unity Connection user/subscriber to a compressed file.

Tool:
http://www.ciscounitytools.com/Applications/CxN/MessageArchiver/MessageArchiver.html

Tool Help:
http://www.ciscounitytools.com/Applications/CxN/MessageArchiver/Help/MessageArchiver.htm#_Toc353954993

Hope this helps.

- Dan

From: cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] On Behalf Of Scott 
Voll
Sent: Tuesday, September 16, 2014 11:09 AM
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] UC bulk export VM from user box

is there a way to bulk export all the VM's out of a users VM box?

Currently on UC 8.6.2

Thanks

Scott

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

[cisco-voip] EWS Limits Throttling Policy

[Daniel Pagan]

Folks:

I'm hoping someone can share their experience with the Cisco recommended method 
for removing EWS limits on Exchange 2010 SP2 RU4 and higher. In earlier 
releases of Ex2010 the process of setting a throttling policy applied only to 
the UM service account, and any throttling performed would be applied to that 
service account and not to the target mailbox. Please correct me if my 
understanding is incorrect, but with E2010 SP2 RU4 and higher, the policy is to 
be applied to every target mailbox, which seems like it would impact all other 
EWS applications impersonating these target mailboxes.
Removing EWS Limits from Exchange 2010 SP2 RU4 and Later
Microsoft has enabled the client throttling policy feature by default. If there 
is no throttling policy already configured, Microsoft Exchange applies a 
default policy to all users. The default throttling policy is tailored for end 
user's load and not for an enterprise application like, Cisco Unity Connection 
using impersonation. If any Cisco Unity Connection users who are configured for 
unified messaging have mailboxes in Exchange 2010, configure the Exchange 2010 
EWS limits for the unified messaging users mailbox by creating and applying a 
new mailbox policy to the unified messaging user mailbox account. If you do not 
configure EWS limits, messages may not be synchronized, and status changes (for 
example, from unread to read), changes to the subject line, and changes to the 
priority may not be replicated. In addition, attempts to access Exchange 
calendars and contacts may fail.

The MS KB referring to the throttling policy change: 
http://support.microsoft.com/kb/2713371

Perhaps my understanding is wrong, but it seems like a backwards move. Has 
anyone seen any adverse effects of applying the Cisco recommended throttling 
values as the system default? Perhaps any problems where applying the 
throttling policy to the target mailbox impacts other EWS apps like BlackBerry 
Enterprise? Are you applying the throttling policy for every single UM enabled 
mailbox, individually, via management shell?

Thanks!

- Dan


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

Re: [cisco-voip] EWS Limits Throttling Policy

[Daniel Pagan]

Thanks – I noticed this as well and the preceding statement under the Exchange 
2010 SP2 RU4 section made me question the page view function when I first 
reviewed it, but it does seem to act as a solution in this case.

I reviewed a few other articles where paged view functionality is mentioned and 
it appears to be helpful in this situation. For others who might encounter this 
thread in the future… In addition to the article Justin provided:

Enhancement Defect:
https://tools.cisco.com/bugsearch/bug/CSCtz20281

Unity SU4 ReadMe – mentions the addition of the page view function:
http://www.cisco.com/web/software/282074295/82/862asu4cucrm.pdf

Neat article explaining the details and providing examples behind page searches 
and the EWS API:
http://msdn.microsoft.com/en-us/library/office/dd633698(v=exchg.80).aspx

Thanks again for the tip, Justin

- Dan


From: Justin Steinberg [mailto:jsteinb...@gmail.com]
Sent: Thursday, September 11, 2014 11:08 AM
To: Daniel Pagan
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] EWS Limits  Throttling Policy

I've successfully used the 'paged view functionality' on the later versions of 
Connections that works around this issue by staying under the EWS default 
limits.

http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/10x/unified_messaging/guide/10xcucumgx/10xcucumg020.html#83993


On Thu, Sep 11, 2014 at 10:52 AM, Daniel Pagan 
dpa...@fidelus.commailto:dpa...@fidelus.com wrote:
Folks:

I’m hoping someone can share their experience with the Cisco recommended method 
for removing EWS limits on Exchange 2010 SP2 RU4 and higher. In earlier 
releases of Ex2010 the process of setting a throttling policy applied only to 
the UM service account, and any throttling performed would be applied to that 
service account and not to the target mailbox. Please correct me if my 
understanding is incorrect, but with E2010 SP2 RU4 and higher, the policy is to 
be applied to every target mailbox, which seems like it would impact all other 
EWS applications impersonating these target mailboxes.
Removing EWS Limits from Exchange 2010 SP2 RU4 and Later
Microsoft has enabled the client throttling policy feature by default. If there 
is no throttling policy already configured, Microsoft Exchange applies a 
default policy to all users. The default throttling policy is tailored for end 
user's load and not for an enterprise application like, Cisco Unity Connection 
using impersonation. If any Cisco Unity Connection users who are configured for 
unified messaging have mailboxes in Exchange 2010, configure the Exchange 2010 
EWS limits for the unified messaging users mailbox by creating and applying a 
new mailbox policy to the unified messaging user mailbox account. If you do not 
configure EWS limits, messages may not be synchronized, and status changes (for 
example, from unread to read), changes to the subject line, and changes to the 
priority may not be replicated. In addition, attempts to access Exchange 
calendars and contacts may fail.

The MS KB referring to the throttling policy change: 
http://support.microsoft.com/kb/2713371

Perhaps my understanding is wrong, but it seems like a backwards move. Has 
anyone seen any adverse effects of applying the Cisco recommended throttling 
values as the system default? Perhaps any problems where applying the 
throttling policy to the target mailbox impacts other EWS apps like BlackBerry 
Enterprise? Are you applying the throttling policy for every single UM enabled 
mailbox, individually, via management shell?

Thanks!

- Dan

___
cisco-voip mailing list
cisco-voip@puck.nether.netmailto: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