Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Cisco: VOIP

intercluster trunk call survivability

 

 

Cisco voip RSS feed   Index | Next | Previous | View Threaded


eric.pedersen at sait

Nov 3, 2009, 9:37 AM

Post #1 of 4 (409 views)
Permalink
intercluster trunk call survivability

Is there a way to configure an intercluster trunk so that calls don't get dropped when a CM goes down or the Callmanager service is restarted? These are CM 7.1(2) clusters with an H.323 intercluster trunk connecting them.


wsisk at cisco

Nov 3, 2009, 12:26 PM

Post #2 of 4 (383 views)
Permalink
Re: intercluster trunk call survivability [In reply to]

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/gateways.html#wpmkr1044182



On Tuesday, November 03, 2009 12:37:58 PM, Eric Pedersen
<eric.pedersen [at] sait> wrote:
>
> Is there a way to configure an intercluster trunk so that calls don't
> get dropped when a CM goes down or the Callmanager service is
> restarted? These are CM 7.1(2) clusters with an H.323 intercluster
> trunk connecting them.
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip [at] puck
> https://puck.nether.net/mailman/listinfo/cisco-voip
>


eric.pedersen at sait

Nov 3, 2009, 3:58 PM

Post #3 of 4 (382 views)
Permalink
Re: intercluster trunk call survivability [In reply to]

Does this apply to intercluster trunks also? There is no option for this. I have not actually tested this since CM 6.x, but I did not see an indication that the default behaviour changed.

From: Wes Sisk [mailto:wsisk [at] cisco]
Sent: November 3, 2009 13:27
To: Eric Pedersen
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] intercluster trunk call survivability

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/gateways.html#wpmkr1044182



On Tuesday, November 03, 2009 12:37:58 PM, Eric Pedersen <eric.pedersen [at] sait><mailto:eric.pedersen [at] sait> wrote:

Is there a way to configure an intercluster trunk so that calls don't get dropped when a CM goes down or the Callmanager service is restarted? These are CM 7.1(2) clusters with an H.323 intercluster trunk connecting them.








________________________________






_______________________________________________

cisco-voip mailing list

cisco-voip [at] puck<mailto:cisco-voip [at] puck>

https://puck.nether.net/mailman/listinfo/cisco-voip


rratliff at cisco

Nov 3, 2009, 4:40 PM

Post #4 of 4 (374 views)
Permalink
Re: intercluster trunk call survivability [In reply to]

An ICT is just an H.225 trunk so yes, it does apply and would require
both clusters to have the service parameter (referenced in the doc)
set to true.

-Ryan

On Nov 3, 2009, at 6:58 PM, Eric Pedersen wrote:

Does this apply to intercluster trunks also? There is no option for
this. I have not actually tested this since CM 6.x, but I did not see
an indication that the default behaviour changed.

From: Wes Sisk [mailto:wsisk [at] cisco]
Sent: November 3, 2009 13:27
To: Eric Pedersen
Cc: cisco-voip [at] puck
Subject: Re: [cisco-voip] intercluster trunk call survivability

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/gateways.html#wpmkr1044182



On Tuesday, November 03, 2009 12:37:58 PM, Eric Pedersen <eric.pedersen [at] sait
> wrote:

Is there a way to configure an intercluster trunk so that calls don’t
get dropped when a CM goes down or the Callmanager service is
restarted? These are CM 7.1(2) clusters with an H.323 intercluster
trunk connecting them.






_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip


_______________________________________________
cisco-voip mailing list
cisco-voip [at] puck
https://puck.nether.net/mailman/listinfo/cisco-voip

Cisco voip RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.