[Serusers] nat and rtpproxy/mediaproxy

[Jan Janak]

On 21-04 13:20, Richard wrote:
> Hi,
> 
> I looked at the archieve and tried to find a solution
> for natted clients in a carrier environment. I have to
> say I am clear as mud. In our senario, some clients
> are behind nat, while others are not. Clients may move
> between nat and no-nat. What's the best approach to
> rtpproxy/mediaproxy. In rtpproxy's readme, it uses
> "search" to find certain client. It has issues to
> support other clients. Is nat_uac_test/client_nat_test
> sufficient to test either src or dest is behind nat
> and should go through media proxy? 
 
  Yes, it will detect clients behind NAT if there is no
  SIP-ALG (something that rewrites SIP messages). If the
  NAT rewrites SIP messages as well then they will look
  like ordinary message coming from clients in the public
  internet and they will not be treated like NATed -- in
  that case the NAT will take care of the clients.

> What if some
> clients have stun support? 

  If implemented properly then it will work. If a phones
  discovers that it can traverse the NAT using STUN then
  it will do so and such a client will look like a client
  in the public internet to ser -- neither special treatment
  nor rtp proxy is necessary.

> What if some are behind
> symmetric NAT and some are not?

  Clients supporting STUN will detect that they are behind
  symmetric NAT and should put private IPs in the messages
  (because symmetric NATs are not traversable by STUN and
  therefore STUN should not be used). In this case SER will
  take care of traversing the NAT (nathelper/rtp relay).

  The rule of thumb for user agents is: Rewrite the contents of
  SIP message only if you are absolutely sure that you can traverse
  the NAT without additional help from the server.
  
  If a SIP user agent is able to detect the type of the NAT and 
  traverse it by any means (STUN, UPNP, whatever) then it should do 
  it. In this case ser won't do anything special.

  If the user agent cannot traverse the NAT or if it is not sure 
  that it can traverse it properly then it _should not do anything_,
  it should just send SIP messages containing private IPs to the
  server and hope that the server will be able to traverse it. In
  this case ser needs to get as much original information
  as possible -- mainly private IP addresses.

    Jan.