[Serusers] ser 0.9.7-pre3 SRV "question"

[Steve Blair]

Klaus Darilion wrote:

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

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