[Users] t_relay does not follow RFC3263 "Locating SIP Servers"

Bogdan-Andrei Iancu bogdan at voice-system.ro
Tue Sep 6 12:31:22 CEST 2005


Hi Franz,

to be RFC 3263 compliant, OpenSER should perform a NAPTR lookup, 
possible followed by several SRV lookups (for different protocols) and 
normal A record lookup.

Adding NAPTR lookup now is a little bi to late for the upcoming release. 
So we should start working on it after the  cvs forks.

What might be done for the next release is to try a two SRV lookups (tcp 
and udp) if no proto is explicitly set, and to select one target based 
on priority and weight.

Or what Klaus suggested - try by default UDP and if fails go for TCP.

regards,
Bogdan


Franz Edler wrote:

>Hi Bogdan,
>
>  
>
>>may you point the section from RFC 3263 which says that?
>>the best I found is
>>    "4.1 Selecting a Transport Protocol"
>>    
>>
>
>Yes exactly.
>
>  
>
>>   If no NAPTR records are found, the client constructs SRV queries for
>>   those transport protocols it supports, and does a query for each.
>>   Queries are done using the service identifier "_sip" for SIP URIs and
>>   "_sips" for SIPS URIs.  A particular transport is supported if the
>>   query is successful.  The client MAY use any transport protocol it
>>   desires which is supported by the server.
>>    
>>
>
>Therefore the first thing should be to look for NAPTR records.
>The next step (in case no NAPTR records are found) should be to look for SRV
>records for transport protocols, which the client supports. In case of a TCP
>enabled openser this should include _sip._tcp. Then the transport protocol
>decision should take into consideration the priority values across all SRV
>records, as you already mentioned.
>
>This method enables comfortable control of transport protocols via DNS
>records without manually selecting protocols in configuration files.
>
>That would be fine.
>
>Regards
>Franz
>
>
>  
>





More information about the Users mailing list