[asterisk-dev] [svn-commits] mmichelson: branch 12 r399083 - in /branches/12: include/asterisk/ res/

[Olle E. Johansson]

16 sep 2013 kl. 11:40 skrev Saúl Ibarra Corretgé <saghul at gmail.com>:

> 
> [snip]
> 
>> After reading your e-mail and the RFCs, I don't have a clear
>> understanding either of all of the issues surrounding usage of a SIPS
>> URI instead of a SIP URI with TLS as transport. The fact that SIPS does
>> not equate to "best-effort" TLS obviously has implications if hops in
>> the middle don't support TLS (you either think you're secure but aren't,
>> or your calls fail, or... something else perhaps?). What I don't have a
>> clear understanding of is why we should prefer SIP with TLS as the
>> transport over SIPS. Couldn't a user make the argument that they really
>> don't want "best-effort" - that is, if they asked for secure
>> communication, they want secure communication along the entire path?
>> What explicit pitfalls are we running into by using SIPS in the URI in
>> the contact header?
> 
> FWIW, I'll just throw here what we do in Blink. I know it's not kosher as per the standard, but oh well, world is not perfect: we ignore SIPS. We basically treat it as it were "sip:". And we use transport=tls.
> 
> I know Olle will want to slap me in the wrist, but that's what has worked so far out there in the wild. Sue me! ;-)

I'll take care of the slapping when we're on tour. :-)

We are several who have voted for deprecating SIPS: totally. The meaning is very unclear and the
benefits of using it even more so.

The important fact is that in this case we don't know if the other UA used udp, tcp or TLS - just the
fact that we get a request over a TLS connection doesn't mean that we can upgrade to SIPS:. 
Could be a proxy or a b2bua that upgraded to TLS based on NAPTR or policy. Adding sips: in a 
contact without getting an inbound complete SIPS: request (with all the right headers in place) will break
communication.

/O