Integrating Third party Telephony providers

[niterid3r]

Hi All,

We have centralised call processing model with SRST as a fallback method. In one of the branch few third party providers running their own telephony system and would like to integrate with us for calls to be routed internally.

I have been debating myself what way of doing would be most suitable as there are few ways you could do it.

1. Direct SIP trunk with CUCM

2. Third party sip trunk with CUBE and connect CUBE with CUCM

3. Integrate with QSIG trunk on the gateway.

now from my understanding all the above options would full-fill the purpose, however all of them has its own pros and cons.

what we are looking for is below

-to be able to restrict third party providers system to dial only specific numbers in cucm

-restrict the trunk to limited number of sessions(concurrent calls)

-redundancy in the event of WAN failure

-Scalable

What i am sure about is if i were to go with option 3 the requirements above would be fulfilled. Whereas what i am not sure about is if i were to go with option 1 then in that case if you can put the restriction on the trunk for the far end to be able to call on your specific numbers instead the whole organisation. 

Now the only way i could think of doing that is creating a route pattern to block all the non-wanting numbers and associate the partition in which this route pattern exist. Create a new CSS(SIP_CSS) and make this partition and internal partition(INT_PT) in which all numbers exist member of this newly created css. Lastly assign that Css to SIP trunk? Not entirely sure if that would work

SIP_CSS(BLKRP_PT and INT_PT) 

Also is there a way to lock down number of sip session in cucm on a sip trunk?

Never tried and worked on option 2 before so interested to receive any feedback?

happy to discuss and receive any suggestions, idea is to investigate what is the best way of doing this

Thanks..

[Vivek Batra]

-to be able to restrict third party providers system to dial only specific numbers in cucm

-restrict the trunk to limited number of sessions(concurrent calls)

-redundancy in the event of WAN failure

-Scalable

I would use option1 to avoid any hop in between as much as possible.

To restrict certain calls, you have a choice in third party solution as well so that only desired calls are routed to CUCM. Else you can always have separate CSS containing only allowed partitions and assign this CSS to SIP trunk in CUCM.

I don't think CUCM has any restriction on number of calls on SIP trunk. CUBE has this provision to maintain maximum number of calls under dial-peer. Although in CUCM, you would like to check CAC (location) to restrict number of calls depends on codec being used.

In event of WAN failure, third party telephony system should have some sort of provision to route such calls through PSTN.

Regarding scalability, whenever you add new third party telephone system, you just have to create new SIP trunk in CUCM.

[Mohammed al Baqari]

Hi,

I agree with Vivek. SIP Trunk to CUCM is best option. This provides single point of management and reduce the complexity of managing CUBE.

QSIG is having lot of restrictions related to supplementary services therefore, I prefer not to use it unless needed.

Other points are well covered by Vivek.

[niterid3r]

Thanks Vivek and Mohd.

Makes things more clear for me.

The only thing i have  to confirm now is that followong the implementation of option 1 if we were to restrict the incoming calls only to Branch 1 (ext 24XXX). Whereas, the whole organization's extensions are part of internal partition lets say INT_PT then how would you only allow Branch1 extensions on thaT trunk?

Will the approach explained by me in the actual discusion is workable of creating a Route patterns to block all the patterns such as [0-1,3-9][0-3,5-9]XXX other than Branch1 patter and make this part of BLK_PT

SIP_CSS will have BLK_PT and INT_PT respectively.  Or is there any other better way of doing this?

Thanks

[Mohammed al Baqari]

Hi,

The easiest way of doing this is to create and partition called BR1_PT. Assign all the DNs in BR1 to this PT. Then create a CSS called BR1_CSS and have BR1_PT as only partition in this CSS.

Then assign this CSS to the SIP trunk connecting to the 3rd party PBX.

Also, make sure that the CSS used by other phones is having BR1_PT included in order not to break existing communication

[niterid3r]

Thanks Mohammed. 

I know by the option you suggested it would definitely work. Whereas, I am looking for solution with minor changes as I already have somewhere around 100 Phones in Branch 1 with all the phone part of INT_PT partition which is basically the partition for all our extensions on cluster. 

Now, If I were to go with your suggested solution then I have to change the partition on all 100 phones. 

Regards,

[niterid3r]

Ok Answering to my own question. 

I did run this test in the lab on the SIP trunk blocking specific extensions via Route Pattern and it works fine. 

This avoids the path of putting all Branch  extensions into a separate Partition. 

Technically I was never less into confidence that it would not work but wanted to check if someone had tried it. 

Regards,

niterid3r

[Mohammed al Baqari]

Hi,

Changing PT for 100 phones is easy using bulk administration. You can do it in one time in less than 2 mins. I prefer this rather than creating route-patterns to block and then allow specific patterns because of future requirements

[niterid3r]

Correct - Bulk tool is good but one of the problem is that when you change the partition on an existing extension it blanks few fields such as Display Name, External Phone Mask etc.. Now All things which are common among extensions is fine you can bulk it but what would you do to fill it Display Name which is different on every extension.