Re: [OpenSIPS-Devel] [opensips] [RFC] An initial attempt of porting rtpproxy-ng module from your twin project to OpenSIPS. (#152)
Merged #152. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#event-132209210___ 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)
Thank you all for the work invested in this new module. I uploaded it on trunk (with some bug fixes, additional renaming and updates). @rfuchs , it will be nice to have an email sent to out on the lists to introduce this module to the users - let me know if you need any assistance from me. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-46318222___ 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)
Thanks! Meanwhile there is a bunch of patches with a new functionality and bugfixes to merge. Stay tuned! --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-46319784___ 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)
What you said leads to an important question (almost to forget about it :) ) - who will be the maintainer of this module, like taking care of it, patching, etc ? We can grand GIT access to avoid going via push requests for every tiny change :) --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-46325471___ 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)
Just to clear things up, I had no part in porting this module to opensips other than the original implementation from which it is derived. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-46328088___ 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)
I guess it is reasonable that nobody expects a developer to stretch to manage his stuff across external forks. I am not maintaining MediaProxy in Kamailio project either, if there are volunteers there it is fine but if they are not, then end-users have indeed a problem with any such fork. I guess Bogdan’s questions is very legitimate, who is going to maintain this new module? Adrian On 17 Jun 2014, at 13:05, Richard Fuchs notificati...@github.com wrote: Just to clear things up, I had no part in porting this module to opensips other than the original implementation from which it is derived. — 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)
If the module is renamed to match the actual engine, I see no problem. Unfortunately we cannot add it to 1.11 as it is already beta released - only fixes accepted, no new things. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-39841419___ 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)
Peter, what do you think about renaming module? Let's add it into master. -- Nick 2014-04-08 16:26 GMT+04:00 Bogdan Andrei IANCU notificati...@github.com: If the module is renamed to match the actual engine, I see no problem. Unfortunately we cannot add it to 1.11 as it is already beta released - only fixes accepted, no new things. — Reply to this email directly or view it on GitHubhttps://github.com/OpenSIPS/opensips/pull/152#issuecomment-39841419 . --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-39849379___ 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)
@nikbyte already done - see the latest commits above ( lemenkov/opensips@a11b4091496ebd70b5eac42d3483e7d85d2c71fc ) --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-39850530___ 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)
Bogdan, about 10 days ago the mediaproxy-ng project was renamed into rtpengine. What about to add new module with this name? As for me, I'd like to use rtpengine for a long time, but I've never had a module. And I'm unhappy that we will have this module only in trunk, but not in 1.11. -- Nick 2014-02-21 19:33 GMT+04:00 Bogdan Andrei IANCU notificati...@github.com: @lemenkov https://github.com/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 GitHubhttps://github.com/OpenSIPS/opensips/pull/152#issuecomment-35740773 . ___ 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)
Speaking with my @sipwise hat on, there will be a name change of at least the mediaproxy-ng back-end part soon, to clear things up for the future. I understand the concerns of AG in regards to name clashing, and we don't like the confusion either. No plans yet for the rtpproxy-ng module name though, because as @rfuchs pointed out, it's really an evolution of the rtpproxy module, and it can be used as rtpproxy drop-in replacement when switching the back-end. Since only the module part (rtpproxy-ng) is going to be maintained by you guys (we don't use opensips, so there are no plans to support the module for opensips), you can name it however you like. However, I find it extremely offensive from this community to have a module pulled into your project, then start accusing the author and demanding an apology for the name, after he's kind enough to chime in and provide an explanation for the naming clashes. The media proxy is available as open source on github since nearly two years, and I would have expected some feedback from AG if there were concerns about the name over this period (it's not that the guys at AG don't know who we are and what we do). --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-36845295___ 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 Andreas, Not sure if you are referring to me but in case you do. I am not demanding any apology. Personally, I have no issue with the name you have chosen. If you knowingly chose that name mediaproxy-ng which I was using since 2008 and expected me to complain about it, is really weird. I am not polling github every day just in case something like this happens. The issue emerged now, in the context of OpenSIPS project where we have an obvious overlap of naming and purpose at the same time. As I mentioned, your software is a great addition and we just asked to eliminate any confusion by renaming it. If you can help with the name change is great, if not then so be it, I don’t really care about your choices and I don’t need any apologies from you or anybody else. Adrian On 06 Mar 2014, at 09:07, Andreas Granig notificati...@github.com wrote: Speaking with my @sipwise hat on, there will be a name change of at least the mediaproxy-ng back-end part soon, to clear things up for the future. I understand the concerns of AG in regards to name clashing, and we don't like the confusion either. No plans yet for the rtpproxy-ng module name though, because as @rfuchs pointed out, it's really an evolution of the rtpproxy module, and it can be used as rtpproxy drop-in replacement when switching the back-end. Since only the module part (rtpproxy-ng) is going to be maintained by you guys (we don't use opensips, so there are no plans to support the module for opensips), you can name it however you like. However, I find it extremely offensive from this community to have a module pulled into your project, then start accusing the author and demanding an apology for the name, after he's kind enough to chime in and provide an explanation for the naming clashes. The media proxy is available as open source on github since nearly two years, and I would have expected some feedback from AG if there were concerns about the name over this period (it's not that the guys at AG don't know who we are and what we do). — 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)
Adrian, you were are asking @rfuchs to admit his mistake in naming the project and you proposed a draft in his name on how he should have approached the opensips project properly. This is ridiculous, as the ongoing efforts to bring all this to opensips (where it seems to cause the confusion) is in no way initiated or driven by the authors (although I really appreciate the efforts of @lemenkov and his contributions to our project, thanks for that!), and Richard made that perfectly clear. On a side note, the history of the name mediaproxy-ng dates back to May 2007 when the rewrite was done, it got open sourced under that same name in 2010, and the repo was made public in 2012. No bad intentions here, and it obviously wasn't a problem until Peter tried to bring it to opensips. If you guys find it useful, please go ahead and use it (there are really cool features coming up over the next months), but you have to handle the naming and everything else around it by yourselves. Renaming the back-end is a good thing to do to make it more distinguishable, so we're going to do that. Everything else is up to you guys. And that's it from our side. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-36877427___ 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)
Even if this new protocol (rtpproxy-ng) is based on the original rtpproxy protocol, naming it as rtpproxy-ng seems a bad idea IMHO as it will generate unavoidable confusion. The fact that the Sippy RTP relayer is named RtpProxy (same name as the protocol) does not help, and things become worse given that there is a protocol (and proxy module) called x-ng which connects to a media relayer called y-ng (where x != y, and y is already used by other protocol, module and server, this is: mediaproxy). I strongly suggest choosing a new name for the protocol (eg. SMCP - Sipwise Media Control Protocol, or whatever), rename the SIP proxy module with that name, and then rename the current mediaproxy-ng server with any name (may not include the SMCP keyword), eg. SipWise Media Relayer. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-36883844___ 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)
Call it fuchs-relay, sipwise-relay or anything else but rtpproxy and mediaproxy as they have nothing to do with any of them. Adrian Pe 22.02.2014, la 12:13, Richard Fuchs notificati...@github.com a scris: Correct, the protocol is different and incompatible, but heavily based on the original rtpproxy protocol in terms of functionality. The protocol offers all the same flags that the original rtpproxy protocol supported, just transported in a different way to allow it to be extended freely. Also, at least in the original rtpproxy-ng module, the function interface is completely identical to the rtpproxy module. — 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)
As for me I really dislike the idea of renaming this module. This module is named after the protocol, not after the backend. Exactly the same situation with rtpproxy module - it implements a protocol, not a particular backend support. One can use rtpproxy module not only with RTPproxy from Sippy Soft but also with mediaproxy-ng or erlrtpproxy backends as well. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-35799110___ 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)
Also I really don't like the direction this discussion is going. Folks, let's just calm down for a while and focus on a technical issues. I have a plenty of patches on top of the original module to be reviewed and I'd love to hear any feedback on them :) --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-35799150___ 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 , I agree, the modules should be named after the protocol it implements. BUT, as far as I understood from @rfuchs's posts this new module has nothing to do with the classical known RTPproxy protocol (used by RTPProxy application). The new protocol is binary, json oriented, etc.. Maybe I got it wrong and if so, please correct it. But if the protocol used in this new module has nothing to do (aside origins) with the protocal used by RTPproxy relay, not even being backward compatible, IMHO, it should not carry the name of rtpproxy-xx at all. It will be confusion and damage to the users (see the arguments in @saghul's initial post ). Please let's keep this discussion strictly technical and strictly about OpenSIPS. Thank you all, Bogdan --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-35802868___ 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)
Correct, the protocol is different and incompatible, but heavily based on the original rtpproxy protocol in terms of functionality. The protocol offers all the same flags that the original rtpproxy protocol supported, just transported in a different way to allow it to be extended freely. Also, at least in the original rtpproxy-ng module, the function interface is completely identical to the rtpproxy module. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-35803475___ 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 @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] [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] [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
Re: [OpenSIPS-Devel] [opensips] [RFC] An initial attempt of porting rtpproxy-ng module from your twin project to OpenSIPS. (#152)
Hi @lemenkov - this rtpproxy_ng module..what is the difference from the existing rtpproxy module ? Thanks and regards, Bogdan --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/pull/152#issuecomment-35653788___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] [RFC] An initial attempt of porting rtpproxy-ng module from your twin project to OpenSIPS. (#152)
Hello All! I#39;ve made some preliminary work on porting rtpproxy-ng from Kamailio to OpenSIPS. Unfortunately I#39;m not certain about my patches#39; quality and love to get any possible feedback on this. Could anyone please review this and help me merging it into OpenSIPS? Also any testing will be highly appreciated. Also I#39;d like to say a big thanks to @rfuchs and his fellow developers from @sipwise for this module! You can merge this Pull Request by running: git pull https://github.com/lemenkov/opensips rtpproxy-ng Or you can view, comment on it, or merge it online at: https://github.com/OpenSIPS/opensips/pull/152 -- Commit Summary -- * rtpproxy-ng: initial checkin * rtpproxy-ng: implement $rtpstat and document start_recording() * rtpproxy-ng: implement second parameter to rtpproxy_offer/answer/manage * rtpproxy-ng: fix possible segfault in rtpproxy_manage * modules/rtpproxy-ng: Allow PV in second rtpproxy_manage parameter * rtpproxy(-ng): patch: has_sdp() does not exist * rtpproxy-ng: fix extraction of multipart SDP body * rtpproxy-ng: ids to sections in documentation * rtpproxy-ng: remove code artifact that broke IPv6 received-from addresses * rtpproxy-ng: remove trailing double \r\n from multipart SDP * Move MODULE_VERSION macro to a OpenSIPS defined location * Adjust decode_mime_type arity * Adjust get_body calling * Adjust HDR_TO_F parsing * Add header file which is necessary for sr in OpenSIPS * Remove header files missing in OpenSIPS * Backport msg_has_sdp from rtpproxy module * Proper arity for mi_export_t structure * Workaround for missing handy macro in OpenSIPS * No need to fee after fixup_spve_null, fixup_spve_spve * No such macro PVT_OTHER in OpenSIPS * Adapt get_via_branch function to OpenSIPS API * No such flag FL_SDP_BODY in OpenSIPS * Replace get_str_fparam with fixup_get_svalue available in OpenSIPS * Don#39;t use pvar caching API unavailable in OpenSIPS -- File Changes -- A modules/rtpproxy-ng/Makefile (19) A modules/rtpproxy-ng/README (652) A modules/rtpproxy-ng/bencode.c (703) A modules/rtpproxy-ng/bencode.h (530) A modules/rtpproxy-ng/doc/Makefile (4) A modules/rtpproxy-ng/doc/rtpproxy-ng.xml (103) A modules/rtpproxy-ng/doc/rtpproxy_admin.xml (823) A modules/rtpproxy-ng/doc/rtpproxy_faq.xml (79) A modules/rtpproxy-ng/rtpproxy.c (1959) A modules/rtpproxy-ng/rtpproxy.h (64) A modules/rtpproxy-ng/rtpproxy_funcs.c (434) A modules/rtpproxy-ng/rtpproxy_funcs.h (40) -- Patch Links -- https://github.com/OpenSIPS/opensips/pull/152.patch https://github.com/OpenSIPS/opensips/pull/152.diff ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
