Solved: Problem with provisioning registration from Internet and CALLS when swicht to the mode TMS Provision...

Vianyfel Cordaro · ‎09-05-2013

Hi, I need help please, because I do not have contract and I can not open a TAC case.

I have the following two problems:

1. When I make the switch to tms provisioning extension mode ,stop working sip calls, I get the following error from both scenarios internal and internet to my internal network:

On VCS-E when the call is Internet to internal network

2013-09-05T11:50:38-04:-30

tvcs: Event="Search Completed" Reason="Invalid permission - Insufficient privilege" Service="H323" Src-alias-type="E164" Src-alias="7449" Dst-alias-type="H323" Dst-alias="anthony_accardi" Call-serial-number="1a069dfa-1647-11e3-86f9-0010f328943a" Tag="1a069f44-1647-11e3-b22f-0010f328943a" Detail="found:false, searchtype:ARQ" Level="1" UTCTime="2013-09-05 16:20:38,670"

On VCS-C when the call is Internal network to Internet:

2013-09-05T11:53:31-04:-30	tvcs: Event="Search Completed" Reason="Forbidden" Service="H323" Src-alias-type="E164" Src-alias="7429" Dst-alias-type="H323" Dst-alias="vianyfel_cordaro" Call-serial-number="812a5198-1647-11e3-ba89-0010f325da04" Tag="812a52e2-1647-11e3-93c9-0010f325da04" Detail="found:false, searchtype:ARQ" Level="1" UTCTime="2013-09-05 16:23:31,687"
2013-09-05T11:53:31-04:-30	tvcs: Event="Search Attempted" Service="H323" Src-alias-type="E164" Src-alias="7429" Dst-alias-type="H323" Dst-alias="vianyfel_cordaro" Call-serial-number="812a5198-1647-11e3-ba89-0010f325da04" Tag="812a52e2-1647-11e3-93c9-0010f325da04" Detail="searchtype:ARQ" Level="1" UTCTime="2013-09-05 16:23:31,680"
2013-09-05T11:53:23-04:-30	tvcs: Event="Search Completed" Reason="Forbidden" Service="H323" Src-alias-type="E164" Src-alias="7429" Dst-alias-type="H323" Dst-alias="vianyfel_cordaro" Call-serial-number="7c9181c4-1647-11e3-bda8-0010f325da04" Tag="7c918304-1647-11e3-865b-0010f325da04" Detail="found:false, searchtype:ARQ" Level="1" UTCTime="2013-09-05 16:23:23,974"

BUT WHEN THE MODE IS TMS AGENT LEGACY ALL THE CALL WORK FINE

2. When I make the switch I can provisioning tms mode i can make the equipment provisioning from internal network but not from outside, and that worries me most is the jabber that being from the internet I get the following error:

