cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1182
Views
5
Helpful
5
Replies

Multiple Expressways with one SIP domain

vctech123
Level 1
Level 1

Hi

I am currently planning to improve a customers video network. The customer has offices spread all over the world, and they have VCS-c installed on every continent. Today they only have one VCS-e, and I would like to install Expressways on every continent as well, to avoid all incoming and outgoing traffic being sent over expensive WAN links to the one VCS-e they have today.

The customers requirement is to still use the one SIP domain that they are using today. The SRV for this SIP domain resolves to the IP of the VCS-e.

When introducing more VCS-e the challenge is about how the the external parties can dial in, since the SRV record can only point to one Expressway.

I have not found any documentation about this subject, but I have heard that this could be achieved by adding a "Directory VCS-e" in front of the Expressways. I have also heard that this Directory VCS-e could be a regular VCS-c, since it will not handle any media routing. It will only be used to set up the call, and then remove itself from the signalling path (with optimized routing set).

I am looking for some design best practices, and I would like to hear other peoples experience around this subject.

I would be greatful for any input on this.

Thanks!

Regards

RA

5 Replies 5

Paulo Souza
VIP Alumni
VIP Alumni

Hi,

I also would suggest you to use a directory VCS, either a control or expressway (If using VCS control this must to be placed on the public internet without NAT). You can forward all the externall call with destination to your domain.com to this VCS, and then route from this VCS to another VCS's. When routing, I think you should consider the following points:

Dial Plan -  In order to be able to route the calls correctly, you should have a dial plan the allow you to route call to each site properly, for example, a dial plan with site code. Using site code or another way to identify which site will receive the call, you will be able to properly route the calls to the correct VCS. Without a proper dial plan, you would have to try to forward the call to all the VCS until you find the destination, this would increase the time to connect the calls, which is not good.

Neighbor Zone - In order to route calls from the directory VCS to another sites. I suggest you to stablish several neighbor zones from the directoryVCS to the other VCS-E's via internet. Creating the Neighbor through internet is the best option, so you will be able to route calls to the the proper VCS-e without using the bandwidth where the directory VCS is installed. If you routed using the local network, all the media would have to cross the directory VCS, which is not good.

There are another points to consider, of course. Do you have Jabber? Do you have presence or another application? What about TMS?

I hope this help.

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Thanks for sharing your thoughts on this Paulo

The dial plan is being improved now, and am going to use country codes in order to route the calls to the correct Expressway from the directory VCS.

There is Jabber Video and TMS in this deployment, but this will be a bit harder to route. The Jabber Video device adresses is the same as their e-mail adresses, and does not contain any geographical indentifier. This could be fixed by using the e-mail adress as their FindMe adress, and create country codes for the device adresses, but they are not using FindMe today, and they have decided to fase out the Jabber Video client, since Lync 2013 is going to be the only soft client .

I have heard someone talking about that you should tweak the hop count settings when using a directory VCS. Do you have any thoughts on that?

Regards

RA

Sound like the Global Dialing Scheme (GDS). Of course, this is global and public, but is an option.

In the UK for instance, the National GK is managed by JANET (https://community.ja.net/library/janet-services-documentation/registering-gatekeeper-global-dialing-scheme).

Also check out http://www.wvn.ac.uk/en/support/globaldiallingschemeexplained/ and http://en.wikipedia.org/wiki/Global_Dialing_Scheme

Cheers,

Chris

There is Jabber Video and TMS in this deployment, but this will be a bit harder to route. The Jabber Video device adresses is the same as their e-mail adresses, and does not contain any geographical indentifier. This could be fixed by using the e-mail adress as their FindMe adress, and create country codes for the device adresses, but they are not using FindMe today, and they have decided to fase out the Jabber Video client, since Lync 2013 is going to be the only soft client .

Well, without FindMe and without having a device address that contain any indentifier or number, you won't have another option to properly route the calls, unless you forward the calls to all VCSs until you find where the destination endpoints is registered to, or if you using more than just one single domain, which is not your case. But if they are going to totally remove Jabber, I don't think it is worthy to implement FindMe or change all the dial plan in order to fix jabber device address.

But the big problem is not how to route calls to the proper VCS towards internall Jabber clients, the big problem is, how to make externall jabber clients to register to the proper VCS if you are pointing SRV records towards the directory VCS? Without using multiple subdomains, that won't be possible!! Not at all! I know that you can forward calls to the proper VCS by using several CPL scripts and routes, and you can also do the same to route provisioning messages, but regarding registration, you cannot forward registration messages to other VCS, unless you use proxied registration, but when using proxied registration, the RTP will flow through directory VCS, which is not good for you.

Well, regarding external Jabber registration. I would suggest:

  • Dont use SRV to register Jabber, give instructions to the user so that they configure their Jabber pointing to the proper VCSe IP address and not to directory VCS or domain. You can create custom jabber instalation setup the automatically configure server address and SIP domain point to the proper VCS
  • Create multiple provisioning directories in TMS, one per site. Configure the templates pointing to the proper VCSc and VCSe according to the site where the users are located

With regards routing calls to internal Jabbers from internet, I would suggest:

  • Route the calls to directory VCS
  • Configure trunks (neighbor zone) through internet from your directory VCS to all the other VCS-E's. In the neighbor zone configuration, Enable SIP poison mode to "On" (it will avoid loops). Do this in the directory VCS and in the other VCSs as well.
  • Create multiple equal search rules with a pattern that matches you jabber device addresses. Point the search rules to all the VCS-E's you have using different priority and set the parameter "on match" to "continue".
  • Make sure that all VCSs are not integrated to other VCSs directly, use directory VCS for all integration between your sites, to avoid loops and long time to connect the calls

Well, this is a complex deployment. I suggest you to take these tips and save a time to think and plan before making any changing.

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Those thoughts are based upon my experience with this kind of deployment. But I am sure that there are another experts here who can give you further suggestions. Martin for example always has a nice solution to offer.   =)

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".