The main reason we write the port in that case is because the idea of that nat hack is to make the contact be the exact ip/port the register came from. Because of NAT it's some random port so putting the port in the contact is the only way we can get the packet back to the phone from our scope of the SIP stack. Any more advanced techniques need to be applied by a router such as openser or from the sofia stack itself. You can visit them in #sofia-sip on the same irc server as ours.
First of all I would like to complement us on our ability to keep up with you. Just as a hint, you are starting to abuse our help by asking for an average of 3 incidents a day this week. Do people you pay money even help you that much? Let me give you a few pointers on how to get along with us. You may or may not have done all of these things but I am listing them for your information. I am not telling you to stop bringing up issues but be careful about dominating our time. You may want to also use http://jira.freeswitch.org as a more formal way to track your problems. 1) Please do not take the extra time to provide any justification to why you think we *should* do something just to help your case. Feel free to ask but do not use what someone else does as an excuse. If everyone in Europe was jumping off a cliff, should we too? This includes used car salesman techniques like using statements like "I have this simple app and it doesn't work how I want. If this were a real soft-switch it would do this....." 2) Do not use RFC as a bible. When someone wants something they tend to stand up on a soapbox and wave it in the air. Meanwhile when something else inconvenient happens like NAT where breaking the RFC usually fixes it, then it's ok. We all know we should try to work as close to the RFC as possible. We also all know it's impossible to actually work right at 100% RFC compliance unless you live on a commune full of SIP purists. So avoid quoting the RFC to prove your point. Save it for rare occasions. The Sofia SIP stack does a lot of work to comply and they do a good job you should thank them. 3) Keep it in mind that FreeSWITCH is developed primarily by me and I only have so many hours in a day. I am more than happy to answer questions and help people but be sure to give others a turn too. Try asking more questions on the users list or the irc channel to give others a chance to help too. 4) When you feel yourself crossing the line from testing the waters to going in production, consider getting a support contract or the visiting the donation and/or wishlists so you can give back to the project and put smiles on underprivileged developer's faces for pennies a day. On Fri, Apr 11, 2008 at 2:22 AM, kokoska rokoska <[EMAIL PROTECTED]> wrote: > > Just for completion of my previous e-mail: > > May be I miss something significant and all my thesis are completly > wrong. If yes, I apologize and ask you for correction of my thoughts :-) > Thank you. > > Best regards, > > kokoska.rokoska > > > kokoska rokoska napsal(a): > > Thank you very much, Michael, for your answer! > > > > My comments are included in the e-mail body: > > > > Michael Jerris napsal(a): > >> The NDLB-connectile-dysfunction is a paramater to explicitly break the > >> rfc > > > > My be, but only internaly - i.e. all your public communication could be > > RFC compliant if you want. > > > >> and re-write our behavior as if we got a contact of the same > >> address that we received the packet from. > > > > Yes, in the same manner as all VoIP TSP (at least all bigger VoIP TSP in > > Europe) do :-) > > > >> If it comes from 5060, it > >> will have 5060 in the contact. > > > > And this brakes the RFC and UAC should refuse your 200 OK. There are a > > lot of broken clients which accepts this but not all of them :-) > > > >> If you would like to handle nat and > >> still be rfc compliant, then you need to use a client that follows the > >> rfc's > > > > I'm sorry but I don't know what is RFC noncomplient if UAC behind NAT > > sends private IP in contact. Could you point me to relevant part of some > > RFC, please? It will be very helpful for me... > > > > > >> so you don't have to use non compliant hacks. > >> > > > > Like I wrote before, I can't remember any real (and not marginal) VoIP > > telco provider in Europe which doesn't internaly rewrite contact URI in > > case of UAC behind NAT. Even thou, a lot of them rewrite EVERY contact > > URI and don't try to detect NAT, because a lot of SOHO routers have > > SIP-ALG support (god dammed) which makes thing even complicated. > > > > But there is - IMO - no reason why to rewrite contact URI in 200 OK > > response to REGISTER request. > > > > ---------------- > > > > All at all, from my point of view there is a big drawback if I couldn't > > use FreeSWITCH for UACs behind NAT. > > It forces me to use OpenSER as registrar (what I want to avid to because > > of performance and harder setup to keep good interoperability) which has > > no problem with clients behind NAT. > > > > I believe that improvement in NAT handling could help FreeSWITCH users a > > lot. Thus I will be glad to help you as much as I can do. > > Please let me know if I can do something handy (other than rewrite FS by > > myself :-). > > > > Thanks once more, Michael, for your answer! > > > > Best regards, > > > > kokoska.rokoska > > > > > > _______________________________________________ > > Freeswitch-dev mailing list > > [EMAIL PROTECTED] > > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > > http://www.freeswitch.org > > > > > _______________________________________________ > Freeswitch-dev mailing list > [EMAIL PROTECTED] > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev > UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev > http://www.freeswitch.org > -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:[EMAIL PROTECTED] <[EMAIL PROTECTED]> GTALK/JABBER/PAYPAL:[EMAIL PROTECTED]<[EMAIL PROTECTED]> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]> iax:[EMAIL PROTECTED]/888 googletalk:[EMAIL PROTECTED]<[EMAIL PROTECTED]> pstn:213-799-1400
_______________________________________________ Freeswitch-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
