Hi, https://trac.pjsip.org/repos/ticket/1319 is still on for 1.12. I'm not convinced about setting the Contact to SIPS (have we discussed this before?). Best regards, ?Benny On Thu, Sep 15, 2011 at 7:53 PM, I?aki Baz Castillo <ibc at aliax.net> wrote: > 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> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >
