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

[Paulo Souza]

Hi Thorten,

Look at this URI provisioning@domain.com (I am assuming the "domain.com" is your domain). As VCSe does not have Provisioning feature enable, VCSe should take this URI and match it against its search rules, then it should find a search rule that forwards this provisioning message to VCS Control, so that provisioining can occur sucessfully.

So you should check:

Is your search rules ok?

Is the call policy really disable? (See the log: Warning: 399 79.34.34.123:5061 "Policy Response")

Is the traversall zone up? (VCS does not route call to down zone)

Did you try to disable registration policy? (I do see you  have it enable on VCSe)

Paulo Souza

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

[thorstenn]

Hi, thanks for help.

@Paulo

Traversal zone is up (h323 and SIP)

Registration policy is set to "none" or do you mean Call Policy? I also tried set to "off" with no difference.

@Alok

Here are my searh rules on VCEe:

LocalSearch

priority: 50

Protocol: Any

Source: ANy

Request must be authenticated: No

Mode: Any alias

On successful match: Continue

Target: LocalZone

TraversalSearch

priority: 100

Protocol: Any

Source: ANy

Request must be authenticated: No

Mode: Any alias

On successful match: Continue

Target: TraversalZone

DNSSearch

priority: 150

Protocol: Any

Source: AllZones

Request must be authenticated: No

Mode: Alias pattern match

PatternType: Regex

Pattern string: (?!.*@%localdomains%.*$).*

Pattern behavior: Leave

On successful match: Stop

Target: DNSZone

I don`t know why. But if i now try again it seems to go to VCSc but with a "

SIP/2.0 407 Proxy Authentication Required"

[Paulo Souza]

I don`t know why. But if i now try again it seems to go to VCSc but with a "
SIP/2.0 407 Proxy Authentication Required"

If the provisioning messages are being received in VCS Control, so VCS Expressay is routing correctly. As you have device authentication enable on VCS Control, VCS will try to authenticate the client regardless of the provisioning process. So the local database on VCS Control (imported from TMS through TMSPE or TMS Agent) must to have the users.

Could you check if your local database on VCS Control has the users list? Is the provisioning service replication status ok? Could you run a diagnostic? When users register directly to VCS Control, does it work?

Regards

Paulo Souza

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

[Alok Jaiswal]

407 proxy authentication is expected behaviour when the provisioning is received by VCS control. Since the provisioning messages are receiving by control then run the diagnostic on the control and exp see whats hapening.

does the user you are trying with exist on VCS control ? also some checks can the user is able to register on VCS control when logging from internal lan.

does the provisioning settings on TMS contains public sip server address as your expressway public ip? recheck the user name and password of the user?

if problem persists please open TAC case with diagnostic logs for further analysis.

Rgds,

Alok

[Alok Jaiswal]

Hi Thorstenn,

404 not found is a response sent by VCS when it can't route the URI to a destination. i believe the issue is related to your search rules configured on the VCS-Exp. we would like to see what search rules you have made on the VCS-Exp.

Also please note that when the initial subscribe message comes it would be user@domain.com and not in form of user.movi@doamin.com. we have seen lot of customers doing this mistake.

so please re-check your search rules on VCS-exp.

Rgds

Alok

[thorstenn]

From internal the user can logon without any problems. So The issue have to be between VCSe and VCSc.

On VCSc i see the same 407 proxy authentication issue.

Its strange. The user exist in local database as "TMS" user. Provisioning Services are all active. Tried also a resync.

So maybe some Authentication / Regestration / Proxy settings are not ok on VCSc / VCSe ?

In TMS the external and the internal IP of VCSc and VCSe are configured in the template.

Earlier i postet the Search Rules on VCSe. Could you see some misconfiguration there?

[Paulo Souza · Accepted solution]

Hi,

Could you check if the parameter "SIP registration proxied mode" is set to "Proxy to known only" on VCS Expressway? You find that parameter on SIP Configuration.

This is a required parameter to allow VCSe to work as SIP proxy for registration. It is not enough to set "Acept proxied registration" on VCS control. In general, you should have this configuration for proxied registration:

If you don't want to use proxied registration but want jabbers from internet to register directly to VCSe, you should disable proxied registration feature and create SIP domain in VCS Expressway. It would be something like this:

Try this.

Paulo Souza

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

[thorstenn]

its exactly configured like this ;(

[thorstenn]

second option i have to try.

[Paulo Souza · Accepted solution]

Try the second option just to check if the problem is really related to proxied registration.

Paulo Souza

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

[thorstenn]

Hey Paulo,

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

[Chris Swinney]

Do you have any Local Zone --> Subzones on the VCSe where the where the Jabber user actually register to? Maybe ther is something set there with regard to the "Authentication Policy"

[Chris Swinney]

In addition, I have found that "example 1" shown above to be slightly incorrect (at least with VCS running x7.2.2).

The SIP domain has to be added to the VCS Expressway even when proxying registrations as the registration actually gets added to the Default subzone on the VCS-E, which also means you also need to ensure that the Default-subzone on the VCS-E "Registration policy" is set to "Allow" (the registration of the Jabber client will be placed into this zone even if you have subzones and membership rules set up)..

[Paulo Souza]

In addition, I have found that "example 1" shown above to be slightly incorrect (at least with VCS running x7.2.2).
The SIP domain has to be added to the VCS Expressway even when proxying registrations as the registration actually gets added to the Default subzone on the VCS-E, which also means you also need to ensure that the Default-subzone on the VCS-E "Registration policy" is set to "Allow" (the registration of the Jabber client will be placed into this zone even if you have subzones and membership rules set up)..

Where did you find that information?

The example I posted was taken from the latest Device Authentication Deployment Guide, X7.2. See page 46:

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/Cisco_VCS_Authenticating_Devices_Deployment_Guide_X7-2.pdf

Paulo Souza

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