6 Jul
2011
6 Jul
'11
3:24 p.m.
6 jul 2011 kl. 14.03 skrev Iñaki Baz Castillo:
2011/7/6 Olle E. Johansson <oej(a)edvina.net>et>:
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
2011/7/6
Olle E. Johansson <oej(a)edvina.net>et>:
And what's the response code if there's no target found? 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).