[cisco-voip] SIP trunk status

[Mark Holloway]

The Acme Packet (now Oracle) SBC does this. Any far-end device that doesn't respond to an options ping will cause the SBC to skip it when it needs to setup a call and automatically use the next "Agent" in the Session Agent Group. Cisco should really adopt this model if they haven't already done so. It's a much more pro-active approach and reduces post dial delay. 

On Jun 6, 2013, at 3:49 PM, Eric Pedersen <PedersenE at bennettjones.com> wrote:

> That's good to hear.
>  
> I have a related question: we have our SIP trunks to IOS gateways configured with OPTIONS ping. If a WAN issue causes the first CM in the CM group to be unable to reach the gateway will all calls to that GW get routed by the second CM provided the gateway is reachable from that server? 
>  
> Thank you,
> Eric
>  
> From: Chris Ward (chrward) [mailto:chrward at cisco.com] 
> Sent: 06 June 2013 1:43 PM
> To: Ryan Ratliff (rratliff); Eric Pedersen
> Cc: cisco-voip
> Subject: RE: [cisco-voip] SIP trunk status
>  
> I believe that feature is en route for 10.0.
>  
> +Chris
> Unity Connection TME
>  
> From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan Ratliff (rratliff)
> Sent: Thursday, June 06, 2013 3:37 PM
> To: Eric Pedersen
> Cc: cisco-voip
> Subject: Re: [cisco-voip] SIP trunk status
>  
> RTMT doesn't currently provide the state of SIP trunks.
>  
> -Ryan
>  
> On Jun 6, 2013, at 3:09 PM, Eric Pedersen <PedersenE at bennettjones.com> wrote:
>  
> Is there a way to monitor the status of a SIP trunk from CUCM's perspective, i.e. in-service/out-of-service, either with RTMT or SNMP? There are syslog messages that are generated when a SIP trunk becomes unreachable by CUCM servers but I'd like to be able to poll for the status.
>  
> Thanks,
> Eric
> 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
>  
> 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/20130607/ae5d6f61/attachment.html>