[Serusers] ser 0.9.7-pre3 SRV "question"

[Klaus Darilion]

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.myserver.myschool.edu
> 
>    _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.

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
>