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

Answered Question
Sep 5th, 2013
User Badges:

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,   [email protected]"

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: [email protected]
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, [email protected]"

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: [email protected]
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,   [email protected]"

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: [email protected]
CSeq: 301 SUBSCRIBE
From: <sip:[email protected]>;tag=2991aa56d191ede3
To: <sip:[email protected]>;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:[email protected], [email protected]"

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:[email protected] 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: [email protected]
CSeq: 301 SUBSCRIBE
Contact: <sip:[email protected]:2379;transport=tcp>
From: <sip:[email protected]>;tag=2991aa56d191ede3
To: <sip:[email protected]>
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:

authentication.jpg


Configuration on VCS Expressway:


Mode TMS Agent Legacy


Seach rule:


local zone- no domain

Any

Any

No

Alias pattern match

Regex

(.+)@domain.com.*

Replace

Continue

LocalZone

local zone- full url

Any

Any

No

Alias pattern   match

Regex

(.+)@domain.com.*

Leave

Continue

LocalZone




Traversal zone search rule

Any

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

\[email protected]



Presence PUA---on

Presence server--off


VCS CONTROL:





Mode TMS Provisioning Extension



Search rule


local zone- no domain

Any

Any

No

Alias pattern   match

Regex

(.+)@domain.com.*

Replace

Continue

LocalZone

local zone- full url

Any

Any

No

Alias pattern match

Regex

(.+)@domain.com.*

Leave

Continue

LocalZone



Traversal zone search rule

Any

Any

No

Any alias




Continue

TraversalZone



External IP address search rule

Any

Any

No

Any IP address




Continue

TraversalZone





Transform



Transform   destinations alis to URL

([^@]*)

Regex

Replace

\[email protected]



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

Correct Answer by Paulo Souza about 3 years 11 months ago

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".

Correct Answer by Paulo Souza about 3 years 11 months ago

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:[email protected] 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: [email protected]

CSeq: 301 SUBSCRIBE

Contact:

From: [email protected]>;tag=1e82c817dc3224d5

To: [email protected]>

Max-Forwards: 70

Route:

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".

Cisco Endorsed by Christian Chacon Solano
Vianyfel Cordaro about 3 years 11 months ago

I have this set:


VCS-E


Traversal zone search ruleAnyAnyNoAny alias


ContinueTraversalZone






Should I create another?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Alok Jaiswal Thu, 09/05/2013 - 23:56
User Badges:
  • Silver, 250 points or more

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 Fri, 09/06/2013 - 08:11
User Badges:

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 Fri, 09/06/2013 - 08:19
User Badges:
  • Silver, 250 points or more

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 Fri, 09/06/2013 - 08:24
User Badges:

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 Fri, 09/06/2013 - 08:36
User Badges:
  • Silver, 250 points or more

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

Alok Jaiswal Fri, 09/06/2013 - 09:20
User Badges:
  • Silver, 250 points or more

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 "[email protected]m" 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 Fri, 09/06/2013 - 09:50
User Badges:

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


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

Alok Jaiswal Fri, 09/06/2013 - 10:14
User Badges:
  • Silver, 250 points or more

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 Fri, 09/06/2013 - 12:09
User Badges:

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:-30tvcs: 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: [email protected]
CSeq: 26662 OPTIONS
From: ;tag=9e979b6ce4dffc06
To: ;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:-30tvcs: 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, [email protected]"
2013-09-06T14:23:18-04:-30tvcs: 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:-30tvcs: 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:-30tvcs: 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:-30tvcs: 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: [email protected]
CSeq: 26662 OPTIONS
From: ;tag=9e979b6ce4dffc06
To:
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:-30tvcs: 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, [email protected]"
2013-09-06T14:23:18-04:-30tvcs: 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: [email protected]
CSeq: 26661 OPTIONS
From: ;tag=9e979b6ce4dffc06
To: ;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:-30tvcs: 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, [email protected]"
2013-09-06T14:23:18-04:-30tvcs: 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: [email protected]
CSeq: 26661 OPTIONS
From: ;tag=9e979b6ce4dffc06
To:
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:-30tvcs: 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, [email protected]"
2013-09-06T14:23:16-04:-30tvcs: 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:-30tvcs: 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:-30tvcs: 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:-30tvcs: 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:-30tvcs: 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:-30tvcs: 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: [email protected]
CSeq: 301 SUBSCRIBE
From: [email protected]>;tag=1e82c817dc3224d5
To: [email protected]>;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:-30tvcs: 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:[email protected], [email protected]"
2013-09-06T14:23:10-04:-30tvcs: 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:[email protected] 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: [email protected]
CSeq: 301 SUBSCRIBE
Contact:
From: [email protected]>;tag=1e82c817dc3224d5
To: [email protected]>
Max-Forwards: 70
Route:
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:-30tvcs: 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:[email protected], [email protected]"
2013-09-06T14:23:10-04:-30tvcs: 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:-30tvcs: 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:-30tvcs: 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: [email protected]
CSeq: 24900 OPTIONS
From: ;tag=9346057860770a9a
To: ;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 Fri, 09/06/2013 - 12:48
User Badges:
  • Gold, 750 points or more

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".

