Bill Zhang wrote:
Bogdan,
Thanks for the reminder, this is a question that I don't know the answer, as I'm struggling to understand the whole configuration. I will try to find out why it is called:).
BTW, I always want to see if I can make SER a powerful server with following configuration:
- Check if SIP end point(base on the SIP message, like Register, Invite)
is behind the NAT, if it is with private IP, then use SER NAThelper for SIP Message and RTP Proxy for RTP. 2. If it is with public IP, check if its IP and Source port is as claimed in the SIP Message(Invite, Register, etc), if yes, then proceed to treat this SIP end point with public IP. 3. If 2 is not true, then this end point may use STUN with wrong detection result, then we treat it as in 1.
I wonder if there is any sample configurations for reference?
Best Regards, Bill Zhang Tel: 626-956-0260 ext 601 Cell: 626-354-0967 web: www.grandstream.com email: wzhang@grandstream.com
Bill,
nathelper.so has all of that functionality:
http://www.openser.org/docs/modules/1.1.x/nathelper.html
1) nat_uac_test & fix_nated_* can do everything you are looking for. Make sure to look at the flags for nat_uac_test. They should probably be >= 19.
2) nat_uac_test only returns true if it detects nat based on your flags. Therefore, you can use logic like this:
#--------REGISTER section----------------------
if (!search("^Contact:[ ]**") && nat_uac_test("23")) { setflag(6); fix_nated_register(); force_rport(); };
#-----INVITE SECTION--------
#(in INVITE message handler)
if (nat_uac_test("23")) { setflag(6); }
#--------Extra Routes--------------
route[4] {
# NAT Traversal Section if (isflagset(6)) { xlog("Fixing NAT in section 4\n"); force_rport(); fix_nated_contact(); force_rtp_proxy(); } }
Now you can just call route(4) BEFORE you call your other route(s).
3) I'm not sure that I really follow you on this one...
P.S. - You'll also want to run RTPProxy to proxy the media streams for clients that are behind nats.
-- Kristian Kielhofner