[Serusers] New versions of RTP proxy/nathelper commited

Maxim Sobolev sobomax at portaone.com
Sat Jan 31 10:56:05 CET 2004


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





More information about the sr-users mailing list