013-09-05T11:07:42-04:-30	tvcs: UTCTime="2013-09-05 15:37:42,263" Module="network.sip" Level="INFO": Src-ip="192.168.0.252" Src-port="25084" Detail="Receive Request Method=OPTIONS, Request-URI=sip:192.168.0.250:7001;transport=tls, Call-ID=624afa120c59ba26@192.168.0.252"
2013-09-05T11:07:42-04:-30	tvcs: UTCTime="2013-09-05 15:37:42,261" Module="network.sip" Level="DEBUG": Dst-ip="192.168.0.252" Dst-port="25084" SIPMSG: \|SIP/2.0 401 Unauthorised Via: SIP/2.0/TLS 192.168.0.252:5061;branch=z9hG4bK4de281330ed1277914e57a4bb98ac81416134;received=192.168.0.252;rport=25084 Call-ID: 624afa120c59ba26@192.168.0.252 CSeq: 38570 OPTIONS From: <sip:192.168.0.252>;tag=21e96c96b3f9a439 To: <sip:192.168.0.250:7001>;tag=ba0e03ca2f6b3957 Server: TANDBERG/4120 (X7.2.1) WWW-Authenticate: Digest realm="TraversalZone", nonce="b40cb8278b4a11da992154324161d566d2b57bac3d83c5c518c4528c790d", opaque="AQAAAN1NC9IHdFS3kNJ3Q6UX2JiBXhut", stale=FALSE, algorithm=MD5, qop="auth" Content-Length: 0 \|
2013-09-05T11:07:42-04:-30	tvcs: UTCTime="2013-09-05 15:37:42,261" Module="network.sip" Level="INFO": Dst-ip="192.168.0.252" Dst-port="25084" Detail="Sending Response Code=401, Method=OPTIONS, To=sip:192.168.0.250:7001, Call-ID=624afa120c59ba26@192.168.0.252"
2013-09-05T11:07:42-04:-30	tvcs: UTCTime="2013-09-05 15:37:42,261" Module="network.sip" Level="DEBUG": Src-ip="192.168.0.252" Src-port="25084" SIPMSG: \|OPTIONS sip:192.168.0.250:7001;transport=tls SIP/2.0 Via: SIP/2.0/TLS 192.168.0.252:5061;branch=z9hG4bK4de281330ed1277914e57a4bb98ac81416134;received=192.168.0.252;rport=25084 Call-ID: 624afa120c59ba26@192.168.0.252 CSeq: 38570 OPTIONS From: <sip:192.168.0.252>;tag=21e96c96b3f9a439 To: <sip:192.168.0.250: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>2496</registrationsavailable><turnrelaysavailable>0</turnrelaysavailable></resourceusageinfo>\|
2013-09-05T11:07:42-04:-30	tvcs: UTCTime="2013-09-05 15:37:42,261" Module="network.sip" Level="INFO": Src-ip="192.168.0.252" Src-port="25084" Detail="Receive Request Method=OPTIONS, Request-URI=sip:192.168.0.250:7001;transport=tls, Call-ID=624afa120c59ba26@192.168.0.252"
2013-09-05T11:07:36-04:-30	tvcs: UTCTime="2013-09-05 15:37:36,757" Module="network.tcp" Level="DEBUG": Src-ip="10.10.10.1" Src-port="10191" Dst-ip="10.10.10.10" Dst-port="5060" Detail="TCP Connection Closed"
2013-09-05T11:07:36-04:-30	tvcs: UTCTime="2013-09-05 15:37:36,641" Module="network.sip" Level="DEBUG": Dst-ip="10.10.10.1" Dst-port="10191" SIPMSG: \|SIP/2.0 404 Not Found Via: SIP/2.0/TCP 201.210.111.54:2379;branch=z9hG4bK5fc6a3c5021e3557216ef01c2434fb00.1;received=10.10.10.1;rport=10191;ingress-zone=DefaultZone Call-ID: 6623b1a226372826@127.0.0.1 CSeq: 301 SUBSCRIBE From: <sip:vianyfel_cordaro@domain.com>;tag=2991aa56d191ede3 To: <sip:provisioning@domain.com>;tag=c4114db76ace49d8 Server: TANDBERG/4120 (X7.2.1) Warning: 399 200.11.230.253:5060 "Policy Response" Content-Length: 0 \|
2013-09-05T11:07:36-04:-30	tvcs: UTCTime="2013-09-05 15:37:36,641" Module="network.sip" Level="INFO": Dst-ip="10.10.10.1" Dst-port="10191" Detail="Sending Response Code=404, Method=SUBSCRIBE, To=sip:provisioning@protokolgroup.com, Call-ID=6623b1a226372826@127.0.0.1"
2013-09-05T11:07:36-04:-30	tvcs: UTCTime="2013-09-05 15:37:36,638" Module="network.sip" Level="DEBUG": Src-ip="10.10.10.1" Src-port="10191" SIPMSG: \|SUBSCRIBE sip:vianyfel_cordaro@domain.com SIP/2.0 Via: SIP/2.0/TCP 201.210.111.54:2379;branch=z9hG4bK5fc6a3c5021e3557216ef01c2434fb00.1;received=10.10.10.1;rport=10191 Call-ID: 6623b1a226372826@127.0.0.1 CSeq: 301 SUBSCRIBE Contact: <sip:vianyfel_cordaro@201.210.111.54:2379;transport=tcp> From: <sip:vianyfel_cordaro@domain.com>;tag=2991aa56d191ede3 To: <sip:provisioning@domain.com> Max-Forwards: 70 Route: <sip:192.168.41.205:5060;lr;transport=tcp> User-Agent: TANDBERG/774 (MCX 4.6.3.17194) - Windows Expires: 300 Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.6.3.17194;clientid="S-1-5-21-1078081533-484061587-725345543";connectivity=1 Accept: application/pidf+xml Content-Length: 0

The configuration I have is:

Configuration on VCS Expressway:

Mode TMS Agent Legacy

Seach rule:

local zone- no domain

Any

No

Alias pattern match

Regex

(.+)@domain.com.*

Replace

Continue

LocalZone

local zone- full url

Any

No

Alias pattern match

Regex

(.+)@domain.com.*

Leave

Continue

LocalZone

Traversal zone search rule

Any

No

Any alias

Continue

TraversalZone

DNS zone search rule

Any

AllZones

No

Alias pattern match

Regex

