[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