we have a new vcs/vcse installation and are having problems with some URI calls. We have a domain *.ac.uk and srv records points to the expressways dns names : vcs *. ac.uk. The problem is that some over seas endpoints can not connect to 1002@*.ac.uk but can call 1002@ip of expressway. They do not get any connection using the our URI. They are going through their local ISP to get to us and the ISP are adamant that they are not blocking traffic.
We have all the srv records that CISCO recommend. The units are mainly c20 but 1 sx20 can't connect
this question is not answered !
Solved! Go to Solution.
Interestingly, as you are are .ac.uk do you utilise the GDS via JVCS? - I assume you have a JANET uplink? With our customers (Education/Public sector in the Wales) we direct them to the JVCS booking service which can work with your VCS-E/C infrastructure but enhance your user experience and ability to call multiple overseas sites very simply. However, often the issues we find are with the "other" site/s.
If you can call using a SIP URI using a standards based endpoint, then I would suggest that your SRVs are OK. Of course, if you can't then do as Patrick has asked and give an indication of the SRVs
In a basic single VCS-E deployment, they should be something like:
_sip._udp.uni.ac.uk. IN SRV 100 100 5060 vcs-e.uni.ac.uk.
_sip._tcp.uni.ac.uk. IN SRV 100 100 5060 vcs-e.uni.ac.uk.
_sips._tcp.uni.ac.uk. IN SRV 100 100 5061 vcs-e.uni.ac.uk.
Obviously, you will also need an 'A' record for vcs-e.uni.ac.uk.
You may not even need the first SIP UDP SRV unless you have a specific need to support SIP UDP signalling (nothing to do with SIP UDP media).
PS. I'm also assuming here the you are using SIP SRVs not H.323 SRVs. Are you sure the far site are using the right protocols?
As an aside, I personally do not like people being able to dial into the endpoints using the VCS-E IP address. There are a lot of SIP spamming attempts that will be run against the IP address of the VCS-E, so I tend to block these as a matter of course, and if SIP UDP is not required, turn that off as well (unless of course you have need for it)
Here the SRV records, there is an A record for vcs.*ac.uk that points to 2 vcse's - a cluster
_h323cs._tcp IN SRV 10 10 1720 vcs.*.ac.uk.
_h323ls._udp IN SRV 10 10 1719 vcs.*.ac.uk.
_sip._tcp IN SRV 10 10 5060 vcs.*.ac.uk.
_sip._udp IN SRV 10 10 5060 vcs.*.ac.uk.
_sips._tcp IN SRV 10 10 5061 vcs.*.ac.uk.
_sips._tls IN SRV 10 10 5061 vcs.*.ac.uk.
_sip._tls IN SRV 10 10 5061 vcs.*.ac.uk.
_turn._udp IN SRV 10 10 3471 vcs.*.ac.uk.
OK, firstly _tls is MS Lync SIP not a standards based SIP, so of no relevance here, and Turn (I pretty sure) is also not relevant in this scenario.
I think, if you have multiple VCS-Es then would probably be worth entering multiple SRVs pointing to each peer. I am supposing that this single set of SRVs point to a "cluster" DNS name, which in turn point to the individual hosts? I think you will find that the SRV records give you more flexibility (should you need it in the future) to prioritise and balance DNS request rather than the A records.
Again, the question then must come back to - have you tested know working endpoint that are able to utilise SRV lookup and to they work? If so, what do the foreign site use in terms of hardware, and what protocols are they trying to use?
Did you read my comments below about utilising the GDS? In Education, the GDS is a very good method of dialling.
the units that fail are the same ones that can connect c20's they are all using H323 as the default protocol. This is what is driving us mad!
Yours posts are a little confusing as you are not replying in-line with the thread so we cannot see where you are posting to.
However, as you are using the H.323 protocol, we can also ignore the SIP SRVs.
Where are you 'local' C20s connected to - are they inside network our outside but in the UK? Can you confirm that the "foreign" hosts have DNS servers setup and are not simply set with a static IP?
Can you run a TCPDUMP on the CODEC an capture any DNS request that may be made during a call setup? (Quick before CISCO in their infinite wisdom remove you arms and legs and any ability you might have to do a half tidy job - https://supportforums.cisco.com/comment/9627936)
Our local c20 are inside our network and behind our vcs and vcse. The foreign hosts are not directly conected to us but have public IP's, thay are based outsdied the UK. What would they have to set up on their DNS servers to be able to connect to us?
Have you tested with other institutions in the UK who understand what is going on but outside of you network to confirm that DNS can be resolve correctly? You are not giving me much info to work on therefore I'm not sure how much any can help you further.
Can I ask once more why you don't; use the GDS or JVCS with your JANET connection? Please answer this question? This would help and make connection and GK configuration simpler. That's why it was designed an implement some 15 years ago!
It wasn't my decison not to use JVCS- politics. We have tested from outside and everything works. Our Campus in Malta also works without any problems. The problems are occuring where there is limited tachnical knowlege both on camus and the ISP's they connect to.
So what infomation do you need to help?
If I were you I would raise the non integration with JVCS and the GDS as a cause for concern to you management. You can still utilise DNS, but the whole point of the GDS is that it has been tried and tested and works extremely well (especially for UK Education - not so sure about Malta though), which mean collaboration with other educational bodies is relatively painless.
So can you help us get a grip on you topology?
Hopefully this is enough to get started, but the more you can give the better we are able to help.
The problem with our units overseas is that they are in verious location outs ide the uk so unlikely JVCS will work with them.
to answer your questions:
no vcs pair in Malta on in the UK
the problem units are in Mauritius, India and Hong Kong
All have public IP addresses
All are static IP's
DNS servers are specified on the c20's
They paths to the outside world are open but going through an ISP.
Can the vesrion of friware couse a problem as the units have differing versions.
To outline the first point WRT JVCS and the GDS -
As part of what we offer (WVN), we utilise and partner with JVCS (we used to be be managed by JANET directly) to provide and all Wales Public Sector managed videoconferencing service. We maintain multiple VCS deployment across numerous public sector bodies in Wales (50+) including all Higher Education establishments, Further Education, Unitary Authorities and National Government. The Infrastructure peers with the JVCS National Gatekeeper and the zones are setup to utilise this infrastructure, meaning that all institutions endpoints can be protected whilst leverageing the GDS and the benefits of the JVCS.
As far as I can see you are attempting to do what we have been performing in Wales for the public sector for the past 15 years (and 6 years using the VCS infrastructure). I cannot state enough how much utilising JVCS would benefit your organisation.
Having said all that, you bring up an interesting point. What firmware revisions are the C20s on that are NOT playing ball? If memory serves correctly, there were some very old version of the TC code that did not support this (perhaps pre TC4.2???), but all recent version should be OK. If, for some reason, these CODECs are running on an ancient software version and they are out of maintenance or no longer under support, there is a way to update them to at least TC6.3 due to security vulnerabilities being disclosed in previous versions (this is NOT with regard to the HeartBleed OpenSSL vulnerability, although I haven't read anything as yet with regard to the C series CODEC line and who it may or may not be affected).
I must admit that I'm no expert in reading these log file, but I can see an H.323 call placed and then be rejected for the reason that:
CallResponse(p=2,s = -1, st = -1) failed network rejected: Caller not registered"
BTW, the log does contain info that you might not want "out there". However, it might also be useful to see a log and config from a call that does work.
Have you setup the VCS in some way to reject authenticated call requests?
Does the Malta unit actually register to the VCS-E or is it a completely independent standalone unit (as I suspect would be the India, Mauritius, and Hong Kong units). I take it none of these register to any other kind or gatekeeper? If Malta works and is essentially a standalone unit the same as the others, then my attentions may turn to the VCS-E, checking out the logs on the VCS-E and search histories etc.
Ok, I suspect that the units that ARE working - if the are NOT registered to the VCS-E, have SIP turned on, and that they are failing back to SIP - which works. However, sending an H.323 LRQ simply times out after multiple re-transmits.
DNS resolution seems to be working fine for both H.323 and SIP, so I would suggest you check out the VCS-E and how it is handling inbound H.323 calls via DNS.
Can you do a tcpdump on both the VCS-E and endpoints (both one that works and one that doesn't).
Can I use the info in the file above to try a test call?
I ran a couple of test calls to your unit from our H.323 endpoint via our VCS infrastructure. I can see the LRQ packet being sent from the VCS-E to an IP address (which I can PM you if you wish but wont post), which means that DNS resolution is working. However, the request times out, which is then followed by a second request to a second IP, which seems to fit with what you have said above. Again this times out, at which point a SIP Invite is sent to the second IP and this connects successfully.
A direct SIP call connects straight away.
I think you would need to look at the packet captures to see what it going on in order to determine what is happening - especially at the VCS-E if H.323 request are being sent and the IP address are correct they should arrive.
Alternatively, what about if you enabled SIP on each of the endpoints as this does appear to be working.
None of the units are registered, Malta and the other units are all standalone. The logs don't show any connections from the failed calls so no search histiore are created.
The ISP's that the units go through to get here don't have gatekeepers