On Fri, 2 Jan 2009, Iñaki Baz Castillo wrote: Let me a question. What is the purpose/advantage of having a STUN server running in the SIP proxy/registrar port? AFAIK this is just valid for a single purpose: allowing STUN *just for SIP signalling* when the device is located behind symmetric NAT (in which "normal" STUN doesn't work since the public mapping the router assigns depends also on the destination ip:port, and not just on the private source ip:port). This is: having a STUN server running in port 5060 in the same host where our SIP proxy/registrar runs is just valid for a UA behind symmetric NAT because it can set the "Contact" header with the mapped public ip:port, so it will be able to receive in-dialog requests (without NAT solution at SIP level in the proxy), but it will never be valid for RTP, since the destination of the RTP will never be PROXY_IP:5060, so the mapping our symmetric NAT router will do for the RTP is completely unknown. So, what is the advantage of a STUN server in port 5060? Thanks. This specification draft-ietf-sip-outbound-16 ios only about SIP: http://tools.ietf.org/html/draft-ietf-sip-outbound-16 So for 100% of UA, STUN is usable for keeping alive and detecting IP changes on the SIP connection. Don't you want kamailio to be standard? For RTP? Even if you put a STUN server on another port, that would not be of any help at all... because only part of the 100% can use the STUN discovered address in their RTP and such solution would not work 100%. Instead for RTP, ICE and TURN are required. That's just a different server that has to be installed: NOT THE SAME as the one running on the SIP server which is ONLY doing STUN binding request. tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/ -- Iñaki Baz Castillo <ibc(a)aliax.net> _______________________________________________ Users mailing list Users(a)lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

On Sat, 3 Jan 2009, Iñaki Baz Castillo wrote: You're welcome. It though you were aware of the draft! This draft looks important to me as a first step, because it's important, for compliance that the contact header is not changed in INVITEs by proxies... This is a first step towards message integrity... (Second step is about ICE discussion below!) Yes. Quoting the new rfc5389 that deprecated old STUN rfc3489: "STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution." So, what I meant is that STUN is not a global solution for RTP: as you know, if you open a hole in your NAT using STUN, you cannot be sure you can receive RTP through this hole. Also, the above new rfc, clearly states that it's impossible to predict a NAT behavior even if you have made some test and determined that it was a symmetric NAT for example. However, the STUN *usage* (wording of ietf rfc5389) described in "draft-ietf-sip-outbound-16" is a global solution for SIP connection to "outbound" proxy. You are right, but I do not think the draft is guilty there: the specification is very interoperable and there is no reason which should prevent application developper to implement it correctly. I'm using an ICE version of draft-13 in my products and I'm not interoperable with anyone (never tested any in fact...) but the solution does work properly in closed environment. No doubt to me. ICE is a scalable solutions: * SRV records do the balancing over several TURN server. * TURN is used ONLY when 2 peers cannot connect together, this means that it's much better than always offering RTP relay which is the solution today. * ICE allow to certify that you are sending the RTP data to your correspondant (ther is an ICE password in SDP) * ICE will allow 100% of direct connection and will never use TURN in a BEHAVE compliant environment: rfc4787. (no symmetric NAT any more...) In the future, ICE is supposed to never use TURN at all because all direct connection will be possible. 0% relay is PLANNED by ietf and ICE ;) Isn't it great news for the future? and peer to peer UDP exchange using a SIP network? I thank you all for yours and wish the best for the next "sip router project"... I also want to inform people that are not aware that a nice turnserver is available there: http://turnserver.sourceforge.net/ That will surely help people to become compliant to ICE! I'm currently working with it for testing purpose and I will try to connect it to my kamailio sql database... tks, Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/ -- Iñaki Baz Castillo <ibc(a)aliax.net> _______________________________________________ Users mailing list Users(a)lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users

On Sun, 4 Jan 2009, Juha Heinanen wrote: My opinion is that no decision can be taken on kamailio. Or any proxy... It's technically not possible. Only the client and ICE could decide wether to use relay or not. All the tools/way/tricks tha I'm aware of, TRY to guess by looking at IPs for example, or comparing source port and contact or via port: all those tricks are just bad guess for many reasons. If you have a 100% working trick, I'll be interested to learn it! Very interested! ICE helps to find direct connection between peers securely: still it doesn't prevent from receiving spoofed data on the discovered connection. zrtp is there to fill the gap: not a conflict at all. Well, I'm not saying it's not complicated... I fully agree there. But still this is the best (& only?) way to optimize the SIP udp media path. Until ICE come, there will never be any success for the internet part of SIP: the only reliable (optimized) calls today are the SIP to PSTN calls and that is very very sad and unusefull. Of course, non optimized free SIP (telephony..) services can be provided, but this comes at a high cost: you have to provide the relay services, modify contact headers, modify SDP contents, break SIP message integrity, provide low quality voice & video (relay...). Last point but not the least, is there any existing way to make sure you can provide inter-domain SIP calls? (2 RTP relays are inserted in the path or a proxy fix a contact header to the IP/port source of the previous proxy...) I want ICE to be implemented, no matter the effort. Else, I think there is no value in SIP or VoIP except for commercial usage. Please help the world and vote for ICE whatever the effort. If not, join the IMS effort to make millions of $ for the next decades. That's a choice! (no flame to anyone here, don't misunderstood me... I just feel sad) MAIL was a success & free probably because correct deployment is easy. With ICE, SIP could become the same. I'm done! Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/

