The main reason we write the port in that case is because the idea of that nat hack is to make the contact <br>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<br>
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<br>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.<br>
<br><br>First of all I would like to complement us on our ability to keep up with you.<br>Just as a hint, you are starting to abuse our help by asking for an average of 3 incidents a day this week. <br>Do people you pay money even help you that much?<br>
<br>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<br>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. <br>
You may want to also use <a href="http://jira.freeswitch.org">http://jira.freeswitch.org</a> as a more formal way to track your problems.<br><br>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.<br>
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?<br> This includes used car salesman techniques like using statements like "I have this simple app and it doesn't work how I want. <br>
If this were a real soft-switch it would do this....."<br><br>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.<br> Meanwhile when something else inconvenient happens like NAT where breaking the RFC usually fixes it, then it's ok.<br>
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<br> at 100% RFC compliance unless you live on a commune full of SIP purists. So avoid quoting the RFC to prove your point.<br>
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.<br><br>3) Keep it in mind that FreeSWITCH is developed primarily by me and I only have so many hours in a day.<br>
I am more than happy to answer questions and help people but be sure to give others a turn too. <br> Try asking more questions on the users list or the irc channel to give others a chance to help too.<br><br>4) When you feel yourself crossing the line from testing the waters to going in production, consider getting a support contract or the visiting <br>
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.<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><div class="gmail_quote">
On Fri, Apr 11, 2008 at 2:22 AM, kokoska rokoska <<a href="mailto:kokoska.rokoska@post.cz">kokoska.rokoska@post.cz</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Just for completion of my previous e-mail:<br>
<br>
May be I miss something significant and all my thesis are completly<br>
wrong. If yes, I apologize and ask you for correction of my thoughts :-)<br>
Thank you.<br>
<div class="Ih2E3d"><br>
Best regards,<br>
<br>
kokoska.rokoska<br>
<br>
<br>
kokoska rokoska napsal(a):<br>
</div><div><div></div><div class="Wj3C7c">> Thank you very much, Michael, for your answer!<br>
><br>
> My comments are included in the e-mail body:<br>
><br>
> Michael Jerris napsal(a):<br>
>> The NDLB-connectile-dysfunction is a paramater to explicitly break the<br>
>> rfc<br>
><br>
> My be, but only internaly - i.e. all your public communication could be<br>
> RFC compliant if you want.<br>
><br>
>> and re-write our behavior as if we got a contact of the same<br>
>> address that we received the packet from.<br>
><br>
> Yes, in the same manner as all VoIP TSP (at least all bigger VoIP TSP in<br>
> Europe) do :-)<br>
><br>
>> If it comes from 5060, it<br>
>> will have 5060 in the contact.<br>
><br>
> And this brakes the RFC and UAC should refuse your 200 OK. There are a<br>
> lot of broken clients which accepts this but not all of them :-)<br>
><br>
>> If you would like to handle nat and<br>
>> still be rfc compliant, then you need to use a client that follows the<br>
>> rfc's<br>
><br>
> I'm sorry but I don't know what is RFC noncomplient if UAC behind NAT<br>
> sends private IP in contact. Could you point me to relevant part of some<br>
> RFC, please? It will be very helpful for me...<br>
><br>
><br>
>> so you don't have to use non compliant hacks.<br>
>><br>
><br>
> Like I wrote before, I can't remember any real (and not marginal) VoIP<br>
> telco provider in Europe which doesn't internaly rewrite contact URI in<br>
> case of UAC behind NAT. Even thou, a lot of them rewrite EVERY contact<br>
> URI and don't try to detect NAT, because a lot of SOHO routers have<br>
> SIP-ALG support (god dammed) which makes thing even complicated.<br>
><br>
> But there is - IMO - no reason why to rewrite contact URI in 200 OK<br>
> response to REGISTER request.<br>
><br>
> ----------------<br>
><br>
> All at all, from my point of view there is a big drawback if I couldn't<br>
> use FreeSWITCH for UACs behind NAT.<br>
> It forces me to use OpenSER as registrar (what I want to avid to because<br>
> of performance and harder setup to keep good interoperability) which has<br>
> no problem with clients behind NAT.<br>
><br>
> I believe that improvement in NAT handling could help FreeSWITCH users a<br>
> lot. Thus I will be glad to help you as much as I can do.<br>
> Please let me know if I can do something handy (other than rewrite FS by<br>
> myself :-).<br>
><br>
> Thanks once more, Michael, for your answer!<br>
><br>
> Best regards,<br>
><br>
> kokoska.rokoska<br>
><br>
><br>
> _______________________________________________<br>
> Freeswitch-dev mailing list<br>
> <a href="mailto:Freeswitch-dev@lists.freeswitch.org">Freeswitch-dev@lists.freeswitch.org</a><br>
> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
><br>
<br>
<br>
_______________________________________________<br>
Freeswitch-dev mailing list<br>
<a href="mailto:Freeswitch-dev@lists.freeswitch.org">Freeswitch-dev@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-dev" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-dev</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400