SIP Trunk issue when CallManager service is down

[jhitt-limited]

I am running CUCM 8.0(3) and have a SIP trunk that is setup with a Device Pool containing a CallManager group that has two subscribers in it.  When I turn off the CallManager service on the first subscriber (to simulate an outage), the call can no longer complete - I get disconnect error 27 - destination out of order.  When both subscribers are up and working, I can see calls on each subscriber using that trunk.  So why when I shut the one sub's CallManager service off does it not just use the working sub?  It is as if taking one sub down takes down the whole trunk which is not what I expect when the documentation indicates that redundancy is achieved by using more than one server in the Call Manager group.  Is shutting off the Call Manager service not a good way to test failover?  Any ideas?                  

[Scott Leport]

Do you have the Run on all active nodes option set in the CM SIP trunk?

Sent from Cisco Technical Support iPhone App

[jhitt-limited]

Unfortunately, that option isn't available in version 8.0(3).  I think you need 8.5 or greater for that.

[Suresh Subramanian]

When I turn off the CallManager service on the first subscriber (to  simulate an outage), the call can no longer complete - I get disconnect  error 27 - destination out of order.

you get the error for inbound call or outbound call? I guess it is inbound call to the cluster?

if it is for inbound call, perhaps the sip trunk in destination cluster might have configured with the cucm ip address in which we have stopped in the ccmservice. And you might have received the destination out of order error message.

The outbound calls should still work when you stop the ccmservice as the sip trunk will failover to 2nd node in the ccm group.

Please rate all the useful posts

[jhitt-limited]

This is actually on calls going out the SIP trunk, not coming in.  And I know the SIP trunk works on both nodes as I can see active calls in RTMT from both nodes when I have them both operational.  But when I take the one service down on one node, it doesn't work.  It is like CUCM doesn't know what to do with the call then.  In the CDR records, the call completes with reason code 27 and there is no destination IP listed in the record.

[Carlo Poggiarelli]

Hi.

To what kind of SIP device is pointing the Trunk defined on CUCM?

Let me know

Regards

Carlo

Please rate all helpful posts

"The more you help the more you learn"