Steve Blair wrote:
Klaus Darilion wrote:
Steve Blair wrote:
Klaus Darilion wrote:
Steve Blair wrote:
Klaus Darilion wrote:
Use ngrep to watch also the DNS lookups (ngrep port 5060 or port 53) and verify what ser really looks up in DNS. The kerberos SRV entries must not interfere, but they are in a different domain, thus when looking up _sip._udp.... the kerberos entries should never be seen by ser.
OK. I'll add this check. I agree the kerberos entries shouldn't interfere but I cannot explain why SER would think the domain controller host would be the next hop.
maybe someone fumbled in DNS? :-)
Possible. I have a test scheduled today with our DNS "person".During that session they will enable logging, it is usually off. Hopefully the logging will explain what is happening.
Why so complicated? Just use grep and dig.
Sometimes you need to confirm things :-)
Anyhow I did the tcpdump, I saw the request from SER and the response from our DNS server. SER is asking for the "A" record instead of the "SRV" record. By this I mean SER is performing the equivalent of "dig myserver.myschool.edu A". This is not what we want and not what happened in past release of SER. What I want is "dig _sip._udp.myserver.myschool.edu SRV". Any thoughts on what might be happening?
ser bybasses SRV lookups if there is a port number present in the r-URI (RFC3263). Make sure there is no port in the r-URI.
regards klaus