[sr-dev] TLS: Sip-Routers adds a Record-Route with "sip" scheme rather than "sips"
Olle E. Johansson
oej at edvina.net
Wed Jul 6 14:32:00 CEST 2011
6 jul 2011 kl. 14.24 skrev Olle E. Johansson:
>
> 6 jul 2011 kl. 14.03 skrev Iñaki Baz Castillo:
>
>> 2011/7/6 Olle E. Johansson <oej at edvina.net>:
>>>> 2011/7/6 Olle E. Johansson <oej at edvina.net>:
>>>>> So what does Kamailio say if I have SIPS target URI and my NAPTR doesn't have any entries for TLS?
>>>>
>>>> Based on RFC 3263 (which I've studied recently in deep) Kamailio
>>>> should discard NAPTR records whose "service" field has not SIPS+XXX.
>>>> So at the end it's like if there are not NAPTR records.
>>>> Then it should perform _sips._tcp SRV for the RURI domain. If there
>>>> is, use its records.
>>>> If not, the perform A/AAAA DNS resolution for the RURI domain and
>>>> choose port 5061 (default por TLS).
>>>>
>>> And what's the response code if there's no target found?
>>
>> I asked fot this in sip.implementors. It would be the very same as if
>> the domain does not exist (A record) which also is unclear which
>> response deservers. Some people suggested 404, others 604...
>>
>> As I hate 6XX responses I would generate a 404.
>>
>> But in case the domain exists but does not listen TLS connections,
>> then again it's not defined which exact response code to return by the
>> proxy. Kamailio uses 478 custom response (maybe it's other code). Note
>> however that due to a limitation in TCP/TLS async mode [*] Kamailio
>> returns 408 after fr_timer.
>>
>> [*] http://sip-router.org/tracker/index.php?do=details&task_id=136
>
> That's interesting.
>
> There are two warning codes registred with IANA that touches SIPS:
>
> 380 SIPS Not Allowed: The UAS or proxy cannot process [RFC5630]
> the request because the SIPS scheme is not allowed
> (e.g., because there are currently no registered
> SIPS Contacts).
>
> 381 SIPS Required: The UAS or proxy cannot process the [RFC5630]
> request because the SIPS scheme is required.
>
> In this case, warning: 381 might be a good one.
> Now, how should we do if we forward a response and the certificate doesn't match? Just drop the response?
>
> There's a new RFC with SIp security call flows, Gotta check that one for reference as well.
http://tools.ietf.org/html/rfc6216
/O
More information about the sr-dev
mailing list