Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

URI calls to vcse

hello

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 !  

1 ACCEPTED SOLUTION

Accepted Solutions
VIP Purple

Do you have all of the

Do you have all of the required SRV records?

What endpoints are trying to call you, do they support SRV records?

21 REPLIES
VIP Purple

Do you have all of the

Do you have all of the required SRV records?

What endpoints are trying to call you, do they support SRV records?

Hi btmdxnet2Interestingly, as

Hi

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)

 

Cheers

Chris

VIP Purple

Can you show us what SRV

Can you show us what SRV records you are using?

New Member

Here the SRV records, there

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

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.

Cheers

Chris

 

New Member

the units that fail are the

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!

Hi btmdxnet2Yours posts are a

Hi btmdxnet2

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)

Cheers

Chris

Chris

New Member

Hi Our local c20 are inside

Hi

 

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

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!

New Member

It wasn't my decison not to

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

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?

  • Do you have a VCS pair in the UK and Malta?
  • I take it that the "troublesome" device is not located at either of these locations?
  • So how is the device that can't dial via DNS connected to a network?
  • Is it connected via NAT or is it assigned a public IP address?
  • Does this device use DHCP to get an IP address or has the IP address been statically assigned?
  • If the later, have you specified DNS servers in the devices IP configuration (it won't obviously be able to dial using DNS if it has no DNS servers assigned)?
  • Is there a path the outside world? Is a firewall blocking DNS lookup.....

Hopefully this is enough to get started, but the more you can give the better we are able to help.

Chris

New Member

HiThe problem with our units

Hi

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.

 

 

 

 

 

Hi btmdxnet2,To outline the

Hi btmdxnet2,

To outline the first point WRT JVCS and the GDS -

  1. GDS - As its name suggests, the Global Dialling Scheme (GDS) is global - it was specifically designed with internationalism in mind for the education community. True, in order for foreign endpoint points to make use of the GDS and to obtain a internationally formatted E.164 number, they would need to register to their countries National Gatekeeper and finding out who maintains the National Gatekeeper is a specific country is not always easy. In the UK, this is JVCS.
  2. The JVCS MCUs and Bridges support both UK and International dialling, either via H.323 using the GDS, or direct IP (both inbound and outbound), SIP, ISDN and Desktop Conferencing using the Codian FREE 'Conference ME' client. It just works and can be used to work around multiple issue in the vast majority of circumstances.

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

 

Cheers

Chris

New Member

Most of the c20 are runing

Most of the c20 are runing tcs 6.2 but  we aslo have a sx20 that can't conect as well. I have attached  the all.log from the web front end of one of the units if this can provide any info and I've asked for the xconfig if this will help.

Hey btmdxnet2

Hey btmdxnet2

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.

Chris

Ok, I suspect that the units

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.

 

Cheers

Chris

New Member

Hi just had a look at the

Hi

 

just had a look at the unit in Malta and SIP is not switched on.

Can you do a tcpdump on both

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?

New Member

HI I've asked the relevent

HI

 

I've asked the relevent partiis to send me the info.

I've already seen calls to the expressway from you so feel free to test

 

 

Hi btmdxnet2I ran a couple of

Hi btmdxnet2

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.

 

Cheers

Chris

New Member

Hi None of the units are

Hi

 

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

459
Views
0
Helpful
21
Replies
CreatePlease login to create content