<div>Well that definitely helps, and according to this all users will be moved to the available node once failover is detected, so that answers that.... Good enough for me! Once I get my second node license (which shipped snail mail rather than e-delivery) I'll test it and let you know what happens. Thanks again.</div>
<div> </div><div>Cisco Unified Presence automatically detects failover in a subcluster by monitoring the heartbeat and monitoring the critical services on the peer node. When Cisco Unified Presence detects failover, it automatically moves all users to the backup node. From the Cisco Unified Presence Administration interface, you can initiate a manual fallback to the primary node. Cisco Unified Presence Release 8.6(4) and later supports automatic fallback to the primary node after failover. </div>
<div> </div><div><a href="http://www.cisco.com/en/US/docs/voice_ip_comm/cups/8_6/english/install_upgrade/deployment/guide/dgcupc.html">http://www.cisco.com/en/US/docs/voice_ip_comm/cups/8_6/english/install_upgrade/deployment/guide/dgcupc.html</a><br>
</div><div><br> </div><div class="gmail_quote">On Fri, Nov 16, 2012 at 1:21 PM, Ryan Ratliff <span dir="ltr"><<a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a>></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">
<div style="word-wrap:break-word">I'm far from a CUP expert so take this with a grain of salt. To understand how UCM uses this SIP trunk you need to keep in mind what information is exchanged over the trunk. For presence information what I'd expect to be happening is CUP sends Subscribe messages to UCM. I'd expect this subscription to be coming from the CUP node the user is assigned to. <div>
<br></div><div>With SIP trunks where UCM is initiating connections you've got a few things to consider. I'd definitely expect to see some load balancing when multiple IPs are defined in the trunk. This has been the case going back to H.323 based ICTs in CCM 4.x. With SIP trunks that use TCP UCM will re-use existing TCP sessions for multiple calls, so you may or may not get 100% pure load balancing. I've not tested this personally so YMMV. <br>
<div><br></div><div>Long story short, I'd expect that for CUP it's going to be as simple as UCM will send presence information to the CUP node(s) that initiated a subscription for it. I wouldn't expect to see UCM sending much SIP traffic at all to a CUP node with no users connecting to it.</div>
<div><span class="HOEnZb"><font color="#888888"><br><div>
<span style="text-transform:none;text-indent:0px;letter-spacing:normal;word-spacing:0px;white-space:normal;border-collapse:separate">-Ryan</span>
</div></font></span><div><div class="h5">
<br><div><div>On Nov 16, 2012, at 12:55 PM, Ted Nugent <<a href="mailto:tednugent73@gmail.com" target="_blank">tednugent73@gmail.com</a>> wrote:</div><br><div>Ryan</div><div>Assuming that you aren't using SRV for the SIP trunk to CUPS and only using multiple hosts (IPs FQDNs etc.) is the assumption that CUCM load balances across those hosts correct? If so, in a CUPS HA environment where all your CUPS users are assigned to a primary node and the second node is simply for failover would just having IPs/FQDNs in the trunk config work in a failover scenario? I'd assume that you would still need SRV configured in Jabber to allow for failover? You see anything wrong with that config?</div>
<div>Thanks for the feedback on this. Very helpful so far.</div><div>T<br><br></div><div class="gmail_quote">On Fri, Nov 16, 2012 at 11:37 AM, Ryan Ratliff <span dir="ltr"><<a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a>></span> wrote:<br>
<blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote"><div style="word-wrap:break-word">The bug applies to how UCM handles SRV records, so it would be for any SIP trunk. I agree that it doesn't make sense to only use the first entry but if that's how the original feature was designed then we're in a situation where rather than getting a bug fixed we are changing expected behavior. It's a fine line, and in some circumstances seems like semantics but it's the world we have to live in.<div>
<br></div><div>I've reached out to the developer that is assigned the bug to confirm that it really is an enhancement and see if there is any ETA for a fix. If this is important to you then you should be sure to bring this to the attention of your account team or the UCM PM team if you happen to have contacts there. TAC has next to no power when it comes to getting enhancement defects fixed. To really make something happen it needs to come from marketing and they need to hear from customers and account teams.<span><font color="#888888"><br>
</font></span><div><span><font color="#888888"><br><div>
<span style="text-transform:none;text-indent:0px;letter-spacing:normal;word-spacing:0px;white-space:normal;border-collapse:separate">-Ryan</span>
</div></font></span><div><div>
<br><div><div>On Nov 16, 2012, at 11:13 AM, Eric Pedersen <<a href="mailto:PedersenE@bennettjones.com" target="_blank">PedersenE@bennettjones.com</a>> wrote:</div><br><div style="text-transform:none;text-indent:0px;letter-spacing:normal;word-spacing:0px;white-space:normal" lang="EN-US" vlink="purple" link="blue">
<div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">Is this referring to only the CUPS publish SIP trunk or any SIP trunk? It doesn't make sense to me for CUCM to support SRV records but only use the first entry.<u></u><u></u></span></div>
<div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt">
<span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">Can I just add both CUPS servers as destinations on the same SIP trunk? The bug looks like it was entered for CUCM 7.1 before multiple destinations were supported.<u></u><u></u></span></div>
<div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></div><div><div style="border-style:solid none none;padding:3pt 0in 0in;border-top-color:rgb(181,196,223);border-top-width:1pt">
<div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><b><span style="font-family:Tahoma,sans-serif;font-size:10pt">From:</span></b><span style="font-family:Tahoma,sans-serif;font-size:10pt"><span> </span><a style="color:purple;text-decoration:underline" href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a><span> </span>[mailto:<a href="mailto:cisco-" target="_blank">cisco-</a><a style="color:purple;text-decoration:underline" href="mailto:voip-bounces@puck.nether.net" target="_blank">voip-bounces@puck.nether.net</a>]<span> </span><b>On Behalf Of<span> </span></b>Ryan Ratliff<br>
<b>Sent:</b><span> </span>15 November 2012 8:15 AM<br><b>To:</b><span> </span>Chris Ward<br><b>Cc:</b><span> </span>Cisco VoIPoE List<br><b>Subject:</b><span> </span>Re: [cisco-voip] CUCM SRV records CSCth25928<u></u><u></u></span></div>
</div></div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><u></u> <u></u></div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt">Since it's an enhancement you should go through your account team as well. TAC can only push so hard on that category of defect.<u></u><u></u></div>
<div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><u></u> <u></u></div><div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><span><span style="font-family:Helvetica,sans-serif;font-size:13.5pt">-Ryan</span></span><u></u><u></u></div>
</div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><u></u> <u></u></div><div><div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt">
On Nov 15, 2012, at 9:29 AM, Chris Ward (chrward) <<a style="color:purple;text-decoration:underline" href="mailto:chrward@cisco.com" target="_blank">chrward@cisco.com</a>> wrote:<u></u><u></u></div></div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt">
<u></u> <u></u></div><div><div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">That defect is still unresolved. You would need to contact TAC for an ETA or for them to push the BU for faster resolution.</span><u></u><u></u></div>
</div><div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span><u></u><u></u></div></div><div>
<div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">+Chris</span><u></u><u></u></div></div><div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt">
<span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">Unity Connection TME</span><u></u><u></u></div></div><div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt">
<span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span><u></u><u></u></div></div><div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><b><span style="font-family:Tahoma,sans-serif;font-size:10pt">From:</span></b><span><span style="font-family:Tahoma,sans-serif;font-size:10pt"> </span></span><span style="font-family:Tahoma,sans-serif;font-size:10pt"><a style="color:purple;text-decoration:underline" href="mailto:cisco-voip-bounces@puck.nether.net" target="_blank">cisco-voip-bounces@puck.nether.net</a><span> </span>[mailto:<a href="mailto:cisco-" target="_blank">cisco-</a><a style="color:purple;text-decoration:underline" href="mailto:voip-bounces@puck.nether.net" target="_blank">voip-bounces@puck.nether.net</a>]<span> </span><b>On Behalf Of<span> </span></b>Ted Nugent<br>
<b>Sent:</b><span> </span>Wednesday, November 14, 2012 6:20 PM<br><b>To:</b><span> </span>Cisco VoIPoE List<br><b>Subject:</b><span> </span>[cisco-voip] CUCM SRV records CSCth25928</span><u></u><u></u></div></div><div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt">
<u></u><u></u></div></div><div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt">Is it possible this is still unresolved or maybe been resolved in a duplicate bug id? HOPEFULLY!<u></u><u></u></div>
</div><div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt">Does anyone know if this was resolved by 8.6.2?<u></u><u></u></div></div><div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt">
<u></u><u></u></div></div><div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><strong>CSCth25928 Bug Details</strong><u></u><u></u></div></div><div><table style="width:739px" border="0" cellpadding="0" width="100%">
<tbody><tr><td style="padding:6pt" colspan="2"><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><strong><span style="font-size:10.5pt">Change the behavior for invoking additional DNS SRV queries</span></strong><u></u><u></u></div>
</td></tr><tr><td style="padding:0in 6pt 6pt" valign="top"><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><b><span style="font-size:10.5pt">Symptom:</span></b><span style="font-size:10.5pt"><br>
When the Primary server is down CM does not try the second server mentioned in<br>the SRV record.<br>Even when the timer expires it resets the timer and again starts sending the<br>NOTIFY request to Primary DNS SRV record.</span><u></u><u></u></div>
</td><td style="padding:3.75pt"></td></tr></tbody></table></div><table style="width:739px" border="0" cellpadding="0" width="100%"><tbody><tr><td style="padding:3.75pt"></td></tr></tbody></table><div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt">
<u></u><u></u></div></div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><span style="font-family:"Lucida Grande",serif;font-size:13.5pt">_______________________________________________<br>
cisco-voip mailing list<br><a style="color:purple;text-decoration:underline" href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br><a style="color:purple;text-decoration:underline" href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><u></u><u></u></span></div>
</div></div><div style="margin:0in 0in 0pt;font-family:"Times New Roman",serif;font-size:12pt"><u></u> <u></u></div></div></div><pre>The contents of this message may contain confidential and/or privileged
subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.
</pre></div><br></div><br></div></div></div></div></div><br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br></blockquote></div><br>
</div><br></div></div></div></div></div></blockquote></div><br>