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:
1. 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(a)grandstream.com
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