[Freeswitch-dev] bad REGISTER processing
anthony.minessale at gmail.com
Fri Apr 11 09:21:34 EDT 2008
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
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 at post.cz>
> 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 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 at 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 at lists.freeswitch.org
Anthony Minessale II
MSN:anthony_minessale at hotmail.com <MSN%3Aanthony_minessale at hotmail.com>
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com<PAYPAL%3Aanthony.minessale at gmail.com>
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org <sip%3A888 at conference.freeswitch.org>
iax:guest at conference.freeswitch.org/888
googletalk:conf+888 at conference.freeswitch.org<googletalk%3Aconf%2B888 at conference.freeswitch.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Freeswitch-dev