2011/9/15 Iñaki Baz Castillo <[email protected]>:
>> It may work for the 1st request. But in a subsequent mid-dialog request in
>> the reverse direction the contact URI becomes the Request-URI, which is now
>> SIPS, and therefore the Contact in this request must also become SIPS, and
>> you end up in an all-SIPS case.
This is not true. The in-dialog request will have, indeed, a RURI with
SIPS schema, but it will also contain a top Route with SIP schema, so
it takes preference and there is no need at all to set a SIPS Contact
URI.
RFC 5630:
5.1.2. UAS Behavior
When presented with a SIPS URI, a UAS MUST NOT change it to a SIP
URI.
As mandated by [RFC3261], Section 12.1.1:
If the request that initiated the dialog contained a SIPS URI in
the Request-URI or in the top Record-Route header field value, if
there was any, or the Contact header field if there was no Record-
Route header field, the Contact header field in the response MUST
be a SIPS URI.
In our case *there is* a Record-Route in the INVITE arriving to the
UAS and it does contain a SIP URI, so the Contact in the response from
the UAS does not need to be a SIPS URI.
Anyhow I insist: SIPS and TLS usage is a pain. Nobody understands it
(it's clear given any mail thread about this topic) and everybody does
wrong assumptions. I think SIP authors should worry about this reality
and react.
Regards.
--
Iñaki Baz Castillo
<[email protected]>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use [email protected] for questions on how to develop a SIP
implementation.
Use [email protected] for new developments on the application of sip.
Use [email protected] for issues related to maintenance of the core SIP
specifications.