(?!.*@%localdomains%.*$).*

Leave

Continue

DNSZone

Transform

Transform destinations alis to URL

([^@]*)

Regex

Replace

\1@protokolgroup.com

Presence PUA---on

Presence server--off

VCS CONTROL:

Mode TMS Provisioning Extension

Search rule

local zone- no domain

Any

No

Alias pattern match

Regex

(.+)@domain.com.*

Replace

Continue

LocalZone

local zone- full url

Any

No

Alias pattern match

Regex

(.+)@domain.com.*

Leave

Continue

LocalZone

Traversal zone search rule

Any

No

Any alias

Continue

TraversalZone

External IP address search rule

Any

No

Any IP address

Continue

TraversalZone

Transform

Transform destinations alis to URL

([^@]*)

Regex

Replace

\1@protokolgroup.com

Pua--on

presence server--on

I dont hace call policy

Please help me to see what I'm missing or where is the error?

Thankss

Vianyfel Cordaro · ‎09-06-2013

I have this set:

VCS-E

Traversal zone search rule

Any

No

Any alias

Continue

TraversalZone

Should I create another?

View solution in original post

Paulo Souza · ‎09-06-2013

Hi,

Ok. Are you saying that VCSe is using the IP address 10.10.10.10 in the external interface, right? Sure, what about the 200.x.x.x IP address? Is this the NAT IP address of your VCSe, right? Is this configured in VCSe?

Well, you reaally have a NAT issue. Take a look at the SUBSCRIBE message received from jabber to VCSe:

SIPMSG:

|SUBSCRIBE sip:vianyfel_cordaro@domain.com SIP/2.0

Via: SIP/2.0/TCP 201.210.116.201:3612;branch=z9hG4bK138dca6bf6cdd458588900dbaf7b45f4.1;received=10.10.10.1;rport=9368

Call-ID: 23c67328b36951e3@127.0.0.1

CSeq: 301 SUBSCRIBE

Contact:

From: <>vianyfel_cordaro@domain.com>;tag=1e82c817dc3224d5

To: <>provisioning@domain.com>

Max-Forwards: 70

Route: <192.168.41.205:5060>

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

Expires: 300

Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.6.3.17194;clientid="S-1-5-21-1078081533-484061587-725345543";connectivity=1

Accept: application/pidf+xml

Content-Length: 0

Do you see? If the IP address in red 192.168.41.205 is the IP address of your router/nat device, then you can come to conclusion that your router is making inspection/ALG, it is placing its own IP address in the SIP headers. Your firewall/router device should not use any ALG/inspection feature, otherwise you are going to have problems.

I can tell with great assurance, VCSe is rejecting the SUBSCRIBE message with "404 not found" response because VCSE does not recognize this IP address in the "route" field, 192.168.41.205.

Furthermore, your NAT configuration is not the recommended. First, you are using port-based NAT (PAT), in fact, you should use one to one NAT. Second, when your firewall makes NAT to VCSe, the source address is 10.10.10.1, which means that your firewall is NATing the source address and not only the destination address. This kind of NAT it is not recommended for H323/SIP applications.

Well, don't be angry with me, I am trying to help, but I need to say this, your VCSe deployment is almost totally wrong, there are many blind points.

I suggest to review and reconfigure your deployment following this guide:

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

I hope this help.

Regards

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

View solution in original post

Paulo Souza · ‎09-10-2013

Hi,

Now I understand! =)

Ok, take a look at the output that you posted from VCS Control:

SubSearch (1)
Type: FindMe
Action: Reject

Are you using FindMe? If yes, your Find configuration is wrong. If not, please, turn off FindMe feature on TMS and on VCS Control.

Another important point is, what did you configured in TMS in the provisioning directory? What is the device address of your endpoints? Can you share a print of that configuration? Probably, you have configured a device address that doesn't match your search rules, that's why you cannot make the calls.

Regards

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

View solution in original post

Alok Jaiswal · ‎09-05-2013

Hi Vianyfel,

You need to go one by one.

first thing you don't need provisioning on the VCS-ex , you can simply remove the provisioning option key from expressway and reboot the server,

You also need a search rule pointing to traversal so what basically you are doing now is passing your provisioning req to VCS-control, also calls to and fro from the video network. i can't see the taversal zone matching search rule on exp.

First thing to know how is your setup of VCS-E? dual nic or single nic? if its single interface static nat then the vcs-control traversal will point towards nat'ed ip-address i.e. the public ip. if the deployment is dual nic then vcs-control will point to the ip in DMZ network.

