Video/Device Address Paterns, FindMe and Funky CPL!

[Chris Swinney]

Hey all,

I'm gradually progressing on all this good stuff, so now I have a discussion on Video/Device Address Pattern (as applied to a user/group in TMSPE), FindMe and the possibility to creating some CPL (of which I know little, but it high on the ToDo list). I want ensure that my thinking is correct as as go.

We manage several VCS-C/VCS-E deployments from a single TMS instance. Each VCS-C belongs to a separate institutions and so can be thought of as disconnected from the rest of the VCSs. To all intents and purposes, this is a directory style deployment - A single VCS-E will act as a traversal server of many VCS-Cs, which then neighboured with a National Gatekeeper.

Only one of the VCS-Cs has a FindMe licence. In this deployment, we have added device address pattern placeholders (i.e. {device.model}.{device.connectivity}) in TMSPE which means that as users log in with different devices, different address patterns are created. Their global video address pattern matches their e-mail. The FindMe licence on the VCS-C allows the VCS-C to query the Provisioned FindMe accounts so that when a call comes in directed at the users e-mail pattern, the VCS-C is able to spawn many searches based on the result from the active location in the FindMe account. Correct?

The only issue here is that when two external users (both register to the VCS-E) call each other, as the call first has to be routed to the VCS-C, then back out the VCS-E. This then impacts calls licensing causing 2 traversal licence to be taken up on the VCS-E and 1 on the VCS-C. Correct?

Originally, I blindly applied the same address device patterns to the other users on other VCS-C without the FindMe licence, but of course quickly realised that no mapping occurs and so a user registered at a given Device, would never be reach when being called by their video pattern. Doh! So in this case, the Device and Video pattern for the group in TMSPE that is applied to the relevant VCS-C needs to be identical. Correct?

So in this case, two externally registered users can call each other direct, which will consume either 1 traversal or 1 non-traversal call on the VCS-E, depending on how those clients are connected. Correct?

Now we come to call policy. As I understand it, FindMe is essentially a call policy extension, where a single URI can be overwritten by multiple other URI's. Correct (yes of course this is an over simplification but I think this is the essence)? In which case, would it be possible, at least at a very simplistic level, to apply some call policy rules to do a similar thing, thus allowing users on no FindMe licensed VCS-Cs to have an experience like FindMe. Of course, having said this, if most search rules are set to "Continue", and a user is logged on to multiple devices in multiple locations with the same device address pattern, all of these device should ring when a call is placed in any case - although I'm not sure what would happen if they are 'busy'.

I have read from other posts that such Call Policy rule might be best kept in one place (such as a VCS-C) and use Search rules to forward the requests. But this leads back to the additional Traversal Licence calls. I suppose that this is an inherant limitation of this kind or routing? Correct?

Anyhow, please correct me where I am wrong.

[Paulo Souza]

Hi Cris,

I understand your point. I think this is a limitation of FindMe solution. As a matter of fact, the FindMe Deployment Guide describes this limitation just like you did here:

Page 60 - http://www.cisco.com/en/US/docs/telepresence/infrastructure/tmspe/install_guide/Cisco_TMSPE_Deployment_Guide_1-0.pdf

From that statement, there are only two possibilities to have it working:

1 - Route calls to VCS Control and then route them back to VCS Expressway. This is will generate two call IDs in VCSe like you pointed, and two traversall call licenses will be taken from VCS Expressway

2 - Dial device URI instead of FindMe ID, so that calls will not be routed to VCS Control and will be forward to the local endpoint registered to VCS Expresway. It is a problem because the caller ID won't be translated, so you must to have dial plan that allow you to call the device address as well and not only the FindMe ID.

Well, apart from the above suggestions, I think you probably won't have another option, even by using CPL to translate the destination address. For example, lets say your FindMe Deployment includes the following provisioning settings:

Video address pattern: {username}@domain.com

Device address pattern: {username}.{device.model}@domain.com

How would you do to take the "device model" using CPL in order to translate the address correctly? You cannot detect the "device model" using CPL, so you cannot translate the address to the correct address, you cannot translate paulo.souza@domain.com to paulo.jabber@domain.com, unless you create several rules or CPLs, what is not worthy.

Well, if you really are willing to create multiple routes, so I guess it is better you achieve your need by using multiple search rules instead of CPL. Of course, I would not recommend you to do this kind of thing, but I think the following example would work:

