7 Jan
2004
7 Jan
'04
6:19 p.m.
Hi,
I've just committed major update for rtpproxy/nathelper, which adds
support for proxying RTCP and also make RTP proxy behave much better for
non-NATed clients by pre-loading remote addresses[1] of each party from
the SIP request/reply. Please note that proxy's command protocol has
been extended to support new functionality, so that you need both new
rtp proxy and new nathelper (old nathelper will not work with new rtp
proxy and vice versa). Both of them can be obtained from the ser's cvs
repository:
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/nathelper/
Please let me know if there are any problems with the new version.
-Maxim
[1] currently only IPv4 addresses can be pre-loaded, though it should be
trivial to extend proxy, nathelper and command protocol to accomodate
IPv6 as well. Proxy's core supports IPv4<->IPv4, IPv4<->IPv6 and
IPv6<->IPv6 relaying already both for RTP and RTCP.
7 Jan
7 Jan
6:24 p.m.
Maxim Sobolev wrote:
Hi,
I've just committed major update for rtpproxy/nathelper, which adds
support for proxying RTCP and also make RTP proxy behave much better for
non-NATed clients by pre-loading remote addresses[1] of each party from
the SIP request/reply. Please note that proxy's command protocol has
been extended to support new functionality, so that you need both new
rtp proxy and new nathelper (old nathelper will not work with new rtp
proxy and vice versa). Both of them can be obtained from the ser's cvs
repository:
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/nathelper/
Please let me know if there are any problems with the new version.
-Maxim
[1] currently only IPv4 addresses can be pre-loaded, though it should be
trivial to extend proxy, nathelper and command protocol to accomodate
IPv6 as well. Proxy's core supports IPv4<->IPv4, IPv4<->IPv6 and
IPv6<->IPv6 relaying already both for RTP and RTCP.
P.S. Forgot to mention: nathelper now inserts special flag into SDP body
which indicates that the session is already forced to go through one rtp
proxy and do not apply rtp proxy to messages with such flag already set.
30 Jan
30 Jan
7:10 a.m.
Hi Maxim,
I am in the process of testing this new version in our lab with 0.8.13.
We have been using the older versions with great success for many months
now. But the new version does not work. We are testing with
Grandstream and Sipura units. When a Sipura calls another Sipura, the
nathelper/rtpproxy fails to insert the proper "Connection Information
(c)" in the SDP. Instead of filling in the IP Address of the RTPProxy it
just leaves the same address and adds these four characters "\000" to
the end which seem to make the other Sipura unhappy because it
terminates the call right away with a "488- Not Acceptable" Message.
When a Grandstream is making the call, the same thing happens, with the
exception of the four characters. (IP Address in Connection Information
(c) is not updated)
The Ports do seem to get changed appropiately by the nathelper/rtpproxy
in both cases. But since the IP is not substituted there is no chance
of audio being setup properly.
I can send the Ethereal traces if you want.
Let me know what we can do to fix this issue.
Thanks,
--
Andres
Network Admin
http://www.telesip.net
Maxim Sobolev wrote:
Maxim Sobolev wrote:
Hi,
I've just committed major update for rtpproxy/nathelper, which adds
support for proxying RTCP and also make RTP proxy behave much better
for non-NATed clients by pre-loading remote addresses[1] of each
party from the SIP request/reply. Please note that proxy's command
protocol has been extended to support new functionality, so that you
need both new rtp proxy and new nathelper (old nathelper will not
work with new rtp proxy and vice versa). Both of them can be obtained
from the ser's cvs repository:
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/
http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/sip_router/modules/nathelper/
Please let me know if there are any problems with the new version.
-Maxim
[1] currently only IPv4 addresses can be pre-loaded, though it should
be trivial to extend proxy, nathelper and command protocol to
accomodate IPv6 as well. Proxy's core supports IPv4<->IPv4,
IPv4<->IPv6 and IPv6<->IPv6 relaying already both for RTP and RTCP.
P.S. Forgot to mention: nathelper now inserts special flag into SDP
body which indicates that the session is already forced to go through
one rtp proxy and do not apply rtp proxy to messages with such flag
already set.
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
5:14 p.m.
Update...
I have now tested multiple versions of nathelper from January. The
problem appears after the changes made by Tristan Colgate on
2004-01-16. Nathelper/rtpproxy works fine on the version from 2004-01-15.
Can you take a look at this Tristan? Maxim?
Thanks,
--
Andres
Network Admin
http://www.telesip.net
Andres wrote:
Hi Maxim,
I am in the process of testing this new version in our lab with
0.8.13. We have been using the older versions with great success for
many months now. But the new version does not work. We are testing
with Grandstream and Sipura units. When a Sipura calls another
Sipura, the nathelper/rtpproxy fails to insert the proper "Connection
Information (c)" in the SDP. Instead of filling in the IP Address of
the RTPProxy it just leaves the same address and adds these four
characters "\000" to the end which seem to make the other Sipura
unhappy because it terminates the call right away with a "488- Not
Acceptable" Message.
When a Grandstream is making the call, the same thing happens, with
the exception of the four characters. (IP Address in Connection
Information (c) is not updated)
The Ports do seem to get changed appropiately by the
nathelper/rtpproxy in both cases. But since the IP is not substituted
there is no chance of audio being setup properly.
I can send the Ethereal traces if you want.
Let me know what we can do to fix this issue.
Thanks,
6:49 p.m.
Andres wrote:
Update...
I have now tested multiple versions of nathelper from January. The
problem appears after the changes made by Tristan Colgate on
2004-01-16. Nathelper/rtpproxy works fine on the version from 2004-01-15.
Can you take a look at this Tristan? Maxim?
I'll be travelling next 5 days. I will take a look at the problem upon
my return if somebody doesn't beat me on it.
-Maxim
31 Jan
31 Jan
2:11 a.m.
What change do you mean ? I reviewed and commited some changes on behalf
of Tristan, so please blame me (and provide me with more details if
possible) :-).
Could you make sure that the version before my commit works ?
Jan.
On 30-01 11:14, Andres wrote:
Update...
I have now tested multiple versions of nathelper from January. The
problem appears after the changes made by Tristan Colgate on
2004-01-16. Nathelper/rtpproxy works fine on the version from 2004-01-15.
Can you take a look at this Tristan? Maxim?
Thanks,
--
Andres
Network Admin
http://www.telesip.net
Andres wrote:
Hi Maxim,
I am in the process of testing this new version in our lab with
0.8.13. We have been using the older versions with great success for
many months now. But the new version does not work. We are testing
with Grandstream and Sipura units. When a Sipura calls another
Sipura, the nathelper/rtpproxy fails to insert the proper "Connection
Information (c)" in the SDP. Instead of filling in the IP Address of
the RTPProxy it just leaves the same address and adds these four
characters "\000" to the end which seem to make the other Sipura
unhappy because it terminates the call right away with a "488- Not
Acceptable" Message.
When a Grandstream is making the call, the same thing happens, with
the exception of the four characters. (IP Address in Connection
Information (c) is not updated)
The Ports do seem to get changed appropiately by the
nathelper/rtpproxy in both cases. But since the IP is not substituted
there is no chance of audio being setup properly.
I can send the Ethereal traces if you want.
Let me know what we can do to fix this issue.
Thanks,
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
2:25 a.m.
Jan Janak wrote:
What change do you mean ? I reviewed and commited some
changes on behalf
of Tristan, so please blame me (and provide me with more details if
possible) :-).
Could you make sure that the version before my commit works ?
Jan.
Right now we are running the nathelper version from 2004-1-15 and it
works fine. We tried the version from yesterday and also from 2004-1-22
and it fails to work (presumably after the patch made by Tristan). See
the attached Ethereal trace and examine frame #3 (the INVITE after
nathelper processes it). Take a look at the "Connection Information" in
the SDP. The IP was not substituted and extra characters were added
that makes Sipura units unhappy.
If you need anything else please let me know.
Andres.
On 30-01 11:14, Andres wrote:
--
Andres
Network Admin
http://www.telesip.net
Update...
I have now tested multiple versions of nathelper from January. The
problem appears after the changes made by Tristan Colgate on
2004-01-16. Nathelper/rtpproxy works fine on the version from 2004-01-15.
Can you take a look at this Tristan? Maxim?
Thanks,
--
Andres
Network Admin
http://www.telesip.net
Andres wrote:
Hi Maxim,
I am in the process of testing this new version in our lab with
0.8.13. We have been using the older versions with great success for
many months now. But the new version does not work. We are testing
with Grandstream and Sipura units. When a Sipura calls another
Sipura, the nathelper/rtpproxy fails to insert the proper "Connection
Information (c)" in the SDP. Instead of filling in the IP Address of
the RTPProxy it just leaves the same address and adds these four
characters "\000" to the end which seem to make the other Sipura
unhappy because it terminates the call right away with a "488- Not
Acceptable" Message.
When a Grandstream is making the call, the same thing happens, with
the exception of the four characters. (IP Address in Connection
Information (c) is not updated)
The Ports do seem to get changed appropiately by the
nathelper/rtpproxy in both cases. But since the IP is not substituted
there is no chance of audio being setup properly.
I can send the Ethereal traces if you want.
Let me know what we can do to fix this issue.
Thanks,
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
10:56 a.m.
Yes, indeed, there was a problem with force_rtp_proxy(). I've just
committed a fix (1.38). The problem was that you were trying to use
results of one call to ip_addr2a() after another call to that function.
Since ip_addr2a() returns pointer to a static internal buffer, it was
leading to incorrect results.
-Maxim
Jan Janak wrote:
What change do you mean ? I reviewed and commited some
changes on behalf
of Tristan, so please blame me (and provide me with more details if
possible) :-).
Could you make sure that the version before my commit works ?
Jan.
On 30-01 11:14, Andres wrote:
Update...
I have now tested multiple versions of nathelper from January. The
problem appears after the changes made by Tristan Colgate on
2004-01-16. Nathelper/rtpproxy works fine on the version from 2004-01-15.
Can you take a look at this Tristan? Maxim?
Thanks,
--
Andres
Network Admin
http://www.telesip.net
Andres wrote:
Hi Maxim,
I am in the process of testing this new version in our lab with
0.8.13. We have been using the older versions with great success for
many months now. But the new version does not work. We are testing
with Grandstream and Sipura units. When a Sipura calls another
Sipura, the nathelper/rtpproxy fails to insert the proper "Connection
Information (c)" in the SDP. Instead of filling in the IP Address of
the RTPProxy it just leaves the same address and adds these four
characters "\000" to the end which seem to make the other Sipura
unhappy because it terminates the call right away with a "488- Not
Acceptable" Message.
When a Grandstream is making the call, the same thing happens, with
the exception of the four characters. (IP Address in Connection
Information (c) is not updated)
The Ports do seem to get changed appropiately by the
nathelper/rtpproxy in both cases. But since the IP is not substituted
there is no chance of audio being setup properly.
I can send the Ethereal traces if you want.
Let me know what we can do to fix this issue.
Thanks,
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
12:13 p.m.
Sorry for this, I should have been more careful.
Jan.
On 31-01 11:56, Maxim Sobolev wrote:
Yes, indeed, there was a problem with
force_rtp_proxy(). I've just
committed a fix (1.38). The problem was that you were trying to use
results of one call to ip_addr2a() after another call to that function.
Since ip_addr2a() returns pointer to a static internal buffer, it was
leading to incorrect results.
-Maxim
Jan Janak wrote:
What change do you mean ? I reviewed and commited
some changes on behalf
of Tristan, so please blame me (and provide me with more details if
possible) :-).
Could you make sure that the version before my commit works ?
Jan.
On 30-01 11:14, Andres wrote:
Update...
I have now tested multiple versions of nathelper from January. The
problem appears after the changes made by Tristan Colgate on
2004-01-16. Nathelper/rtpproxy works fine on the version from 2004-01-15.
Can you take a look at this Tristan? Maxim?
Thanks,
--
Andres
Network Admin
http://www.telesip.net
Andres wrote:
Hi Maxim,
I am in the process of testing this new version in our lab with
0.8.13. We have been using the older versions with great success for
many months now. But the new version does not work. We are testing
with Grandstream and Sipura units. When a Sipura calls another
Sipura, the nathelper/rtpproxy fails to insert the proper "Connection
Information (c)" in the SDP. Instead of filling in the IP Address of
the RTPProxy it just leaves the same address and adds these four
characters "\000" to the end which seem to make the other Sipura
unhappy because it terminates the call right away with a "488- Not
Acceptable" Message.
When a Grandstream is making the call, the same thing happens, with
the exception of the four characters. (IP Address in Connection
Information (c) is not updated)
The Ports do seem to get changed appropiately by the
nathelper/rtpproxy in both cases. But since the IP is not substituted
there is no chance of audio being setup properly.
I can send the Ethereal traces if you want.
Let me know what we can do to fix this issue.
Thanks,
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers 
12:17 p.m.
Pls can you tell me where to get the update version.
I have just downloaded the latest tarball from CVS 1.4 but it does not
appear to be the one updated today.
Thanks,
Dinesh
Dinesh Mahbubani
The International Marketing Exchange Ltd.
Email: dinesh(a)imelhk.com <mailto:dinesh@imelhk.com>
Tel: (852) 2541-2617
Fax (852) 2543-4537
-----Original Message-----
From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Maxim Sobolev
Sent: Saturday, January 31, 2004 5:56 PM
To: Jan Janak
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] New versions of RTP proxy/nathelper commited
Yes, indeed, there was a problem with force_rtp_proxy(). I've just
committed a fix (1.38). The problem was that you were trying to use
results of one call to ip_addr2a() after another call to that function.
Since ip_addr2a() returns pointer to a static internal buffer, it was
leading to incorrect results.
-Maxim
Jan Janak wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
What change do you mean ? I reviewed and commited some
changes on
behalf
of Tristan, so please blame me (and provide me with
more details if
possible) :-).
Could you make sure that the version before my commit works ?
Jan.
On 30-01 11:14, Andres wrote:
>Update...
>
>I have now tested multiple versions of nathelper from January. The
>problem appears after the changes made by Tristan Colgate on
>2004-01-16. Nathelper/rtpproxy works fine on the version from
2004-01-15.
>
>Can you take a look at this Tristan? Maxim?
>
>Thanks,
>
>--
>Andres
>Network Admin
>http://www.telesip.net
>
>
>
>Andres wrote:
>
>
>>Hi Maxim,
>>
>>I am in the process of testing this new version in our lab with
>>0.8.13. We have been using the older versions with great success for
>>many months now. But the new version does not
work. We are testing
>>with Grandstream and Sipura units. When a
Sipura calls another
>>Sipura, the nathelper/rtpproxy fails to insert the proper
"Connection
>>Information (c)" in the SDP. Instead of
filling in the IP Address of
>>the RTPProxy it just leaves the same address and adds these four
>>characters "\000" to the end which seem to make the other Sipura
>>unhappy because it terminates the call right away with a "488- Not
>>Acceptable" Message.
>>
>>When a Grandstream is making the call, the same thing happens, with
>>the exception of the four characters. (IP Address in Connection
>>Information (c) is not updated)
>>
>>The Ports do seem to get changed appropiately by the
>>nathelper/rtpproxy in both cases. But since the IP is not
substituted
there is no chance of audio being setup properly.
I can send the Ethereal traces if you want.
Let me know what we can do to fix this issue.
Thanks,
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
12:20 p.m.
The unstable CVS branch has been updated.
Jan.
On 31-01 19:17, Dinesh wrote:
Pls can you tell me where to get the update version.
I have just downloaded the latest tarball from CVS 1.4 but it does not
appear to be the one updated today.
Thanks,
Dinesh
Dinesh Mahbubani
The International Marketing Exchange Ltd.
Email: dinesh(a)imelhk.com <mailto:dinesh@imelhk.com>
Tel: (852) 2541-2617
Fax (852) 2543-4537
-----Original Message-----
From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Maxim Sobolev
Sent: Saturday, January 31, 2004 5:56 PM
To: Jan Janak
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] New versions of RTP proxy/nathelper commited
Yes, indeed, there was a problem with force_rtp_proxy(). I've just
committed a fix (1.38). The problem was that you were trying to use
results of one call to ip_addr2a() after another call to that function.
Since ip_addr2a() returns pointer to a static internal buffer, it was
leading to incorrect results.
-Maxim
Jan Janak wrote:
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
What change do you mean ? I reviewed and commited
some changes on
behalf
of Tristan, so please blame me (and provide me
with more details if
possible) :-).
Could you make sure that the version before my commit works ?
Jan.
On 30-01 11:14, Andres wrote:
>Update...
>
>I have now tested multiple versions of nathelper from January. The
>problem appears after the changes made by Tristan Colgate on
>2004-01-16. Nathelper/rtpproxy works fine on the version from
2004-01-15.
>
>Can you take a look at this Tristan? Maxim?
>
>Thanks,
>
>--
>Andres
>Network Admin
>http://www.telesip.net
>
>
>
>Andres wrote:
>
>
>>Hi Maxim,
>>
>>I am in the process of testing this new version in our lab with
>>0.8.13. We have been using the older versions with great success for
>>many months now. But the new version
does not work. We are testing
>>with Grandstream and Sipura units. When a
Sipura calls another
>>Sipura, the nathelper/rtpproxy fails to insert the proper
"Connection
>>Information (c)" in the SDP. Instead
of filling in the IP Address of
>>the RTPProxy it just leaves the same address and adds these four
>>characters "\000" to the end which seem to make the other Sipura
>>unhappy because it terminates the call right away with a "488- Not
>>Acceptable" Message.
>>
>>When a Grandstream is making the call, the same thing happens, with
>>the exception of the four characters. (IP Address in Connection
>>Information (c) is not updated)
>>
>>The Ports do seem to get changed appropiately by the
>>nathelper/rtpproxy in both cases. But since the IP is not
substituted
there is no chance of audio being setup properly.
I can send the Ethereal traces if you want.
Let me know what we can do to fix this issue.
Thanks,
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
12:58 p.m.
I am sorry to trouble you with this but how do I get to the unstable cvs
Branch.
I have created an account and tried to browse for it but don't seem to
be able to find it.
Presently I do not have any CVS software installed on my sys.
If such software is required I would be grateful if you could email me
the update.
Thanks,
Dinesh
Dinesh Mahbubani
The International Marketing Exchange Ltd.
Email: dinesh(a)imelhk.com <mailto:dinesh@imelhk.com>
Tel: (852) 2541-2617
Fax (852) 2543-4537
-----Original Message-----
From: Jan Janak [mailto:jan@iptel.org]
Sent: Saturday, January 31, 2004 7:21 PM
To: Dinesh
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] New versions of RTP proxy/nathelper commited
The unstable CVS branch has been updated.
Jan.
On 31-01 19:17, Dinesh wrote:
of
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
Pls can you tell me where to get the update version.
I have just downloaded the latest tarball from CVS 1.4 but it does not
appear to be the one updated today.
Thanks,
Dinesh
Dinesh Mahbubani
The International Marketing Exchange Ltd.
Email: dinesh(a)imelhk.com <mailto:dinesh@imelhk.com>
Tel: (852) 2541-2617
Fax (852) 2543-4537
-----Original Message-----
From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org]
On
Behalf Of Maxim Sobolev
Sent: Saturday, January 31, 2004 5:56 PM
To: Jan Janak
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] New versions of RTP proxy/nathelper commited
Yes, indeed, there was a problem with force_rtp_proxy(). I've just
committed a fix (1.38). The problem was that you were trying to use
results of one call to ip_addr2a() after another call to that
function.
Since ip_addr2a() returns pointer to a static internal
buffer, it was
leading to incorrect results.
-Maxim
Jan Janak wrote:
for
What change do you mean ? I reviewed and commited
some changes on
behalf
of Tristan, so please blame me (and provide me
with more details if
possible) :-).
Could you make sure that the version before my commit works ?
Jan.
On 30-01 11:14, Andres wrote:
>Update...
>
>I have now tested multiple versions of nathelper from January. The
>problem appears after the changes made by Tristan Colgate on
>2004-01-16. Nathelper/rtpproxy works fine on the version from
2004-01-15.
>>
>>Can you take a look at this Tristan? Maxim?
>>
>>Thanks,
>>
>>--
>>Andres
>>Network Admin
>>http://www.telesip.net
>>
>>
>>
>>Andres wrote:
>>
>>
>>>Hi Maxim,
>>>
>>>I am in the process of testing this new version in our lab with
>>>0.8.13. We have been using the older versions with great success
>>>many months now. But the new version does not work. We are
testing
>>with Grandstream and Sipura units. When a
Sipura calls another
>>Sipura, the nathelper/rtpproxy fails to insert the proper
"Connection
>>>Information (c)" in the SDP. Instead of filling in the IP Address
>>>the RTPProxy it just leaves the same
address and adds these four
>>>characters "\000" to the end which seem to make the other Sipura
>>>unhappy because it terminates the call right away with a "488- Not
>>>Acceptable" Message.
>>>
>>>When a Grandstream is making the call, the same thing happens, with
>>the
exception of the four characters. (IP Address in Connection
>>Information (c) is not updated)
>>
>>The Ports do seem to get changed appropiately by the
>>nathelper/rtpproxy in both cases. But since the IP is not
substituted
there is no chance of audio being setup properly.
I can send the Ethereal traces if you want.
Let me know what we can do to fix this issue.
Thanks,
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
1 Feb
1 Feb
3:20 a.m.
Maxim Sobolev wrote:
Yes, indeed, there was a problem with
force_rtp_proxy(). I've just
committed a fix (1.38). The problem was that you were trying to use
results of one call to ip_addr2a() after another call to that
function. Since ip_addr2a() returns pointer to a static internal
buffer, it was leading to incorrect results.
-Maxim
Thank you Maxim! It is working properly now with today's nathelper
version on CVS.
--
Andres
Network Admin
http://www.telesip.net
7395
days inactive
7420
days old
12 comments
4 participants
participants (4)
-
Andres -
Dinesh -
Jan Janak -
Maxim Sobolev