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:
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
_______________________________________________
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