On Dec 10, 2008, at 1:54 PM, Jiri Kuthan wrote:
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
Jiri, I would like to make sure I understand exactly what is broken
here. So, say some B2BUA that implements 4474, like SER is running at
iptel.org. And I have an account, say [EMAIL PROTECTED] Now my phone
is registered and sends an INVITE to SER with the From set to "[EMAIL PROTECTED]
". My understanding is SER edits the SDP then does the 4474 signature
and sends it on.
So in the case you are discussing here, what exactly is broken that
stops iptel.org from both editing SDP and doing 4474?
Cullen <with my individual contributor role>
_______________________________________________
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