On Sun, 4 Jan 2009, Juha Heinanen wrote: 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. 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/

Iñaki Baz Castillo writes: forcing sip through proxies means that headers cannot be encrypted. i fail to see a big difference. the above is not true. -- juha

On Sun, 4 Jan 2009, Iñaki Baz Castillo wrote: My 2 cents to the discussion: The obvious advantage are that if you have an encrypted copy of SDP and To/From header AND a readable copy of To/From header in the same message: * the target endpoint is the only one to decrypt the SDP * the target endpoint can be sure no proxy have modified the To/From identity of the caller. I agree S/MIME is not well accepted -same for mail- but this feature will be possible with other technology. I do! ;) Good to hear that... It will! Elegant & clean and when deployed on behave-compliant IP network, you don't even need TURN... and ICE becomes fairly simple. The problem with this is that the decision about endpoints are not 100% true: * what about redirection? * what about case where you have several proxy? * What if the endpoint is detected as a non-symmetric NAT (most probably, you detect this on SIP signalling port.) but becomes symmetric on the RTP port? ICE don't need to know where you are on the internet: it just work. It's also capable of doing TCP/TLS connection to the TURN server to tunnel UDP data for NAT configured to block UDP... Aymeric

On Sun, 4 Jan 2009, Iñaki Baz Castillo wrote: Not all relay work if several media proxy are used because some RTP relay wait for RTP data before relaying and RTP is received on the other relay.... so hard... UA can have correct contact even if not using outbound: send OPTIONS check received= and rport= parameter in answer. send REGISTER with correct contact binding! easy.... Aymeric MOIZARD / ANTISIP amsip - http://www.antisip.com osip2 - http://www.osip.org eXosip2 - http://savannah.nongnu.org/projects/exosip/

Happy new year everybody! I'm trying to do some testing of the carrierroute module, but after doing adding some gateways on the carrierroute table and doing some testings I got the following error: ERROR:carrierroute:cr_do_route: desired routing domain doesn't exist, prefix 12345, carrier 1, domain 2 Can any of you give me some advice about how to tackle this error? Thanks in advance, Juan.- My carrierroute table looks like this: mysql> select * from carrierroute; +----+---------+--------+-------------+-------+------+------+-------+-----------------+----------------+----------------+-------------+ | id | carrier | domain | scan_prefix | flags | mask | prob | strip | rewrite_host | rewrite_prefix | rewrite_suffix | description | +----+---------+--------+-------------+-------+------+------+-------+-----------------+----------------+----------------+-------------+ | 1 | 1 | 1 | | 0 | 0 | 1 | 0 | 192.168.50.114 | | | NULL | | 2 | 2 | 1 | | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | | 3 | 3 | 1 | | 0 | 0 | 1 | 0 | 192.168.50.114 | | | NULL | | 4 | 1 | 2 | | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | | 5 | 2 | 2 | | 0 | 0 | 1 | 0 | 192.168.50.114 | | | NULL | | 6 | 3 | 2 | | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | | 7 | 1 | 2 | 0 | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | | 8 | 2 | 2 | 1 | 0 | 0 | 1 | 0 | 192.168.50.114 | | | NULL | | 9 | 3 | 2 | 2 | 0 | 0 | 1 | 0 | 192.168.50.115 | | | NULL | +----+---------+--------+-------------+-------+------+------+-------+-----------------+----------------+----------------+-------------+ 9 rows in set (0.00 sec)

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'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) -jiri Aymeric Moizard wrote:

Aymeric Moizard wrote: 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"? -jiri

On Fri, Jan 9, 2009 at 11:10 AM, Daniel-Constantin Mierla <miconda(a)gmail.com> wrote: I agree with what Daniel says. However, if we keep stuck to the solutions we have now we'll never obsolete them. Cheers, -Victor -- Victor Pascual Ávila

On 01/09/2009 12:26 PM, Victor Pascual Ávila wrote: 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

On Fri, Jan 9, 2009 at 12:06 PM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote: Too acid to my taste -- Victor Pascual Ávila

2009/1/9 Iñaki Baz Castillo <ibc(a)aliax.net>et>: Also, don't worry at all. No member of IETF will read my joke since this is a maillist about a *real* implementation, so no interesting XD PD: Maybe too acid now? How could I delete this mail? -- Iñaki Baz Castillo <ibc(a)aliax.net>

On 01/09/2009 01:06 PM, Iñaki Baz Castillo wrote: well, on the other hand is not bad. You would have been probably unemployed (or in other business) now if the SIP would have been simple. I am thinking of SIP as developer's heaven -- never run out of new tasks. It is an amazing business/money flow environment: - voip/++ services - developing - teaching - conformance testing - rfc writing - and you can still add... Daniel -- Daniel-Constantin Mierla http://www.asipto.com

Aymeric Moizard schrieb: Another working trick is to use the media relay in 100% of the calls. Yes, it is not optimal but it works - and support hours do costs more money than bandwidth. regards klaus