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

Victor Pascual Ávila victor.pascual.avila at gmail.com
Fri Jan 9 11:26:39 CET 2009


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.

Cheers,
-Victor

>
> 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
>
>
> _______________________________________________
> Kamailio (OpenSER) - Users mailing list
> Users at lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
>



-- 
Victor Pascual Ávila


More information about the Users mailing list