[OpenSIPS-Devel] New OpenXCAP release 2.2.0
Changelog openxcap (2.2.0) * Add a 30 second timeout to avoid keeping TCP lingering connections * Removed deprecated port setting * Raise open file descriptor limit on start * Lower HTTP input timeout to 30 seconds * Dropped Python 2.7 support To upgrade or install see http://openxcap.org -- Adrian ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Changes to stop keepalives on unregisters (#366)
On 25 Nov 2014, at 08:04, David Sanders notificati...@github.com wrote: @saghul, fair points. This problem is known, but it never seemed worth fixing because it would involve keeping track of the registered AoR for NAT_Contact. It was worth fixing for us, hence this fix which worked for our needs. It would seem that the multiple accounts from the same IP and port would be more of a corner case than the main use case. Well, your corner case may be other's main usage scenario. My main usage is multiple accounts on the same client and I will not be reachable at any of them by using the current patch. We have users on sip2sip.info using several accounts registered at the same time from the same end-point as a normal use case. The patch should improve things and fix also your problem but without sacrificing existing functionality that you don't care much about, others do. Adrian In ensuring the multiple accounts case works you're sacrificing the main use case. Without this change keepalives just continue for user agents that unregister after registering for a long period. In a production environment with ~70,000 user agents registering and unregistering constantly this was basically unacceptable behavior due to the continued keepalives. At the least there should probably be a high-visibility note in the documentation for the module that explains that keepalives will continue to a user agent after unregister. — 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 -- Adrian ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] Devel Digest, Vol 72, Issue 27
Sounds like a generic tunnelling technique that has little to do with SIP or media. Why can’t you just use OpenVPN or similar ? Adrian On 25 Jun 2014, at 08:28, kaushik parmar androidj...@gmail.com wrote: Hi, I am encrypting SIP and RTP message before sending it from sip mobile dialer and it sends UDP packet over network. So no one can know about the type (SIP or RTP) of packet until we decrypt it. This is for secured call and also solution for voip blocked countries. I want to know which file or module is used in opensips to get and send udp packets? when opensips receives message , i will decrypt it and before send response to mobile dialer , i will encrypt the message. Same for rtpproxy server. On Wed, Jun 25, 2014 at 2:41 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi Kaushik, So the while SIP package is encrypted . It is not easy to add hooks before the SIP stack (between transport layer and SIP stack), but can be done - could you provide more details how the encryption / decryption works, if over UDP or TCP, etc ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 25.06.2014 09:26, kaushik parmar wrote: Hi Adrian, It is not OTR. Actually we have own algorithm for encryption and decryption of sip and rtp packets. We implemented it in our SIP mobile dialer. Now we need to implement it on proxy server. I want to add encryption and decryption code in opensips (and rtpproxy) so opensips (rtpproxy) can come to know that it is SIP and rtp packets. Can you please tell me where should i add this code in opensips? I am searching for file where opensips getting sip messages and from where it sends/forward sip messages. On Tue, Jun 24, 2014 at 3:30 PM, devel-requ...@lists.opensips.org wrote: Send Devel mailing list submissions to devel@lists.opensips.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.opensips.org/cgi-bin/mailman/listinfo/devel or, via email, send a message with subject or body 'help' to devel-requ...@lists.opensips.org You can reach the person managing the list at devel-ow...@lists.opensips.org When replying, please edit your Subject line so it is more specific than Re: Contents of Devel digest... Today's Topics: 1. Re: [OpenSIPS-Users] Encrypt and Decrypt sip signals (a...@ag-projects.com) -- Message: 1 Date: Mon, 23 Jun 2014 16:11:46 -0300 From: a...@ag-projects.com Subject: Re: [OpenSIPS-Devel] [OpenSIPS-Users] Encrypt and Decrypt sip signals To: OpenSIPS users mailling list us...@lists.opensips.org Cc: OpenSIPS devel mailling list devel@lists.opensips.org Message-ID: 2ea9531b-f5b8-42ef-b513-395b6a493...@ag-projects.com Content-Type: text/plain; charset=us-ascii Perhaps is using OTR? In this case the encryption is end-to-end and cannot be handled by an intermediary as it defies the purpose. Adrian On 23 Jun 2014, at 04:24, Olle E. Johansson o...@edvina.net wrote: On 23 Jun 2014, at 09:12, kaushik parmar androidj...@gmail.com wrote: Hello All, My Android mobile SIP Dialer is sending Encrypted SIP messages Is it actually using S/MIME to decrypt on a per-message basis or do you mean it's using TLS as a transport? /O and i want to decrypt that SIP message on opensips proxy server. Opensips server will Decrypt the sip request and forward it to my voip server. Same way it will take sip request of voip switch , Encrypt it and send Encrypted SIP request to Android mobile Application. Can anyone tell me where should i write Encryption and Decryption code in opensips? Is there any particular file in which i can write my encryption code? -- Kind regards, Kaushik Parmar ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- next part -- An HTML attachment was scrubbed... URL: http://lists.opensips.org/pipermail/devel/attachments/20140623/813151c3/attachment.html -- ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel End of Devel Digest, Vol 72, Issue 27 * -- Kind regards, Kaushik Parmar ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel -- Kind regards, Kaushik Parmar ___ Devel mailing list
Re: [OpenSIPS-Devel] [OpenSIPS-Users] Encrypt and Decrypt sip signals
Perhaps is using OTR? In this case the encryption is end-to-end and cannot be handled by an intermediary as it defies the purpose. Adrian On 23 Jun 2014, at 04:24, Olle E. Johansson o...@edvina.net wrote: On 23 Jun 2014, at 09:12, kaushik parmar androidj...@gmail.com wrote: Hello All, My Android mobile SIP Dialer is sending Encrypted SIP messages Is it actually using S/MIME to decrypt on a per-message basis or do you mean it's using TLS as a transport? /O and i want to decrypt that SIP message on opensips proxy server. Opensips server will Decrypt the sip request and forward it to my voip server. Same way it will take sip request of voip switch , Encrypt it and send Encrypted SIP request to Android mobile Application. Can anyone tell me where should i write Encryption and Decryption code in opensips? Is there any particular file in which i can write my encryption code? -- Kind regards, Kaushik Parmar ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] Fwd: RTPproxy project
I think #webrtc is all the rage for all the good or wrong reasons :-) Is indeed the wrong expectation that a sip server would need to handle this natively but people ask about this and other solutions are there to fill up the gap. Adrian On 17 Jun 2014, at 13:17, Bogdan-Andrei Iancu bog...@opensips.org wrote: Adrian, We tried all the time to guide the opensips development (as project) based on the community needs - basically you add features on demand/usage - you mentioned you felt like left behind feature-wise - could you mention the features you are missing (especially that you are a foundation member, and we should provide guidance for the project). I'm all ears :). It is more or less what I'm doing (as user) with the rtpproxy project - I have the need for some missing features and I'm asking about the future plan. Of course, there must be an understanding that different people doing different things may have different needs - this is the beauty of an Open Source project - different people, different needs, all combined into a unitary effort. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 13.06.2014 20:55, a...@ag-projects.com wrote: Guys, All these softwares are mature with many years in service both for the media relays and the SIP part. They deal find with most of the expected failures, which is what the customers expect. For the un-expected failures, well the sky if the limit for optimising with infinite cost/benefit ratio. I personally did not hear my customers asking for any more resilience or scalability for the media relay component, so I stopped optimising long time ago. A better question is where would OpenSIPS project go next, beyond optimisations, as the outside world does not stay still and the perception of some of my customers is that we are being left behind feature-wise. Adrian On 13 Jun 2014, at 14:18, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hi Maxim, It is good to know about the rtp_cluster, but aside simplifying things, it does not bring any new functionality - the LB and failover between RTPproxy nodes can be done now in OpenSIPS module . The most challenging thing we are looking at is the ability to move calls between different instances of RTPP (for HA purposes)..or some restart persistence for the sessions - without something like that it's very hard to deal with SW/HW failures ; there are ways to go around for scheduled stops/restarts (maintenance), but non for unexpected failures. Thanks and Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 13.06.2014 00:36, Maxim Sobolev wrote: Brett, on the HA/carrier-grade side there is little-advertized middle-layer component called rtp_cluster, which in essence is load-balancing, transparent dispatcher that can be inserted in between some call-controlling component like OpenSIPS or Sippy B2BUA and bunch of RTPP instances running on the same or multiple nodes. From the point of view of that OpenSIPS it's just another RTPP instance. And it handles all logic necessary to load-balance incoming requests between online instances plus it can handle dynamic re-confiduration of the cluster and track individual nodes going up and down. The code is pretty usable, we have it deployed for several customers and it's being actively developed as well. We have it working reliably controlling up to 30-40 RTPP instances scattered over at least 5 nodes. http://sourceforge.net/p/sippy/sippy/ci/master/tree/rtp_cluster/ We have at least one pretty well known service provider whose name starts with capital V using it in combination with OpenSIPS to load balance RTP traffic via bunch of Amazon EC2 instances. On Tue, May 27, 2014 at 6:52 AM, Brett Nemeroff br...@nemeroff.com wrote: Just wanted to add my 0.02 here.. I totally agree with Bogdan. For the applications where opensips + a RTP relay make sense, HA and persistence are much more important. WebRTC and ICE are kinda applications in of themselves. And although these applications are going to grow in popularity, the legacy needs for an RTP relay are still massively prevalent in the space. A general push towards Carrier Grade, resiliency and redundancy I think is much better for the project as a whole. Not only that, consider that applications requiring ICE or WebRTC will greatly benefit from HA / persistence, but not so much the other way around :) YMMV -Brett On Sun, May 25, 2014 at 6:30 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hello, As always, the truth is in the middle. I agree RTPP is behind on certain things (and this is why we want to do them), but on the other hand it is a good platform with other good features (missing on the other relays). RTPP has better ability in individually
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-Users] Fwd: RTPproxy project
Well, the way we implemented ‘persistence’ was by applying a different thinking. The goal is to allow live software updates without disrupting traffic. With MediaProxy one can shutdown gracefully a relay by allowing it to carry on finishing existing calls and then shutdown while the traffic is handled by other relays. This way one can upgrade the software on a relay farm without dropping a single call. Adrian On 28 May 2014, at 03:04, Bogdan-Andrei Iancu bog...@opensips.org wrote: Saul, the carrier grade features are mainly referring to HA and persistenceacross restarts. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 27.05.2014 23:07, Saúl Ibarra Corretgé wrote: On May 27, 2014, at 4:29 PM, Bogdan-Andrei Iancu wrote: Brett, you put the finger on the wound :) I looked around to other alternatives (to avoid re-inventing the wheel) - like mediaproxy or rtpengine - and I saw no carrier-grade features in the there - please correct me if I'm wrong. I'm looking to see if the problem is correctly identified and if there is a large consent in the community about this need. As we would like to through some resources into this (hopefully other parties too), as ideally we should be going in the right direction :) What carrier grade features are those? -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ 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-Users] Fwd: RTPproxy project
Regarding high availability. I admit that in ten years of deployments I have never heard a single customer asking for this. They were rather asking for having multiple relays in multiple data centers because losing one IP was in most cases associated with complete connectivity failure to that data centre and a single IP failover was something that even if possible the costs far exceeded the benefits. A single IP address going down out of a larger connectivity issue context is such a rare occurrence, practically I don’t remember ever hearing a customer complaining about such a thing. In my opinion addressing new features like what rtp engine solves with regards to interoperability in more real time scenarios is a smarter investment rather than optimising in places were the benefits can be hardly measurable. Not to mention that the term carrier-grade” like its predecessor five times 9 availability is slowly exiting the vocabulary and is being replaced with webRTC ready and other newer concepts. My two cents Adrian On 28 May 2014, at 09:35, a...@ag-projects.com wrote: Well, the way we implemented ‘persistence’ was by applying a different thinking. The goal is to allow live software updates without disrupting traffic. With MediaProxy one can shutdown gracefully a relay by allowing it to carry on finishing existing calls and then shutdown while the traffic is handled by other relays. This way one can upgrade the software on a relay farm without dropping a single call. Adrian On 28 May 2014, at 03:04, Bogdan-Andrei Iancu bog...@opensips.org wrote: Saul, the carrier grade features are mainly referring to HA and persistenceacross restarts. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 27.05.2014 23:07, Saúl Ibarra Corretgé wrote: On May 27, 2014, at 4:29 PM, Bogdan-Andrei Iancu wrote: Brett, you put the finger on the wound :) I looked around to other alternatives (to avoid re-inventing the wheel) - like mediaproxy or rtpengine - and I saw no carrier-grade features in the there - please correct me if I'm wrong. I'm looking to see if the problem is correctly identified and if there is a large consent in the community about this need. As we would like to through some resources into this (hopefully other parties too), as ideally we should be going in the right direction :) What carrier grade features are those? -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ 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 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] Fwd: RTPproxy project
Not me. But most of the people are buying these in flocks! On 28 May 2014, at 13:26, Bogdan-Andrei Iancu bog...@opensips.org wrote: Would you buy a Iphone 6 ready car over a NCAP - proven car ? :) Thanks and regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 28.05.2014 17:40, a...@ag-projects.com wrote: Not to mention that the term carrier-grade” like its predecessor five times 9 availability is slowly exiting the vocabulary and is being replaced with webRTC ready and other newer concepts. ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] New MediaProxy version 2.6.1 released
Hello, There is a new MediaProxy release with fixes related to ICE support. For change log see http://mediaproxy.ag-projects.com/news/161 Regards, Adrian ___ 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)
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)
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)
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
