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? What if some clients have stun support? What if some are behind symmetric NAT and some are not?
Thanks for your help. Richard
__________________________________ Do you Yahoo!? Yahoo! Photos: High-quality 4x6 digital prints for 25� http://photos.yahoo.com/ph/print_splash
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.
-
Jan Janak -
Richard