1 May
2003
1 May
'03
6:18 a.m.
I've just committed into the cvs the autopinging feature useful to
keep NAT bindings alive. If possible, please test and let me know
then. Basically, everything you need to do is to recompile/reinstall
ser and all modules and add the following into your config:
modparam("nathelper", "natping_interval", N)
Where N is some non-zero interval in seconds (usually 15-30 should
be OK).
Thanks!
-Maxim
On Tue, Apr 29, 2003 at 09:38:44PM +0100, jaime(a)umtstrial.co.uk wrote:
Hello Maxim,
I have been trying your module on one server with a customised
configuration, very similar to the default one in nathelper.cfg. Actually,
I'm trying to connect through a NAT to a server running SER with the
nathelper module. The overall configuration looks like this:
UA1 --- NAT --- SER (proxy and registrar)
UA2 |
UA1 and UA2 must traverse a NAT in order to reach SER. The NAT does not
have port forwarding whatsoever.
I was trying to see what happens to REGISTER, SUBSCRIBE, MESSAGE and
INVITE messages. The nathelper adds rport and received to the Via field,
so any response from the server gets routed correctly to the appropriate
destination (that is, the NAT external interface).
REGISTER's Contact is stored at registration and the 200 OK reaches the
initiating client through the NAT.
However, any other SIP message involving a database lookup into "location"
will try to relay the message to the natted client, which is not reachable
from the SER proxy (see diagram above). I think this could work if in
location table you stored the "received" and "rport" values instead
of the
"Contact" field received when regitering (if that does not go against
standards...). Then, just keep alive the NAT binding somehow (I think you
where mentioning it in a previous email).
Does this sound resonable? Making this scenario work would allow people at
home with simple NAT's to use a public proxy (like Iptel's) and its
services (Instant Messaging and Presence mainly)...
Jaime
14 May
14 May
7:40 p.m.
Hi Maxim,
I tried out the nathelper module and it works as described. It certainly
solves the problem of getting Natted ATAs to send SIP messages between each
other. Unfortunately I do not see how one can solve the problem of the
Natted RTP stream. For example, an ATA behind a NAT sends an INVITE message
(to a UA that is out in the internet) saying that its audio port is 20000.
Once the call is established (thanks to the nathelper module), the ATA
starts generating the audio stream with source port 20000 but once it passes
through the NAT the source port gets changed to some random number. The
remote user agent is trying to send its stream to port 20000 but the NAT
drops it because it is not valid in its NAT table.
How have you solved this issue?
Thanks,
Ricardo
----- Original Message -----
From: "Maxim Sobolev" <sobomax(a)portaone.com>
To: <jaime(a)umtstrial.co.uk>
Cc: <serdev(a)lists.iptel.org>rg>; <serusers(a)lists.iptel.org>
Sent: Thursday, May 01, 2003 5:18 AM
Subject: [Serusers] Re: First tests with nathelper
I've just committed into the cvs the autopinging
feature useful to
keep NAT bindings alive. If possible, please test and let me know
then. Basically, everything you need to do is to recompile/reinstall
ser and all modules and add the following into your config:
modparam("nathelper", "natping_interval", N)
Where N is some non-zero interval in seconds (usually 15-30 should
be OK).
Thanks!
-Maxim
On Tue, Apr 29, 2003 at 09:38:44PM +0100, jaime(a)umtstrial.co.uk wrote:
> Hello Maxim,
>
> I have been trying your module on one server with a customised
> configuration, very similar to the default one in nathelper.cfg.
Actually,
> I'm trying to connect through a NAT to a
server running SER with the
> nathelper module. The overall configuration looks like this:
>
> UA1 --- NAT --- SER (proxy and registrar)
> UA2 |
>
> UA1 and UA2 must traverse a NAT in order to reach SER. The NAT does not
> have port forwarding whatsoever.
>
> I was trying to see what happens to REGISTER, SUBSCRIBE, MESSAGE and
> INVITE messages. The nathelper adds rport and received to the Via field,
> so any response from the server gets routed correctly to the appropriate
> destination (that is, the NAT external interface).
>
> REGISTER's Contact is stored at registration and the 200 OK reaches the
> initiating client through the NAT.
>
> However, any other SIP message involving a database lookup into
"location"
> will try to relay the message to the natted
client, which is not
reachable
> from the SER proxy (see diagram above). I think
this could work if in
> location table you stored the "received" and "rport" values
instead of
the
> "Contact" field received when
regitering (if that does not go against
> standards...). Then, just keep alive the NAT binding somehow (I think
you
> where mentioning it in a previous email).
>
> Does this sound resonable? Making this scenario work would allow people
at
home with
simple NAT's to use a public proxy (like Iptel's) and its
services (Instant Messaging and Presence mainly)...
Jaime
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7:45 p.m.
We have solved this issue by using symmetric rtp proxy integrated with
nathelper module. We have not released it yet, but planning to do it in
the nearest future. Stay tuned.
-Maxim
Ricardo Villa wrote:
Hi Maxim,
I tried out the nathelper module and it works as described. It certainly
solves the problem of getting Natted ATAs to send SIP messages between each
other. Unfortunately I do not see how one can solve the problem of the
Natted RTP stream. For example, an ATA behind a NAT sends an INVITE message
(to a UA that is out in the internet) saying that its audio port is 20000.
Once the call is established (thanks to the nathelper module), the ATA
starts generating the audio stream with source port 20000 but once it passes
through the NAT the source port gets changed to some random number. The
remote user agent is trying to send its stream to port 20000 but the NAT
drops it because it is not valid in its NAT table.
How have you solved this issue?
Thanks,
Ricardo
----- Original Message -----
From: "Maxim Sobolev" <sobomax(a)portaone.com>
To: <jaime(a)umtstrial.co.uk>
Cc: <serdev(a)lists.iptel.org>rg>; <serusers(a)lists.iptel.org>
Sent: Thursday, May 01, 2003 5:18 AM
Subject: [Serusers] Re: First tests with nathelper
"location"
reachable
the
you
at
I've just committed into the cvs the
autopinging feature useful to
keep NAT bindings alive. If possible, please test and let me know
then. Basically, everything you need to do is to recompile/reinstall
ser and all modules and add the following into your config:
modparam("nathelper", "natping_interval", N)
Where N is some non-zero interval in seconds (usually 15-30 should
be OK).
Thanks!
-Maxim
On Tue, Apr 29, 2003 at 09:38:44PM +0100, jaime(a)umtstrial.co.uk wrote:
Actually,
Hello Maxim,
I have been trying your module on one server with a customised
configuration, very similar to the default one in nathelper.cfg.
I'm
trying to connect through a NAT to a server running SER with the
nathelper module. The overall configuration looks like this:
UA1 --- NAT --- SER (proxy and registrar)
UA2 |
UA1 and UA2 must traverse a NAT in order to reach SER. The NAT does not
have port forwarding whatsoever.
I was trying to see what happens to REGISTER, SUBSCRIBE, MESSAGE and
INVITE messages. The nathelper adds rport and received to the Via field,
so any response from the server gets routed correctly to the appropriate
destination (that is, the NAT external interface).
REGISTER's Contact is stored at registration and the 200 OK reaches the
initiating client through the NAT.
However, any other SIP message involving a database lookup into
will try
to relay the message to the natted client, which is not
from the
SER proxy (see diagram above). I think this could work if in
location table you stored the "received" and "rport" values instead of
"Contact" field received when regitering (if that does not go against
standards...). Then, just keep alive the NAT binding somehow (I think
where
mentioning it in a previous email).
Does this sound resonable? Making this scenario work would allow people
home with
simple NAT's to use a public proxy (like Iptel's) and its
services (Instant Messaging and Presence mainly)...
Jaime
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
15 May
15 May
4:32 a.m.
New subject: [Serdev] Re: [Serusers] Re: First tests with nathelper
Maxim,
Let me know once you release it. We will deploy it on iptel.org along
with the nathelper module for testing.
Jan.
On 15-05 02:45, Maxim Sobolev wrote:
We have solved this issue by using symmetric rtp proxy
integrated with
nathelper module. We have not released it yet, but planning to do it in
the nearest future. Stay tuned.
-Maxim
Ricardo Villa wrote:
Hi Maxim,
I tried out the nathelper module and it works as described. It certainly
solves the problem of getting Natted ATAs to send SIP messages between each
other. Unfortunately I do not see how one can solve the problem of the
Natted RTP stream. For example, an ATA behind a NAT sends an INVITE
message
(to a UA that is out in the internet) saying that its audio port is 20000.
Once the call is established (thanks to the nathelper module), the ATA
starts generating the audio stream with source port 20000 but once it
passes
through the NAT the source port gets changed to some random number. The
remote user agent is trying to send its stream to port 20000 but the NAT
drops it because it is not valid in its NAT table.
How have you solved this issue?
Thanks,
Ricardo
----- Original Message -----
From: "Maxim Sobolev" <sobomax(a)portaone.com>
To: <jaime(a)umtstrial.co.uk>
Cc: <serdev(a)lists.iptel.org>rg>; <serusers(a)lists.iptel.org>
Sent: Thursday, May 01, 2003 5:18 AM
Subject: [Serusers] Re: First tests with nathelper
"location"
reachable
the
you
at
_______________________________________________
Serdev mailing list
serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev I've just committed into the cvs the
autopinging feature useful to
keep NAT bindings alive. If possible, please test and let me know
then. Basically, everything you need to do is to recompile/reinstall
ser and all modules and add the following into your config:
modparam("nathelper", "natping_interval", N)
Where N is some non-zero interval in seconds (usually 15-30 should
be OK).
Thanks!
-Maxim
On Tue, Apr 29, 2003 at 09:38:44PM +0100, jaime(a)umtstrial.co.uk wrote:
Actually,
Hello Maxim,
I have been trying your module on one server with a customised
configuration, very similar to the default one in nathelper.cfg.
I'm
trying to connect through a NAT to a server running SER with the
nathelper module. The overall configuration looks like this:
UA1 --- NAT --- SER (proxy and registrar)
UA2 |
UA1 and UA2 must traverse a NAT in order to reach SER. The NAT does not
have port forwarding whatsoever.
I was trying to see what happens to REGISTER, SUBSCRIBE, MESSAGE and
INVITE messages. The nathelper adds rport and received to the Via field,
so any response from the server gets routed correctly to the appropriate
destination (that is, the NAT external interface).
REGISTER's Contact is stored at registration and the 200 OK reaches the
initiating client through the NAT.
However, any other SIP message involving a database lookup into
will try
to relay the message to the natted client, which is not
from the
SER proxy (see diagram above). I think this could work if in
location table you stored the "received" and "rport" values instead of
"Contact" field received when regitering (if that does not go against
standards...). Then, just keep alive the NAT binding somehow (I think
where
mentioning it in a previous email).
Does this sound resonable? Making this scenario work would allow people
home with
simple NAT's to use a public proxy (like Iptel's) and its
services (Instant Messaging and Presence mainly)...
Jaime
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7 Jun
7 Jun
2:42 a.m.
New subject: [Serdev] Re: [Serusers] Re: First tests with nathelper
At 01:40 AM 5/15/2003, Ricardo Villa wrote:
Hi Maxim,
I tried out the nathelper module and it works as described. It certainly
solves the problem of getting Natted ATAs to send SIP messages between each
other. Unfortunately I do not see how one can solve the problem of the
Natted RTP stream. For example, an ATA behind a NAT sends an INVITE message
(to a UA that is out in the internet) saying that its audio port is 20000.
Once the call is established (thanks to the nathelper module), the ATA
starts generating the audio stream with source port 20000 but once it passes
through the NAT the source port gets changed to some random number. The
remote user agent is trying to send its stream to port 20000 but the NAT
drops it because it is not valid in its NAT table.
How have you solved this issue?
Use a symmetric device as UAS in the Internet. They will see direction=active
in ATA's SDP, ignore thus IP:port in there, and send their media to where ATA's
media come from. Note that there is no better help than media relay if both
parties are behind symmetric NATs.
-jiri
Thanks,
Ricardo
----- Original Message -----
From: "Maxim Sobolev" <sobomax(a)portaone.com>
To: <jaime(a)umtstrial.co.uk>
Cc: <serdev(a)lists.iptel.org>rg>; <serusers(a)lists.iptel.org>
Sent: Thursday, May 01, 2003 5:18 AM
Subject: [Serusers] Re: First tests with nathelper
_______________________________________________
Serdev mailing list
serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
--
Jiri Kuthan http://iptel.org/~jiri/
I've just committed into the cvs the
autopinging feature useful to
keep NAT bindings alive. If possible, please test and let me know
then. Basically, everything you need to do is to recompile/reinstall
ser and all modules and add the following into your config:
modparam("nathelper", "natping_interval", N)
Where N is some non-zero interval in seconds (usually 15-30 should
be OK).
Thanks!
-Maxim
On Tue, Apr 29, 2003 at 09:38:44PM +0100, jaime(a)umtstrial.co.uk wrote:
> Hello Maxim,
>
> I have been trying your module on one server with a customised
> configuration, very similar to the default one in nathelper.cfg.
Actually,
> I'm trying to connect through a NAT to a
server running SER with the
> nathelper module. The overall configuration looks like this:
>
> UA1 --- NAT --- SER (proxy and registrar)
> UA2 |
>
> UA1 and UA2 must traverse a NAT in order to reach SER. The NAT does not
> have port forwarding whatsoever.
>
> I was trying to see what happens to REGISTER, SUBSCRIBE, MESSAGE and
> INVITE messages. The nathelper adds rport and received to the Via field,
> so any response from the server gets routed correctly to the appropriate
> destination (that is, the NAT external interface).
>
> REGISTER's Contact is stored at registration and the 200 OK reaches the
> initiating client through the NAT.
>
> However, any other SIP message involving a database lookup into
"location"
> will try to relay the message to the natted
client, which is not
reachable
> from the SER proxy (see diagram above). I
think this could work if in
> location table you stored the "received" and "rport" values
instead of
the
> "Contact" field received when
regitering (if that does not go against
> standards...). Then, just keep alive the NAT binding somehow (I think
you
> where mentioning it in a previous email).
>
> Does this sound resonable? Making this scenario work would allow people
at
home with
simple NAT's to use a public proxy (like Iptel's) and its
services (Instant Messaging and Presence mainly)...
Jaime
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
7872
days inactive
7909
days old
4 comments
5 participants
participants (5)
-
Jan Janak -
Jiri Kuthan -
Maxim Sobolev -
Maxim Sobolev -
Ricardo Villa