Steve Blair wrote:
Hello:
We are running ser 0.9.7-pre3 and seeing some strange behavior. I'm
hoping someone on this list might have some input.
Our SIP domain name is actually an SRV service name that points to
two A records. This configuration has existed for years and has
worked reliably.
_sip._udp.myserver.myschool.edu
_sip._udp.myserver.myschool.edu service = 1 5 5060
proxy1.myschool.edu.
_sip._udp.myserver.myschool.edu service = 3 5 5060
proxy1.myschool.edu.
The "myserver.myschool.edu" name is not the real name it is just for
discussion purposes. The name "myserver.myschool.edu" has other SRV
records associated with it. For example:
$nslookup > set type=SRV
_kerberos._udp.net.isc.upenn.edu service = 0 100 88
trixie.myserver.myschool.edu
_kerberos._udp.net.isc.upenn.edu service = 0 100 88
pops.myserver.myschool.edu
In the past month we upgraded to this release of SER and noticed a
problem when users call forward their extension to an off campus PSTN
number.
If the Call Forward Always flag is set to Y then the R-URI is
re-written to be a new user portion with our SIP domain name appended
as the hostname. In some ngrep traces I'm seeing our proxy trying to
send the forwarded call to a next hop address of
"pops.myserver.myschool.edu" as shown above. The problem is pops is
not a SIP server.
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.
_Steve
regards
klaus
The only connection between our SIP environment and the host pops is
the domain name. This suggests an issue with SRV resolution but I do
not see the problem in my traces. Does anyone have any thoughts on
this issue?
Thanks,Steve