Once the traversal is up then you need to configure the authentication policy on VCS control in traversal zone as "check credential". and on VCS-E all zones and subzones should be set to "do not check credential". its important that you have the sip domain configured on the VCS-E. Security part can be worked on later.

Rgds

Alok

Vianyfel Cordaro · ‎09-06-2013

Hi,

-I don´t have provisioning in VCS-E.

- I have configured the vcs-e with dual nic, lan 1 in dmz with nat static public IP address

lan 2: Data segment internal network without nat, and i configure a route static.

-vcs-c - data segment internal network

-Traversal zone in the vcs-c is active

-You can see the search rule that I have, I have already one for traversal zone, I do not know if I'm missing any others?

-I configure the authentication policy as is as you indicate, and as I indicated in the picture above you can see place.

Alok Jaiswal · ‎09-06-2013

Hi Vianyfel,

under your description you didn't mentioned that you have search rule on vcs-exp which is going towards from expressway to vcs control?

also do you have a provisioning option key on VCS-Exp if yes, then delete that and reboot the server. And try again..

Rgds

Alok

Vianyfel Cordaro · ‎09-06-2013

I delete the provisioning option key in VCS-E.

The only search rule that I have set are the ones mencioned in my question. You can check them to see if I need one?. If I missed anyone could tell me how it should be please

thanks Alok

Alok Jaiswal · ‎09-06-2013

Hi Vianyfel,

since the vcs-control is the provisioning server you need another search rule which will send the provisoning req to traversal zone which will go to vcs control.

on the exp can you create another search rule may be a default one line "ant" to "any alias" search rule and point it towards the traversal zone on the VCS-Exp.

Rgds

Alok

Vianyfel Cordaro · ‎09-06-2013

I have this set:

VCS-E

Traversal zone search rule

Any

No

Any alias

Continue

TraversalZone

Should I create another?

Alok Jaiswal · ‎09-06-2013

If search rule is there then it is not required. I expect this working untill there is some more issue.

search the forum and you will get n number of issue with jabber registraton from outside. i think some might fit your scenario.

From the logs it seems that when the subscribe is received for "vianyfel_cordaro@domain.com" the req is not passing to traversal zone but in fact it is going to provisioning server?

after deleting the provisioning option key have you rebooted the server. ?

if yes, and login still doesn't works then i think you need to check if your sip routes are cleared or not. that can be checked through the admin command line.

collect the xconfig of the VCS-E and check for entry "xconfig sip routes" if you have any entry can you please paste here.

Rgds

Alok

Vianyfel Cordaro · ‎09-06-2013

Yes, I restart the server after deleting the option key.

The output of the command "xconfig sip routes" is OK....

Alok Jaiswal · ‎09-06-2013

you should not have sip routes configured on expressway. if there are any sip route exists then you might have to delete it. After that check login again. Do you still see 404 not found error?

Also can you collect the diagnostic logs on expressway and see after first subscribe message on VCS-E what all actions are taken by VCS-E.

this will give us a fair indication that what is going wrong.

Rgds

alok

Vianyfel Cordaro · ‎09-06-2013

I do not know what else to do?

In trying to loggin on jabber outside see this on each vcs:

vcs-ex

