From sobomax at sippysoft.com Mon Aug 10 01:22:41 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Mon, 10 Aug 2009 01:22:41 -0700 Subject: [RTPproxy Devel] Automatic bridging for RTP proxy and advertised address for external NAT In-Reply-To: <4A7371F7.7010200@ives.fr> References: <4A72BFD9.50305@ives.fr> <4A736AD5.5090907@sippysoft.com> <4A7371F7.7010200@ives.fr> Message-ID: <4A7FD8D1.5060105@sippysoft.com> Emmanuel BUU wrote: >> > Hum great, maybe I can help with the NATHELPER module of OpenSIPS if you > describe me what change have been made to the RTP proxy control protocol > and provide me access to the source code. Yes, it should be possible. I will see what I can do in the next few days. >>> 2/ External NAT handling >>> >>> I would also to handle the case where RTP proxy is behind a NAT (one to >>> one NAT). If the communication is on the internal network then the >>> previous processing is applied. If the communication is to be done with >>> the external network, rtp proxy would bind to the same interface but >>> advertise the NATed adress in the answer. >>> > What about this case? Is there a way to handle external NAT by pairing > some interface witn an external advertised address ? >>> We propose to implement these two enhancements but would like to agree >>> with the rtp maintainer in order to have a chance to push this into the >>> open source. This lead me to another question. RTPProxy has currently >>> no configuration file. Would the crowd here consider such an addition to >>> describe the networks (and maybe the port range)? >>> >>> What config library would you favor? >>> >> >> Yes, RTPproxy really needs a configuration file, this is something on my >> list of features for 2.0 as well. I don't have any strong preference for >> config library, however it should meet the few basic criteria: >> >> 1. BSD-like license. Apache, Mozilla, MIT are fine. No GPL/LGPL. >> >> 2. Clean interface and internal representation. Ability to have >> different contexts. >> >> 3. Ability to handle on-the-fly config file reload gracefully. >> >> So, feel free if you want to suggest and discuss something or even want >> to make a code submission. >> > Few !! These are proper requirements. Why is GPL not accepted? I thought > that rtpproxy was GPL also? > Or maybe there is an intellectual propery issue? RTPproxy is BSD licensed, and I have reasons for it to stay that way. So we cannot include any GPL or LGPL code since it would effectively "infect" the rest of the codebase. > Ok I did not find any of these compling the 3 requirements. Req #3 is > tough ... This one should not be very difficult, I think many of the packages that use config files out there has it in one way or another. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com MSN: sales at sippysoft.com Skype: SippySoft From emmanuel.buu at ives.fr Mon Aug 10 05:21:14 2009 From: emmanuel.buu at ives.fr (Emmanuel BUU) Date: Mon, 10 Aug 2009 14:21:14 +0200 Subject: [RTPproxy Devel] Automatic bridging for RTP proxy and advertised address for external NAT In-Reply-To: <4A7FD8D1.5060105@sippysoft.com> References: <4A72BFD9.50305@ives.fr> <4A736AD5.5090907@sippysoft.com> <4A7371F7.7010200@ives.fr> <4A7FD8D1.5060105@sippysoft.com> Message-ID: <4A8010BA.8050304@ives.fr> Maxim Sobolev a ?crit : > Emmanuel BUU wrote: > >>> >>> >> Hum great, maybe I can help with the NATHELPER module of OpenSIPS if you >> describe me what change have been made to the RTP proxy control protocol >> and provide me access to the source code. >> > > Yes, it should be possible. I will see what I can do in the next few days. > > Hello : I made may one crude implementatiion of automated routing. I had indeed to modify the NATHELPER module to pass the requested host. So I am a bit more confortable with this piece of code. Of course, when the 2.0 will be out, I will migrate to any official solution. Emmanuel From sobomax at sippysoft.com Mon Aug 10 16:24:06 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Tue, 11 Aug 2009 01:24:06 +0200 (CEST) Subject: [RTPproxy Devel] CVS:commitlog: rtpproxy main.c rtpp_command.c rtpp_defines.h rtpp_network.c rtpp_network.h Message-ID: <20090810232406.C39EB187F81@mail.berlios.de> sobomax 2009/08/11 01:24:06 CEST SER CVS Repository Modified files: . main.c rtpp_command.c rtpp_defines.h rtpp_network.c rtpp_network.h Log: Introduce automatic bridging functionality. The way it works is that the RTPproxy expects signalling layer (B2BUA, Sip Proxy etc) to let it know either local IP for media or remote IP for this particular call leg. If the local IP is specified, then it will be used verbatim, otherwise the local address will be determined automatically based on remote IP and result of dummy connect(2)/getsockname(2) calls. Both IPv6 and IPv4 addresses are supported. Internally feature is implemented as an extension to the U/L command. option "l" should be used for local addresses, or option "r" for remote, with IPv6 address enclosed into square brackets. For example: Ul[abcd:efgh:0:1] callid remote_ip remote_port fromtag Lr1.2.3.4 callid remote_ip remote_port fromtag totag Changes to OpenSIPS, Kamalio/SER and Sippy B2BUA are to follow. Sponsored by: Evision GmbH Revision Changes Path 1.92 +8 -8 rtpproxy/main.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/main.c.diff?r1=1.91&r2=1.92 1.29 +76 -6 rtpproxy/rtpp_command.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_command.c.diff?r1=1.28&r2=1.29 1.27 +7 -1 rtpproxy/rtpp_defines.h http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_defines.h.diff?r1=1.26&r2=1.27 1.16 +97 -2 rtpproxy/rtpp_network.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_network.c.diff?r1=1.15&r2=1.16 1.21 +8 -2 rtpproxy/rtpp_network.h http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_network.h.diff?r1=1.20&r2=1.21 From sobomax at sippysoft.com Mon Aug 10 23:04:06 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Mon, 10 Aug 2009 23:04:06 -0700 Subject: [RTPproxy Devel] Automatic bridging for RTP proxy and advertised address for external NAT In-Reply-To: <4A8010BA.8050304@ives.fr> References: <4A72BFD9.50305@ives.fr> <4A736AD5.5090907@sippysoft.com> <4A7371F7.7010200@ives.fr> <4A7FD8D1.5060105@sippysoft.com> <4A8010BA.8050304@ives.fr> Message-ID: <4A8109D6.5090102@sippysoft.com> Emmanuel BUU wrote: > Maxim Sobolev a ?crit : >> Emmanuel BUU wrote: >> >>>> >>>> >>> Hum great, maybe I can help with the NATHELPER module of OpenSIPS if you >>> describe me what change have been made to the RTP proxy control protocol >>> and provide me access to the source code. >>> >> Yes, it should be possible. I will see what I can do in the next few days. >> >> > Hello : I made may one crude implementatiion of automated routing. I had > indeed to modify the NATHELPER module to pass the requested host. > So I am a bit more confortable with this piece of code. > > Of course, when the 2.0 will be out, I will migrate to any official > solution. Emmanuel, The change is in CVS now, you are expected to provide either binding address for media or expected remote media address for automatic local address determination: > sobomax 2009/08/11 01:24:06 CEST > > SER CVS Repository > > Modified files: > . main.c rtpp_command.c rtpp_defines.h > rtpp_network.c rtpp_network.h > Log: > Introduce automatic bridging functionality. The way it works is that > the RTPproxy expects signalling layer (B2BUA, Sip Proxy etc) to let it > know either local IP for media or remote IP for this particular call > leg. If the local IP is specified, then it will be used verbatim, > otherwise the local address will be determined automatically based > on remote IP and result of dummy connect(2)/getsockname(2) calls. > Both IPv6 and IPv4 addresses are supported. > > Internally feature is implemented as an extension to the U/L command. > option "l" should be used for local addresses, or option "r" for remote, > with IPv6 address enclosed into square brackets. For example: > > Ul[abcd:efgh:0:1] callid remote_ip remote_port fromtag > > Lr1.2.3.4 callid remote_ip remote_port fromtag totag > > Changes to OpenSIPS, Kamalio/SER and Sippy B2BUA are to follow. Please let me know if you want to go ahead and make a patch for the nathelper. It would involve extracting destination address from the RURI for INVITE, and from upper Via for 200 OK. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com MSN: sales at sippysoft.com Skype: SippySoft From emmanuel.buu at ives.fr Tue Aug 11 08:55:29 2009 From: emmanuel.buu at ives.fr (Emmanuel BUU) Date: Tue, 11 Aug 2009 17:55:29 +0200 Subject: [RTPproxy Devel] Automatic bridging for RTP proxy and advertised address for external NAT In-Reply-To: <4A8109D6.5090102@sippysoft.com> References: <4A72BFD9.50305@ives.fr> <4A736AD5.5090907@sippysoft.com> <4A7371F7.7010200@ives.fr> <4A7FD8D1.5060105@sippysoft.com> <4A8010BA.8050304@ives.fr> <4A8109D6.5090102@sippysoft.com> Message-ID: <4A819471.5050303@ives.fr> Maxim Sobolev a ?crit : > Emmanuel BUU wrote: > >> Maxim Sobolev a ?crit : >> >>> Emmanuel BUU wrote: >>> >>> >>>>> >>>>> >>>>> >>>> Hum great, maybe I can help with the NATHELPER module of OpenSIPS if you >>>> describe me what change have been made to the RTP proxy control protocol >>>> and provide me access to the source code. >>>> >>>> >>> Yes, it should be possible. I will see what I can do in the next few days. >>> >>> >>> >> Hello : I made may one crude implementatiion of automated routing. I had >> indeed to modify the NATHELPER module to pass the requested host. >> So I am a bit more confortable with this piece of code. >> >> Of course, when the 2.0 will be out, I will migrate to any official >> solution. >> > > Emmanuel, > > The change is in CVS now, you are expected to provide either binding > address for media or expected remote media address for automatic local > address determination: > > > sobomax 2009/08/11 01:24:06 CEST > > > > SER CVS Repository > > > > Modified files: > > . main.c rtpp_command.c rtpp_defines.h > > rtpp_network.c rtpp_network.h > > Log: > > Introduce automatic bridging functionality. The way it works is that > > the RTPproxy expects signalling layer (B2BUA, Sip Proxy etc) to let it > > know either local IP for media or remote IP for this particular call > > leg. If the local IP is specified, then it will be used verbatim, > > otherwise the local address will be determined automatically based > > on remote IP and result of dummy connect(2)/getsockname(2) calls. > > Both IPv6 and IPv4 addresses are supported. > > > > Internally feature is implemented as an extension to the U/L command. > > option "l" should be used for local addresses, or option "r" for > remote, > > with IPv6 address enclosed into square brackets. For example: > > > > Ul[abcd:efgh:0:1] callid remote_ip remote_port fromtag > > > > Lr1.2.3.4 callid remote_ip remote_port fromtag totag > > > > Changes to OpenSIPS, Kamalio/SER and Sippy B2BUA are to follow. > > Please let me know if you want to go ahead and make a patch for the > nathelper. It would involve extracting destination address from the RURI > for INVITE, and from upper Via for 200 OK. > Well I have a question: if I extract the dest address from RURI, this may not be a numerical adress. Is the new RTPPROXY able to handle that? Ex : Lrsip.external.comzegeryerzeyyr remote_ip 19874 fzepitzejnt lsdknglkt > Regards, > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.rtpproxy.org/pipermail/devel/attachments/20090811/66b63e43/attachment.htm From emmanuel.buu at ives.fr Tue Aug 11 13:16:38 2009 From: emmanuel.buu at ives.fr (Emmanuel BUU) Date: Tue, 11 Aug 2009 22:16:38 +0200 Subject: [RTPproxy Devel] Automatic bridging for RTP proxy and advertised address for external NAT In-Reply-To: <4A8109D6.5090102@sippysoft.com> References: <4A72BFD9.50305@ives.fr> <4A736AD5.5090907@sippysoft.com> <4A7371F7.7010200@ives.fr> <4A7FD8D1.5060105@sippysoft.com> <4A8010BA.8050304@ives.fr> <4A8109D6.5090102@sippysoft.com> Message-ID: <4A81D1A6.9040006@ives.fr> Maxim Sobolev a ?crit : > Emmanuel BUU wrote: > >> Maxim Sobolev a ?crit : >> >>> Emmanuel BUU wrote: >>> >>>> Hum great, maybe I can help with the NATHELPER module of OpenSIPS if you >>>> describe me what change have been made to the RTP proxy control protocol >>>> and provide me access to the source code. >>>> >>>> >>> Yes, it should be possible. I will see what I can do in the next few days. >>> > > Emmanuel, > > The change is in CVS now, you are expected to provide either binding > address for media or expected remote media address for automatic local > address determination: > > > > > > Internally feature is implemented as an extension to the U/L command. > > option "l" should be used for local addresses, or option "r" for > remote, > > with IPv6 address enclosed into square brackets. For example: > > > > Ul[abcd:efgh:0:1] callid remote_ip remote_port fromtag > > > > Lr1.2.3.4 callid remote_ip remote_port fromtag totag > > > > Changes to OpenSIPS, Kamalio/SER and Sippy B2BUA are to follow. > > Please let me know if you want to go ahead and make a patch for the > nathelper. It would involve extracting destination address from the RURI > for INVITE, and from upper Via for 200 OK. > Well I have a question: if I extract the dest address from RURI, this may not be a numerical adress. Is the new RTPPROXY able to handle that? Ex : Lrsip.external.com zegeryerzeyyr remote_ip 19874 fzepitzejnt lsdknglkt > Regards, > From sobomax at sippysoft.com Sat Aug 15 15:07:46 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Sun, 16 Aug 2009 00:07:46 +0200 (CEST) Subject: [RTPproxy Devel] CVS:commitlog: rtpproxy rtpp_command.c Message-ID: <20090815220746.8CDA918D097@mail.berlios.de> sobomax 2009/08/16 00:07:45 CEST SER CVS Repository Modified files: . rtpp_command.c Log: Properly advertize automatic bridging capability. Revision Changes Path 1.30 +2 -1 rtpproxy/rtpp_command.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_command.c.diff?r1=1.29&r2=1.30 From sobomax at sippysoft.com Sat Aug 15 15:19:29 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Sun, 16 Aug 2009 00:19:29 +0200 (CEST) Subject: [RTPproxy Devel] CVS:commitlog: rtpproxy rtpp_network.c Message-ID: <20090815221929.9801F18B6B4@mail.berlios.de> sobomax 2009/08/16 00:19:29 CEST SER CVS Repository Modified files: . rtpp_network.c Log: Use isxdigit(3) instead of ishexnumber(3). The former belongs to C90 standard, while the latter does not. Submitted by: Greger Viken Teigre Revision Changes Path 1.17 +2 -2 rtpproxy/rtpp_network.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_network.c.diff?r1=1.16&r2=1.17 From sobomax at sippysoft.com Sat Aug 15 16:32:09 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Sun, 16 Aug 2009 01:32:09 +0200 (CEST) Subject: [RTPproxy Devel] CVS:commitlog: rtpproxy/debian rtpproxy.init Message-ID: <20090815233209.0AE00E3389@mail.berlios.de> sobomax 2009/08/16 01:32:09 CEST SER CVS Repository Modified files: debian rtpproxy.init Log: Don't use "basename $0", since init.d subsystem starts RTPproxy using symbolic link, whose name K20rtpproxy, S20rtpproxy and so on. Submitted by: Inaki Baz Castillo Revision Changes Path 1.4 +1 -2 rtpproxy/debian/rtpproxy.init http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/debian/rtpproxy.init.diff?r1=1.3&r2=1.4 From gregert at teigre.com Sun Aug 16 02:55:05 2009 From: gregert at teigre.com (Greger Viken Teigre) Date: Sun, 16 Aug 2009 11:55:05 +0200 Subject: [RTPproxy Devel] [sr-dev] CVS:commitlog: rtpproxy rtpp_network.c In-Reply-To: <20090815221929.9801F18B6B4@mail.berlios.de> References: <20090815221929.9801F18B6B4@mail.berlios.de> Message-ID: <4A87D779.1070801@teigre.com> Thanks, Maxim! That was quick :-D g-) Maxim Sobolev wrote: > sobomax 2009/08/16 00:19:29 CEST > > SER CVS Repository > > Modified files: > . rtpp_network.c > Log: > Use isxdigit(3) instead of ishexnumber(3). The former belongs to C90 > standard, while the latter does not. > > Submitted by: Greger Viken Teigre > > Revision Changes Path > 1.17 +2 -2 rtpproxy/rtpp_network.c > http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_network.c.diff?r1=1.16&r2=1.17 > > _______________________________________________ > sr-dev mailing list > sr-dev at lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > From sobomax at sippysoft.com Sun Aug 16 22:04:24 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Sun, 16 Aug 2009 22:04:24 -0700 Subject: [RTPproxy Devel] [ANNOUNCE] IPv6 support in B2BUA / RTPproxy Message-ID: <4A88E4D8.4040105@sippysoft.com> Hi, This is a quick note to announce IPv6 support availability in the B2BUA and extended IPv6 support in the RTPproxy. Basically, now it's possible to use B2BUA + RTPproxy combo as a generic automatic IPv4 to IPv6 and vice-versa SIP SBC. For example, the following command will accept all incoming traffic on either IPv6 or IPv4 and forward it to 0022@[fec0::2]:5061 doing automatic gatewaying of media: $ ./b2bua_radius.py -f -u -s '0022@[fec0::2]:5061' -A 0 -r /var/run/rtpproxy.sock If no RTPproxy has been specified, only signaling will be gatwayed, SDP will pass intact. The feature is available in trunk version of both B2BUA and RTPproxy. It is still beta-quality code, so use with caution. Regards, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com MSN: sales at sippysoft.com Skype: SippySoft From emmanuel.buu at ives.fr Wed Aug 19 15:36:57 2009 From: emmanuel.buu at ives.fr (Emmanuel BUU) Date: Thu, 20 Aug 2009 00:36:57 +0200 Subject: [RTPproxy Devel] Strange compilation issue on Fedora Core 9 64 bits Message-ID: <4A8C7E89.3000100@ives.fr> Hello everybody, I stumbled upon a strange issue: When I configure / compile rtpproxy and generate an RPM package, it uses -O2 optimisation flag during compilation. This is normal. However, when I run rtppproxy and try to open a session, it fails in create_twin_listener(). In fact everytime bind is called it fails with errno = EADDRINUSE. I added some traces inside the function and cannot see any issue with the IP address or the port. If I remove -02, it works. Any idea? Platform is fedora core 9 64 bits. Emmanuel BUU IV?S