From sobomax at sippysoft.com Mon Jun 1 01:31:03 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Mon, 1 Jun 2009 10:31:03 +0200 (CEST) Subject: [RTPproxy Devel] CVS:commitlog: rtpproxy/debian rtpproxy.init Message-ID: <20090601083103.B94F429600@mail.berlios.de> sobomax 2009/06/01 10:31:03 CEST SER CVS Repository Modified files: debian rtpproxy.init Log: Make Debian init script LSB compliant. Submitted by: Inaki Baz Castillo Revision Changes Path 1.3 +4 -4 rtpproxy/debian/rtpproxy.init http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/debian/rtpproxy.init.diff?r1=1.2&r2=1.3 From sobomax at sippysoft.com Mon Jun 1 01:31:26 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Mon, 01 Jun 2009 01:31:26 -0700 Subject: [RTPproxy Devel] [patch] Debian init script LSB compliant In-Reply-To: <200905312007.01532.ibc@aliax.net> References: <200905312007.01532.ibc@aliax.net> Message-ID: <4A2391DE.60106@sippysoft.com> Done, please check. 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 ibc at aliax.net Mon Jun 1 01:40:16 2009 From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=) Date: Mon, 1 Jun 2009 10:40:16 +0200 Subject: [RTPproxy Devel] [patch] Debian init script LSB compliant In-Reply-To: <4A2391DE.60106@sippysoft.com> References: <200905312007.01532.ibc@aliax.net> <4A2391DE.60106@sippysoft.com> Message-ID: 2009/6/1 Maxim Sobolev : > Done, please check. Yes, I was already running RtpProxy with the patched version of the Debian init script and it works well (and it's LSB compliant). Thanks. -- I?aki Baz Castillo From ibc at aliax.net Mon Jun 1 13:11:19 2009 From: ibc at aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=) Date: Mon, 1 Jun 2009 22:11:19 +0200 Subject: [RTPproxy Devel] [sr-dev] [RtpProxy] Add log facility feature In-Reply-To: References: <200905291752.19189.ibc@aliax.net> <4A237B10.6050309@sippysoft.com> Message-ID: <200906012211.19780.ibc@aliax.net> El Lunes, 1 de Junio de 2009, I?aki Baz Castillo escribi?: > 2009/6/1 Maxim Sobolev : > >> Unfortunatelly I can't get it working. I run rtpproxy with "-d > >> INFO:LOG_LOCAL6" and configure syslog-ng to log local6 facility into > >> /var/log/rtpproxy (exactly the *same* I do with kamailio and local7 > >> working perfectly). > >> But /var/log/rtpproxy is not generated when restarting rtpproxy and it > >> remains logging into syslog, messages and daemon files. > >> > >> Does it work for you? > > > > OK, it looks like I made a mistake. I've checked in a fix few minutes > > ago, please do cvs update, rebuild and try again. > > It works now, thanks :) It's really really strange, but while I've got it working perfectly in a Debian Etch 64 bits using syslog-ng, I can't get it working in a Debian Etch 32 bits, also with syslog-ng. Exactly the *same* configuration. rtpproxy remains logging in default facility. I insist on it: exactly the same configuration (in syslog-ng.conf, in /etc/default/rtpproxy). I've also tested that the sources are updates (make clean, make, make install...). Any idea? Thanks. -- I?aki Baz Castillo From ibc at aliax.net Tue Jun 2 04:30:52 2009 From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=) Date: Tue, 2 Jun 2009 13:30:52 +0200 Subject: [RTPproxy Devel] [sr-dev] [RtpProxy] Add log facility feature In-Reply-To: <200906012211.19780.ibc@aliax.net> References: <200905291752.19189.ibc@aliax.net> <4A237B10.6050309@sippysoft.com> <200906012211.19780.ibc@aliax.net> Message-ID: 2009/6/1 I?aki Baz Castillo : > It's really really strange, but while I've got it working perfectly in a > Debian Etch 64 bits using syslog-ng, I can't get it working in a Debian Etch > 32 bits, also with syslog-ng. > Exactly the *same* configuration. rtpproxy remains logging in default > facility. I insist on it: exactly the same configuration (in syslog-ng.conf, > in /etc/default/rtpproxy). I've also tested that the sources are updates (make > clean, make, make install...). For sure I've running the latest CVS version in this 32 bits Debian Etch, since dissabling TOS modification (-t -1) is working :) -- I?aki Baz Castillo From ibc at aliax.net Fri Jun 5 04:25:08 2009 From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=) Date: Fri, 5 Jun 2009 13:25:08 +0200 Subject: [RTPproxy Devel] passed 80% threshold on the open file descriptors limit (1024) Message-ID: Hi, Kamailio handling no more than 150 concurrent calls. Two days ago I got this warning in RtpProxy log: WARN:handle_command: passed 80% threshold on the open file descriptors limit (1024), consider increasing the limit using -L command line option How is it possible with just 150 calls at the same time? What is -L command line option? Thanks. -- I?aki Baz Castillo From ibc at aliax.net Fri Jun 5 04:53:15 2009 From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=) Date: Fri, 5 Jun 2009 13:53:15 +0200 Subject: [RTPproxy Devel] passed 80% threshold on the open file descriptors limit (1024) In-Reply-To: References: Message-ID: 2009/6/5 I?aki Baz Castillo : > Hi, Kamailio handling no more than 150 concurrent calls. Two days ago > I got this warning in RtpProxy log: > > ?WARN:handle_command: passed 80% threshold on the open file > descriptors limit (1024), consider increasing the limit using -L > command line option > > How is it possible with just 150 calls at the same time? > What is -L command line option? I've increased the maximum number of open files to solve the possible issue: ulimit -n 16384 but I wonder why it occurs with just 150 calls. NOTE: kamailio and rtpproxy are both running as kamailio user. -- I?aki Baz Castillo From jesusr at voztele.com Fri Jun 5 06:56:07 2009 From: jesusr at voztele.com (Jesus Rodriguez) Date: Fri, 5 Jun 2009 15:56:07 +0200 Subject: [RTPproxy Devel] passed 80% threshold on the open file descriptors limit (1024) In-Reply-To: References: Message-ID: <70345D89-2179-4E9D-9C13-DCCD5011E12A@voztele.com> Hola I?aki, > 2009/6/5 I?aki Baz Castillo : >> Hi, Kamailio handling no more than 150 concurrent calls. Two days ago >> I got this warning in RtpProxy log: >> >> WARN:handle_command: passed 80% threshold on the open file >> descriptors limit (1024), consider increasing the limit using -L >> command line option >> >> How is it possible with just 150 calls at the same time? >> What is -L command line option? > > I've increased the maximum number of open files to solve the > possible issue: > ulimit -n 16384 > > but I wonder why it occurs with just 150 calls. > > NOTE: kamailio and rtpproxy are both running as kamailio user. Every call needs 5 file descriptors (or 4 if no rtcp) so 150 calls use between 600 and 700 file descriptors. Saludos JesusR. ------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr at voztele.com http://www.voztele.com Tel. 902360305 ------------------------------------- From ibc at aliax.net Fri Jun 5 08:21:34 2009 From: ibc at aliax.net (=?iso-8859-1?q?I=F1aki_Baz_Castillo?=) Date: Fri, 5 Jun 2009 17:21:34 +0200 Subject: [RTPproxy Devel] passed 80% threshold on the open file descriptors limit (1024) In-Reply-To: <70345D89-2179-4E9D-9C13-DCCD5011E12A@voztele.com> References: <70345D89-2179-4E9D-9C13-DCCD5011E12A@voztele.com> Message-ID: <200906051721.34886.ibc@aliax.net> El Viernes, 5 de Junio de 2009, Jesus Rodriguez escribi?: > > I've increased the maximum number of open files to solve the > > possible issue: > > ulimit -n 16384 > > > > but I wonder why it occurs with just 150 calls. > > > > NOTE: kamailio and rtpproxy are both running as kamailio user. > > Every call needs 5 file descriptors (or 4 if no rtcp) so 150 calls use > between 600 and 700 file descriptors. So: 1024 x 0,80 = 819,2 819,2 / 5 = 163,84 simultaneous calls Yes, it's really possible that RtpProxy has handled ~163 simultaneous calls, so it makes really sense :) Thanks a lot. -- I?aki Baz Castillo From rabs at dimension-virtual.com Fri Jun 5 10:00:49 2009 From: rabs at dimension-virtual.com (=?utf-8?q?Ra=C3=BAl_Alexis_Betancor_Santana?=) Date: Fri, 5 Jun 2009 18:00:49 +0100 Subject: [RTPproxy Devel] passed 80% threshold on the open file descriptors limit (1024) In-Reply-To: References: Message-ID: <200906051800.50469.rabs@dimension-virtual.com> On Friday 05 June 2009 12:53:15 I?aki Baz Castillo wrote: > 2009/6/5 I?aki Baz Castillo : > > Hi, Kamailio handling no more than 150 concurrent calls. Two days ago > > I got this warning in RtpProxy log: > > > > ?WARN:handle_command: passed 80% threshold on the open file > > descriptors limit (1024), consider increasing the limit using -L > > command line option > > > > How is it possible with just 150 calls at the same time? > > What is -L command line option? > > I've increased the maximum number of open files to solve the possible > issue: ulimit -n 16384 > > but I wonder why it occurs with just 150 calls. > > NOTE: kamailio and rtpproxy are both running as kamailio user. Maybe because FD are not closed JUST when a call ends, so you could have some FD's on "TIME_FIN" state -- Ra?l Alexis Betancor Santana Dimensi?n Virtual From jesusr at voztele.com Fri Jun 5 06:49:48 2009 From: jesusr at voztele.com (Jesus Rodriguez) Date: Fri, 5 Jun 2009 15:49:48 +0200 Subject: [RTPproxy Devel] passed 80% threshold on the open file descriptors limit (1024) In-Reply-To: References: Message-ID: Hola I?aki, > 2009/6/5 I?aki Baz Castillo : >> Hi, Kamailio handling no more than 150 concurrent calls. Two days ago >> I got this warning in RtpProxy log: >> >> WARN:handle_command: passed 80% threshold on the open file >> descriptors limit (1024), consider increasing the limit using -L >> command line option >> >> How is it possible with just 150 calls at the same time? >> What is -L command line option? > > I've increased the maximum number of open files to solve the > possible issue: > ulimit -n 16384 > > but I wonder why it occurs with just 150 calls. > > NOTE: kamailio and rtpproxy are both running as kamailio user. Every call needs 5 file descriptors (or 4 if no rtcp) so 150 calls use between 600 and 700 file descriptors for 150 calls. Saludos JesusR. ------------------------------------ Jesus Rodriguez VozTelecom Sistemas, S.L. jesusr at voztele.com http://www.voztele.com Tel. 902360305 ------------------------------------- From ibc at aliax.net Sat Jun 6 06:40:06 2009 From: ibc at aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=) Date: Sat, 6 Jun 2009 15:40:06 +0200 Subject: [RTPproxy Devel] [rtpproxy module] set_rtp_proxy_set() to allow pv as parameter Message-ID: <200906061540.06711.ibc@aliax.net> Hi, using multiple RtpProxy instancies would be more flexible if set_rtp_proxy_set() allows a pseudo-variable instead of just a fixed integer. Without this feature, it's impossible to implement real RtpProxy loadbalancing since: how to use the same RtpProxy for an in-dialog request? Let me show an example: - Let's suppose we have these rtpproxies: modparam("nathelper", "rtpproxy_sock", "1 == udp:1.1.1.1:12221") modparam("nathelper", "rtpproxy_sock", "2 == udp:2.2.2.2:12221") (note that I don't use various rtpproxies in the same set since with the, real loadbalancing it's not possible). - An INVITE arrives and we want to use a ramdom rtpproxy (set 1 or 2). Since set_rtp_proxy_set() doesn't allow pv, the only way is something as computing the from_tag or call-id and get values 0 or 1 (or 1 or 2). In the first case we invoke set_rtp_proxy_set("1") and in the second set_rtp_proxy_set("2"). - When processing the 183/200 response we should do the same (get 1 or 2 from the from_tag or call-id), or perhaps add a parameter in RR (rtpproxy_set=1) and invoke the corresponding set_rtp_proxy_set() function. - The same for every in-dialog request (re-INVITE, BYE...). I understand that this mechanims is not really scalable since adding a new rtpproxy requires modifications in the kamailio script (the ramdom function which now should return 1, 2 or 3 depending on the call-id/from_tag hash or something similar) and also adding a new "else if (XXXXX) { set_rtp_proxy_set("3") ... }" So, extending set_rtp_proxy_set() to allow pv would mitigate this issue: - When the INVITE arrives a ramdom function returns 1,2,3..., we store that value in a pv and use it into set_rtp_proxy_set(). - We also store that value in a RR param to retrieve it in replies and in- dialog requests in order to invoke the samertpproxy set. About various rtpproxy instances per set: I consider there is no solution for it. If we have: # multiple rtproxies for LB modparam("nathelper", "rtpproxy_sock", "udp:localhost:12221 udp:localhost:12222") We invoke "rtpproxy_offer" and some rtpproxy has been transparently selected, but we CANNOT know which one, so, how to reuse it in the reply and in-dialog requests?? I remember a thread about it in which the code was inspected and some "hash algorithm" resulted to take place to select the rtpproxy instance. However I remember that this algorithm is not so robust as required for a real loadbalancing system. So, in conclusion, is there any aim in improving RtpProxy module to allow real and robust load-balancing? What about multiple rtpproxy instances in the same set? is it really usable? Thanks a lot for any comment on it. -- I?aki Baz Castillo From sobomax at sippysoft.com Fri Jun 12 12:10:09 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Fri, 12 Jun 2009 21:10:09 +0200 (CEST) Subject: [RTPproxy Devel] CVS:commitlog: rtpproxy Makefile.am main.c rtp.c rtpp_defines.h rtpp_network.c rtpp_network.h rtpp_record.h rtpp_util.c rtpp_util.h Message-ID: <20090612191009.05F833755E@mail.berlios.de> sobomax 2009/06/12 21:10:08 CEST SER CVS Repository Modified files: . Makefile.am main.c rtp.c rtpp_defines.h rtpp_network.c rtpp_network.h rtpp_record.h rtpp_util.c rtpp_util.h Log: Move network-related functions into the seperate file - rtpp_network.c, copied over from rtpp_network.h. Revision Changes Path 1.15 +1 -1 rtpproxy/Makefile.am http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/Makefile.am.diff?r1=1.14&r2=1.15 1.91 +2 -1 rtpproxy/main.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/main.c.diff?r1=1.90&r2=1.91 1.10 +2 -2 rtpproxy/rtp.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtp.c.diff?r1=1.9&r2=1.10 1.26 +3 -1 rtpproxy/rtpp_defines.h http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_defines.h.diff?r1=1.25&r2=1.26 1.15 +2 -213 rtpproxy/rtpp_network.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_network.c.diff?r1=1.14&r2=1.15 1.20 +3 -43 rtpproxy/rtpp_network.h http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_network.h.diff?r1=1.19&r2=1.20 1.10 +2 -2 rtpproxy/rtpp_record.h http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_record.h.diff?r1=1.9&r2=1.10 1.15 +1 -144 rtpproxy/rtpp_util.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_util.c.diff?r1=1.14&r2=1.15 1.20 +1 -58 rtpproxy/rtpp_util.h http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_util.h.diff?r1=1.19&r2=1.20 From sobomax at sippysoft.com Fri Jun 12 12:43:28 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Fri, 12 Jun 2009 21:43:28 +0200 (CEST) Subject: [RTPproxy Devel] CVS:commitlog: rtpproxy rtpp_command.c Message-ID: <20090612194328.CA0BB181827@mail.berlios.de> sobomax 2009/06/12 21:43:28 CEST SER CVS Repository Modified files: . rtpp_command.c Log: Remove code that is not doing anything. Revision Changes Path 1.28 +1 -2 rtpproxy/rtpp_command.c http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/rtpp_command.c.diff?r1=1.27&r2=1.28 From marcoshack at gmail.com Fri Jun 12 13:21:16 2009 From: marcoshack at gmail.com (Marcos Hack) Date: Fri, 12 Jun 2009 17:21:16 -0300 Subject: [RTPproxy Devel] RTPProxy-Client API for Java Message-ID: <842e837b0906121321p4977fdadi942dce6bf04e4a6a@mail.gmail.com> Hello all, I just released the first version of what we called "RTPProxy Client API" for Java. It provides a Java library to create and control RTPProxy sessions. As described in the project site [1] this first version supports the creation (with callee's media address), update (to get the caller's media address) and delete sessions operations. Any kind of feedback is very welcome. Best regards, Marcos Hack Voice Technology [1] http://rtpproxy-client.googlecode.com/ From sobomax at sippysoft.com Fri Jun 12 14:08:56 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Fri, 12 Jun 2009 14:08:56 -0700 Subject: [RTPproxy Devel] RTPProxy-Client API for Java In-Reply-To: <842e837b0906121321p4977fdadi942dce6bf04e4a6a@mail.gmail.com> References: <842e837b0906121321p4977fdadi942dce6bf04e4a6a@mail.gmail.com> Message-ID: <4A32C3E8.6000003@sippysoft.com> Marcos Hack wrote: > Hello all, > > I just released the first version of what we called "RTPProxy Client > API" for Java. It provides a Java library to create and control > RTPProxy sessions. > > As described in the project site [1] this first version supports the > creation (with callee's media address), update (to get the caller's > media address) and delete sessions operations. > > Any kind of feedback is very welcome. > > Best regards, > > Marcos Hack > Voice Technology > > [1] http://rtpproxy-client.googlecode.com/ Great, thank you Marcos! I will put link to our web site. Sincerely, -- 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 ibc at aliax.net Sun Jun 14 10:07:02 2009 From: ibc at aliax.net (=?utf-8?q?I=C3=B1aki_Baz_Castillo?=) Date: Sun, 14 Jun 2009 19:07:02 +0200 Subject: [RTPproxy Devel] Error compiling RtpProxy Trunk Message-ID: <200906141907.03045.ibc@aliax.net> Hi, I 've upgraded my Debian Etch 64 bits to Leeny, and also updated the source of RtpProxy. Now, "make" gives this error (before the updates I could install it perfectly): [...] if gcc -DHAVE_CONFIG_H -I. -I. -I. -D_BSD_SOURCE -std=gnu99 -Wall -Wno-uninitialized -g -O2 -MT rtpp_log.o -MD -MP -MF ".deps/rtpp_log.Tpo" -c -o rtpp_log.o rtpp_log.c; \ then mv -f ".deps/rtpp_log.Tpo" ".deps/rtpp_log.Po"; else rm -f ".deps/rtpp_log.Tpo"; exit 1; fi gcc -std=gnu99 -Wall -Wno-uninitialized -g -O2 -o rtpproxy main.o rtp_server.o rtpp_record.o rtpp_util.o rtp.o rtp_resizer.o rtpp_session.o rtpp_command.o rtpp_log.o -lm main.o: In function `setbindhost': /usr/src/rtpproxy-trunk/main.c:91: undefined reference to `resolve' main.o: In function `rxmit_packets': /usr/src/rtpproxy-trunk/main.c:591: undefined reference to `addr2char' /usr/src/rtpproxy-trunk/main.c:604: undefined reference to `ishostseq' /usr/src/rtpproxy-trunk/main.c:551: undefined reference to `ishostseq' rtpp_record.o: In function `prepare_pkt_hdr_pcap': /usr/src/rtpproxy-trunk/rtpp_record.c:286: undefined reference to `rtpp_in_cksum' rtpp_record.o: In function `ropen': /usr/src/rtpproxy-trunk/rtpp_record.c:110: undefined reference to `resolve' rtpp_command.o: In function `reply_port': /usr/src/rtpproxy-trunk/rtpp_command.c:202: undefined reference to `ishostnull' /usr/src/rtpproxy-trunk/rtpp_command.c:205: undefined reference to `addr2char' rtpp_command.o: In function `handle_command': /usr/src/rtpproxy-trunk/rtpp_command.c:438: undefined reference to `addr2char_r' /usr/src/rtpproxy-trunk/rtpp_command.c:442: undefined reference to `addr2char' /usr/src/rtpproxy-trunk/rtpp_command.c:445: undefined reference to `addr2char_r' /usr/src/rtpproxy-trunk/rtpp_command.c:449: undefined reference to `addr2char' /usr/src/rtpproxy-trunk/rtpp_command.c:643: undefined reference to `resolve' /usr/src/rtpproxy-trunk/rtpp_command.c:792: undefined reference to `ishostseq' /usr/src/rtpproxy-trunk/rtpp_command.c:645: undefined reference to `ishostnull' collect2: ld returned 1 exit status make[1]: *** [rtpproxy] Error 1 make[1]: se sale del directorio `/usr/src/rtpproxy-trunk' make: *** [all] Error 2 Do I need to install some library? Thanks. -- I?aki Baz Castillo From sobomax at sippysoft.com Mon Jun 15 05:33:34 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Mon, 15 Jun 2009 14:33:34 +0200 (CEST) Subject: [RTPproxy Devel] CVS:commitlog: rtpproxy Makefile.in Message-ID: <20090615123334.DEE81135A3@mail.berlios.de> sobomax 2009/06/15 14:33:34 CEST SER CVS Repository Modified files: . Makefile.in Log: Re-gen after addition of rtpp_network.[ch]. Revision Changes Path 1.14 +4 -2 rtpproxy/Makefile.in http://cvs.berlios.de/cgi-bin/viewcvs.cgi/ser/rtpproxy/Makefile.in.diff?r1=1.13&r2=1.14 From sobomax at sippysoft.com Mon Jun 15 05:34:19 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Mon, 15 Jun 2009 05:34:19 -0700 Subject: [RTPproxy Devel] Error compiling RtpProxy Trunk In-Reply-To: <200906141907.03045.ibc@aliax.net> References: <200906141907.03045.ibc@aliax.net> Message-ID: <4A363FCB.1000803@sippysoft.com> I?aki, Sorry, I forgot to check in updated Makefile.in. Please do cvs update and try again. Thank you for reporting! I?aki Baz Castillo wrote: > Hi, I 've upgraded my Debian Etch 64 bits to Leeny, and also updated the source of RtpProxy. > > Now, "make" gives this error (before the updates I could install it perfectly): 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 ibc at aliax.net Mon Jun 15 06:09:10 2009 From: ibc at aliax.net (=?UTF-8?Q?I=C3=B1aki_Baz_Castillo?=) Date: Mon, 15 Jun 2009 15:09:10 +0200 Subject: [RTPproxy Devel] Error compiling RtpProxy Trunk In-Reply-To: <4A363FCB.1000803@sippysoft.com> References: <200906141907.03045.ibc@aliax.net> <4A363FCB.1000803@sippysoft.com> Message-ID: 2009/6/15 Maxim Sobolev : > I?aki, > > Sorry, I forgot to check in updated Makefile.in. Please do cvs update > and try again. Thank you for reporting! It works now, thanks. -- I?aki Baz Castillo From marcoshack at gmail.com Mon Jun 22 16:23:51 2009 From: marcoshack at gmail.com (Marcos Hack) Date: Mon, 22 Jun 2009 20:23:51 -0300 Subject: [RTPproxy Devel] RTPProxy-Client API for Java In-Reply-To: <4A32C3E8.6000003@sippysoft.com> References: <842e837b0906121321p4977fdadi942dce6bf04e4a6a@mail.gmail.com> <4A32C3E8.6000003@sippysoft.com> Message-ID: <842e837b0906221623q4d26ee29w6ca1f69d5e412eb0@mail.gmail.com> Hello Maxim, Suppose I have an RTPProxy session that already received RTP packets from both legs. If I issue a new 'Update' command without the IP address and Port, for example "cookie U callid 0 0 from_tag to_tag". Is RTPProxy going to "reset" the Callee address association and start to forward the packets to a new IP and port that will start to send the RTP packets? It's for a call transfer scenario when I want to change the Caller or Callee media address to the transfer destination. Thank you in advance. Marcos Hack. On Fri, Jun 12, 2009 at 6:08 PM, Maxim Sobolev wrote: > Marcos Hack wrote: >> Hello all, >> >> I just released the first version of what we called "RTPProxy Client >> API" for Java. It provides a Java library to create and control >> RTPProxy sessions. >> >> As described in the project site [1] this first version supports the >> creation (with callee's media address), update (to get the caller's >> media address) and delete sessions operations. >> >> Any kind of feedback is very welcome. >> >> Best regards, >> >> Marcos Hack >> Voice Technology >> >> [1] http://rtpproxy-client.googlecode.com/ > > Great, thank you Marcos! > > I will put link to our web site. > > Sincerely, > -- > 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 > > _______________________________________________ > Devel mailing list > Devel at rtpproxy.org > http://lists.rtpproxy.org/mailman/listinfo/devel > From sobomax at sippysoft.com Wed Jun 24 04:44:56 2009 From: sobomax at sippysoft.com (Maxim Sobolev) Date: Wed, 24 Jun 2009 04:44:56 -0700 Subject: [RTPproxy Devel] RTPProxy-Client API for Java In-Reply-To: <842e837b0906221623q4d26ee29w6ca1f69d5e412eb0@mail.gmail.com> References: <842e837b0906121321p4977fdadi942dce6bf04e4a6a@mail.gmail.com> <4A32C3E8.6000003@sippysoft.com> <842e837b0906221623q4d26ee29w6ca1f69d5e412eb0@mail.gmail.com> Message-ID: <4A4211B8.1000809@sippysoft.com> Marcos Hack wrote: > Hello Maxim, > > Suppose I have an RTPProxy session that already received RTP packets > from both legs. If I issue a new 'Update' command without the IP > address and Port, for example "cookie U callid 0 0 from_tag to_tag". No, you should always send IP/port in the U, even if they have not changed. > Is RTPProxy going to "reset" the Callee address association and start > to forward the packets to a new IP and port that will start to send > the RTP packets? There is a bit of heuristics in there. If the address historically cannot be trusted (i.e. LAN IP in the SDP) the RTPproxy will note the update, however the destination for RTP packets will not change immediately pending receiving some actual RTP packets from the new source. This is done to prevent NAT'ed address generated by the re-INVITE from distracting the session. If the address is "trustworthy", the change would happen immediately. > It's for a call transfer scenario when I want to change the Caller or > Callee media address to the transfer destination. Two approaches are possible here: 1. You can simply update RTPproxy with the new addresses. 2. You can create a whole new session in the proxy for the transferred call leg and use that session instead when doing transfer. Hopefully it helps. Don't hesitate to contact me if you have any other questions. 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 marcoshack at gmail.com Wed Jun 24 20:39:11 2009 From: marcoshack at gmail.com (Marcos Hack) Date: Thu, 25 Jun 2009 00:39:11 -0300 Subject: [RTPproxy Devel] RTPProxy-Client API for Java In-Reply-To: <4A4211B8.1000809@sippysoft.com> References: <842e837b0906121321p4977fdadi942dce6bf04e4a6a@mail.gmail.com> <4A32C3E8.6000003@sippysoft.com> <842e837b0906221623q4d26ee29w6ca1f69d5e412eb0@mail.gmail.com> <4A4211B8.1000809@sippysoft.com> Message-ID: <842e837b0906242039j43312ca9q89a43454dfbcff94@mail.gmail.com> Hi Sobolev, Thanks for your enlightening answer. On Wed, Jun 24, 2009 at 8:44 AM, Maxim Sobolev wrote: > > Two approaches are possible here: > > 1. You can simply update RTPproxy with the new addresses. > > 2. You can create a whole new session in the proxy for the transferred > call leg and use that session instead when doing transfer. > We used the second option and it works perfect. I think it's the best choice as we generally don't know the real IP address because the NAT. Best regards, Marcos Hack.