Results
2013-09-06T14:23:18-04:-30	tvcs: UTCTime="2013-09-06 18:53:18,899" Module="network.sip" Level="DEBUG": Dst-ip="192.168.0.252" Dst-port="25026" SIPMSG: \|SIP/2.0 200 OK Via: SIP/2.0/TLS 192.168.0.252:5061;branch=z9hG4bK18a8e30abe6d481060832169429d809b8946;received=192.168.0.252;rport=25026 Call-ID: 82eaf51a9a69cc92@192.168.0.252 CSeq: 26662 OPTIONS From: <192.168.0.252>;tag=9e979b6ce4dffc06 To: <192.168.0.250:7001>;tag=ff00d4754cd2125e Server: TANDBERG/4120 (X7.2.1) Supported: com.tandberg.vcs.resourceusage,path,outbound,gruu Content-Type: text/xml Content-Length: 253 25075025001800\|
2013-09-06T14:23:18-04:-30	tvcs: UTCTime="2013-09-06 18:53:18,899" Module="network.sip" Level="INFO": Dst-ip="192.168.0.252" Dst-port="25026" Detail="Sending Response Code=200, Method=OPTIONS, To=sip:192.168.0.250:7001, Call-ID=82eaf51a9a69cc92@192.168.0.252"
2013-09-06T14:23:18-04:-30	tvcs: UTCTime="2013-09-06 18:53:18,899" Module="network.ldap" Level="INFO": Detail="Authentication credential found in directory for identity: vcszone"
2013-09-06T14:23:18-04:-30	tvcs: UTCTime="2013-09-06 18:53:18,899" Module="network.http" Level="DEBUG": Message="Response" Src-ip="127.0.0.1" Src-port="9998" Dst-ip="127.0.0.1" Dst-port="49191" Response="200 OK" ResponseTime="0.00207" Ref="0x7f28a5319aa0"
2013-09-06T14:23:18-04:-30	tvcs: UTCTime="2013-09-06 18:53:18,896" Module="network.http" Level="DEBUG": Message="Request" Method="POST" URL="http://127.0.0.1:9998/credential/name/vcszone" Ref="0x7f28a5319aa0"
2013-09-06T14:23:18-04:-30	tvcs: UTCTime="2013-09-06 18:53:18,896" Module="network.sip" Level="DEBUG": Src-ip="192.168.0.252" Src-port="25026" SIPMSG: \|OPTIONS sip:192.168.0.250:7001;transport=tls SIP/2.0 Via: SIP/2.0/TLS 192.168.0.252:5061;branch=z9hG4bK18a8e30abe6d481060832169429d809b8946;received=192.168.0.252;rport=25026 Call-ID: 82eaf51a9a69cc92@192.168.0.252 CSeq: 26662 OPTIONS From: <192.168.0.252>;tag=9e979b6ce4dffc06 To: <192.168.0.250:7001> Max-Forwards: 0 User-Agent: TANDBERG/4120 (X7.2.1) Authorization: Digest nonce="053c57657c579a201bbc82984603587e500d8908a6d26352312ee9a8631b", realm="TraversalZone", opaque="AQAAAJFfp23/DZpRtrJm2zr4q/BsEeYh", algorithm=MD5, uri="sip:192.168.0.250:7001;transport=tls", username="vcszone", response="7915f5f363c03e1d07ea11e8c0190bb7", qop=auth, cnonce="3fd89c639c1f280d67015aaec14d0d4a7b7f02b272ae6f75e7ce585a7068", nc=00000001 Supported: com.tandberg.vcs.resourceusage Content-Type: text/xml Content-Length: 250 25075024970\|
2013-09-06T14:23:18-04:-30	tvcs: UTCTime="2013-09-06 18:53:18,896" Module="network.sip" Level="INFO": Src-ip="192.168.0.252" Src-port="25026" Detail="Receive Request Method=OPTIONS, Request-URI=sip:192.168.0.250:7001;transport=tls, Call-ID=82eaf51a9a69cc92@192.168.0.252"
2013-09-06T14:23:18-04:-30	tvcs: UTCTime="2013-09-06 18:53:18,894" Module="network.sip" Level="DEBUG": Dst-ip="192.168.0.252" Dst-port="25026" SIPMSG: \|SIP/2.0 401 Unauthorised Via: SIP/2.0/TLS 192.168.0.252:5061;branch=z9hG4bK13c2d22416734e361db864c2b083f4b58945;received=192.168.0.252;rport=25026 Call-ID: 82eaf51a9a69cc92@192.168.0.252 CSeq: 26661 OPTIONS From: <192.168.0.252>;tag=9e979b6ce4dffc06 To: <192.168.0.250:7001>;tag=c2f35d74ba6220d6 Server: TANDBERG/4120 (X7.2.1) WWW-Authenticate: Digest realm="TraversalZone", nonce="053c57657c579a201bbc82984603587e500d8908a6d26352312ee9a8631b", opaque="AQAAAJFfp23/DZpRtrJm2zr4q/BsEeYh", stale=FALSE, algorithm=MD5, qop="auth" Content-Length: 0 \|
2013-09-06T14:23:18-04:-30	tvcs: UTCTime="2013-09-06 18:53:18,893" Module="network.sip" Level="INFO": Dst-ip="192.168.0.252" Dst-port="25026" Detail="Sending Response Code=401, Method=OPTIONS, To=sip:192.168.0.250:7001, Call-ID=82eaf51a9a69cc92@192.168.0.252"
2013-09-06T14:23:18-04:-30	tvcs: UTCTime="2013-09-06 18:53:18,893" Module="network.sip" Level="DEBUG": Src-ip="192.168.0.252" Src-port="25026" SIPMSG: \|OPTIONS sip:192.168.0.250:7001;transport=tls SIP/2.0 Via: SIP/2.0/TLS 192.168.0.252:5061;branch=z9hG4bK13c2d22416734e361db864c2b083f4b58945;received=192.168.0.252;rport=25026 Call-ID: 82eaf51a9a69cc92@192.168.0.252 CSeq: 26661 OPTIONS From: <192.168.0.252>;tag=9e979b6ce4dffc06 To: <192.168.0.250:7001> Max-Forwards: 0 User-Agent: TANDBERG/4120 (X7.2.1) Supported: com.tandberg.vcs.resourceusage Content-Type: text/xml Content-Length: 250 25075024970\|
2013-09-06T14:23:18-04:-30	tvcs: UTCTime="2013-09-06 18:53:18,893" Module="network.sip" Level="INFO": Src-ip="192.168.0.252" Src-port="25026" Detail="Receive Request Method=OPTIONS, Request-URI=sip:192.168.0.250:7001;transport=tls, Call-ID=82eaf51a9a69cc92@192.168.0.252"
2013-09-06T14:23:16-04:-30	tvcs: UTCTime="2013-09-06 18:53:16,814" Module="network.h323" Level="DEBUG": Dst-ip="192.168.0.252" Dst-port="1719" Sending RAS PDU: value RasMessage ::= nonStandardMessage : { requestSeqNum 22648, nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 130, t35Extension 1, manufacturerCode 256 }, data '03000004'H }, genericData { { id nonStandard : 'C2F2D2A2152711DDA1230FC456D89593'H, parameters { { id nonStandard : 'C2F2D2A2152711DDA1230FC456D89593'H, content raw : '3C7265736F757263657573616765696E666F3E3C74726176657273616C63616C6C7361 ...'H } } } } }
2013-09-06T14:23:16-04:-30	tvcs: UTCTime="2013-09-06 18:53:16,814" Module="network.h323" Level="INFO": Dst-ip="192.168.0.252" Dst-port="1719" Detail="Sending RAS NST SeqNum=22648 ASSENT Probe"
2013-09-06T14:23:16-04:-30	tvcs: UTCTime="2013-09-06 18:53:16,813" Module="network.h323" Level="DEBUG": Src-ip="192.168.0.252" Src-port="1719" Received RAS PDU: value RasMessage ::= nonStandardMessage : { requestSeqNum 22648, nonStandardData { nonStandardIdentifier h221NonStandard : { t35CountryCode 130, t35Extension 1, manufacturerCode 256 }, data '03000004'H }, genericData { { id nonStandard : 'C2F2D2A2152711DDA1230FC456D89593'H, parameters { { id nonStandard : 'C2F2D2A2152711DDA1230FC456D89593'H, content raw : '3C7265736F757263657573616765696E666F3E3C74726176657273616C63616C6C7361 ...'H } } } } }
2013-09-06T14:23:16-04:-30	tvcs: UTCTime="2013-09-06 18:53:16,813" Module="network.h323" Level="INFO": Src-ip="192.168.0.252" Src-port="1719" Detail="Received RAS NST SeqNum=22648 ASSENT Probe"
2013-09-06T14:23:10-04:-30	tvcs: UTCTime="2013-09-06 18:53:10,972" Module="network.tcp" Level="DEBUG": Src-ip="10.10.10.1" Src-port="9368" Dst-ip="10.10.10.10" Dst-port="5060" Detail="TCP Connection Closed"
2013-09-06T14:23:10-04:-30	tvcs: UTCTime="2013-09-06 18:53:10,943" Module="network.sip" Level="DEBUG": Dst-ip="10.10.10.1" Dst-port="9368" SIPMSG: \|SIP/2.0 404 Not Found Via: SIP/2.0/TCP 201.210.116.201:3612;branch=z9hG4bK138dca6bf6cdd458588900dbaf7b45f4.1;received=10.10.10.1;rport=9368;ingress-zone=DefaultZone Call-ID: 23c67328b36951e3@127.0.0.1 CSeq: 301 SUBSCRIBE From: <>vianyfel_cordaro@domain.com>;tag=1e82c817dc3224d5 To: <>provisioning@domain.com>;tag=ff0229cfe8466f7e Server: TANDBERG/4120 (X7.2.1) Warning: 399 200.X.X.X:5060 "Policy Response" Content-Length: 0 \|
2013-09-06T14:23:10-04:-30	tvcs: UTCTime="2013-09-06 18:53:10,943" Module="network.sip" Level="INFO": Dst-ip="10.10.10.1" Dst-port="9368" Detail="Sending Response Code=404, Method=SUBSCRIBE, To=sip:provisioning@protokolgroup.com, Call-ID=23c67328b36951e3@127.0.0.1"
2013-09-06T14:23:10-04:-30	tvcs: UTCTime="2013-09-06 18:53:10,940" Module="network.sip" Level="DEBUG": Src-ip="10.10.10.1" Src-port="9368" SIPMSG: \|SUBSCRIBE sip:vianyfel_cordaro@domain.com SIP/2.0 Via: SIP/2.0/TCP 201.210.116.201:3612;branch=z9hG4bK138dca6bf6cdd458588900dbaf7b45f4.1;received=10.10.10.1;rport=9368 Call-ID: 23c67328b36951e3@127.0.0.1 CSeq: 301 SUBSCRIBE Contact: From: <>vianyfel_cordaro@domain.com>;tag=1e82c817dc3224d5 To: <>provisioning@domain.com> Max-Forwards: 70 Route: <192.168.41.205:5060> User-Agent: TANDBERG/774 (MCX 4.6.3.17194) - Windows Expires: 300 Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.6.3.17194;clientid="S-1-5-21-1078081533-484061587-725345543";connectivity=1 Accept: application/pidf+xml Content-Length: 0 \|
2013-09-06T14:23:10-04:-30	tvcs: UTCTime="2013-09-06 18:53:10,940" Module="network.sip" Level="INFO": Src-ip="10.10.10.1" Src-port="9368" Detail="Receive Request Method=SUBSCRIBE, Request-URI=sip:vianyfel_cordaro@domain.com, Call-ID=23c67328b36951e3@127.0.0.1"
2013-09-06T14:23:10-04:-30	tvcs: UTCTime="2013-09-06 18:53:10,919" Module="network.tcp" Level="DEBUG": Src-ip="10.10.10.1" Src-port="9368" Dst-ip="10.10.10.10" Dst-port="5060" Detail="TCP Connection Established"
2013-09-06T14:23:10-04:-30	tvcs: UTCTime="2013-09-06 18:53:10,918" Module="network.tcp" Level="DEBUG": Src-ip="10.10.10.1" Src-port="9368" Dst-ip="10.10.10.10" Dst-port="5060" Detail="TCP Connecting"

