[sr-dev] TLS: Sip-Routers adds a Record-Route with "sip" scheme rather than "sips"

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

/O