Yesterday I had an interesting discussion with Bogdan-Andrei Iancu (OpenSIPS core developer) on #opensips IRC Channel (Freenode). Topic where clients frequently changing port in their REGISTER Contact headers as of STUN errors, caused either by braindead UACs, routers or admins.
After reflecting a while I had an keen idea on how to cleanly solve the issue. However, as also Bogdan has not been really sure whether it could work while maintaining RFC conformance, I decided to ask for feedback on SIP-Implementors mailinglist.
Here is what I wrote:
Hi All,
after discussing the following issue with an OpenSIPS core developer I
came to an interesting conclusion I'd like to share and to ask feedback
for. As being pretty nitpicky I tried to track down one of the few re-
maining problems I still have with some clients sitting behind strange
NAT devices.
Nothing new, you may say - and so do I. I'm able to handle most kinds of
SIP/NAT-strangeness quite well with a mixture of STUN, Far-End NAT Tra-
versal, RTP Proxies, more or less aggressive keepalives - things you all
know, probably better than I do.
The problem we were talking about are clients filling the registrars
location database with multiple (usually in the range of 3-30) different
records. Same UAC, same Call-ID, same username, same (official) IP but
changing port in their Contact, usually followed by (equal) "line=" or
"uniq=" param.
Something like this could either be caused by buggy UACs, by friendly
ALGs or (just a guess) symmetric routers where some "specialists" added
manual NAT rules for some ports they have seen hitting the firewall
(STUN). It could also happen with gateways changing NAT bindings very
fast - but I examined cases where the port number in the Contact header
changed often, the packets however kept being sent from the same socket
at the NAT gateways WAN side.
Manual NAT "fixes" by adding some static port mapping would definiti-
vely confuse correctly behaving clients. For the sake of completeness:
UACs I see showing this problem are from different vendors: AVM, Snom,
Elmeg, just to name the first ones I stumbled over. Therefore I doubt
they were guilty in this case.
Regardless of who is to blame for this issues (I stronlgy guess most
of them could be layer 8 problems), as a SIP provider my primary goal
is to somehow solve them automagically.
OpenSIPS developer said he has to compare Contact and Call-ID, in order
to remain conform with RFCs - he cannot use some "heuristic" based on
non-standard Contact params as "uniq" or "line" are. And he is right.
After reflecting a little bit I came to the following conclusion:
RFC3261 clearly specifies all details about URI-matching, Call-IDs in
REGISTER requests and so on. In case of NAT issues current best practice
is to store the Contact provided by the client, but to send requests and
replies to a different ip:port pair, also stored together with this each
location record. Mechanisms as described for the rport extension (or
some other Voodoo) are used in this case to discover the correct socket
for each UAC.
This implies that we already consider the ip:port information in the
contact being wrong. And if those information are wrong, why should we
trust them for Contact matching when storing new or updating old loca-
tion records for REGISTER requests? IMO it would be far better to match
against
<sip:(local)@(host):(port)[;pa=rams]>
having
(local) = localpart from Contact as provided by the client
(host) = ip as learned by rport / received / other mechanism
(port) = port as learned by rport / received / other mechanism
[;pa=rams] = optional params, as they have been provided in the
Contact header
Wouldn't it? Of course only in cases where the registrar overruled the
clients Contact information based on other mechanisms - otherwise the
Contact shall be used "as-is". Doing so a registrar would still act
perfectly RFC-conform - and automagically solve a few more NAT issues.
Are those assumptions correct? Looking forward to your feedback, I'd
like to thank you in advance for your efforts.
Best regards,
Thomas Gelf
--
mail: thomas@gelf.net
web: http://thomas.gelf.net/
I'm pretty curious about the results. If you have an opinion on this argument I'd be happy to hear it, either here or on the related thread on SIP-Implementors or Opensips-devel!
Yesterday I had an interesting discussion with Bogdan-Andrei Iancu (OpenSIPS core developer) on #opensips IRC Channel (Freenode). Topic where clients frequently changing port in their REGISTER Contact headers as of STUN errors, caused either by braindead UACs, routers or admins.
