cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3296
Views
0
Helpful
9
Replies

VCSE-VCSC-TMSPE-AD, alway get back 404 not found for movi login

startryst
Level 1
Level 1

Hi, Experts.

Situation:

VCS-Control: X7.2.1

VCS-Expressway: X7.2.1

TMSPE: 13.2.1

AD: Windows 2K3

By VPN, movi user can login to VCS-C(which integrated with AD, so user authentication in AD), but without VPN, by VCS-E, movi user can't login.

VCS-E has static NAT to an public IP address with all necessary port opened up.

VCS-E only have minimun configuration from factory default as below:

1. System name, IP, DNS, NTP

2. Create SIP domain, Enable SIP

3. Create TraversalZone to VCS-C, and both h.323 and SIP connection been estalished, shown as green indicator

4. Create necessary bandwidth link accross all the zones

5. Create an traversal search rule, set target to traversalzone for any alias

6. All zones's authentication policy set to "Do not check credentials" including defaultZone, defaultsubzone, traversalzone

See below for the logging I captures from VCS Expressway, it always get back with 404 Not found error message:

2012-11-28T17:22:00+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:00,448" Module="network.sip" Level="INFO":  Src-ip="172.16.50.3"  Src-port="25000"   Detail="Receive Request Method=OPTIONS, Request-URI=sip:172.16.5.10:7001;transport=tls, Call-ID=b5a570d8afbf7b58@172.16.50.3"

2012-11-28T17:22:00+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:00,448" Module="network.sip" Level="DEBUG":  Src-ip="172.16.50.3"  Src-port="25000"

SIPMSG:

|OPTIONS sip:172.16.5.10:7001;transport=tls SIP/2.0

Via: SIP/2.0/TLS 172.16.50.3:5061;branch=z9hG4bK560062cbd420650fbdcd1423acc049d649;received=172.16.50.3;rport=25000

Call-ID: b5a570d8afbf7b58@172.16.50.3

CSeq: 34143 OPTIONS

From: <sip:172.16.50.3>;tag=0c3b86c51458f605

To: <sip:172.16.5.10:7001>

Max-Forwards: 0

User-Agent: TANDBERG/4120 (X7.2.1)

Supported: com.tandberg.vcs.resourceusage

Content-Type: text/xml

Content-Length: 250

<resourceusageinfo><traversalcallsavailable>250</traversalcallsavailable><nontraversalcallsavailable>750</nontraversalcallsavailable><registrationsavailable>2500</registrationsavailable><turnrelaysavailable>0</turnrelaysavailable></resourceusageinfo>|

2012-11-28T17:22:00+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:00,448" Module="network.sip" Level="INFO":  Dst-ip="172.16.50.3"  Dst-port="25000"   Detail="Sending Response Code=401, Method=OPTIONS, To=sip:172.16.5.10:7001, Call-ID=b5a570d8afbf7b58@172.16.50.3"

2012-11-28T17:22:00+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:00,449" Module="network.sip" Level="DEBUG":  Dst-ip="172.16.50.3"  Dst-port="25000"

SIPMSG:

|SIP/2.0 401 Unauthorised

Via: SIP/2.0/TLS 172.16.50.3:5061;branch=z9hG4bK560062cbd420650fbdcd1423acc049d649;received=172.16.50.3;rport=25000

Call-ID: b5a570d8afbf7b58@172.16.50.3

CSeq: 34143 OPTIONS

From: <sip:172.16.50.3>;tag=0c3b86c51458f605

To: <sip:172.16.5.10:7001>;tag=7ea25e18118002bd

Server: TANDBERG/4120 (X7.2.1)

WWW-Authenticate: Digest realm="TraversalZone", nonce="b1863670c75e193fed666bb5e0b381b7081bccfd4f029bc392157553d58d", opaque="AQAAAM/lI9sgrVIOAlyA49AKb1XNNSQG", stale=FALSE, algorithm=MD5, qop="auth"

Content-Length: 0

|

2012-11-28T17:22:00+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:00,452" Module="network.sip" Level="INFO":  Src-ip="172.16.50.3"  Src-port="25000"   Detail="Receive Request Method=OPTIONS, Request-URI=sip:172.16.5.10:7001;transport=tls, Call-ID=b5a570d8afbf7b58@172.16.50.3"

2012-11-28T17:22:00+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:00,452" Module="network.sip" Level="DEBUG":  Src-ip="172.16.50.3"  Src-port="25000"

SIPMSG:

|OPTIONS sip:172.16.5.10:7001;transport=tls SIP/2.0

Via: SIP/2.0/TLS 172.16.50.3:5061;branch=z9hG4bK0543f31f3f612b0be1752d6785832d1a50;received=172.16.50.3;rport=25000

Call-ID: b5a570d8afbf7b58@172.16.50.3

CSeq: 34144 OPTIONS

From: <sip:172.16.50.3>;tag=0c3b86c51458f605

To: <sip:172.16.5.10:7001>

Max-Forwards: 0