Vianyfel Cordaro Fri, 09/06/2013 - 13:17
User Badges:

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

Correct Answer
Paulo Souza Fri, 09/06/2013 - 13:40
User Badges:
  • Gold, 750 points or more

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:[email protected] 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: [email protected]

CSeq: 301 SUBSCRIBE

Contact:

From: [email protected]>;tag=1e82c817dc3224d5

To: [email protected]>

Max-Forwards: 70

Route:

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".

Vianyfel Cordaro Fri, 09/06/2013 - 14:08
User Badges:

Thanks,Paulo



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

Paulo Souza Fri, 09/06/2013 - 14:28
User Badges:
  • Gold, 750 points or more

Well, maybe you have got some changing in the network and not only the migration from TMS Agent legacy to TMSPE. Are you sure that it was the only chaging in your environment?


Anyway, following Cisco documentation, your current deployment is not correct, mainly the inspection/ALG feature enabled in your router/firewall. That is the cause for VCSe reject the SUBSCRIBE message from Jabber.


Take a look at this thread, check the responses by Zac with five green stars:

https://supportforums.cisco.com/thread/2238051?tstart=0


The guy has a VCSe with the same error message, "404 not found". He has a NAT problem too, the IP address in the "route" field inside the SUBSCRIBE message was not recognized by VCSE, so VCSe rejected the message. Just like your issue, but in your case, the firewall is putting the wrong IP address inside the SIP message. In his case, VCSe was not configured with the NAT IP address, but in your case, the inspection/ALG is the problem.


And take a look at the guide that I posted above, the guide states clearly to turn off any inspection/ALG feature in the Firewall/NAT device.


Regards


Paulo Souza

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

Vianyfel Cordaro Tue, 09/10/2013 - 11:31
User Badges:

Hello,


I do the NAT settings as suggested by the documentation:



Effectively solved the problem jabber connection from the external network. So thank you very much for the help!




But continuing with the problem of trying to calls with alias firstname_lastname, the logs on the vcs-e indicate  the following message:




2013-09-10T11:33:14-04:-30tvcs: 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="7fc1a8d0-1a32-11e3-98a1-0010f328943a" Tag="7fc1aa24-1a32-11e3-bfb7-0010f328943a" Detail="found:false, searchtype:ARQ" Level="1" UTCTime="2013-09-10 16:03:14,565"
2013-09-10T11:33:14-04:-30tvcs: Event="Search Attempted" Service="H323" Src-alias-type="E164" Src-alias="7449" Dst-alias-type="H323" Dst-alias="anthony_accardi" Call-serial-number="7fc1a8d0-1a32-11e3-98a1-0010f328943a" Tag="7fc1aa24-1a32-11e3-bfb7-0010f328943a" Detail="searchtype:ARQ" Level="1" UTCTime="2013-09-10 16:03:14,534"



What could it be?

Paulo Souza Tue, 09/10/2013 - 13:46
User Badges:
  • Gold, 750 points or more

Hi,


Great to hear that you have fixed the NAT settings.    =)


Well, can you post the search history details for this call attempt (Status >> Search History)?


Regards


Paulo Souza

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

Vianyfel Cordaro Tue, 09/10/2013 - 14:03
User Badges:

On the calls history i see nothing but on log>>event log:



2013-09-10T16:30:55-04:-30tvcs: 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="15d7b354-1a5c-11e3-b73a-0010f328943a" Tag="15d7b4a8-1a5c-11e3-8331-0010f328943a" Detail="found:false, searchtype:ARQ" Level="1" UTCTime="2013-09-10 21:00:55,761"
2013-09-10T16:30:55-04:-30tvcs: Event="Search Attempted" Service="H323" Src-alias-type="E164" Src-alias="7449" Dst-alias-type="H323" Dst-alias="anthony_accardi" Call-serial-number="15d7b354-1a5c-11e3-b73a-0010f328943a" Tag="15d7b4a8-1a5c-11e3-8331-0010f328943a" Detail="searchtype:ARQ" Level="1" UTCTime="2013-09-10 21:00:55,702"


