> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jiri > Kuthan > Sent: Monday, December 08, 2008 3:26 PM > > RFC4474 is simply not there. Despite we=iptel/TKLC have implemented in > SER, > we found ourselves to be rather alone with it. I think the root reason > is it is heavier than it seems. Body integrity protection and dependence > on CAs > makes it just too impracticable. I would say as a hand waving > guesstimate 90% of > all SDPs on this planet gets rewritten for sake of NAT traversal and > there is 0% > SIP deployments leaning on a CA.
I don't think 4474 has failed to get implementation due to CA's. At least companies don't seem to have trouble getting them for HTTPS. (They're not *that* hard to get AFAIK, though they're not free) I think 4474 failed to get implementation because (1) most people don't have this problem yet, (2) many don't think they'll have a problem anytime soon, and (3) it won't work in the cases it would actually provide value for. (or at least #3 is why we didn't bother with it) The main "issue" with 4474 is in fact signing that SDP. The other issues with it that make it break are all resolvable, I think. If you're willing to live with ignoring SDP, as DERIVE does, then a concept similar to 4474 can easily be made to work. But so far we have not gotten consensus in this WG that we can be allowed to ignore the SDP. (even though we have made the argument that we're not providing media identity - we're providing caller-identity) :( -hadriel _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
