Hi Greger,
The system is currently being tested by someone else but I believe they are behind a Linksys VPN router. Are you suggesting it could simply be the settings in this? I "think" I understand the nat issues associated with sip and sdp fairly ok so would I be correct in saying that if my two clients are behind nat(the same nat)on the same subnet the rtpproxy should be invoked? This would be my understanding of the situation but then I saw a recent email (see message header below)which suggests an external script should be used.
Re: FW: [Serusers] calls between UA´s b ehind same NAT us ing nathelper/rtpproxy
Also what confuses me is that the scenario works sometimes and yet other times it doesnt. I will attempt to get a full message dump (of both the working and non working scenario)from the tester if that will help.
Kindest Regards, Pat.
--- "Greger V. Teigre" greger@teigre.com wrote:
Pat, You haven't said anything of the type of NAT you are behind. To me it sounds like an ALG (Application layer gateway) problem. Try to turn of the SIP ALG in your router. If not, please post a full SIP message exchange. You need to find out if they communicate through the NAT (hairpin media) or directly. That depends on the SDP payload in the INVITE and OK messages. The new Getting Started document on http://onsip.org/ (you need to register) has a thorough review of NAT issues and rewriting. Recommend! (I wrote it ;-) ) g-)
pat newham wrote:
Following on from my below email, I can now
definately
say the problem is not nat pings. Just to recap I
am
experiencing intermittent audio. It works when the phones have very recently registered, then
sometimes
theres one way audio and then sometimes no audio.
Does
anyone have any ideas what the problem could be or where I could begin to troubleshoot this?
Hi,
I have a strange problem. I have two grandstream budgetone clients on the same subnet behind nat registering with ser on a public address.
Obviously
their public addresses would be the same but they listen on different ports. When they initially register, I can the call,audio is transmitted and everything is successful.
However sometimes theres only one way audio, other times theres no audio and then other times it works....I am guessing that this is because the
nat
router is forgetting the nat mapping so after a
while
when the nat mapping is "forgotten" and a packet arrives destined for a client, the router drops
it....
Could someone verify this for me??...Am I on the
right
track?? I have the following settings in ser.cfg
which
I thought would keep the nat settings alive.
modparam("registrar", "nat_flag", 6) modparam("nathelper", "natping_interval", 30) #
Ping
interval 30 s modparam("nathelper", "ping_nated_only", 1) #
Ping
only clients behind NAT
I also increased the nat keep alives "pings" sent
in
the configuration settings of the grandstream phone....Any further ideas??
Regards, Pat.
Send instant messages to your online friends http://uk.messenger.yahoo.com
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Send instant messages to your online friends http://uk.messenger.yahoo.com
Pat,
The system is currently being tested by someone else but I believe they are behind a Linksys VPN router.
Have a look at these: http://lists.iptel.org/pipermail/serusers/2005-January/014620.html http://www.linksysinfo.org/modules.php?name=Forums&file=viewtopic&p=...
Are you suggesting it could simply be the settings in this?
Yes.
I "think" I understand the nat issues associated with sip and sdp fairly ok so would I be correct in saying that if my two clients are behind nat(the same nat)on the same subnet the rtpproxy should be invoked? This would be my understanding of the situation but then I saw a recent email (see message header below)which suggests an external script should be used.
I'm afraid it's not that simple. ;-) If the clients are directly routable on your LAN, you would be best off not doing any nathelper/rtpproxy. The rtp will then flow directly between the clients. However, if you use nathelper, it depends on your knowledge of the clients. If you send the SIP messages through an ALG, the ALG will change the SDP IP addresses (probably), unless it detects that both are on it's own LAN. This is dependent on the implementation. Anyway, an ALG rewriting to send rtp in a hairpin (turn in the NAT) will probably support hairpin. The problem is that you get all sorts of problems if the ALG is rewriting and you make some assumptions about the SDP payload. You should probably dump the SIP messages on the outside of the NAT (I believe you said ser is on a public address outside?)
External scripts should never be used. If a script blocks, you block the ser ser process. If the same error is triggered in several processes, ser will stop responding.
Re: FW: [Serusers] calls between UA´s b ehind same NAT us ing nathelper/rtpproxy
Also what confuses me is that the scenario works sometimes and yet other times it doesnt.
:-) Welcome to the club...
g-)
I will attempt to get a full message dump (of both the working and non working scenario)from the tester if that will help.
Kindest Regards, Pat.
--- "Greger V. Teigre" greger@teigre.com wrote:
Pat, You haven't said anything of the type of NAT you are behind. To me it sounds like an ALG (Application layer gateway) problem. Try to turn of the SIP ALG in your router. If not, please post a full SIP message exchange. You need to find out if they communicate through the NAT (hairpin media) or directly. That depends on the SDP payload in the INVITE and OK messages. The new Getting Started document on http://onsip.org/ (you need to register) has a thorough review of NAT issues and rewriting. Recommend! (I wrote it ;-) ) g-)
pat newham wrote:
Following on from my below email, I can now
definately
say the problem is not nat pings. Just to recap I
am
experiencing intermittent audio. It works when the phones have very recently registered, then
sometimes
theres one way audio and then sometimes no audio.
Does
anyone have any ideas what the problem could be or where I could begin to troubleshoot this?
Hi,
I have a strange problem. I have two grandstream budgetone clients on the same subnet behind nat registering with ser on a public address.
Obviously
their public addresses would be the same but they listen on different ports. When they initially register, I can the call,audio is transmitted and everything is successful.
However sometimes theres only one way audio, other times theres no audio and then other times it works....I am guessing that this is because the
nat
router is forgetting the nat mapping so after a
while
when the nat mapping is "forgotten" and a packet arrives destined for a client, the router drops
it....
Could someone verify this for me??...Am I on the
right
track?? I have the following settings in ser.cfg
which
I thought would keep the nat settings alive.
modparam("registrar", "nat_flag", 6) modparam("nathelper", "natping_interval", 30) #
Ping
interval 30 s modparam("nathelper", "ping_nated_only", 1) #
Ping
only clients behind NAT
I also increased the nat keep alives "pings" sent
in
the configuration settings of the grandstream phone....Any further ideas??
Regards, Pat.
Send instant messages to your online friends http://uk.messenger.yahoo.com
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Send instant messages to your online friends http://uk.messenger.yahoo.com
Thank you for the explanation...perhaps my view of the nat issues are too simplified!! I realise now that there is no point in invoking rtpproxy when the user agents are behind the same nat on the same subnet. I do not think the linksys router has any sip alg settings. However while I acknowledge this is bad design practice, I suspect now that the problem is that my rtpproxy isnt working correctly anyway.
I found the following messages in /var/log/messages:
localhost /usr/sbin/ser: ERROR: send rtpp_test: cant read reply from a rtp proxy localhost /usr/sbin/ser: WARNING: rtpp_test: cant get version of the RTP proxy localhost /usr/sbin/ser: WARNING: support for the rtpproxy has been temporarily disabled
I searched the archives and determined that I am probably running the wrong version of RTPProxy so from the /usr/sbin directory I ran the following command:
cvs -d:pserver:anonymous@cvs.ser.berlios.de:/cvsroot/ser co rtpproxy.
However this seems not to have made any difference. Any further ideas? Do you think this is the source of the problem?
Regards, Pat.
--- "Greger V. Teigre" greger@teigre.com wrote:
Pat,
The system is currently being tested by someone
else
but I believe they are behind a Linksys VPN
router.
Have a look at these:
http://lists.iptel.org/pipermail/serusers/2005-January/014620.html
http://www.linksysinfo.org/modules.php?name=Forums&file=viewtopic&p=...
Are you suggesting it could simply be the settings
in
this?
Yes.
I "think" I understand the nat issues associated
with
sip and sdp fairly ok so would I be correct in
saying
that if my two clients are behind nat(the same
nat)on
the same subnet the rtpproxy should be invoked?
This
would be my understanding of the situation but
then I
saw a recent email (see message header below)which suggests an external script should be used.
I'm afraid it's not that simple. ;-) If the clients are directly routable on your LAN, you would be best off not doing any nathelper/rtpproxy. The rtp will then flow directly between the clients. However, if you use nathelper, it depends on your knowledge of the clients. If you send the SIP messages through an ALG, the ALG will change the SDP IP addresses (probably), unless it detects that both are on it's own LAN. This is dependent on the implementation. Anyway, an ALG rewriting to send rtp in a hairpin (turn in the NAT) will probably support hairpin. The problem is that you get all sorts of problems if the ALG is rewriting and you make some assumptions about the SDP payload. You should probably dump the SIP messages on the outside of the NAT (I believe you said ser is on a public address outside?)
External scripts should never be used. If a script blocks, you block the ser ser process. If the same error is triggered in several processes, ser will stop responding.
Re: FW: [Serusers] calls between UA´s b ehind same
NAT
us ing nathelper/rtpproxy
Also what confuses me is that the scenario works sometimes and yet other times it doesnt.
:-) Welcome to the club...
g-)
I will attempt to get a full message dump (of both the working and non working scenario)from the tester
if
that will help.
Kindest Regards, Pat.
--- "Greger V. Teigre" greger@teigre.com wrote:
Pat, You haven't said anything of the type of NAT you
are
behind. To me it sounds like an ALG (Application layer gateway) problem.
Try
to turn of the SIP ALG in your router. If not, please post a full SIP message exchange. You need to find out if they communicate through the NAT (hairpin media) or directly. That depends on the SDP payload in the INVITE and
OK
messages. The new Getting Started document on http://onsip.org/ (you need to register) has a thorough review of NAT issues and rewriting. Recommend! (I wrote it ;-) ) g-)
pat newham wrote:
Following on from my below email, I can now
definately
say the problem is not nat pings. Just to recap
I
am
experiencing intermittent audio. It works when
the
phones have very recently registered, then
sometimes
theres one way audio and then sometimes no
audio.
Does
anyone have any ideas what the problem could be
or
where I could begin to troubleshoot this?
Hi,
I have a strange problem. I have two grandstream budgetone clients on the same subnet behind nat registering with ser on a public address.
Obviously
their public addresses would be the same but
they
listen on different ports. When they initially register, I can the call,audio is transmitted
and
everything is successful.
However sometimes theres only one way audio,
other
times theres no audio and then other times it works....I am guessing that this is because the
nat
router is forgetting the nat mapping so after a
while
when the nat mapping is "forgotten" and a packet arrives destined for a client, the router drops
it....
Could someone verify this for me??...Am I on the
right
track?? I have the following settings in ser.cfg
which
I thought would keep the nat settings alive.
modparam("registrar", "nat_flag", 6) modparam("nathelper", "natping_interval", 30) #
Ping
interval 30 s modparam("nathelper", "ping_nated_only", 1) #
Ping
only clients behind NAT
I also increased the nat keep alives "pings"
sent
in
the configuration settings of the grandstream phone....Any further ideas??
Regards, Pat.
Send instant messages to your online friends http://uk.messenger.yahoo.com
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Send instant messages to your online friends http://uk.messenger.yahoo.com
Send instant messages to your online friends http://uk.messenger.yahoo.com
Yes, an update could be of help. There was a protocol change (between rtpproxy and ser/nathelper) at one point. I don't remember when. I would agree that getting rid of the error messages would be priority 1. As the warning says, rtpproxy is disabled and force_rtp_proxy will not help you... An updated version of the Getting Started document with NAT (both mediaproxy and rtpproxy) is in the works and will be released within the next couple of weeks (probably). Until then I suggest that you make sure that rtpproxy is really updated and running correctly and that they are able to communicate (permissions) through the /var/run/rtpproxy.sock socket. g-)
pat newham wrote:
Thank you for the explanation...perhaps my view of the nat issues are too simplified!! I realise now that there is no point in invoking rtpproxy when the user agents are behind the same nat on the same subnet. I do not think the linksys router has any sip alg settings. However while I acknowledge this is bad design practice, I suspect now that the problem is that my rtpproxy isnt working correctly anyway.
I found the following messages in /var/log/messages:
localhost /usr/sbin/ser: ERROR: send rtpp_test: cant read reply from a rtp proxy localhost /usr/sbin/ser: WARNING: rtpp_test: cant get version of the RTP proxy localhost /usr/sbin/ser: WARNING: support for the rtpproxy has been temporarily disabled
I searched the archives and determined that I am probably running the wrong version of RTPProxy so from the /usr/sbin directory I ran the following command:
cvs -d:pserver:anonymous@cvs.ser.berlios.de:/cvsroot/ser co rtpproxy.
However this seems not to have made any difference. Any further ideas? Do you think this is the source of the problem?
Regards, Pat.
--- "Greger V. Teigre" greger@teigre.com wrote:
Pat,
The system is currently being tested by someone
else
but I believe they are behind a Linksys VPN
router.
Have a look at these:
http://lists.iptel.org/pipermail/serusers/2005-January/014620.html
http://www.linksysinfo.org/modules.php?name=Forums&file=viewtopic&p=...
Are you suggesting it could simply be the settings
in
this?
Yes.
I "think" I understand the nat issues associated
with
sip and sdp fairly ok so would I be correct in
saying
that if my two clients are behind nat(the same
nat)on
the same subnet the rtpproxy should be invoked?
This
would be my understanding of the situation but
then I
saw a recent email (see message header below)which suggests an external script should be used.
I'm afraid it's not that simple. ;-) If the clients are directly routable on your LAN, you would be best off not doing any nathelper/rtpproxy. The rtp will then flow directly between the clients. However, if you use nathelper, it depends on your knowledge of the clients. If you send the SIP messages through an ALG, the ALG will change the SDP IP addresses (probably), unless it detects that both are on it's own LAN. This is dependent on the implementation. Anyway, an ALG rewriting to send rtp in a hairpin (turn in the NAT) will probably support hairpin. The problem is that you get all sorts of problems if the ALG is rewriting and you make some assumptions about the SDP payload. You should probably dump the SIP messages on the outside of the NAT (I believe you said ser is on a public address outside?)
External scripts should never be used. If a script blocks, you block the ser ser process. If the same error is triggered in several processes, ser will stop responding.
Re: FW: [Serusers] calls between UA´s b ehind same
NAT
us ing nathelper/rtpproxy
Also what confuses me is that the scenario works sometimes and yet other times it doesnt.
:-) Welcome to the club...
g-)
I will attempt to get a full message dump (of both the working and non working scenario)from the tester
if
that will help.
Kindest Regards, Pat.
--- "Greger V. Teigre" greger@teigre.com wrote:
Pat, You haven't said anything of the type of NAT you
are
behind. To me it sounds like an ALG (Application layer gateway) problem.
Try
to turn of the SIP ALG in your router. If not, please post a full SIP message exchange. You need to find out if they communicate through the NAT (hairpin media) or directly. That depends on the SDP payload in the INVITE and
OK
messages. The new Getting Started document on http://onsip.org/ (you need to register) has a thorough review of NAT issues and rewriting. Recommend! (I wrote it ;-) ) g-)
pat newham wrote:
Following on from my below email, I can now
definately
say the problem is not nat pings. Just to recap I am experiencing intermittent audio. It works when
the
phones have very recently registered, then
sometimes
theres one way audio and then sometimes no audio. Does anyone have any ideas what the problem could be
or
where I could begin to troubleshoot this?
Hi,
I have a strange problem. I have two grandstream budgetone clients on the same subnet behind nat registering with ser on a public address.
Obviously
their public addresses would be the same but
they
listen on different ports. When they initially register, I can the call,audio is transmitted
and
everything is successful.
However sometimes theres only one way audio,
other
times theres no audio and then other times it works....I am guessing that this is because the
nat
router is forgetting the nat mapping so after a
while
when the nat mapping is "forgotten" and a packet arrives destined for a client, the router drops
it....
Could someone verify this for me??...Am I on the
right
track?? I have the following settings in ser.cfg
which
I thought would keep the nat settings alive.
modparam("registrar", "nat_flag", 6) modparam("nathelper", "natping_interval", 30) #
Ping
interval 30 s modparam("nathelper", "ping_nated_only", 1) #
Ping
only clients behind NAT
I also increased the nat keep alives "pings" sent in the configuration settings of the grandstream phone....Any further ideas??
Regards, Pat.
Send instant messages to your online friends http://uk.messenger.yahoo.com
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Send instant messages to your online friends http://uk.messenger.yahoo.com
Send instant messages to your online friends http://uk.messenger.yahoo.com
In the ser.cfg file i have:
modparam("nathelper", "rtpproxy_sock", "/var/run/rtpproxy.sock")
When I go to the /var/run directory and do "ls" I can see rtpproxy.sock along with a directory called "rtpproxy" containing c files/readme files etc. I ran "ls -l rtpproxy.sock" and got the following results:
srwxr-xr-x 1root root [date]rtpproxy.sock
I also checked pstree and can see rtpproxy running.
Is it correct for rtpproxy.sock to be in a different directory to all the rtpproxy c files etc?
When I run the following:
localhost:/var/run# cvs -d:pserver:anonymous@cvs.ser.berlios.de:/cvsroot/ser co rtpproxy
I get: ? rtpproxy/127.0.0.1 cvs server: Updating rtpproxy.
Am I running this command in the correct directory?
I again stopped rtpproxy and ser (killall rtpproxy and killall ser) and restarted rtpproxy ("rtpproxy" from the command line...does this have to be started in a particular directory?) and then restarted ser(/etc/init.d/ser restart). I still have the errors described below.
Am I doing something ridiculously stupid or missing something very obvious or is all the above correct?
Regards, Pat.
--- "Greger V. Teigre" greger@teigre.com wrote:
Yes, an update could be of help. There was a protocol change (between rtpproxy and ser/nathelper) at one point. I don't remember when. I would agree that getting rid of the error messages would be priority 1. As the warning says, rtpproxy is disabled and force_rtp_proxy will not help you... An updated version of the Getting Started document with NAT (both mediaproxy and rtpproxy) is in the works and will be released within the next couple of weeks (probably). Until then I suggest that you make sure that rtpproxy is really updated and running correctly and that they are able to communicate (permissions) through the /var/run/rtpproxy.sock socket. g-)
pat newham wrote:
Thank you for the explanation...perhaps my view of
the
nat issues are too simplified!! I realise now that there is no point in invoking rtpproxy when the
user
agents are behind the same nat on the same subnet.
I
do not think the linksys router has any sip alg settings. However while I acknowledge this is bad design practice, I suspect now that the problem is that my rtpproxy isnt working correctly anyway.
I found the following messages in
/var/log/messages:
localhost /usr/sbin/ser: ERROR: send rtpp_test:
cant
read reply from a rtp proxy localhost /usr/sbin/ser: WARNING: rtpp_test: cant
get
version of the RTP proxy localhost /usr/sbin/ser: WARNING: support for the rtpproxy has been temporarily disabled
I searched the archives and determined that I am probably running the wrong version of RTPProxy so
from
the /usr/sbin directory I ran the following
command:
cvs
-d:pserver:anonymous@cvs.ser.berlios.de:/cvsroot/ser
co rtpproxy.
However this seems not to have made any
difference.
Any further ideas? Do you think this is the source
of
the problem?
Regards, Pat.
--- "Greger V. Teigre" greger@teigre.com wrote:
Pat,
The system is currently being tested by someone
else
but I believe they are behind a Linksys VPN
router.
Have a look at these:
http://lists.iptel.org/pipermail/serusers/2005-January/014620.html
http://www.linksysinfo.org/modules.php?name=Forums&file=viewtopic&p=...
Are you suggesting it could simply be the
settings
in
this?
Yes.
I "think" I understand the nat issues associated
with
sip and sdp fairly ok so would I be correct in
saying
that if my two clients are behind nat(the same
nat)on
the same subnet the rtpproxy should be invoked?
This
would be my understanding of the situation but
then I
saw a recent email (see message header
below)which
suggests an external script should be used.
I'm afraid it's not that simple. ;-) If the
clients
are directly routable on your LAN, you would be best off not doing any nathelper/rtpproxy. The rtp will then flow directly between the clients. However, if you use nathelper, it depends on your knowledge of the clients. If
you
send the SIP messages through an ALG, the ALG will change the SDP IP addresses (probably), unless it detects that both are on it's own LAN. This is dependent on the implementation. Anyway, an ALG rewriting to send rtp in a hairpin (turn in the NAT) will probably support hairpin. The
problem
is that you get all sorts of problems if the ALG is rewriting and you make some assumptions about the SDP payload. You should probably dump the SIP messages on the outside of the NAT (I believe you said ser is on a public address outside?)
External scripts should never be used. If a
script
blocks, you block the ser ser process. If the same error is triggered in several processes, ser will stop responding.
Re: FW: [Serusers] calls between UA´s b ehind
same
NAT
us ing nathelper/rtpproxy
Also what confuses me is that the scenario works sometimes and yet other times it doesnt.
:-) Welcome to the club...
g-)
I will attempt to get a full message dump (of both the working and non working scenario)from the tester
if
that will help.
Kindest Regards, Pat.
--- "Greger V. Teigre" greger@teigre.com
wrote:
Pat, You haven't said anything of the type of NAT
you
are
behind. To me it sounds like an ALG (Application layer gateway)
problem.
Try
to turn of the SIP ALG in your router. If not, please post a full SIP message exchange. You need to find out if they communicate through the NAT (hairpin media) or directly. That depends on the SDP payload in the INVITE
and
OK
messages. The new Getting Started document on http://onsip.org/ (you need to register) has a thorough review of NAT issues
and
rewriting. Recommend! (I wrote it ;-) ) g-)
pat newham wrote:
Following on from my below email, I can now
definately
say the problem is not nat pings. Just to
recap I am
experiencing intermittent audio. It works when
the
phones have very recently registered, then
sometimes
theres one way audio and then sometimes no
audio. Does
anyone have any ideas what the problem could
be
or
where I could begin to troubleshoot this?
Hi,
=== message truncated ===
Send instant messages to your online friends http://uk.messenger.yahoo.com
-
Greger V. Teigre -
pat newham