Log>>network log


2013-09-10T16:32:54-04:-30tvcs: UTCTime="2013-09-10 21:02:54,351" Module="network.h323" Level="DEBUG": Dst-ip="10.10.10.1" Dst-port="62003"
Sending RAS PDU:
value RasMessage ::= admissionReject :
{
   requestSeqNum 46482,
   rejectReason invalidPermission : NULL,
   genericData
   {
   
    {
       id nonStandard : '65CD7B8ADC6711DBBED400123F634B1D'H,
       parameters
       {
        
         {
          id nonStandard : '65CD7B8BDC6711DBBED400123F634B1D'H,
          content number32 : 14
         }
       }
    }
   }
}
2013-09-10T16:32:54-04:-30tvcs: UTCTime="2013-09-10 21:02:54,351" Module="network.h323" Level="INFO": Dst-ip="10.10.10.1" Dst-port="62003"
Detail="Sending RAS ARJ SeqNum=46482 Reason='invalid permission' AdditionalCauseCode='insufficient privilege' "
2013-09-10T16:32:54-04:-30tvcs: UTCTime="2013-09-10 21:02:54,349" Module="network.sip" Level="DEBUG": Src-ip="192.168.0.252" Src-port="25026"
SIPMSG:
|SIP/2.0 403 Forbidden
Via: SIP/2.0/TLS 192.168.0.250:7001;egress-zone=TraversalZone;branch=z9hG4bKb74138b1c7558fb00c1c4d6d93745d8e884.9bd60383ce63180d0267417314b41c71;proxy-call-id=5c86c434-1a5c-11e3-8bac-0010f328943a;received=192.168.0.250;rport=7001;ingress-zone=TraversalZone
Via: SIP/2.0/TCP 127.0.0.1;branch=z9hG4bKc835a9c72018fb7532f2fff18c32aed2883
Call-ID: [email protected]
CSeq: 26498 OPTIONS
From: ;tag=63a88518dbcf102d
To: ;tag=4d05e8fc19fd1e71
Server: TANDBERG/4120 (X7.2.1)
Warning: 399 192.168.0.252:5061 "Policy Response"
Content-Length: 0
Paulo Souza Tue, 09/10/2013 - 14:11
User Badges:
  • Gold, 750 points or more

Hi,


In fact, I am talking about search history. Go to Status >> Search History. Find your call attempt and click in "View details". Then post the result here.


Furtheremore, provide further informaion, such as, are you trying to call from internal jabber registered VCSC to an external Jabber registered to VCSE? Is there Call Policy enabled on any VCS?


Regards


Paulo Souza

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

Vianyfel Cordaro Tue, 09/10/2013 - 19:18
User Badges:

Hi,


The details for search>>history:




when I make the call from a registered jabber Internet to any internal endpoint alias dialing works.



  But if from the internet EX90 registered, we perform alias call fails, or the registered EX90 marking the internal network by alias does not work.


I don´t have any call policy

Paulo Souza Tue, 09/10/2013 - 19:50
User Badges:
  • Gold, 750 points or more

Hi,


This searc history output was taken from VCSE, right? The call is being rejected by the other VCS. So, can you post the search history of the another VCS as well??


As I understand, you have an EX90 registered to VCSE and you cannot use it to call internal endpoints. And you also have an internal EX90 registered to VCSC that cannot dial external endpoint registered to VCSE. Is my understanding correct?? Sorry, I really didn't understand your scenario very well.


Regards


Paulo Souza

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

Vianyfel Cordaro Tue, 09/10/2013 - 20:16
User Badges:

the output of the VCS Control is:




The scenario is such that you indicate :


-1 Ex90 register on VCS-E

-1 EX90 register on VCS-C

-1 Jabber on VCS-E

-1 Jabber on VCS-C



All are configured to register for H323 and sip:



h323: E164 >> 74XX

           or [email protected]



SIP: [email protected]



when I try to make a call by dialing firstname_lastname not work either from the EX90 registered with VCS-E to the registered EX90 VCS-C or vice versa, but if I call dialing 74XX  it works.

Correct Answer
Paulo Souza Tue, 09/10/2013 - 20:33
User Badges:
  • Gold, 750 points or more

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 Thu, 09/12/2013 - 12:09
User Badges:
  • Gold, 750 points or more


Great to hear that your issue has been resolved! Thanks for your feedback. You are welcome!


Regards


Paulo Souza

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

Actions

This Discussion