Send cisco-voip mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-voip
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-voip digest..."
Today's Topics:
1. Re: CUCM SRV records CSCth25928 (Ted Nugent)
2. Re: CUCM SRV records CSCth25928 (Ryan Ratliff)
3. Re: CUCM SRV records CSCth25928 (Ted Nugent)
4. Re: CUCM SRV records CSCth25928 (Adam Frankel (afrankel))
5. Re: CUCM SRV records CSCth25928 (Ted Nugent)
6. CUBE on ASR1002-F (Robert Hass)
----------------------------------------------------------------------
Message: 1
Date: Fri, 16 Nov 2012 12:55:45 -0500
From: Ted Nugent <[email protected]>
To: Ryan Ratliff <[email protected]>
Cc: Cisco VoIPoE List <[email protected]>
Subject: Re: [cisco-voip] CUCM SRV records CSCth25928
Message-ID:
<CAHs2VYvAB6KHaATHOUgCrcZRzVzzML605P=0n5qtzkvrvyz...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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 <[email protected]> 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 <[email protected]>
> 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:* [email protected] [mailto:cisco-
> [email protected]] *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) <[email protected]>
> 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:* [email protected] [mailto:cisco-
> [email protected]] *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
> [email protected]
> 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
> [email protected]
> 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-0001.html>
------------------------------
Message: 2
Date: Fri, 16 Nov 2012 13:21:49 -0500
From: Ryan Ratliff <[email protected]>
To: Ted Nugent <[email protected]>
Cc: Cisco VoIPoE List <[email protected]>
Subject: Re: [cisco-voip] CUCM SRV records CSCth25928
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
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.
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.
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.
-Ryan
On Nov 16, 2012, at 12:55 PM, Ted Nugent <[email protected]> wrote:
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 <[email protected]> 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 <[email protected]> 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: [email protected]
[mailto:[email protected]] 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) <[email protected]> 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: [email protected]
[mailto:[email protected]] 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
[email protected]
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
[email protected]
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/3e1c9f57/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 16 Nov 2012 13:32:40 -0500
From: Ted Nugent <[email protected]>
To: Ryan Ratliff <[email protected]>
Cc: Cisco VoIPoE List <[email protected]>
Subject: Re: [cisco-voip] CUCM SRV records CSCth25928
Message-ID:
<CAHs2VYvLPe+-VkxDaiUN=A=esi+U3LG4yw_Adr2tue=qmrg...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
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.
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.
http://www.cisco.com/en/US/docs/voice_ip_comm/cups/8_6/english/install_upgrade/deployment/guide/dgcupc.html
On Fri, Nov 16, 2012 at 1:21 PM, Ryan Ratliff <[email protected]> wrote:
> 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.
>
> 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.
>
> 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.
>
> -Ryan
>
> On Nov 16, 2012, at 12:55 PM, Ted Nugent <[email protected]> wrote:
>
> 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 <[email protected]> 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 <[email protected]>
>> 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:* [email protected] [mailto:cisco-
>> [email protected]] *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) <[email protected]>
>> 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:* [email protected] [mailto:cisco-
>> [email protected]] *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
>> [email protected]
>> 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
>> [email protected]
>> 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/202fcd29/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 16 Nov 2012 16:35:36 -0500
From: "Adam Frankel (afrankel)" <[email protected]>
To: Ted Nugent <[email protected]>
Cc: Cisco VoIPoE List <[email protected]>
Subject: Re: [cisco-voip] CUCM SRV records CSCth25928
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/trunks.html#wp1123287
SIP OPTIONS Ping
The SIP OPTIONS Ping feature can be enabled on the SIP Profile
associated with a SIP trunk to dynamically track the state of the
trunk's destination(s). When this feature is enabled, each node running
the trunk's SIP daemon will periodically send an OPTIONS Request to each
of the trunk's destination IP addresses to determine its reachability
and will send calls only to reachable nodes. *A destination address is
considered to be "out of service" if it fails to respond to an OPTIONS
Request, if it sends a Service Unavailable (503) response or Request
Timeout (408) response, or if a TCP connection cannot be established. *
The trunk state is considered to be "in service" when at least one node
receives a response (other than a 408 or 503) from a least one
destination address. SIP trunk nodes can send OPTIONS Requests to the
trunk's configured destination IP addresses or to the resolved IP
addresses of the trunk's DNS SRV entry. Enabling SIP OPTIONS Ping is
recommended for all SIP trunks because it allows Unified CM to
dynamically track trunk state rather than determining trunk state on a
per-call and timeout basis.
HTH,
Adam
------------------------------------------------------------------------
*From:* Ted Nugent <[email protected]>
*Sent:* Thu, Nov 15, 2012 5:58:11 PM
*To:* Ryan Ratliff <[email protected]>
*CC:* Cisco VoIPoE List <[email protected]>
*Subject:* Re: [cisco-voip] CUCM SRV records CSCth25928
> Does anyone know (have tested) that the multiple hosts on the SIP
> trunk will actually provide failover if the primary host goes done? If
> that's the case then no need to make a-records right?
>
> On Thu, Nov 15, 2012 at 10:15 AM, Ted Nugent <[email protected]
> <mailto:[email protected]>> wrote:
>
> That's what I was afraid of... Was allowing multiple host entries
> in the SIP trunk configuration put in place to get around this at
> least in a failover configuration? This "enhancement" has been
> open for WELL over a year!
>
>
> On Thu, Nov 15, 2012 at 9:29 AM, Ryan Ratliff <[email protected]
> <mailto:[email protected]>> wrote:
>
>> Status: Open(Assigned)
>
> Not resolved yet. Use A records as a workaround.
>
> -Ryan
>
> On Nov 14, 2012, at 6:19 PM, Ted Nugent <[email protected]
> <mailto:[email protected]>> wrote:
>
> 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
> [email protected] <mailto:[email protected]>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> [email protected]
> 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/3fce77fe/attachment-0001.html>
------------------------------
Message: 5
Date: Fri, 16 Nov 2012 16:52:17 -0500
From: Ted Nugent <[email protected]>
To: "Adam Frankel (afrankel)" <[email protected]>
Cc: Cisco VoIPoE List <[email protected]>
Subject: Re: [cisco-voip] CUCM SRV records CSCth25928
Message-ID:
<cahs2vyufysggohpm-euwcsisqjjuh-_6m7wemkybkfjkeh9...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Sweet! Thanks
On Fri, Nov 16, 2012 at 4:35 PM, Adam Frankel (afrankel) <[email protected]
> wrote:
>
> http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/8x/trunks.html#wp1123287
> SIP OPTIONS Ping
>
> The SIP OPTIONS Ping feature can be enabled on the SIP Profile associated
> with a SIP trunk to dynamically track the state of the trunk's
> destination(s). When this feature is enabled, each node running the trunk's
> SIP daemon will periodically send an OPTIONS Request to each of the trunk's
> destination IP addresses to determine its reachability and will send calls
> only to reachable nodes. *A destination address is considered to be "out
> of service" if it fails to respond to an OPTIONS Request, if it sends a
> Service Unavailable (503) response or Request Timeout (408) response, or if
> a TCP connection cannot be established. * The trunk state is considered
> to be "in service" when at least one node receives a response (other than a
> 408 or 503) from a least one destination address. SIP trunk nodes can send
> OPTIONS Requests to the trunk's configured destination IP addresses or to
> the resolved IP addresses of the trunk's DNS SRV entry. Enabling SIP
> OPTIONS Ping is recommended for all SIP trunks because it allows Unified CM
> to dynamically track trunk state rather than determining trunk state on a
> per-call and timeout basis.
>
> HTH,
> Adam
>
>
> ------------------------------
> *From:* Ted Nugent <[email protected]> <[email protected]>
> *Sent:* Thu, Nov 15, 2012 5:58:11 PM
> *To:* Ryan Ratliff <[email protected]> <[email protected]>
> *CC:* Cisco VoIPoE List
> <[email protected]><[email protected]>
>
> *Subject:* Re: [cisco-voip] CUCM SRV records CSCth25928
>
> Does anyone know (have tested) that the multiple hosts on the SIP trunk
> will actually provide failover if the primary host goes done? If that's the
> case then no need to make a-records right?
>
> On Thu, Nov 15, 2012 at 10:15 AM, Ted Nugent <[email protected]>wrote:
>
>> That's what I was afraid of... Was allowing multiple host entries in the
>> SIP trunk configuration put in place to get around this at least in
>> a failover configuration? This "enhancement" has been open for WELL over a
>> year!
>>
>>
>> On Thu, Nov 15, 2012 at 9:29 AM, Ryan Ratliff <[email protected]> wrote:
>>
>>> Status: Open(Assigned)
>>>
>>>
>>> Not resolved yet. Use A records as a workaround.
>>>
>>> -Ryan
>>>
>>> On Nov 14, 2012, at 6:19 PM, Ted Nugent <[email protected]> wrote:
>>>
>>> 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
>>> [email protected]
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>
>
> _______________________________________________
> cisco-voip mailing
> [email protected]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/d15e9908/attachment-0001.html>
------------------------------
Message: 6
Date: Sat, 17 Nov 2012 15:02:46 +0100
From: Robert Hass <[email protected]>
To: cisco-voip <[email protected]>
Subject: [cisco-voip] CUBE on ASR1002-F
Message-ID:
<calnfftfb9xexs57f9kpbd-yn0l9spdeuv0p_wv+kuot-ud+...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hi
We need to deploy test box with CUBE. We want to use old ASR1002-F
which is unused in our network, but I'm unsure about few details.
Is Cube supported on "fixed" ASR1002-F ? If not then if it's supported
on ASR1002 + ESP-5G (we can swap fixed version for full 1002 as we're
using no-fixed in one POP)
What IOS XE release is minimum required for CUBE ?
As first (before buy) we need to test everything - are CUBE licensing
is enforced of ASR 1002 / ASR 1002-F ? If it's enforced are trial
license is supported ?
Rob
------------------------------
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
End of cisco-voip Digest, Vol 109, Issue 14
*******************************************
