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

[Daniel-Constantin Mierla]

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.

Cheers,
Daniel


> -jiri
>
>   
>> Aymeric
>>
>>     
>>> -jiri
>>>
>>> Aymeric Moizard wrote:
>>>       
>>>> On Sun, 4 Jan 2009, Juha Heinanen wrote:
>>>>
>>>>         
>>>>> Aymeric Moizard writes:
>>>>>
>>>>>           
>>>>>> If you have a 100% working trick, I'll be interested to learn it! Very
>>>>>> interested!
>>>>>>             
>>>>> no, i don't have 100% working trick, but normal means cover 90+% of the
>>>>> cases.  trying to avoid needless use of rtp proxy for the remainder is
>>>>> not worth of the extreme complexity that comes with ice.
>>>>>           
>>>> So the 10% calls are the one that use relay when they should not? right?
>>>> I'm pretty convinced this is not a true value. Anyway, I don't think
>>>> this is a problem of number here.
>>>>
>>>> Let's describe a case:
>>>>
>>>> I send an INVITE and encrypt the SDP. I'm behind a symmetric NAT. I'm
>>>> calling somebody (a UA of course) who is able to decrypt it.
>>>>
>>>> Whatever trick you provide, I will not have always voice (except
>>>> if ICE is supported or if the NAT are kind with me)
>>>>
>>>> Conclusion: I'm forced to provide UA and ask my customer to NOT encrypt
>>>> their signalling. NEVER encrypt their signalling.
>>>>
>>>>         
>>>>> i don't understand what you try to say in above.  sip works fine over
>>>>> the internet today.
>>>>>           
>>>> SIP works today **if**:
>>>>   * no security
>>>>   * no SIP message integrity is used
>>>>   * sip server are well configured (...)
>>>>   * sip server is not compliant (modifying contact and SDP...)
>>>>
>>>> My conclusion is that it's not acceptable. I want my applications
>>>> to do security and I don't want to be dependant on badly configured
>>>> servers.
>>>>
>>>> I don't want "SIP works today **if**", I want "SIP works today."
>>>>
>>>> I just need a SIP compliant internet infrastructure.
>>>>
>>>> tks,
>>>> Aymeric MOIZARD / ANTISIP
>>>> amsip - http://www.antisip.com
>>>> osip2 - http://www.osip.org
>>>> eXosip2 - http://savannah.nongnu.org/projects/exosip/
>>>>
>>>>
>>>>         
>>>>> -- juha
>>>>>
>>>>>           
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.kamailio.org
>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>         
>
> _______________________________________________
> Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>
>   

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