09-05-2013 11:45 AM - last edited on 03-25-2019 09:09 PM by ciscomoderator
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" |
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" |
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" |
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" |
The configuration I have is:
Configuration on VCS Expressway:
Mode TMS Agent Legacy
Seach rule:
Any | Any | No | Alias pattern match | Regex | (.+)@domain.com.* | Replace | Continue | LocalZone |
Any | Any | No | Alias pattern match | Regex | (.+)@domain.com.* | Leave | Continue | LocalZone |
Any | Any | No | Any alias | Continue |
Any | AllZones | No | Alias pattern match | Regex | (?!.*@%localdomains%.*$).* | Leave | Continue |
Transform
([^@]*) | Regex | Replace |
Presence PUA---on
Presence server--off
VCS CONTROL:
Mode TMS Provisioning Extension
Search rule
Any | Any | No | Alias pattern match | Regex | (.+)@domain.com.* | Replace | Continue | LocalZone |
Any | Any | No | Alias pattern match | Regex | (.+)@domain.com.* | Leave | Continue | LocalZone |
Any | Any | No | Any alias | Continue |
Any | Any | No | Any IP address | Continue |
Transform
([^@]*) | Regex | Replace |
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
Solved! Go to Solution.
09-06-2013 08:43 AM
I have this set:
VCS-E
Traversal zone search rule | Any | Any | No | Any alias | Continue | TraversalZone |
Should I create another?
09-06-2013 01:40 PM
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>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:
I hope this help.
Regards
Paulo Souza
Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
09-10-2013 08:33 PM
Hi,
Now I understand! =)
Ok, take a look at the output that you posted from VCS Control:
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".
09-05-2013 11:56 PM
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
09-06-2013 08:11 AM
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.
09-06-2013 08:19 AM
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
09-06-2013 08:24 AM
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
09-06-2013 08:36 AM
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
09-06-2013 08:43 AM
I have this set:
VCS-E
Traversal zone search rule | Any | Any | No | Any alias | Continue | TraversalZone |
Should I create another?
09-06-2013 09:20 AM
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
09-06-2013 09:50 AM
Yes, I restart the server after deleting the option key.
The output of the command "xconfig sip routes" is OK....
09-06-2013 10:14 AM
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
09-06-2013 12:09 PM
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 |
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 |
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|192.168.0.250:7001>192.168.0.252> |
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 |
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|192.168.41.205:5060> |
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: 0192.168.0.250:7001>192.168.0.252> |
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" |
09-06-2013 12:48 PM
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".
09-06-2013 01:17 PM
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
09-06-2013 01:40 PM
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>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:
I hope this help.
Regards
Paulo Souza
Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".
09-06-2013 02:08 PM
Thanks,Paulo
And why when I don't have provisioning enabled all it works perfectly?
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: