AW: [Serusers] New versions of RTP proxy/nathelper commited
Brunner, Armin
armin.brunner at id.ethz.ch
Thu Feb 5 05:02:49 CET 2004
Maxim,
there seem a problem with the IPv6 part of the rtpproxy. All works fine with nathelper/rtpproxy
inthe ipv4 mode (rtpproxy without an address or only with the "-l IPv4-address" option).
But if I start rtpproxy in the IPv6-mode with "-6 IPv6-address" crashes as soon there is a session
atempt:
boostie:/home/brunner # ser/rtpproxy/rtpproxy -f -6 2001:620:8:801:201:2ff:fe94:8e10
rtpproxy: rtpproxy started, pid 9787
rtpproxy: new session CD1B7AB1-2784-4203-AF8F-7DAC8AE4E250 at 192.94.63.109 <mailto:CD1B7AB1-2784-4203-AF8F-7DAC8AE4E250 at 192.94.63.109> , tag 2953072307 requested
segmentation fault
I'm using the newest CVS versions of nathelper and rtpproxy.
Regards
Armin
P.S.
In your announcment of the new rtpproxy/nathelper version you mention that there is no IPv6
address preloading. Because not writen any C-program for 15 years it would be definitly not
trivial for me to do this extension. You you think to finish the IPv6 support in nathelper/rtpproxy
in the next 3 month?
-----Ursprüngliche Nachricht-----
Von: serusers-bounces at lists.iptel.org im Auftrag von Maxim Sobolev
Gesendet: Sa 31.01.2004 20:56
An: Jan Janak
Cc: serusers at lists.iptel.org
Betreff: 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
More information about the sr-users
mailing list