[OpenSIPS-Users] Via header interpretation with rport parameter being set

[Iñaki Baz Castillo]

2009/9/14 Thomas Gelf <thomas at gelf.net>:
> Hi All,
>
> I stumbled over an intersting issue I'd like to share and to ask
> feedback for. Grandstream phones offer an option called "use symmetric
> RFC 3581 routing". If that option is enabled and STUN detection was
> successful, it's REGISTER packets show a perfectly correct Contact
> header and a Via header using it's private IP address and port.
>
> IMO RFC 3581 is not clear about whether in such situations a client
> shall nonetheless replace it's Via ip:port pair with what he has
> learned by doing STUN. Please correct me if this assumption is wrong,
> I'll open a ticket at Grandstream and forget about this.

It doesn't matter if a client sets Via with the private or public
(STUN) address. When a proxy or server receives a request it must
inspect the Via header sent-field value (the IP and port).
If the IP doesn't match the real source IP, then the proxy/server adds
";received=REAL_SOURCE_IP so responses would be sent to REAL_SOURCE_IP
and original port in Via sent-field value. This doesn't solve NAT
since the port used is still the original (private) port. So "rport"
makes sense here:
If the client adds an empty ;rport parameter, it means that it uses
symmetric SIP so the server adds to the Via header:
- ;received=REAL_SOURCE_IP
- ;rport=REAL_SOURCE_PORT
and the proxy/server sends replies to REAL_SOURCE_IP:REAL_SOURCE_PORT
(so "fixes" NAT).

In conclusion: a client doing STUN is not required to change its Via
sent-by header as adding ";rport" gets the same effect.

Of course, all the above is just for UDP. In TCP it makes no sense as
the first attempt is to send the replies using the existing TCP
connection.



> Said so, I'd like to raise a few questions:
>
> * is there something like a has_rport() function in OpenSIPS?

I don't know why you need it.


> * would a new test checking whether Contact differs from the socket
>  where the UAC's packet came from make sense?

Be carefull since it wouldn't work for TCP clients (the listening port
could be 5060 while each request uses a random source port different
than 5060).



> * More and more clients are adding the rport parameter, and while most
>  of them are setting Via as learned by STUN, this must not be always
>  true. At least I didn't find anything in RFC 3581 stating so. Even if
>  I definitively would never ever suggest using Grandstream as a refe-
>  rence implementation, the fact that they are doing as told above
>  means that different interpretations could definitively be possible
>  here. As told before, I could be wrong here!

As I explained above, it doesn't matter (or it shouldn't). The server
should inspect the "Contact" header rather than Via to detect NAT.


> * Contact is as correct as possible in most cases, however just checking
>  for private IPs doesn't suffice (for the very same reason there are
 >  multiple checks for Via headers), but one should also NOT consider the
>  client being behind NAT just because Contact and client socket differ.

If a client uses symmetric SIP (as most of them do), and uses UDP,
then NAT is detected by comparing the real source IP:port with the
value of the Contact header.
In case of TCP, just the real source IP should be compared against the
Contact IP.




-- 
Iñaki Baz Castillo
<ibc at aliax.net>