[Kamailio-Users] stun/outbound draft...

[Daniel-Constantin Mierla]

On 01/09/2009 12:26 PM, Victor Pascual Ávila wrote:
> On Fri, Jan 9, 2009 at 11:10 AM, Daniel-Constantin Mierla
> <miconda at gmail.com> wrote:
>   
>> Hello,
>>
>> On 01/08/2009 09:32 PM, Jiri Kuthan wrote:
>>     
>>> Aymeric Moizard wrote:
>>>
>>>       
>>>> On Wed, 7 Jan 2009, Jiri Kuthan wrote:
>>>>
>>>>
>>>>         
>>>>> I respectfully disagree -- the field has clearly shown that working
>>>>> NAT traversal today is more valuable than message integrity and ICE
>>>>> architecture both together. (Whcih happens to be my personal
>>>>> preference too: getting over NATs today is more important to me than
>>>>> any sort of securing free phone calls.) Generally I tend to prefer
>>>>> priorities as articulated by live deployments.
>>>>>
>>>>>           
>>>> I think we both agree on where we want to go.
>>>>
>>>> The difference is probably that current way SIP is used might be enough
>>>> for you, but as a 10 years SIP endpoint stack builder, I'm just bored
>>>> about using SIP over non transparent network. Not your fault...
>>>>
>>>>
>>>>         
>>>>> I'm sorry to be so differently opinionated on this, particularly
>>>>> because I like ICE esthetically as the "e2e" solution. However,
>>>>> somehow in the Internet the things that are deployable today always
>>>>> matter. (even if considered evil, such as NATs)
>>>>>
>>>>>           
>>>> Don't be sorry.
>>>> My intention for this thread was just to ask ser/kamailio/whatever to
>>>> make sure the future will not be the same as the 10 past years. My
>>>> intention was not to say "you are all wrong".
>>>>
>>>>         
>>> No problem at all -- it is indeed an uneasy question.
>>>
>>> The end-to-end-ness of ice seems appealing like say TCP does. TCP is robust
>>> in that whatever happens in the network, smart software (quite complex
>>> in fact)
>>> in the end-devices can deal with it. So I keep asking myself why ICE is
>>> getting so little traction if the same thing works for TCP. One of the
>>> reasons
>>> could be that it is  a sort of backwards-compatibility problem, since in
>>> a way
>>> it is a layer 3/4 technology and changing IP/transport layer is just
>>> painful. One
>>> could also argue that it can't be fully e2e since it relies on network
>>> via TURN,
>>> even though as the last resort.
>>>
>>> It is not a clear bet to me -- in fact I fell a bit ashamed I may be
>>> giving up
>>> on ICE too early. Still I do. Does anyone have a memory of a technology that
>>> was "clean", came late and surpassed "internet workarounds"?
>>>
>>>       
>> The question could be the other way around: does anyone remember another
>> technology that needed so many patches and workarounds :-)? Just
>> thinking about the number of RFCs and drafts coming to
>> complete/recommend/give usage guidelines ...
>>
>> ICE came too late, the are millions of end user devices sold out there,
>> without it. And as "workarounds" are in place, nobody will invest now
>> (crisis :-) ?!?!) to replace them -- only the time will obsolete them.
>> So we still have to stick to the solutions we have now.
>>     
>
> I agree with what Daniel says. However, if we keep stuck to the
> solutions we have now we'll never obsolete them.
>   
Completely true. It is scary that some technologies even obsolete look 
like never to be removed ... :-)

And from experience, for SIP, it has to get a new version number or a 
new name. It will be more attractive to be SIP3.0 compliant than SIP2.0 
+ RFCxyzw.

SIP 2.0 is so vagues right now with lot of extensions/amendments and 
what is still must/should/may.

Daniel

-- 
Daniel-Constantin Mierla
http://www.asipto.com