I am having VCS-C at one of the client-location, Whenever I am dialing a call from register endpoint to un-register endpoint (located remotely) , I am getting an error code no.6 (i.e Unacceptable channel) error on my local TANDBERG ENdoint.VCS-C is running on X6.0.
I am not gettting this error for all the register to un-register endpoint but only for some of the remotely located sites.
Can you guys hwlp me out on this ? It will be a great help.
Thanks brother ,
for the quick response ,
We are dialing direct IP address of Unregister -endpoint. It is in indirect mode. I tried changing it on direct mode. But still getting the same error.
Can you please describe your deplyoment for understanding. Where is this ip you are dialing to. was it a public ip? is it reachable from VCS?
can you ping this ip from VCS?
We have VCS-C and VCS-E.
VCS-E , we are using VCE-E only for internet dialing.
We do have other MPLS infrastructure sutup at Mexico , Eygpt etc.This locaitons are part on Client's infrastucture.
Endpoint wihch are located at this remote location are decribed as Un-registered end-point on VCS-C.
Whenever we dial this un-register endpoint's IP address , The requests goes to VCS-C , its selecting proper search-rule and going ahead.
In my search History, I am getting the call up to H323 seup mode. and then cancelled.
I am not getting anyother clue on my VCS-C., At the same time , my endpoint shows error code no. 6 (i.e-
indicates that the channel most recently identified is not acceptable to the sending party for use in this call.).
Here is the attached file.
As soon as , I bypass the VCS-C , and make a call on direct mode , everything goes well.
From the logs we see a release complete coming from "126.96.36.199". but from where you have taken this TCP dump. is the call setup is via expressway or control?
on control you should have call setup mode to "indirect" and configure a search rule for "any" to "any ip-address" pointing to traversal zone. and on expressway call setup mode should be "direct".
I think this could be issue with media ports as well, as i see a proceeding coming from the remote end. Can you check if this call is routing via expressway or not. ??
if yes, then can you post the searh details for this call fron VCS-Expressway.
Thanks for the response ,
Its NOT a public dialing (Internet dialing) , The both the IP address (source and destinations ) are within infrasctucture.
So the call is routed via VCS-C only. And its not going to VCS-E. We do have a search rule on VCS-C with
"any" to "any ip-address" pointing to Local zone (Unregestered Endpoint ) with priority 95 and one more same search rule pointing towards traversal zone with priority 100 , So only unknown IP address (IPs which are not identified by VCS-C) will be forwarded to VCS-E
In our scenario , the dialed call is pointing towards localZone (unregister endpoint). and we have defined that unregister endpoinht in our Subzone membership rule.
TCP dump provided is of VCS-C. Source address is 188.8.131.52 & remote-end IP address is 184.108.40.206.
Also , On VCS-C , the settings is of "indirect " and on VCS-E its "direct".
Awaiting for your response.
Just wanna ask you , Please dont mind , the capture-result what I have provided to you , are they publically accessible ? Or its accessible only by your team ?
first to clarify this is a accessible to all the internet users registered to cisco and part of telepresence group.
so if the case is that the endpoint is in your LAN. But if its not registered to your control then how would it be connecting into call. Because the searh rule for "ip-address" pointing to local zone is only be matched when you have that endpoint registered to VCS control in local zone.
however if you do not have registered this endpoint on the control then as pointed earlier by Haydn call setup mode would be set to direct and then when you dial the ip-address then the vcs control will try to reach this ip-address directly and want be using any search rule.
anyways when i am checking the logs and TCP dump i see that the call request from VCS is sent to 220.127.116.11 and VCS just waits for the reply and after timer expiry it sends a release complete. So from this it seems we actually never received any reply from remote end.
What is the remote end? is it registered on vcs control?? as i see under vcs config that call setup mode is indirect.
Is the endpoint you are trying to call registered to an other gatekeeper?
What kind of system is that, any chance to also get some logs?
Btw, also do a xstatus in additon to the xconfig, this gives some additinal info.
Btw, Arne had made some debugging info guidelines:
Any nat / application layer gw or anything else in between the devices?
If the ips are added to the local subzone with a membership rule it shall be ok without a registration
to match on the ip. Could you check that this is done for both ip addresses / ranges.
Please remember to rate helpful responses and identify
Yes , We hav added tht IP-segment range in Local-Sunzone membership rule.
This rule , gives all the list of all the unregistered devices. My local device is registered endpoint , where as my remote device is unregistered device. This unregistered device is already added in local subzone with a membership rule.
I checkedout , there is not VCS at remote end.
Like said: network trace and logs and xconf/xstat of all devices would be helpful. What kind of system is it anyhow?
What is the reason on not registering the endpoint to a VCS? (either the -C or -E)?
Btw, is "Call routed mode" in "VCS configuration > Calls" set to optimal or always?
I would try if toggeling this parameter changes the behavior.
In short Alok thinkgs it shall not work at all if not registered, I think I have had a case with a
setup like this which worked, but I have not tried it again in the lab.
Btw, can the non registered party call one of the registered ips?
Please remember to rate helpful responses and identify
Hi Nirav - Can you also verify that the 2.99 address actually received the call setup from the VCS? What is that endpoint and can you run debug on this endpoint? 16.100 seems to release this call cause it seems it never received a response for setup for almost 15 seconds. If you run debug on 2.99 and it never receives the setup to send alerting or connect message, then where would the packet be dropped would be the next best place to look. Frame 1775 is when the setup is sent, and the TCP packet was ACK'ed for transmission in Frame 1778, but looking at the MAC Address, this MAC address is some Hewlett device and doesn't look like a Cisco Endpoint MAC Address. If you can, find out if the CS Setup makes it it to the endpoint in question. Source port on VCS 15020 to destination port 1720 is opened, but need to know if the packet or call setup actually made it to the endpoint to confirm it received the message.
Start on the 2.99 address to see if it received it. If not, there may be something going on network wise to hamper this transmission.
I think the whole conversation is pointing to the remote end only. What is the remote end and whether it receives the setup or not is the most important part!!
(1) Under search rule you have Calls to unknown IP addresses selected as "INDIRECT"
(2) you have configured a subzone as "Subzone Local IP Address"
(3) configured membership rule and assigning IP subnet for not registered end point under that subzone
(3) Search rule configured for Intranet end points not registered on VCS-C as "Search rule for Local IP Address"
with priority say 50 pointing to Local Zone
(4) Make sure you are not STOPing search on successful match in search rule configuration if you want internet IP calling as well
Will enable IP Calling between Registered to Unregistered End point or vice versa
Additionally you may have
(1) Search rule configured for Internet end points not registered on VCS-C as " Search rule for Internet IP Address"
with priority say 60 pointing to Traversal ZOne will do what you are expecting.
If above configurations are correct i will suggest to check (1) what is the remote/Unregistered End Point make/model and configuration (2) Also check rechability and link latency,delay etc for this call to happen