VCS-C

013-09-06T14:23:38-04:-30

tvcs: UTCTime="2013-09-06 18:53:38,904" Module="network.sip" Level="DEBUG": Src-ip="192.168.0.250" Src-port="7001"
SIPMSG:
|SIP/2.0 401 Unauthorised
Via: SIP/2.0/TLS 192.168.0.252:5061;branch=z9hG4bK909ea5d0e025febf749f3540dc2572cc8949;received=192.168.0.252;rport=25026
Call-ID: d57247d8f1834fd7@192.168.0.252
CSeq: 24900 OPTIONS
From: <192.168.0.252>;tag=9346057860770a9a
To: <192.168.0.250:7001>;tag=f235999e663ec65b
Server: TANDBERG/4120 (X7.2.1)
WWW-Authenticate: Digest realm="TraversalZone", nonce="4975c0d5e41256131cde94c1d2186520230fed68ed2ccdcdff230458e4f8", opaque="AQAAAJFfp23/DZpRtrJm2zr4q/BsEeYh", stale=FALSE, algorithm=MD5, qop="auth"
Content-Length: 0

And when I want make a call sip internet to internal o viceversa i see the same thing:

On VCS-E when the call is Internet to internal network: Invalid permission - Insufficient privilege

2013-09-05T11:50:38-04:-30

