Re: scope of derive

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