Jabber Registration to Traversal Zone and Authentication

[Paul Woelfel]

Hi,

I was using TMS 13.1.2 as an LDAP Authentication source for both VCS-Control and VCS-Expressway, but noticed, that not all passwords are synched correctly in the TMS H.350 LDAP database, because the user is saved in two entries. I switched to local authentication, including the Provisioning database on the VCS-C and local database with proxying SIP registrations from the VSC-E to the VCS-C. This is working fine and I'm able to do calls.

I've created search rules on the VCS Expressway to replace all MCU aliases to a special external auto attendant. Locally registered endpoints on the VCS-E are allowed to call internal aliases. I tried to do the same for Jabber Clients, which are registered to the Traversal Zone of the VCS-C. This is not working as expected, because the Jabber Clients are not registered to a Local Zone and the SIP INVITE is not challenged.

I expected, that all message from the Jabber client will be challenged by the VCSE, but this is not the case. As a result, the SIP Invite is treated like an external user and not an internal.

May 9 10:11:28     tvcs: UTCTime="2012-05-09 08:11:28,425" Module="network.search" Level="INFO": Detail="Search rule 'my.domain proxy registrations' did not match destination alias 'mcu@my.domain'"
May 9 10:11:28     tvcs: UTCTime="2012-05-09 08:11:28,423" Module="network.sip" Level="INFO": Dst-ip="84.113.206.194" Dst-port="62503" Detail="Sending Response Code=100, Method=INVITE, To=sip:mcu@my.domain, Call-ID=999d4c4d96027b31@192.168.210.19"
May 9 10:11:28     tvcs: UTCTime="2012-05-09 08:11:28,419" Module="network.sip" Level="INFO": Src-ip="84.113.206.194" Src-port="62503" Detail="Receive Request Method=INVITE, Request-URI=sip:mcu@my.domain, Call-ID=999d4c4d96027b31@192.168.210.19"

These are the search rules I was talking about:

110     Enabled     "local registered to Traversal"     LocalZone      No      Alias pattern match      Regex      ^(.*)@my.domain$      Leave      Continue      TraverselZone
115     Enabled     "authenticated to internal"     Any      Yes      Alias pattern match      Regex      ^(.*)@my.domain$      Leave      Continue      TraverselZone
120     Enabled     "mcu all to 899"     Any      No      Alias pattern match      Regex      ^(900\d*|conference)@nts\.eu$      Replace      Stop      TraverselZone

Is it possible to allow Jabber Clients to be authenticated on the VCS-E, so a search rule can aply?

Thanks for your help!

[Paul Woelfel]

I forgot one info:

All Zones and Subzones are set to check credentials on VCSC and VCSE.

Traversal Server Subzone on VCSE is set to Treat as Authenticated.

[Martin Koch]

I did tot check it with 13.2 but the h350 towards the opends was never really officially supported.

and many TMS versions have the limitation that the password in the h350 directory did not

get updated after you changed it.

TMS13.2 can be of your interest as the TMSPE will populate the local database with the

usernames and password. Besides that its also not to hard to set up your own h.350 directory.

I do not know your deployment and the decisions on how it is set up, but

you can register the JabberVideo clients also directly to the VCS-E, then your

search rules would fit as well.

An other option could be to have a CPL doing what you want to do.

[Paul Woelfel]

Hi Martin,

I'm using TMS 13.2 with TMSPE, but as I know, the Provisioning database could only be synched to the VCS-C. Has this changed with X7.1 and TMSPE?

I'll change the Authentication to the VCS-E, when I switch over from normal authentication to AD Auth. So the Jabber Clients will be authenticated on the VCS-E and my call routing will work as expected. But what's with other clients, like a EX90, which is registered as a provisioning endpoint. This endpoint won't be able to authenticate against AD with NTLM, so we would require the credentials on the VCS-E.

[Martin Koch · Accepted solution]

You get the "Device Provisioning" key for your VCS-E as well, its free of charge,

it may require a valid service contract.

I have the new provisioning running on a VCS-E cluster in my lab, works fine.

In the old times that deployment was not officially supported, it was running great anyhow :-)

Did not check if its now a officially supported deployment.

I do not know enough about your deployment to say what would be the best for you.

There will always some scenarios where not all features can be deployed together,for whatever reason.

Maybe somebody can assist you in reviewing how the implementation could be best done.

If you would like to have authentication and AD integration you would have to connect

the VCS-E to the AD as well. Endpoints (At least for now) do not auth via AD, but you could

either use a h.350 db (could also be hosted with AD) or the local authentication database.

Which is now also propagated by TMS, might be a answer for your issue as well.

[Paul Woelfel]

Thanks Martin for your answer.

I think I will either one of this ways, depending on the requirements:

1. authenticate all SIP Endpoint on the VCS-C in the Traversal Zone
2. authenticate Jabbers with NTLM on VCS-C on VCS-E, and normal Endpoints with local credentials
3. authenticate all devices on VCS-C and VCS-E with TMSPE on both boxes.

I think the answer of the original question is, that if a endpoint is authorized on the Traversal Subzone of the VCS-C, it is treated as unauthenticated on the VCS-E. The call rules treat the endpoint like an unregistered endpoint.