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@192.94.63.109 mailto:CD1B7AB1-2784-4203-AF8F-7DAC8AE4E250@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@lists.iptel.org im Auftrag von Maxim Sobolev Gesendet: Sa 31.01.2004 20:56 An: Jan Janak Cc: serusers@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@lists.iptel.org >>http://lists.iptel.org/mailman/listinfo/serusers > > > > _______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers