[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