On Fri, Jan 9, 2009 at 11:10 AM, Daniel-Constantin Mierla <[email protected]> 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 >>>>> [email protected] >>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>>>> >>>>> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >> >> > > -- > Daniel-Constantin Mierla > http://www.asipto.com > > > _______________________________________________ > Kamailio (OpenSER) - Users mailing list > [email protected] > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > -- Victor Pascual Ávila _______________________________________________ Kamailio (OpenSER) - Users mailing list [email protected] http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
