Hi, any update about this report? Basically the only I ask is that PJSIP should use TLS in case the destination URI (the top most Route of the RURI if there is no Route) has "sips" schema (and optionally ;transport=tcp param which is not required as sips: means TCP by default). Note that "sips:alice at example.com" (which is equivalent to "sips:alice at example.com;transport=tcp" means: "Use TCP transport but securily", which implies TLS over TCP. The usage of ;transport=tls is widely used but it's incorrect as per RFC 3261 and other RFC's. No one RFC about SIP suggests the usage of ;transport=tls. Also, then the UAC (PJSIP) uses TLS as first hop but the destination (i.e. the RURI) has "sip" schema, it must construct the request as follows: INVITE sip:alice at domain.com SIP/2.0 Via: SIP/2.0/TLS 1.2.3.4;branch=qweqwe From: sip:bob@xxxxxxxxxx;tag=qweqwe To: sip:alice at domain.com Contact: sips:alice at 1.2.3.4;transport=tcp The SIPS URI in the Contact is important beacuse this will tell the proxy (if it does loose-routing) to send incoming in-dialog request (as BYE) using TLS-over-TCP to arrive to 1.2.3.4 (as PJSIP is listening on TLS:1.2.3.4:5061. There is no problem with SIPS schema in the Contact URI, as when the request passes through a proxy (or more) it would add Record-Route headers and the remote peer should contact the top most Record-Route when it sends an in-dialog request, so it will no care about the SIPS schema in the Contact. All of this is fully tested. Regards. 2011/7/13 I?aki Baz Castillo <ibc at aliax.net>: > 2011/7/13 Benny Prijono <bennylp at teluu.com>: >>> [RFC3261] Section 19.1: >>> >>> ? ? ?A SIPS URI specifies that the resource be contacted securely. >>> ? ? ?This means, in particular, that TLS is to be used between the UAC >>> ? ? ?and the domain that owns the URI. ?From there, secure >>> ? ? ?communications are used to reach the user, where the specific >>> ? ? ?security mechanism depends on the policy of the domain. >>> >> >> That's fine. >> >>> [RFC3261] Section 8.1.1.8: >>> >>> ? If the Request-URI or top Route header field value contains a SIPS >>> ? URI, the Contact header field MUST contain a SIPS URI as well. >>> >>> ** My comment: in case the INVITE has no Route header but the UA has >>> configured a TLS outbound proxy, it means that the real destination of >>> the next hop of the INVITE is a SIP TLS server, so same rules as >>> 8.1.1.8 applies. This is: the Contact MUST contain a SIPS URI. >>> >> >> I disagree. The client doesn't have to put SIPS in its Contact just >> because the next hop uses TLS. That's not what the paragraph said. > > Yes, that is what the RFC says. However it implies that the INVITE is > sent via TLS from caller to proxy, but in-coming dialog from proxy to > client would go via UDP. IMHO it's a "bug" in the specification. I > also opened a thread in sip-implementors about this topic: > > ?https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-July/027489.html > > > >> I also have a problem with proxy adding SIPS Record-Route. The >> original INVITE has no Route, and the UAC also gives SIP URI, not >> SIPS. So when a proxy injects a SIPS Record-Route, it really puts the >> UAC into a bit of problem since it now must update its Contact to use >> SIPS in the next request. > > Good point! as RFC 3261 says in section 8.1.1.8: > > ? "if the > ? Request-URI or top Route header field value contains a SIPS URI, the > ? Contact header field MUST contain a SIPS URI as well". > > So an in-dialog request from the UAC should change the Contact to a > SIPS uri. Really ugly :) > > But note that this would be "fixed" as I suggested above, this is: > using sips in the Contact of the initial INVITE (and then all would > make more sense). Unfortunatelly the spec says the opposite (use sip > in Contact of the initial INVITE). > > Please let me discuss about it also in the sip-implementors thread. > > > > >>> [RFC5630] Section 5.1.1: >>> >>> ? To emphasize what is already defined in [RFC3261], UAs MUST NOT use >>> ? the "transport=tls" parameter. >>> >> >> Well I don't quite agree with that either. I really don't understand >> why "transport=tls" is forbidden. > > ;transport=tls is nowhere/never defined. Can you find it in RFC 3261 > or in any other RFC after 3261? > > Note that Via transport and URI transport have different grammar/values: > > 1) Request sent by TLS over TCP: > > ? ?INVITE sip:bob at domain.org > ? ?Via: SIP/2.0/TLS 1.2.3.4 > ? ?Contact: <sips:alice at 1.2.3.4;transport=tcp> > > 2) Request sent by TLS over SCTP: > > ? ?INVITE sip:bob at domain.org > ? ?Via: SIP/2.0/TLS-SCTP 1.2.3.4 > ? ?Contact: <sips:alice at 1.2.3.4;transport=sctp> > > > This is, the RFC's consider that TLS is not a transport, but a > security layer over a real transport (as TCP or SCTP). In a SIP URI it > must be set the real transport ("tls" is not a transport, so "tcp" in > case of TLS over TCP). However in Via transport "TLS" must be set. > It's a bit confusing. > > > > ?> If TLS usage is still allowed, why >> are we not allowed to use "transport=tls" in the URI. > > As said above "transport=tls" means nothing in SIP RFC's. It's like > setting "transport=foo". > > >> It's just an URI >> parameter, just as what "transport=tcp" is. > > "tcp" is a valid/standarized transport value for SIP URI ;transport param. > > > > >>> ?# Alice -> Proxy (TLS) >>> ?INVITE sip:bob at domain.com >>> ?Via: SIP/2.0/TLS 1.2.3.4 >>> ?Contact: <sip:alice at 1.2.3.4> >>> >>> This means that when Bob sends a BYE it would arrive to Alice's >>> outbound proxy as follows: >>> >>> ?INVITE sip:alice at 1.2.3.4 >>> ?Route: xxxxxxx >>> >>> The proxy would remove Route header(s) and just the RURI remains, >>> which has no SIPS scheme so it would send the request using UDP (or >>> TCP if the Contact URI includes a ;transport=tcp). >>> >>> IMHO it would be better if the Contact in the INVITE contains a SIPS schema. >>> >> >> This is where I disagree. As I said above, this will put the caller >> into trouble since it now must use SIPS scheme as its Contact. > > I agree. As said above, setting "Contact: > <sips:alice at 1.2.3.4;transport=tcp>" in the initial INVITE would fix > all these issues. > > >> It may >> not even support SIPS in the first place. And this whole mess is >> caused by the deprecation of "transport=tls" parameter. > > "transport=tls" is not deprecated (even if RFC 3261 says that). The > fact is that is defined no where at all. For example, RFC 4168 (SIP > over SCTP) defines "SCTP" and "TLS-SCTP" for Via transport, but does > not define ";transport=tls-sctp" (but just ";transport=sctp"). In > order to tell a proxy "route this request using TLS over SCTP, the > RURI or remaining Route header (after loose routing) should look like: > > ?sips:bob at 1.2.3.4;transport=sctp > > http://tools.ietf.org/html/rfc4168#section-4 > > > >> If this is not >> deprecated, proxy will just insert an URI with "transport=tls" and >> everyone would be happy by now. > > Yes, indeed I agree. But it's not a standard. Anyhow it's ok that > PJSIP allows it (as many other implementations also use > ;transport=tls, even if it's fully undefined). But I think that PJSIP > should also allow/implement the really standarized way :) > > >> So I'd say leave the "transport=tls" parameter alone. > > I don't ask for removing it, but just for understanding "sips" schema > implications. And the fact that "sips" with ";transport=tcp" means TLS > over TCP. > > > >> P.S. >> ?Of course we have bugs here and there, and that's normal for any >> software, but let's not say the whole thing is so UGLY just because of >> this. Or at least if we can't contribute anything to keep a free >> software slightly more beautiful, let's keep opinion like these to >> ourselves. > > Sorry if I used such word, it was not intencional. What I really > consider ugly is the SIP specification regardless all this topic > (sips, TLS, and so) :) -- I?aki Baz Castillo <ibc at aliax.net>
