Re: [OpenSIPS-Devel] [opensips] [RFC] An initial attempt of porting rtpproxy-ng module from your twin project to OpenSIPS. (#152)
Hello @bogdan-iancu ! First of all do NOT merge it at least during the next few monts - it's stil in a w.i.p. stage and I see some errors and suspicious warnings during operation. Also I've got few patches from your twin project to cheryr-pick. Please give me more time to polish that. This is entirely different module from rtpproxy - it uses bencoded messages instead of plain text protocol and requires a compatible media proxy application (so far there is the only one - https://github.com/sipwise/mediaproxy-ng ). --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-35714679___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Segfault on usr_avp.c (#166)
Hello Bogdan, how are you? As you asked me, thats the back trace: (gdb) bt #0 destroy_avp_list_unsafe (list=0x7f11c412f958) at usr_avp.c:436 #1 0x7f11dcace09f in free_cell (dead_cell=0x7f11c412df48) at h_table.c:183 #2 0x7f11dcace18f in free_hash_table () at h_table.c:357 #3 0x7f11dcadd60a in tm_shutdown () at t_funcs.c:99 #4 0x0049f760 in destroy_modules () at sr_module.c:371 #5 0x0042d708 in cleanup (show_status=1) at main.c:348 #6 0x0042e1cb in handle_sigs () at main.c:549 #7 0x00431e95 in main_loop (argc=value optimized out, argv=value optimized out) at main.c:1024 #8 main (argc=value optimized out, argv=value optimized out) at main.c:1557 Thanks, 2014-02-20 15:34 GMT-03:00 Bogdan Andrei IANCU notificati...@github.com: Hi Carlos, the trace is not complete - the lower frames are missing - could you post the entires set of frame (just bt, no need to bt full) ? or email it to me please. Thanks and regards, Bogdan -- Reply to this email directly or view it on GitHubhttps://github.com/OpenSIPS/opensips/issues/166#issuecomment-35653527 . -- Carlos Eduardo Wagner Tecnólogo em Telecomunicações, dCAA --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/166#issuecomment-35729920___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] [RFC] An initial attempt of porting rtpproxy-ng module from your twin project to OpenSIPS. (#152)
@lemenkov thanks for the update...I'm a but confused and puzzled. .The media engine from sipwise is called mediaproxy-ng, but has noting to do to with mediaproxy from AG-projects (not even a fork) - how comes this ??? Further more, why to name the module in OpenSIPS rtpproxy-ng, while it has nothing to do with the RTPproxy media relay ?? It is a lot of confusion and IMHO we should try to clear it up before considering any code. Regards, Bogdan --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-35740773___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] [RFC] An initial attempt of porting rtpproxy-ng module from your twin project to OpenSIPS. (#152)
As the author of mediaproxy-ng, let me try to clear up the confusion about the naming. Many moons ago, the team at Sipwise was using a privately developed, closed source RTP proxy. It was designed to be used with the Openser mediaproxy module, and as such we called our project mediaproxy, even though it was completely unrelated to the AG Projects Mediaproxy. Later on, we decided to redesign our mediaproxy from scratch and eventually make it open source. Thus, mediaproxy-ng was born. At around the same time, we decided to shift our focus away from the Openser mediaproxy module and support the control module rtpproxy instead (even though compatibility with the other module was retained). Yet again later on, consensus among developers was that the future way to go for media/RTP proxying was to employ a JSON-like control protocol that allows complete rewriting of the entire SDP body. We went ahead and implemented this into mediaproxy-ng. As a new control module was required, we took the old rtpproxy module and modified it. As the new module was (and still is) intended as a drop-in replacement for the rtpproxy module (and not the unrelated mediaproxy module), we called it rtpproxy-ng to make transitioning easier. Other people have suggested to call the new module mediaproxy-ng instead of rtpproxy-ng, which would be more logical because it was meant to be used with the mediaproxy-ng daemon, but then that would imply that this module somehow is a fork or modification of the old mediaproxy module, which it isn't. All the functions within rtpproxy-ng are taken more or less directly from rtpproxy without even renaming them, so it makes sense to retain rtpproxy in the name of the module. Also, there's no reason why rtpproxy-ng cannot be used with other RTP/media proxies if they choose to implement this new protocol. By no means is it exclusive to mediaproxy-ng. So the reasons for the naming are entirely historical. Other than the reasons given for easy transitioning from rtpproxy to rtpproxy-ng, there's no reason why the module can't be renamed to anything else. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-35743563___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] call_control: Passthrough sip_application (#170)
@@ -228,6 +232,7 @@ struct module_exports exports = {
str call_token;
char* prepaid_account;
int call_limit;
+str sip_application;
Fixed.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/170/files#r9951912___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] [RFC] An initial attempt of porting rtpproxy-ng module from your twin project to OpenSIPS. (#152)
Why don’t you simply call it sipwise-rtp-mediarelay or something similar so is beyond doubt who made it and where it fits or does not fit. Secondly mediaproxy-ng.org domain name was used by AG Projects for many years for hosting our MediaProxy software version. Regards, Adrian On 21 Feb 2014, at 13:59, Richard Fuchs notificati...@github.com wrote: As the author of mediaproxy-ng, let me try to clear up the confusion about the naming. Many moons ago, the team at Sipwise was using a privately developed, closed source RTP proxy. It was designed to be used with the Openser mediaproxy module, and as such we called our project mediaproxy, even though it was completely unrelated to the AG Projects Mediaproxy. Later on, we decided to redesign our mediaproxy from scratch and eventually make it open source. Thus, mediaproxy-ng was born. At around the same time, we decided to shift our focus away from the Openser mediaproxy module and support the control module rtpproxy instead (even though compatibility with the other module was retained). Yet again later on, consensus among developers was that the future way to go for media/RTP proxying was to employ a JSON-like control protocol that allows complete rewriting of the entire SDP body. We went ahead and implemented this into mediaproxy-ng. As a new control module was required, we took the old rtpproxy module and modified it. As the new module was (and still is) intended as a drop-in replacement for the rtpproxy module (and not the unrelated mediaproxy module), we called it rtpproxy-ng to make transitioning easier. Other people have suggested to call the new module mediaproxy-ng instead of rtpproxy-ng, which would be more logical because it was meant to be used with the mediaproxy-ng daemon, but then that would imply that this module somehow is a fork or modification of the old mediaproxy module, which it isn't. All the functions within rtpproxy-ng are taken more or less directly from rtpproxy without even renaming them, so it makes sense to retain rtpproxy in the name of the module. Also, there's no reason why rtpproxy-ng cannot be used with other RTP/media proxies if they choose to implement this new protocol. By no means is it exclusive to mediaproxy-ng. So the reasons for the naming are entirely historical. Other than the reasons given for easy transitioning from rtpproxy to rtpproxy-ng, there's no reason why the module can't be renamed to anything else. — Reply to this email directly or view it on GitHub. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] [RFC] An initial attempt of porting rtpproxy-ng module from your twin project to OpenSIPS. (#152)
Hi all, I agree with @saghul - I also prefer to avoid confusions as much as possible. Also I understand what @rfuchs explains (as history). What I'm concerned of : - in regards to the media engine - I disagree with the name of the sipwise media engine (as conflicts with something existing); but this out of my scope, something between AG and SIPWISE. - in regards to the OpenSIPS module - it cannot be rtpproxy-ng as it has nothing to do with rtpproxy engine. So, to be accepted, it must have a name which does not conflict with any other module or existing media engines. Otherwise, such new functionality is more than welcome. Regards, Bogdan --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-35763209___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] [RFC] An initial attempt of porting rtpproxy-ng module from your twin project to OpenSIPS. (#152)
Hi Richard, As you are the author then change your software name to straigthen things out. The problem is then solved elegantly, we all benefit of your addition to the project and you take all the credits! -- Adrian On 21 Feb 2014, at 16:21, Richard Fuchs notificati...@github.com wrote: I'm not disagreeing that the naming is unfortunate, and we may remedy it at some point in the future. But for the time being, it is what it is. — Reply to this email directly or view it on GitHub. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] [RFC] An initial attempt of porting rtpproxy-ng module from your twin project to OpenSIPS. (#152)
Actually it's not all that easy. Plus, I find it silly to argue about a mere name like that. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-35787429___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] [RFC] An initial attempt of porting rtpproxy-ng module from your twin project to OpenSIPS. (#152)
Hello Richard, This is not silly. Is very healthy to argue about it, now that the time has come. Here it is what you wrote: Many moons ago, the team at Sipwise was using a privately developed, closed source RTP proxy. It was designed to be used with the Openser mediaproxy module, and as such we called our project mediaproxy, even though it was completely unrelated to the AG Projects Mediaproxy. Later on, we decided to redesign our mediaproxy from scratch and eventually make it open source. Thus, mediaproxy-ng was born. At around the same time, we decided to shift our focus away from the Openser mediaproxy module and support the control module rtpproxy instead (even though compatibility with the other module was retained). Yet again later on, consensus among developers was that the future way to go for media/RTP proxying was to employ a JSON-like control protocol that allows complete rewriting of the entire SDP body. We went ahead and implemented this into mediaproxy-ng. As a new control module was required, we took the old rtpproxy module and modified it. As the new module was (and still is) intended as a drop-in replacement for the rtpproxy module (and not the unrelated mediaproxy module), we called it rtpproxy-ng to make transitioning easier. Other people have suggested to call the new module mediaproxy-ng instead of rtpproxy-ng, which would be more logical because it was meant to be used with the mediaproxy-ng daemon, but then that would imply that this module somehow is a fork or modification of the old mediaproxy module, which it isn't. All the functions within rtpproxy-ng are taken more or less directly from rtpproxy without even renaming them, so it makes sense to retain rtpproxy in the name of the module. Also, there's no reason why rtpproxy-ng cannot be used with other RTP/media proxies if they choose to implement this new protocol. By no means is it exclusive to mediaproxy-ng.“ End of quote. I am not amused to have to point to it. Building consensus around of chain of re-entrant poor choices is not an excuse for not be willing to rename your software now. Admit the mistake (it may not even be yours, things just evolved to this unfortunate state of affairs) and fix it now. How about: My name is Richard Fuchs and I made a new RTP media relay module that makes a difference, it does X, Y and Z features than no other modules of OpenSIPS do to date. I am aware that the software name was unfortunate as it collides with similar implementations but I CAN change it to fix the problem because I am the AUTHOR. I can change the software name to fuchs-relay or whatever name avoids collisions. Can it be added to the project, what do you think? And the answer would be a big Yes, this is great addition, and welcome. Instead, you are trying to justify the chain of bad name choices and claim ‘consensus’ of developers that are not involved of this project. Adrian On 21 Feb 2014, at 22:16, Richard Fuchs notificati...@github.com wrote: Actually it's not all that easy. Plus, I find it silly to argue about a mere name like that. — Reply to this email directly or view it on GitHub. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel signature.asc Description: Message signed with OpenPGP using GPGMail ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] [RFC] An initial attempt of porting rtpproxy-ng module from your twin project to OpenSIPS. (#152)
It wasn't me who asked for this module to be included in your project. I only provided an explanation of why things were named the way they are. The original rtpproxy-ng module is called rtpproxy-ng because it's based on the module named rtpproxy. For now, it happens to work only with a software called mediaproxy-ng. If you feel that this (subjectively) confusing naming is reason enough for this new protocol not to be supported by your software, then that's fine (even though you're free to give the module any name you wish). I'm not going to argue with you about that. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-35792240___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
