Problem registering movi to VCSe (VCSc working)

[thorstenn]

Hi,

for any reason Jabber Video clients are not able to logon to VCSe. If they are in the office and connecting to VCSc its working.

Deployment:

VCS: 7.2.2

TMSPE: 14.2

VCSc is joined to the domain so people should be able to logon with LDAP credentials. For some days we changed a OU for the users in AD. I resynced the users to TMS. In VCSc my thought is i have nothing to do, right? I don`t no its depending the OU change cause the movi client is not som uch in use.

I started a debug trace on VCSe while logging in from external with movi (IPs and names changed):

SIPMSG:

|SUBSCRIBE sip:<user>@domain.comSIP/2.0

Via: SIP/2.0/TLS 192.168.100.10:3157;branch=z9hG4bK06fbfdf1d928fdea44551eb01444f279.1;received=78.51.4.182;rport=45938

Call-ID: bb23e7fc29870f7a@127.0.0.1

CSeq: 201 SUBSCRIBE

Contact: <sip:<user>@192.168.100.10:3157;transport=tls>

From: <sip:<user>@domain.com>;tag=ff9e0e9142437b34

To: <sip:provisioning@domain.com>

Max-Forwards: 70

Route: <sip:79.34.34.123:5061;lr;transport=tls>

User-Agent: TANDBERG/774 (MCX 4.5.7.16762) - Windows

Expires: 300

Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.5.7.16762;clientid="S-1-5-21-176747291-1711663684-1688638919";connectivity=1

Accept: application/pidf+xml

Content-Length: 0

SIPMSG:

|SIP/2.0 404 Not Found

Via: SIP/2.0/TLS 192.168.100.10:3157;branch=z9hG4bK06fbfdf1d928fdea44551eb01444f279.1;received=78.51.4.182;rport=45938;ingress-zone=DefaultZone

Call-ID: bb23e7fc29870f7a@127.0.0.1

CSeq: 201 SUBSCRIBE

From: <sip:<user>@domain.com>;tag=ff9e0e9142437b34

To: <sip:provisioning@domain.com>;tag=a9bdf7d526c0cb56

Server: TANDBERG/4120 (X7.2.2)

Warning: 399 79.34.34.123:5061 "Policy Response"

Content-Length: 0

So we have a 404 Not found, but why and what is not found, the user who tried to login? For some reason it looks like the request goes not through VCSe to VCSc, thats my feeling?

Zone Auth is as following:

VCSe:

     DZ: do not check credentials

     TZ: do not check credentials, Accept proxied registrations: deny

     DSZ: do not check credentials, Registration policy: deny

VCSc:

      DZ: check credentials

      TZ: check credentials, Accept proxied registrations: allow

      DSZ: check credentials, Registration policy: allow

I also implemented a CPL on VCSe (not on VCSc) but i also disabled the policy an tried again with no success so this should not be the problem.

I have tested some other constelattion without success. :-( Maybe  someone have an idea what i can test. Could it be a firewall problem?

Regards

Thorsten

[Chris Swinney]

Hi Paulo,

Indeed, I do agree with that fact that this is the way it should be, however (like thorstenn), I have been unable to get the example 1 working. Of course setting a domain on the VCS-e essentially set the VCS-E as an authoritative registrar for the domain, so of course an endpoint will register to it. Problem is I can't get the proxying to work.

I have looked at the Expressway Network Log and noticed an error in TCP communication between the VCS-E and client. In general, I can see the provisioning working on the client, however, the registration is an issue - Jabber repots an login error "due to a registration failure".

The Network Log in the VCS-E shows:

2013-06-30T17:52:06+01:00
tvcs: UTCTime="2013-06-30 16:52:06,684" Module="network.tcp" Level="ERROR":  Src-ip="IP_Add_Of_VCS-E" Src-port="25147" Dst-ip="IP_Add_of_client" Dst-port="54810" Detail="TCP Connection Failed" 
2013-06-30T17:52:06+01:00
tvcs: UTCTime="2013-06-30 16:52:06,587" Module="network.tcp" Level="DEBUG":  Src-ip="IP_Add_Of_VCS-E" Src-port="25147" Dst-ip="IP_Add_of_client" Dst-port="54810" Detail="TCP Connecting" 
2013-06-30T17:52:06+01:00
tvcs: UTCTime="2013-06-30 16:52:06,585" Module="network.tcp" Level="DEBUG":  Src-ip="IP_Add_of_client" Src-port="54810" Dst-ip="IP_Add_Of_VCS-E" Dst-port="5061" Detail="TCP Connection Closed" 

Not sure what is going on here as it looks as though the VCS-E closes the established TCP connection from the client, then tries to re-establish and outbound connection from a different por - which isn't going to happen.

Not sure if this will make a difference, but in this test setup, we have two VCS-E in a cluster, connecting to a single VCS-C. To mitigate some issue, I have pointed the Jabber client "External Server" to just one of the VCS-E peers, and have set the "Public SIP Server" in the provisioning template to the same peer.

It would be interesting to see if thorstenn is seeinng the same issue.

Chris

[Paulo Souza]

Hey Cris,

I do see your point. I suggested to not using proxied registration only as a temporary solution until we have proxied registration working, that's why I asked Thorthenn to post detailed logs here.

Well, I have a environment with proxied registration working, this is the setup:

VCS Control (7.1):

Traversal Zone: Check credential

Default Zone: Treat as authenticated

DefaultSubzone: Treat as authenticated

Accept proxied registrations: Allow

SIP Domains

VCS Expressway (7.1):

Traversal Zone: Do not Check credential

Default Zone: Do not Check credential

DefaultSubzone: Do not Check credential

Accept proxied registrations: Allow

SIP registration proxy mode: Proxy to known only

No SIP Domain

Note that, in this environment, Jabber clients are used through internet only, that's why I don't have "check credential" enabled on DSZ and DZ, because provisioning messages are never received through those zones, only through traversal zone. VCSc and VCSe are not in cluster.

To investigate the problem I would need to check all the events that come up when Jabber attempts to register, including all the SIP messages in VCSc and VCSe.

Regards

Paulo Souza

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

[Chris Swinney]

Sorry all - I'm leading you all up the garden path....

I have resolved the error with our installation which was due to a search rule misconfiguration. We have a search rule on the VCS-E that forwards all requests that matched a domain suffix of "@domain.com" via the traversal zone to the VCS-C Whilst this works for calls - the registration attempt uses ONLY "domain.com" - NO '@' symbol. Therefore the search was failing.

Removed the '@' from the pattern sting, and all works as expected. I believe this will be the same case for our other VCS-Es as we have only recently looked to potentially register mobile user to the Expressway.

BTW - I saw the same 404 error found message in a SIP debug as thorsten shows above. Tracing back a few lines, I saw all the search requests that failed. This certianly helped me understand what was going wrong.

[Paulo Souza]

second option worked. But why the first not? Is there any reason not show the registered devices on Expressway ?

Tell me something, using the second option, is your jabber client registered to VCS control or Expressway? It is supposed to be registered to VCS Expressway, once you have SIP domain created on VCSe.

With regards the first option not working, if your configuration is really correct as you are telling, I would suggest to collect all the SIP messages generated when trying to use proxied registration, including the messages on both VCSs, so that we can debug the communication to figure out the problem.

Paulo Souza

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

[Paulo Souza]

Thorthenn,

One more suggestion, Could you also post your transforms here?

This is an important point, because VCSe must to be able to forward REGISTER messages to VCS Control in order to proxied registration work. When a client try to register to VCSe and VCSe has no SIP domain configured, if proxied registration is enable, VCSe will try to forward the registration to VCS Control, then VCSe will take the domain portion of the URI which the client is using to register and VCSe will try to match this domain to its dial plan (transforms, search rules...). So you must to have a transform and search rules to allow the SIP domain to be routed to VCS control.

In your case, your search rules to VCS Control is "Any alias", so the search rules are not the problem. But you may have some transform that is replacing the domain. For example, let's say you have a jabber trying to register by using the URI paulo@domain.com. VCSe must to be able to route "domain.com" to VCS Control in order to proxied registration work. If you had the following tranform, it could be a problem:

This is a very common transform used by most people who implement VCS, because it is suggested by Cisco documentation.

When VCSe tries to route "domain.com", the pattern would be transformed to "domain.com@domain.com", then it would be routed to VCS Control and it wouldn't not work, because VCSe should route the SIP domain alone, "domain.com", in order to proxied registration work.

So, first, check your tranforms and share with us if possible. If there is no problem with transforms, I would to suggest you to post here all the events and SIP messages involved in a registration attempt, so that we can further investigate it.

Regards

Paulo Souza

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

[Paulo Souza]

This is a summary of the registration process of a Jabber client when using proxied registration from VCSe to VCSc in a simple deployment:

1. Jabber client sends SUBSCRIBE message to VCSe using the URI user@domain.com
2. As VCSe does not have provisioning service enable, VCSe forwards the message to VCS Control using its dial plan. So it is necessary to have a dial plan configuration to route user@domain.com to VCS Control
3. VCS Control receives the SUBSCRIBE message and challenge the client for authentication. Client will receive a "407 Proxy Authentication Required" and will send SUBSCRIBE message again including the credentials
4. If the credentials is ok, VCS Control sends a "200 ok" to the client
5. Provisioning will be done in VCS Control, then VCS Control will send a NOTIFY message to the client which contains a Text/XML content with all the configuration that Jabber must to use (exactly the configuration you set in TMS provisioning directory). This content also includes the URI and the External SIP Server which Jabber will use to register
6. Jabber will try to register to VCSe using the URI informed by provisioning, normally the same, user@domain.com
7. As VCSe does not have the SIP domain "domain.com" configured, if proxied registration is enable, VCSe will use its dial plan to route "domain.com" to VCS Control. So it is necessary to have a dial plan configuration to route the pattern "domain.com" to VCS Control
8. Then VCSe will forward REGISTER message to VCS Control
9. VCS Control will challenge the client for authentication again by sending a "401 Unauthorised"
10. Then Jabber will resend REGISTER message including credentials
11. If the credentials is ok, Jabber will register to VCS Control through proxied registration in VCSe

Therefore, to have it working you will need to have a dial plan on VCSe to route "user@domain.com" and "domain.com" patterns to VCS Control. Of course you will need all the basic configuration as well.

I hope this help to understand better proxied registration process with Jabber.

Regards

Paulo Souza

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

[Chris Swinney]

This is an excellent point Paulo. How would you modify the regular expression so that it doesn't cause this problem?

After having a little think about this and I'm not sure how to get around this issue. You can only apply one pre-search transform and I can't see a way to set an either/or condition within a transform. The only thing I can think of to to create a specific search rule for this condition and transform the result 'domain.com@domain.com' back to 'domain.com'.

PS. looks like the HTML formatting of the above post has gone a little squiffy.

[Chris Swinney]

To answer myself again (after having a little thinking time), I suppose you could simply have a higher priority transform that matches 'domain.com' exactly but leaves is as is (so the transform mentioned by Paulo above won't actually fire). Not sure if this is a good thing or not.

[Paulo Souza]

Hey Cris,

This is a good option, but I would use regex to fix that issue.

See this example:

-------------------------------

Following the example above you will be able to suffix your domain when the alias is not a URI, but without doind that when the pattern is your domain.

If you like, please rate. =)

That's why I love regex!

Paulo Souza

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

[Chris Swinney]

That's why I hate RegEx.

;)

..... But I'm getting there

[Martin Koch]

The question would also be how many people need this kind of dialing?

Some time ago I made a feature request to have a counter on search rules and transoforms,

so you can see if and how often things are hit (or not hit :-)

Btw, if you use sip its suffixed anyhow with the sip domain.

So its most likely only older h323 systems.

And maybe I am to used with multi domain setup which domain would you then even map it to :-)

Also if you dial mainly from a phonebook or the ease of the Cisco Touch 8 you might not see the

need of that kind of mapping.

For e164 numbers it might make sense so add the domain and have a search rule stripping it again.

btw, in Paulos example, if you have sip domains configured you can also use:

(?!%localdomains%)([^@]*)

that matches (or better said not) on all the configured domains, but you still need to

rewrite it to a main domain (like the \1@domain.com)

[thorstenn]

Hi Paulo and Chris,

First. Thanks for your support here.

I will try you suggestions and let you know what are the result. I will try as fast as i can because its a very busy time at the moment. :-)

Thanks

Thorsten

[Chris Swinney]

Hey Both,

Just for your info, I'm running through this to test for ourselves as well in a sort of "follow along at home" fashion.

Looks like I can get the registration proxying from the VCS-E to the VCS-C. The Jabber client appears as a registered endpoint in the Default Zone on the VCS-C. So all good

However, there are other issue. The External Jabber client can call an Internal client, however I see no presence info. In addition, the External Jabber client cannot call external clients Internal Client cals external client OK.

If I check the search history on the VCS-E, I see that a two searches are attempted per call attempted - one fails with a "Proxy Authentication Required" error, the other fails as not found. Both follow the search rule successfully as pass the search down the Transversal zone to the VCS-C, but both have parameter Authenticated: False.

I have quickly played with the Zone and Subzone authentication rules on both the VCS-C and VCS-E, setting them ALL to "Treat as Authenticated", but no joy. I will have a proper look tomorrow.

[Chris Swinney]

Correction to above. Looks like if I set the Default Zone on the VCS-E Authentication Policy to "Treat as Authenticated", the "Proxy Authentication Required" error disappears - however, still no presence info and still unable to make external call.

After viewing the search history on the VCS-C, it appears that no sub search rule is fired - so nothing is found. Ther is, however, an ANY ANY rule that should pass searches matched again any alias back to the Traversal Zone, unless the VCS wont allow this type of thing to happen,

[Chris Swinney]

Well, haven't had too much chance to play with this today but we the only way we have been able to allow an external proxied Jabber client from make external calls it to set up multiple traversal zones - or to allow the search rule to the DNS zone to accept a source of the Default Zone on the VCS-E! I think both of these are not good.

Am I right in thinking that calls made from a external client that is proxy registered (i.e. actually appears registered on the VCS-C rather the the VSC-E to which ) should always be routed through the traversal zone to the VCS-C such that:

     External Jabber --> Deafult Zone VCS-E --> Traversal zone to VCS-C -->

However, an alias lookup that comes into the VCS-C on a traversal zone doesn't appear to match a search rule that re-targets the same traversal zone (potential for loops?). So creating a second outbound traversal zone seems to get around the problem.

I need to read more about what problems this might cause.or if there are any other solution.

Even with this in place, the externally proxy registered client still do not receive presence info from remote domains