Re: [Freeswitch-users] [Freeswitch-dev] bad REGISTER processing
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 <kokoska.rokoska@post.cz> 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 Freeswitch-dev@lists.freeswitch.org 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 Freeswitch-dev@lists.freeswitch.org 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:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Anthony Minessale napsal(a):
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.
Thank you very much, Anthony, for your explanation! I'm not sure I understand well, but I try to read it once more or look into sources to get a clue :-)
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.
OK, thank you for pointing me to right direction, I will ask someone from Sofia.
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.
First of all, let me apologize if my comments looks like I try to abuse your willingness. It is not what I want. For my defence I like to say that majority of my messages are bug-reports...
Do people you pay money even help you that much?
As my voluntary work I'm active in some local VoIP forum and try to help others with things I have enough knowledge about. May be I don't need much brain power to answer the questions because most of them are very simple, but there is a huge amount of them per day. And thus I never think about how much someone can ask me and how much I could ask others. It is my mistake, let me apologize.
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.
To every Open Source project I have involved in I try to help as much as I can. And the best thing I can do (due to my home lab setup :-) is finding bugs. And I think I'm good at it :-) It sounds very strange to me your are so displeased with it, but I respect your wishes, of course.
You may want to also use http://jira.freeswitch.org as a more formal way to track your problems.
OK, if I see it is not avoidable, I insert it in the jira.
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.
If I ever used "should" I never meant to force you to help me. It was just advice about what could help FreeSWITCH to be better - from my point of view. Nothing more. If it bother you, I never repeat it.
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.
I'm sorry, in confers I contribute to there is a frequent practice to support the thoughts by exact RFC content and I just bring this practice with me to FreeSWITCH conference, because I'm very accustomed with it. You tell me it is not wonted - ok, I stop it.
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.
I'm very thankful to them, but I hope it doesn't mean I couldn't think about improvements. Like on any other projects.
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.
I'm sorry. I'm accustomed to send bug reports to dev-lists and I just continue in this practice with FreeSWITCH. If it is not desired, I stop it and use jira exlusively.
Try asking more questions on the users list or the irc channel to give others a chance to help too.
I hope I have asked questions in user-list. If not, let me apologize, it was an oversight...
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.
Majority of projects I'm using VoIP SW in are non-profit and costs me not only a lot of time but real money too. But - wheter I ever will use FreeSWITCH in production or not, I do what I can to support it because I see big potential in it. Besides like I do for any other SW project I feel truly amazing... Best regards, kokoska.rokoska
The point of that NDLB-nat-connectile-dysfunction param is to perform a hack on the RFC and ignore the contact given in the packet and replace it in our database with our own contact we formulate by using the IP and PORT the packet was received from. Thus the PORT has to be included because sending invites to that exact IP and PORT is the only way we know will make it back over the NAT translation path. If you register to me on a public server and you say your contact is foo@10.0.0.1. but I see the NAT hack enabled on your account. I notice the packet was received from a valid internet IP:PORT since I cannot reach 10.0.0.1 I replace the host from your real contact with the IP you registered from. and I append the PORT the register came from and save that as a contact. Then if i send an invite to that url it will go backwards over your NAT path assuming you are doing keepalives on SIP. Now, "To every Open Source project I have involved in I try to help as much as I can. And the best thing I can do (due to my home lab setup :-) is finding bugs. And I think I'm good at it :-) It sounds very strange to me your are so displeased with it, but I respect your wishes, of course." and "I'm sorry, in confers I contribute to there is a frequent practice to support the thoughts by exact RFC content and I just bring this practice with me to FreeSWITCH conference, because I'm very accustomed with it. You tell me it is not wonted - ok, I stop it." This is the condescending passive-aggressive "kill em with kindness" thing that I was trying to explain is annoying. So if you are serious about not trying to make me mad, tone that down a little more please. I have answered every one of your questions, fixed every one of your issues ahead of stuff I am already working on and I am simply trying to tell you what our policy is and you essentially dismissed each of them with some sort of "I'm sorry but not really" type response. I clearly said shoving the RFC in someones face as an excuse why they should fix your problem is what annoys us and I said we do comply to the RFC as much as we can apart from the proven cases where conforming to it makes us unable to interop. You still chose to "apologize" and promise never to refer to the RFC again. That is passive-agressive and unwanted behavior. The conclusion that something is a bug, unless it's a seg fault, is subjective and the issue must be deliberated on before a fix is applied and it helps to have that process documented. So, yes please find bugs, and yes use jira to report issues and use the mailing list to ask questions or discuss an ongoing development process. Please simply acknowledge that you understand my point and do not riddle my email with comments and I will be happy. We look forward to your success with FreeSWITCH and welcome to the community. On Fri, Apr 11, 2008 at 10:23 AM, kokoska rokoska <kokoska.rokoska@post.cz> wrote:
Anthony Minessale napsal(a):
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.
Thank you very much, Anthony, for your explanation! I'm not sure I understand well, but I try to read it once more or look into sources to get a clue :-)
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.
OK, thank you for pointing me to right direction, I will ask someone from Sofia.
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.
First of all, let me apologize if my comments looks like I try to abuse your willingness. It is not what I want.
For my defence I like to say that majority of my messages are bug-reports...
Do people you pay money even help you that much?
As my voluntary work I'm active in some local VoIP forum and try to help others with things I have enough knowledge about. May be I don't need much brain power to answer the questions because most of them are very simple, but there is a huge amount of them per day. And thus I never think about how much someone can ask me and how much I could ask others. It is my mistake, let me apologize.
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.
To every Open Source project I have involved in I try to help as much as I can. And the best thing I can do (due to my home lab setup :-) is finding bugs. And I think I'm good at it :-) It sounds very strange to me your are so displeased with it, but I respect your wishes, of course.
You may want to also use http://jira.freeswitch.org as a more formal way to track your problems.
OK, if I see it is not avoidable, I insert it in the jira.
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.
If I ever used "should" I never meant to force you to help me. It was just advice about what could help FreeSWITCH to be better - from my point of view. Nothing more. If it bother you, I never repeat it.
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.
I'm sorry, in confers I contribute to there is a frequent practice to support the thoughts by exact RFC content and I just bring this practice with me to FreeSWITCH conference, because I'm very accustomed with it. You tell me it is not wonted - ok, I stop it.
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.
I'm very thankful to them, but I hope it doesn't mean I couldn't think about improvements. Like on any other projects.
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.
I'm sorry. I'm accustomed to send bug reports to dev-lists and I just continue in this practice with FreeSWITCH. If it is not desired, I stop it and use jira exlusively.
Try asking more questions on the users list or the irc channel to give others a chance to help too.
I hope I have asked questions in user-list. If not, let me apologize, it was an oversight...
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.
Majority of projects I'm using VoIP SW in are non-profit and costs me not only a lot of time but real money too. But - wheter I ever will use FreeSWITCH in production or not, I do what I can to support it because I see big potential in it. Besides like I do for any other SW project I feel truly amazing...
Best regards,
kokoska.rokoska
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Anthony Minessale napsal(a):
The point of that NDLB-nat-connectile-dysfunction param is to perform a hack on the RFC and ignore the contact given in the packet and replace it in our database with our own contact we formulate by using the IP and PORT the packet was received from. Thus the PORT has to be included because sending invites to that exact IP and PORT is the only way we know will make it back over the NAT translation path.
If you register to me on a public server and you say your contact is foo@10.0.0.1 <mailto:foo@10.0.0.1>. but I see the NAT hack enabled on your account. I notice the packet was received from a valid internet IP:PORT since I cannot reach 10.0.0.1 <http://10.0.0.1> I replace the host from your real contact with the IP you registered from. and I append the PORT the register came from and save that as a contact. Then if i send an invite to that url it will go backwards over your NAT path assuming you are doing keepalives on SIP.
Thank you, Anthony, for your answer! It is clear to me and I think, there is no dispute between us. But I just still don't catch why modifeid contact should be in 200 OK response to REGISTER request. I thought the 200 OK response could contain the same contact you received and you just store modified one for later INVITE/NOTIFY/etc processing. I had looked into sources and than slightly modified sofia_reg.c (5 lines of code :-) and everything works as I want. If someone interested, I send the modified version, but: 1. I accidentaly delete original sofia_reg.c so I can't make a diff. 2. It is simple stupid workaround and I realy don't know what other things I break with it... <off-topic> About our other debate: We both have unmatched view about what I meant in my e-mails. I feel bad about it, but I can do nothing with it. So, if you can, forget the debate please, and make peace together :-) </off-topic> Best regards, kokoska.rokoska
On Apr 12, 2008, at 4:38 AM, kokoska rokoska wrote:
I had looked into sources and than slightly modified sofia_reg.c (5 lines of code :-) and everything works as I want. If someone interested, I send the modified version, but: 1. I accidentaly delete original sofia_reg.c so I can't make a diff.
svn diff sofia_reg.c
2. It is simple stupid workaround and I realy don't know what other things I break with it...
Post it to jira.freeswitch.org if you can. Thanks, Brian West sip:brian@freeswitch.org
Brian West napsal(a):
On Apr 12, 2008, at 4:38 AM, kokoska rokoska wrote:
I had looked into sources and than slightly modified sofia_reg.c (5 lines of code :-) and everything works as I want. If someone interested, I send the modified version, but: 1. I accidentaly delete original sofia_reg.c so I can't make a diff.
svn diff sofia_reg.c
Thank you very much, Brian, for your hit!
2. It is simple stupid workaround and I realy don't know what other things I break with it...
Post it to jira.freeswitch.org if you can.
I will do it in a while. Best regards, kokoska.rokoska
Your issue only appears when you enable the NAT mode? correct? What I mean, is by definition, that NAT mode purposely changes the contact. The name of the param is force-contact. If you show me a diff from your patch that works how you want, I will convert it into an optional param for you and add it to the tree. On Sat, Apr 12, 2008 at 5:15 AM, kokoska rokoska <kokoska.rokoska@post.cz> wrote:
Brian West napsal(a):
On Apr 12, 2008, at 4:38 AM, kokoska rokoska wrote:
I had looked into sources and than slightly modified sofia_reg.c (5 lines of code :-) and everything works as I want. If someone interested, I send the modified version, but: 1. I accidentaly delete original sofia_reg.c so I can't make a diff.
svn diff sofia_reg.c
Thank you very much, Brian, for your hit!
2. It is simple stupid workaround and I realy don't know what other things I break with it...
Post it to jira.freeswitch.org if you can.
I will do it in a while.
Best regards,
kokoska.rokoska
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Anthony Minessale napsal(a):
Your issue only appears when you enable the NAT mode? correct?
Yes :-)
What I mean, is by definition, that NAT mode purposely changes the contact. The name of the param is force-contact. If you show me a diff from your patch that works how you want, I will convert it into an optional param for you and add it to the tree.
Based on Brian advice a inserted it into jira (with other second one patch), but I could send both anywhere you want. Best regards, kokoska.rokoska
Yes jira is the right place for all issues. Bugs, Suggestions for changes, Behavior issues and patches. I'll have a look on Monday. On Sat, Apr 12, 2008 at 11:49 AM, kokoska rokoska <kokoska.rokoska@post.cz> wrote:
Anthony Minessale napsal(a):
Your issue only appears when you enable the NAT mode? correct?
Yes :-)
What I mean, is by definition, that NAT mode purposely changes the contact. The name of the param is force-contact. If you show me a diff from your patch that works how you want, I will convert it into an optional param for you and add it to the tree.
Based on Brian advice a inserted it into jira (with other second one patch), but I could send both anywhere you want.
Best regards,
kokoska.rokoska
_______________________________________________ Freeswitch-users mailing list Freeswitch-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Anthony Minessale napsal(a):
Yes jira is the right place for all issues. Bugs, Suggestions for changes, Behavior issues and patches. I'll have a look on Monday.
Thank you very much, Anthony! BTW: Now I figure out I forgot to look how Sofia sends out the replies and thus my piece of code may be piece of shit instead :-) I will look at it in the evening (CET timezone)... Best regards, kokoska.rokoska
participants (3)
-
Anthony Minessale
-
Brian West
-
kokoska rokoska