Re: [SR-Users] NAPTR, SRV and sips vs. transport=tls

11 dec 2012 kl. 01:39 skrev Juha Heinanen <jh(a)tutpro.com>om>: The interesting part was that it was deprecated in the text of RFC 3261, but never existed. And yes, it solves a problem that we can't solve without it, so everyone implements it. RFC 3261 description of the SIPS: uri scheme was kind of naive, and did not work in practise. RFC 5630 did a good job in trying to clarify the mess. Most SIP people agree that it's still not really resolved. SIPS: doesn't deliver the same promise as HTTPS - security end to end. SIPS: just guarantees the first hop. In addition there is a lot of missing pieces to get SIPS: to work. LIke how a proxy can signal back to the originating UA that it could not set up a TLS connection because the certificate of the next hop was bad/expired/not signed by approved CA or something else. After ten years, I think SIPS as a uri scheme is a lost cause. This does NOT mean that TLS is a lost cause, but I think we can't leave the decision about security to the end point user - and they can't decide whether or not they want to place a request for "secure signalling" in their call setup. The WebRTC way is better, just make every call more secure. /O