Hadriel Kaplan wrote:
-----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) :(
Possibly yes.
Definitely the SDP is the key obstacle. I mean the WG seems to be quite
insincere to itself if it bets on pristine SDP. For sake of record, we have
been deploying SDP-rewriting proxies since 2003 and till today we would not
be able to run VoIP without it. It almost reminds me when someone during
an applauded NAT rant asked a WG who is using them and about 99% raised
hands (probably applauding in anticipation of turning on IPv6 next month).
Would be RFC4474 rolling out without this limitation -- I'm guessing
not, but
unlike the SDP fact, it is a guess of mine. We indeed obtained some
concerns
about the extra CA overhead (more about third party, SLA, etc rather than
technical concerns) but it was more what-if type of concern and we
did not pass the SDP-if. On the scale straight-forward/doable/better-not
I would upgrade it from better-not to doable but not to straight-forward.
-jiri
_______________________________________________
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
