I recently implemented a VCS Express solution in my domain but I need your help to troubleshoot my dns issue.
My infrastructure is:
1 VCSE in dmz 2 nic option and natted with public IP
1 VCSC in lan subnet
All working fine, Traversal call, registration (Movi) from outside, call out SIP/H323 in IP or dns, Interworking... All ok
My issue are for incoming call from non registered endpoint.
When I call from outsite in:
alias@publicIP, working (I create a transform rule to convert IP to Domain
email@example.com working but the search rule failed in agreement with my search rule
firstname.lastname@example.org Failed no incomig call
I suspect that this is a misconfiguration of dns.
We use Bind9 DNS servers as authoritative for our zone
I have configured according to the deployment guides the SRV and A records to point my public IP
I try to query my DNS from outside, nslookup and dig utility, query returns OK
I do not know well Bind9 and I can not understand why the calls are not received in the format email@example.com
I attach a sample of my DNS zone file
$TTL 86400 ; 1 day
@ IN SOA ns1.mydomain.com. root.mydomain.com. (
2011072147 ; Serial YYYYMMDDnn
7200 ; Refresh every 2 hours
7200 ; Retry every 2 hours
7200 ; Expire after 2 hours
14400 ) ; Minimum ttl of 4 hours
IN NS ns1.mydomain.com.
IN NS ns2.mydomain.com.
IN NS ns3.mydomain.com.
mydomain.com. IN NS ns1.mydomain.com. "After creating this entry the call to firstname.lastname@example.org began operating"
mydomain.com. IN A X.X.X.X
ns1 IN A X.X.X.X
ns2 IN A X.X.X.X
ns3 IN A X.X.X.X
vcse IN A X.X.X.X
_h323cs._tcp.mydomain.com. 86400 IN SRV 10 10 1720 vcse.mydomain.com.
_h323ls._udp.mydomain.com. 86400 IN SRV 10 10 1719 vcse.mydomain.com.
_sip._tcp.mydomain.com. 86400 IN SRV 10 10 5060 vcse.mydomain.com.
_sip._udp.mydomain.com. 86400 IN SRV 10 10 5060 vcse.mydomain.com.
_sips._tcp.mydomain.com. 86400 IN SRV 10 10 5061 vcse.mydomain.com.
_sips._tls.mydomain.com. 86400 IN SRV 10 10 5061 vcse.mydomain.com.
_sip._tls.mydomain.com. 86400 IN SRV 10 10 5061 vcse.mydomain.com.
; This entry is for testing
;mydomain.com. IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.mydomain.com.
;mydomain.com. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.mydomain.com.
;mydomain.com. IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.mydomain.com.
any idea is appreciated!
Sorry for my english
Solved! Go to Solution.
what endpoint are you using to test incoming calls? Are you sure that this endpoint supports DNS SRV?
If you could let me know your actual domain name (Send me a PM) I can verify from my end whether or not your SRV records look OK.
Like Andreas said, it can be dependent on the remote endpoint/infrastructure which you use.
Especially if the call to the A record address works. If the remote side does not support SRV or
has a higher priority on A records it would most likely try to set up a call to the web server (if the
A record of the pure domain points to it)
As you already have had in your testing, some clients might also support NAPTR, but they
would most likely also support SRV.
Be aware that a remote DNS might cache the entry or that sometimes you hit a split DNS setup.
As you will always hit limitations regards some endpoints I would just add an additional
search rule so it maps the vcse A record (or maybe you could think of a "video" or "tp" (like video.domain.com) hostname), to make also such remote clients happy.
Please remember to rate helpful responses and identify
Hi Andreasmy domain in PM
Im testing with my friend in other organization they have a similar solution vcse vcsc
I can call him in dns mode but he can not call me.
In addition from his vcse, diagnostic, dns lookup my domain not queryed
i try from my jabber.com account, some sip softphone account and videoconferece test system callback
Thanks for your help
If an nslookup from an external PC is returing the correct resutls then the DNS records would appear to be correct, if you see no incoming call for the then it would appears the problem is with the calling end.
I dont like converting the IP of the expressway to a domain with a transform primarily for the reason that it makes it easier for some targeting the IP of you VCS-E for toll fraud to be routed from your VCSE to the VCS-C and onto your ISDN gateway or your IP Tel environment if its trunked to the VCS.
If you have an ISND GW registered to you VCS or you have a trunk to IP Tel with PSTN acces and you have not already done so you should also implement the VCS E configuration to mitigate the risk of toll fraud thats detaield in the VCS configuration documentation
Good news!! yesterday I correct the Issue.. it works!!
Thanks Andreas for your eagle eye .
The problem was just a typo in the destination host of my long domain name.
When I return in office I kill my network admin!!!
Thanks to all for support and advice for a novice like me
congratulations for the community is of great help