tvcs: Event="Search Completed" Reason="Invalid permission - Insufficient privilege" Service="H323" Src-alias-type="E164" Src-alias="7449" Dst-alias-type="H323" Dst-alias="anthony_accardi" Call-serial-number="1a069dfa-1647-11e3-86f9-0010f328943a" Tag="1a069f44-1647-11e3-b22f-0010f328943a" Detail="found:false, searchtype:ARQ" Level="1" UTCTime="2013-09-05 16:20:38,670"

On VCS-C when the call is Internal network to Internet: Forbidden

2013-09-05T11:53:31-04:-30	tvcs: Event="Search Completed" Reason="Forbidden" Service="H323" Src-alias-type="E164" Src-alias="7429" Dst-alias-type="H323" Dst-alias="vianyfel_cordaro" Call-serial-number="812a5198-1647-11e3-ba89-0010f325da04" Tag="812a52e2-1647-11e3-93c9-0010f325da04" Detail="found:false, searchtype:ARQ" Level="1" UTCTime="2013-09-05 16:23:31,687"
2013-09-05T11:53:31-04:-30	tvcs: Event="Search Attempted" Service="H323" Src-alias-type="E164" Src-alias="7429" Dst-alias-type="H323" Dst-alias="vianyfel_cordaro" Call-serial-number="812a5198-1647-11e3-ba89-0010f325da04" Tag="812a52e2-1647-11e3-93c9-0010f325da04" Detail="searchtype:ARQ" Level="1" UTCTime="2013-09-05 16:23:31,680"
2013-09-05T11:53:23-04:-30	tvcs: Event="Search Completed" Reason="Forbidden" Service="H323" Src-alias-type="E164" Src-alias="7429" Dst-alias-type="H323" Dst-alias="vianyfel_cordaro" Call-serial-number="7c9181c4-1647-11e3-bda8-0010f325da04" Tag="7c918304-1647-11e3-865b-0010f325da04" Detail="found:false, searchtype:ARQ" Level="1" UTCTime="2013-09-05 16:23:23,974"