User-Agent: TANDBERG/4120 (X7.2.1)

Authorization: Digest nonce="b1863670c75e193fed666bb5e0b381b7081bccfd4f029bc392157553d58d", realm="TraversalZone", opaque="AQAAAM/lI9sgrVIOAlyA49AKb1XNNSQG", algorithm=MD5, uri="sip:172.16.5.10:7001;transport=tls", username="exampleauth", response="5424b23056e3408bb7c5057ca8921cba", qop=auth, cnonce="32d6888de492c717c771f89e4b9931e3a4dd3090380a925b76349acf62b7", nc=00000001

Supported: com.tandberg.vcs.resourceusage

Content-Type: text/xml

Content-Length: 250

<resourceusageinfo><traversalcallsavailable>250</traversalcallsavailable><nontraversalcallsavailable>750</nontraversalcallsavailable><registrationsavailable>2500</registrationsavailable><turnrelaysavailable>0</turnrelaysavailable></resourceusageinfo>|

2012-11-28T17:22:00+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:00,453" Module="network.http" Level="DEBUG":  Message="Request" Method="POST" URL="http://127.0.0.1:9998/credential/name/exampleauth" Ref="0x460b500"

2012-11-28T17:22:00+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:00,456" Module="network.http" Level="DEBUG":  Message="Response" Src-ip="127.0.0.1" Src-port="9998" Dst-ip="127.0.0.1" Dst-port="45146" Response="200 OK" ResponseTime="0.003486" Ref="0x460b500"

2012-11-28T17:22:00+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:00,456" Module="network.ldap" Level="INFO":   Detail="Authentication credential found in directory for identity: exampleauth"

2012-11-28T17:22:00+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:00,458" Module="network.sip" Level="INFO":  Dst-ip="172.16.50.3"  Dst-port="25000"   Detail="Sending Response Code=200, Method=OPTIONS, To=sip:172.16.5.10:7001, Call-ID=b5a570d8afbf7b58@172.16.50.3"

2012-11-28T17:22:00+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:00,458" Module="network.sip" Level="DEBUG":  Dst-ip="172.16.50.3"  Dst-port="25000"

SIPMSG:

|SIP/2.0 200 OK

Via: SIP/2.0/TLS 172.16.50.3:5061;branch=z9hG4bK0543f31f3f612b0be1752d6785832d1a50;received=172.16.50.3;rport=25000

Call-ID: b5a570d8afbf7b58@172.16.50.3

CSeq: 34144 OPTIONS

From: <sip:172.16.50.3>;tag=0c3b86c51458f605

To: <sip:172.16.5.10:7001>;tag=2f5366fe32e2f0ee

Server: TANDBERG/4120 (X7.2.1)

Supported: com.tandberg.vcs.resourceusage,path,outbound,gruu

Content-Type: text/xml

Content-Length: 250

<resourceusageinfo><traversalcallsavailable>250</traversalcallsavailable><nontraversalcallsavailable>750</nontraversalcallsavailable><registrationsavailable>2500</registrationsavailable><turnrelaysavailable>0</turnrelaysavailable></resourceusageinfo>|

2012-11-28T17:22:02+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:02,195" Module="network.tcp" Level="DEBUG":  Src-ip="101.85.21.125" Src-port="51161" Dst-ip="172.16.5.10" Dst-port="5061" Detail="TCP Connecting"

2012-11-28T17:22:02+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:02,196" Module="network.tcp" Level="DEBUG":  Src-ip="101.85.21.125" Src-port="51161" Dst-ip="172.16.5.10" Dst-port="5061" Detail="TCP Connection Established"

2012-11-28T17:22:02+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:02,277" Module="network.sip" Level="INFO":  Src-ip="101.85.21.125"  Src-port="51161"   Detail="Receive Request Method=SUBSCRIBE, Request-URI=sip:xxx@yyy.com, Call-ID=1ab2eeb3b63676b8@127.0.0.1"

2012-11-28T17:22:02+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:02,277" Module="network.sip" Level="DEBUG":  Src-ip="101.85.21.125"  Src-port="51161"

SIPMSG:

|SUBSCRIBE sip:xxx@yyy.com SIP/2.0

Via: SIP/2.0/TLS 192.168.1.3:51161;branch=z9hG4bKf60920d0f72bbac899bfab5b8e5e30c9.1;received=101.85.21.125;rport=51161

Call-ID: 1ab2eeb3b63676b8@127.0.0.1

CSeq: 201 SUBSCRIBE

Contact: <sip:xxx@192.168.1.3:51161;transport=tls>

From: <sip:xxx@yyy.com>;tag=c9331fde9f056be2

To: <sip:provisioning@yyy.com>

Max-Forwards: 70

Route: <sip:Y.Y.Y.Y:5061;lr;transport=tls>

User-Agent: TANDBERG/774 (MCX 4.5.7.16762) - Mac OS X

Expires: 300

Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.5.7.16762;clientid="7B26CD64-18E7-5443-982A-DD2E496560D2";connectivity=1

