6 jul 2011 kl. 14.03 skrev Iñaki Baz Castillo:
2011/7/6 Olle E. Johansson oej@edvina.net:
2011/7/6 Olle E. Johansson oej@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