Paulo Souza · ‎09-06-2013

Hi,

Take a look at the "404 not found" message, see the warning field:

Warning: 399 200.X.X.X:5060 "Policy Response"

Tell me something, is your VCSe behind NAT? If yes, have you configured the NAT address in VCSe (that requires the dual nic option key)? If it is not behind NAT, tell me, what is this IP address 192.168.41.205?? This IP address is included in the "route" field inside your SUBCRIBE message, it seems to be the IP address of your VCSE. However, the SUBSCRIBE message was sent to the IP address 10.10.10.10 and not 192.168.41.205.

It seems you have NAT issue going on here.

Please, post more information about your VCSe topology, including the NAT/firewall information and IP addresses.

Regards

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Vianyfel Cordaro · ‎09-06-2013

Hello,

There is a new thing is that since l internal ared by making an internet call the team could do the call by dialing the sip alias but no video and I went out an error message that said ecryptacion off.

And

- I have configured the vcs-e with dual nic, lan 1 in dmz with nat static public IP address

lan 2: Data segment internal network without nat, and i configure a route static.

-vcs-c - data segment internal network

-On my router border its configure with a pat it sends from 192.168.41.205 that is the router internal IP address to the address 192.168.41.206 address IP internal for my firewall, who makes the requested port nat to 10.10.10.10 this IP address is in the DMZ and it is the VCS-E.

-Traversal zone in the vcs-c is active

Paulo Souza · ‎09-06-2013

Hi,

Ok. Are you saying that VCSe is using the IP address 10.10.10.10 in the external interface, right? Sure, what about the 200.x.x.x IP address? Is this the NAT IP address of your VCSe, right? Is this configured in VCSe?

Well, you reaally have a NAT issue. Take a look at the SUBSCRIBE message received from jabber to VCSe:

SIPMSG:

|SUBSCRIBE sip:vianyfel_cordaro@domain.com SIP/2.0

Via: SIP/2.0/TCP 201.210.116.201:3612;branch=z9hG4bK138dca6bf6cdd458588900dbaf7b45f4.1;received=10.10.10.1;rport=9368

Call-ID: 23c67328b36951e3@127.0.0.1

CSeq: 301 SUBSCRIBE

Contact:

From: <>vianyfel_cordaro@domain.com>;tag=1e82c817dc3224d5

To: <>provisioning@domain.com>

Max-Forwards: 70

Route: <192.168.41.205:5060>

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

Expires: 300

Event: ua-profile;model=movi;vendor=tandberg.com;profile-type=user;version=4.6.3.17194;clientid="S-1-5-21-1078081533-484061587-725345543";connectivity=1

Accept: application/pidf+xml

Content-Length: 0

Do you see? If the IP address in red 192.168.41.205 is the IP address of your router/nat device, then you can come to conclusion that your router is making inspection/ALG, it is placing its own IP address in the SIP headers. Your firewall/router device should not use any ALG/inspection feature, otherwise you are going to have problems.

I can tell with great assurance, VCSe is rejecting the SUBSCRIBE message with "404 not found" response because VCSE does not recognize this IP address in the "route" field, 192.168.41.205.

Furthermore, your NAT configuration is not the recommended. First, you are using port-based NAT (PAT), in fact, you should use one to one NAT. Second, when your firewall makes NAT to VCSe, the source address is 10.10.10.1, which means that your firewall is NATing the source address and not only the destination address. This kind of NAT it is not recommended for H323/SIP applications.

Well, don't be angry with me, I am trying to help, but I need to say this, your VCSe deployment is almost totally wrong, there are many blind points.

I suggest to review and reconfigure your deployment following this guide:

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

I hope this help.

Regards

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Paulo Souza Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

Vianyfel Cordaro · ‎09-06-2013

Thanks,Paulo

And why when I don't have provisioning enabled all it works perfectly?

Problem with provisioning registration from Internet and CALLS when swicht to the mode TMS Provisioning mode Extension