[Serusers] New versions of RTP proxy/nathelper commited

[Dinesh]

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 at imelhk.com <mailto:dinesh at imelhk.com> 
Tel: (852) 2541-2617
Fax (852) 2543-4537


-----Original Message-----
From: serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
Behalf Of Maxim Sobolev
Sent: Saturday, January 31, 2004 5:56 PM
To: Jan Janak
Cc: serusers at 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 at lists.iptel.org
>>http://lists.iptel.org/mailman/listinfo/serusers
> 
> 
> 
> 


_______________________________________________
Serusers mailing list
serusers at lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers