[cisco-voip] CUCM SRV records CSCth25928

[Ted Nugent]

Ryan
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?
Thanks for the feedback on this. Very helpful so far.
T

On Fri, Nov 16, 2012 at 11:37 AM, Ryan Ratliff <rratliff at cisco.com> wrote:

> 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.
>
> 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.
>
> -Ryan
>
> On Nov 16, 2012, at 11:13 AM, Eric Pedersen <PedersenE at bennettjones.com>
> wrote:
>
> 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.****
>
> 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.****
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:cisco-
> voip-bounces at puck.nether.net] *On Behalf Of *Ryan Ratliff
> *Sent:* 15 November 2012 8:15 AM
> *To:* Chris Ward
> *Cc:* Cisco VoIPoE List
> *Subject:* Re: [cisco-voip] CUCM SRV records CSCth25928****
> ** **
> 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.****
> ** **
> -Ryan****
> ** **
> On Nov 15, 2012, at 9:29 AM, Chris Ward (chrward) <chrward at cisco.com>
> wrote:****
> ** **
> That defect is still unresolved. You would need to contact TAC for an ETA
> or for them to push the BU for faster resolution.****
>  ****
> +Chris****
> Unity Connection TME****
>  ****
> *From:* cisco-voip-bounces at puck.nether.net [mailto:cisco-
> voip-bounces at puck.nether.net] *On Behalf Of *Ted Nugent
> *Sent:* Wednesday, November 14, 2012 6:20 PM
> *To:* Cisco VoIPoE List
> *Subject:* [cisco-voip] CUCM SRV records CSCth25928****
>  ****
> Is it possible this is still unresolved or maybe been resolved in a
> duplicate bug id? HOPEFULLY!****
> Does anyone know if this was resolved by 8.6.2?****
>  ****
> *CSCth25928 Bug Details*****
> *Change the behavior for invoking additional DNS SRV queries*****
> *Symptom:*
> When the Primary server is down CM does not try the second server
> mentioned in
> the SRV record.
> Even when the timer expires it resets the timer and again starts sending
> the
> NOTIFY request to Primary DNS SRV record.****
>  ****
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip****
> ** **
>
> 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.
>
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20121116/7b918c74/attachment.html>