cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1077
Views
240
Helpful
8
Replies

Sip Trunk Failover

adrian.mcleod
Level 1
Level 1

We have a CUCM cluster that will have SIP trunks to a product running Asterisk.  Looking to see how to ring a phone if no SIP trunk is available (asterisk dies). 

 

We have a route pattern 655X that points to the SIP trunk but in the even that the SIP trunk is down, I would like calls to ring DN 678.

 

Looking for options as there doesn't appear to be a simple failover mechanism for this.

Any help is appreciated.

 

Thanks

 

 

1 Accepted Solution

Accepted Solutions

I am not aware of a way to make a route list/route group fail to a DN. Do you have Unity Connection? Is it SIP integrated? If so, you could add another route group to the route list that send calls to asterisk fail with the route group with the Unity Connection in it. There would be some more setup to get it to a call handler or subscriber greeting, but that is the only way I can think to handle that.

View solution in original post

8 Replies 8

I am not aware of a way to make a route list/route group fail to a DN. Do you have Unity Connection? Is it SIP integrated? If so, you could add another route group to the route list that send calls to asterisk fail with the route group with the Unity Connection in it. There would be some more setup to get it to a call handler or subscriber greeting, but that is the only way I can think to handle that.

We do have Unity Connection but I will need to look into setting up a SIP trunk for it, currently utilizing SCCP. 

So I guess, now I need to confirm you can utilize both SCCP and SIP between CUCM and CUC?

 

i.e. regular phones will utilize SCCP for their CUC services (voicemail, call handlers, etc..).

But a SIP trunk can be created so that the Route points to CUC and a Call handler with Extension 6551 answers.

That call handler could be as simple as no greeting message and transfer to 658.

 

The above, if it worked, would then be using SCCP between CUC to 658, so now will that work; or is it going to require that the SIP/Call handler be in a separate Phone System so the Call Handler uses the SIP trunk to reach 658?  I don't see changing the VM from SCCP to SIP in the near future for us.

 

I guess long story short, can SCCP and SIP be used at the same time.

 

Thanks

 

 

Yes, you can have both SCCP and SIP integrations with CUCM. I have done that for multiple customers. Depending on the version of CUC, you make have to adjust the number of ports. Some version have license limits for the number of ports. I think starting with V12 those limits aren't there any longer.

Thank you for the assistance.  Running 12.5 so believe I am good with the ports. 

 

Will look at setting it up as a second phone-system in CUC; so I can keep the current VM ports/SCCP out of the mix.

 

The headache of all of this is that the config would be so much simpler if asterisk just registered the 4 endpoints I needed to CUCM (I think it should be able to but that is on a third party to configure).

 

Again thank you.

I don't think you need a second phone system. You need to add additional port groups that are SIP. One for each server assuming you have a subscriber. If you only want the SIP ports to answer calls, make sure you clear the MWI and TRAP flags on the SIP ports. The SIP profile and SIP security profile info is well documented in the Unity admin guide. It depends on your personal preference. You can do one trunk in CUCM with the IP's for both PUB and SUB, or a separate trunk for each. Add the trunk(s) to a route group, and then add that new route group to the route list for asterisk.

okay, I was concerned with it trying to go back to CUCM via the SCCP ports but if that isn't a concern this should be fairly straight forward.

 

Thanks

Ratheesh Kumar
VIP Alumni
VIP Alumni

I agree with Elliot, add the Unity trunk into the route group and failover option. In Unity Call handlers use calltransfer or alternate

 

Hope this Helps

Cheers
Rath!

***Please rate helpful posts and if applicable mark "Accept as a Solution"***

 

You could also use a called party transformation in the route details or on the SIP trunk to change the redirecting party from 655X to a single number for the appropriate call handler.