Considering the above provisioning settings as an example, you can create multiple search rules in VCSe that match FindMe ID and translate to the possible device URIs:

1 - Pattern: (.*)@domain.com Replace: \1.jabber@domain.com Target: LocalZone (Continue)

2 - Pattern: (.*)@domain.com Replace: \1.ex60@domain.com Target: LocalZone (Continue)

3 - Pattern: (.*)@domain.com Replace: \1.e20@domain.com Target: LocalZone (Continue)

4 - Pattern: (.*)@domain.com Leave Target: TraversalZone (Stop)

Why dont I suggest this schema? That is simple, because of some good reasons:

• In this example, only the destination will be translated, the source address (caller ID) will remain same. Whe routing via FindMe in VCS Control, both destination address and caller ID are translated, so that the called user will see the FindMe ID as source and will be able to callback the correct FindMe ID rather then calling the device address. So you must to have dial plan that allow you to call the device address as well and not only the FindMe ID.
• It is hard to manage and troubleshoot
• Multiple search rules or even CPLs are useless if you have a setup where the video address has nothing to do with the device address, for example:

Video address pattern: {email}@domain.com

Device address pattern: {username}.{device.model}@domain.com

or

Video address pattern: {email}@domain.com

Device address pattern: {phone}@domain.com

or something else that follows the same logic.

Paulo Souza

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

[Paulo Souza]

Well, I think that I cannot point a right solution to your issue, I only can point things you should investigate and consider.

I personally would prefer to buy additional licenses for VCS Expresssway, I mean, If the customer doesn't kill me first rsrs...

I hope this help.

Paulo Souza

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

[Chris Swinney]

I shall pass on your details .

Seriously though - I didn't even realise that the VCS-E could take a FindMe Licence as well as the VCS-C as I though a find me account should only appear on one VCS or cluster?

[Paulo Souza]

Well, you can put FindMe license on VCSe and replicate accounts to it, but according to the documentation, you cannot have the same account in different VCSs (or VCS cluster). Therefore, the same FindMe account should not be placed in VCSc and in VCSe at the same time. Just refer to the print that I posted above.

If you have multiples VCS's(or VCS cluster) with FindMe enable, you should have multiple groups in TMS and replicate each group to the proper VCS (or VCS cluster).

Paulo Souza

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

[Paulo Souza]

Now we come to call policy. As I understand it, FindMe is essentially a call policy extension, where a single URI can be overwritten by multiple other URI's. Correct (yes of course this is an over simplification but I think this is the essence)? In which case, would it be possible, at least at a very simplistic level, to apply some call policy rules to do a similar thing, thus allowing users on no FindMe licensed VCS-Cs to have an experience like FindMe. 

Well, in fact, FindMe also has a database involved and not only scripts to rewrite addresses. So It is not possible to do FindMe feature by using CPL alone.

Of course, having said this, if most search rules are set to "Continue", and a user is logged on to multiple devices in multiple locations with the same device address pattern, all of these device should ring when a call is placed in any case - although I'm not sure what would happen if they are 'busy'.

This sounds like the example that I described above, however there are many limitation, that's why I wouldn't recommend this method. But be aware that you won't have multiple devices ringing at the same time, because VCS does not route a call to multiple devices at the same time, VCS routes by trying one a one.

Paulo Souza

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

[Chris Swinney]

Hi Paulo,

Thanks for the pointers. Here I am trying to understand the potential for achieving something although I had suspected that it might not be as obvious as all that. Still, I like to explore different possibilities on route to understanding the whole package.

There is another factor I need to think about which are non-provisioning standard SIP clients.

With the VCS that runs FindMe, I think I should get the users to register with a hard coded entry in the SIP registration URI (e.g. user.sip@mydom.com) then add this pattern as a device template to the FindMe location in TMS. Am I correct in thinking that with FindMe deployed, you shouldn't have devices registered with the actual find me URI?

With the other VCSs, things are a little simpler as the user will register with their main SIP URI.

Chris

[Paulo Souza]

With the VCS that runs FindMe, I think I should get the users to register with a hard coded entry in the SIP registration URI (e.g. user.sip@mydom.com) then add this pattern as a device template to the FindMe location in TMS. Am I correct in thinking that with FindMe deployed, you shouldn't have devices registered with the actual find me URI?

Yes. The FindMe URI and the device URI should be different.

Paulo Souza

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