5 Mar
2013
5 Mar
'13
1:04 p.m.
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
--
Khoa Pham
HCMC University of Science
Faculty of Information Technology
5 Mar
5 Mar
1:08 p.m.
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/
1:18 p.m.
@Alex:
Many router out there are using Full cone NAT.
On Tue, Mar 5, 2013 at 7:08 PM, Alex Balashov <abalashov(a)evaristesys.com>wrote;wrote:
On 03/05/2013 07:04 AM, Khoa Pham wrote:
When client use STUN, it can detect the NAT type. When client
--
Khoa Pham
HCMC University of Science
Faculty of Information Technology
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(a)lists.sip-router.org
http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**dev<http://l…
1:20 p.m.
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?
--
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/
1:37 p.m.
Le 2013-03-05 13:20, Alex Balashov a écrit :
I guess he wants to activate RTP proxying for clients behind a symmetric
NAT only.
Simon
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?
1:37 p.m.
@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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/**cgi-bin/mailman/listinfo/sr-**dev<http://l…
--
Khoa Pham
HCMC University of Science
Faculty of Information Technology
1:35 p.m.
Le 2013-03-05 13:08, Alex Balashov a écrit :
You're confusing "symmetric RTP" (as defined in RFC 4961) with
"symmetric NAT" (as defined in RFC 3489).
Simon
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. 
1:23 p.m.
5 mar 2013 kl. 13:04 skrev Khoa Pham <onmyway133(a)gmail.com>om>:
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
1:44 p.m.
I think that's what I was trying to say, but did not quite say.
Simon Perreault <simon.perreault(a)viagenie.ca> wrote:
Le 2013-03-05 13:04, Khoa Pham a écrit :
--
Sent from my mobile, and thus lacking in the refinement one might expect from a
fully-fledged keyboard.
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/
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
4094
days inactive
4094
days old
9 comments
4 participants
participants (4)
-
Alex Balashov -
Khoa Pham -
Olle E. Johansson -
Simon Perreault