Accept: application/pidf+xml

Content-Length: 0

|

2012-11-28T17:22:02+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:02,282" Module="network.sip" Level="INFO":  Dst-ip="101.85.21.125"  Dst-port="51161"   Detail="Sending Response Code=404, Method=SUBSCRIBE, To=sip:provisioning@yyy.com, Call-ID=1ab2eeb3b63676b8@127.0.0.1"

2012-11-28T17:22:02+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:02,282" Module="network.sip" Level="DEBUG":  Dst-ip="101.85.21.125"  Dst-port="51161"

SIPMSG:

|SIP/2.0 404 Not Found

Via: SIP/2.0/TLS 192.168.1.3:51161;branch=z9hG4bKf60920d0f72bbac899bfab5b8e5e30c9.1;received=101.85.21.125;rport=51161;ingress-zone=DefaultZone

Call-ID: 1ab2eeb3b63676b8@127.0.0.1

CSeq: 201 SUBSCRIBE

From: <sip:xxx@yyy.com>;tag=c9331fde9f056be2

To: <sip:provisioning@yyy.com>;tag=709c4dfeda5f3666

Server: TANDBERG/4120 (X7.2.1)

Warning: 399 172.16.5.10:5061 "Policy Response"

Content-Length: 0

|

2012-11-28T17:22:02+08:00 vcse tvcs: UTCTime="2012-11-28 09:22:02,295" Module="network.tcp" Level="DEBUG":  Src-ip="101.85.21.125" Src-port="51161" Dst-ip="172.16.5.10" Dst-port="5061" Detail="TCP Connection Closed"

1 Accepted Solution

Accepted Solutions

awinter2
Level 7
Level 7

Hi,

you mention that the VCS-E is behind a static NAT. Does the VCS-E have the Dual Network Interfaces option key installed, and if this is the case, have you correctly enabled and configured the static NAT configuration on the VCS itself, on the System > IP page in the VCS web interface?

This option key is required when deploying the VCS-E behind NAT, you can find more information on this in Appendix 4 in the following document:

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

View solution in original post

9 Replies 9

awinter2
Level 7
Level 7

Hi,

you mention that the VCS-E is behind a static NAT. Does the VCS-E have the Dual Network Interfaces option key installed, and if this is the case, have you correctly enabled and configured the static NAT configuration on the VCS itself, on the System > IP page in the VCS web interface?

This option key is required when deploying the VCS-E behind NAT, you can find more information on this in Appendix 4 in the following document:

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

Instead of going that way, what's the alternative way for me? I guess I don't have the required dual network key.

If I can set the VCSE's IP to the public routable IP address, which means no NAT/FW ahead of it, is it will be work?

Hi,

yes, thats right..without the dual nic option key the workaround is to set the VCS-exp ip as public routable without NAT/FW as you mentioned. And it should work after that.

also check you shouldn't have a device provisioning key installed on vcs exp..instead you would be proxying all the messages to VCS-control.

rgds

Alok

Good, I've installed any provisioning key on vcs-e, so no worries on this.

will try to reconfigure VCS-e to public, will get back the result soon...

startryst
Level 1
Level 1

After re-deplyed the VCS Expressway to public IP address, the remote movi still can't login, but after I changed the TraversalZone's authentication policy to "Check credentials", the remote movi works....

Just to clarify for avoiding mislead the resolution for future reference.

  • Page 10 of https://supportforums.cisco.com/docs/DOC-25398 (and also device authentication deployment guide) mention, authentication policy should be configure as “Check Credential” for traversal zone when Jabber Video client trying to provisioning from VCS-E while user authentication handle on VCS-C.
    => Resolved by corrected the authentication policy setting.

  • Device authentication method support together with VCS-E, but this partipular case, VCS-E deployed behind firewall with NAT address but haven’t had Dual Interface Option (and no NAT configuration on VCS-E interface) on VCS-E.
    => Resolved by move VCS-E directly on public network.

    Hi, Tomonori

    Acutally for your first point, only the traversalzone on VCS-C set to "Check credential" is fine, leave the traversalzone of VCS-E to "Do not check credentials"....

    Not quite sure about your second point, acutally my practice is either your deploy your VCS-E in pubic, or behind NAT with Dual interface option and related configuration, this is only talk about deployment advice.

    Yes, correct regarding to authentication policy configuration and that's what has been documented.

    Bill Ruhnke
    Level 1
    Level 1

    Wherever you are challenging for credentials is where the Movi client will seek provisioning.  If you challenge on the VCS-E default zone, then VCS-E must connect to TMS provisioning user list.  If you set the SIP domain on the VCS-E then Movi client will register to VCS-E SIP server. I prefer set VCS-E to "proxy", no SIP domain, and challenge for credentials on the VCS-C traversal zone. Set up AD on the VCS-C, which adds the provisioning user directory from TMS to the VCS-C's local authentication database, using those AD credentials to make an LDAP call from TMS to the domain controller.

    Getting Started

    Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: