Hi,
I search for Kamailio source, and found that Kamailio doesnot handle the x-NAT field in SDP body.
When client use STUN, it can detect the NAT type. When client register, it contains x-NAT (0:unknown, 1: full cone, ..., 6: symmetric), which will be helpful for the server to detect NAT type.
Why doesn't Kamailio handle x-NAT? I think this is a must-have feature
On 03/05/2013 07:04 AM, Khoa Pham wrote:
When client use STUN, it can detect the NAT type. When client register, it contains x-NAT (0:unknown, 1: full cone, ..., 6: symmetric), which will be helpful for the server to detect NAT type.
Again, where are you finding these nonsymmetric clients? The amount of non-symmetrical SIP and RTP implementations out there in the wild at this point is negligible.
@Alex:
Many router out there are using Full cone NAT.
On Tue, Mar 5, 2013 at 7:08 PM, Alex Balashov abalashov@evaristesys.comwrote:
On 03/05/2013 07:04 AM, Khoa Pham wrote:
When client use STUN, it can detect the NAT type. When client
register, it contains x-NAT (0:unknown, 1: full cone, ..., 6: symmetric), which will be helpful for the server to detect NAT type.
Again, where are you finding these nonsymmetric clients? The amount of non-symmetrical SIP and RTP implementations out there in the wild at this point is negligible.
-- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
______________________________**_________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**devhttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 03/05/2013 07:18 AM, Khoa Pham wrote:
@Alex:
Many router out there are using Full cone NAT.
Yes, but how does full cone NAT change the treatment you must give to the SIP client on the far (proxy) end?
Le 2013-03-05 13:20, Alex Balashov a écrit :
Many router out there are using Full cone NAT.
Yes, but how does full cone NAT change the treatment you must give to the SIP client on the far (proxy) end?
I guess he wants to activate RTP proxying for clients behind a symmetric NAT only.
Simon
@Simon
Yes, when either caller or callee is behind symmetric NAT, I want to activate RTP proxy. I think that makes sense
On Tue, Mar 5, 2013 at 7:37 PM, Simon Perreault <simon.perreault@viagenie.ca
wrote:
Le 2013-03-05 13:20, Alex Balashov a écrit :
Many router out there are using Full cone NAT.
Yes, but how does full cone NAT change the treatment you must give to the SIP client on the far (proxy) end?
I guess he wants to activate RTP proxying for clients behind a symmetric NAT only.
Simon
______________________________**_________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**devhttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Le 2013-03-05 13:08, Alex Balashov a écrit :
When client use STUN, it can detect the NAT type. When client register, it contains x-NAT (0:unknown, 1: full cone, ..., 6: symmetric), which will be helpful for the server to detect NAT type.
Again, where are you finding these nonsymmetric clients? The amount of non-symmetrical SIP and RTP implementations out there in the wild at this point is negligible.
You're confusing "symmetric RTP" (as defined in RFC 4961) with "symmetric NAT" (as defined in RFC 3489).
Simon
5 mar 2013 kl. 13:04 skrev Khoa Pham onmyway133@gmail.com:
Hi,
I search for Kamailio source, and found that Kamailio doesnot handle the x-NAT field in SDP body.
When client use STUN, it can detect the NAT type. When client register, it contains x-NAT (0:unknown, 1: full cone, ..., 6: symmetric), which will be helpful for the server to detect NAT type.
Why doesn't Kamailio handle x-NAT? I think this is a must-have feature
Kamailio is a toolbox where you build your own application. These kind of headers are non-standard but easily parsed and handled in your Kamailio configuration. There are very few headers of all possible headers out there that the source-code actually use. The rest is up to your configuration script, especially when it comes to variables prefixed with "x-", that are for internal non-standard use.
Regards, /O
I think that's what I was trying to say, but did not quite say.
Simon Perreault simon.perreault@viagenie.ca wrote:
Le 2013-03-05 13:04, Khoa Pham a écrit :
When client use STUN, it can detect the NAT type.
This is not true in many important cases. See RFC 5780.
Trying to detect a NAT type is useless and the result will be fragile.
Simon
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Alex Balashov -
Khoa Pham -
Olle E. Johansson -
Simon Perreault