Fwd: RTPproxy project

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: RTPproxy project

Bogdan-Andrei Iancu-2
Going for a public exposure on this question to Maxim, maybe we will get an answer here.


-------- Original Message --------
Subject: RTPproxy project
Date: Mon, 14 Apr 2014 15:03:31 +0300
From: Bogdan-Andrei Iancu [hidden email]
To: Maxim Sobolev [hidden email]
CC: Razvan Crainea [hidden email]


Hello Maxim,

Long time, no talks, but I hope everything is fine on your side.

I'm reaching you in order to ask about your future plans in regards to 
the rtpproxy project? We see no much activity around it and other media 
relays are popping around.

RTPP is an essential component for us, we invested a lot of work, we 
have many patches (extensions) for it (which we want to push to the 
public tree, but there is no answer on this) and we are also looking for 
investing a lot into big future plans (as adding more functionalities).

Now, my question is - what is your commitment and disponibility for the 
RTPP project ? depending on that we what to re-position ourselves, as we 
do not want to waste time and work on things which are out of control.

Best regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com





_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: RTPproxy project

Muhammad Shahzad Shafi

To be honest, i have stopped using rtpproxy for over 2 years now. It is not evolving as fast as it should be, specially in the context of ICE and WebRTC technologies.

I would like to suggest that opensips team should consider adding support for rtpengine from SIPWise,

https://github.com/sipwise/rtpengine

For now mediaproxy from AG Projects is the only good choice for handling media in opensips with ICE support (though it still lacks WebRTC features).

Thank you.

 

On 2014-05-23 14:55, Bogdan-Andrei Iancu wrote:

Going for a public exposure on this question to Maxim, maybe we will get an answer here.


-------- Original Message --------
Subject: RTPproxy project
Date: Mon, 14 Apr 2014 15:03:31 +0300
From: Bogdan-Andrei Iancu
To: Maxim Sobolev
CC: Razvan Crainea


Hello Maxim,

Long time, no talks, but I hope everything is fine on your side.

I'm reaching you in order to ask about your future plans in regards to 
the rtpproxy project? We see no much activity around it and other media 
relays are popping around.

RTPP is an essential component for us, we invested a lot of work, we 
have many patches (extensions) for it (which we want to push to the 
public tree, but there is no answer on this) and we are also looking for 
investing a lot into big future plans (as adding more functionalities).

Now, my question is - what is your commitment and disponibility for the 
RTPP project ? depending on that we what to re-position ourselves, as we 
do not want to waste time and work on things which are out of control.

Best regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


-- 
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: +49 176 99 83 10 85
MSN: [hidden email]
Email: [hidden email]

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: RTPproxy project

Bogdan-Andrei Iancu-2
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 controlling the stream (audio /video), ability to set timeouts and onhold with no conflicts, ability to generates events on timeout, more flexibility in handling symmetric / asymmetric NATs, ability to do media injection (playback), ability to do call recording

What neither  mediaproxy, nor rtpengine have is a mechanism for implementing RTP failover (for ongoing calls) or restart persistence . This is something we want to look into. I would love to have ICE and WebRTC on my media relay, for the HA and persistence are more important I would say.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 24.05.2014 01:59, Muhammad Shahzad Shafi wrote:

To be honest, i have stopped using rtpproxy for over 2 years now. It is not evolving as fast as it should be, specially in the context of ICE and WebRTC technologies.

I would like to suggest that opensips team should consider adding support for rtpengine from SIPWise,

https://github.com/sipwise/rtpengine

For now mediaproxy from AG Projects is the only good choice for handling media in opensips with ICE support (though it still lacks WebRTC features).

Thank you.

 

On 2014-05-23 14:55, Bogdan-Andrei Iancu wrote:

Going for a public exposure on this question to Maxim, maybe we will get an answer here.


-------- Original Message --------
Subject: RTPproxy project
Date: Mon, 14 Apr 2014 15:03:31 +0300
From: Bogdan-Andrei Iancu
To: Maxim Sobolev
CC: Razvan Crainea


Hello Maxim,

Long time, no talks, but I hope everything is fine on your side.

I'm reaching you in order to ask about your future plans in regards to 
the rtpproxy project? We see no much activity around it and other media 
relays are popping around.

RTPP is an essential component for us, we invested a lot of work, we 
have many patches (extensions) for it (which we want to push to the 
public tree, but there is no answer on this) and we are also looking for 
investing a lot into big future plans (as adding more functionalities).

Now, my question is - what is your commitment and disponibility for the 
RTPP project ? depending on that we what to re-position ourselves, as we 
do not want to waste time and work on things which are out of control.

Best regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


-- 
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: +49 176 99 83 10 85
MSN: [hidden email]
Email: [hidden email]


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: RTPproxy project

Brett Nemeroff
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 <[hidden email]> 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 controlling the stream (audio /video), ability to set timeouts and onhold with no conflicts, ability to generates events on timeout, more flexibility in handling symmetric / asymmetric NATs, ability to do media injection (playback), ability to do call recording

What neither  mediaproxy, nor rtpengine have is a mechanism for implementing RTP failover (for ongoing calls) or restart persistence . This is something we want to look into. I would love to have ICE and WebRTC on my media relay, for the HA and persistence are more important I would say.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On <a href="tel:24.05.2014%2001" value="+12405201401" target="_blank">24.05.2014 01:59, Muhammad Shahzad Shafi wrote:

To be honest, i have stopped using rtpproxy for over 2 years now. It is not evolving as fast as it should be, specially in the context of ICE and WebRTC technologies.

I would like to suggest that opensips team should consider adding support for rtpengine from SIPWise,

https://github.com/sipwise/rtpengine

For now mediaproxy from AG Projects is the only good choice for handling media in opensips with ICE support (though it still lacks WebRTC features).

Thank you.

 

On 2014-05-23 14:55, Bogdan-Andrei Iancu wrote:

Going for a public exposure on this question to Maxim, maybe we will get an answer here.


-------- Original Message --------
Subject: RTPproxy project
Date: Mon, 14 Apr 2014 15:03:31 +0300
From: Bogdan-Andrei Iancu
To: Maxim Sobolev
CC: Razvan Crainea


Hello Maxim,

Long time, no talks, but I hope everything is fine on your side.

I'm reaching you in order to ask about your future plans in regards to 
the rtpproxy project? We see no much activity around it and other media 
relays are popping around.

RTPP is an essential component for us, we invested a lot of work, we 
have many patches (extensions) for it (which we want to push to the 
public tree, but there is no answer on this) and we are also looking for 
investing a lot into big future plans (as adding more functionalities).

Now, my question is - what is your commitment and disponibility for the 
RTPP project ? depending on that we what to re-position ourselves, as we 
do not want to waste time and work on things which are out of control.

Best regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


-- 
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: <a href="tel:%2B49%20176%2099%2083%2010%2085" value="+4917699831085" target="_blank">+49 176 99 83 10 85
MSN: [hidden email]
Email: [hidden email]


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: RTPproxy project

Bogdan-Andrei Iancu-2
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 :)

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 27.05.2014 16:52, Brett Nemeroff 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 <[hidden email]> 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 controlling the stream (audio /video), ability to set timeouts and onhold with no conflicts, ability to generates events on timeout, more flexibility in handling symmetric / asymmetric NATs, ability to do media injection (playback), ability to do call recording

What neither  mediaproxy, nor rtpengine have is a mechanism for implementing RTP failover (for ongoing calls) or restart persistence . This is something we want to look into. I would love to have ICE and WebRTC on my media relay, for the HA and persistence are more important I would say.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On <a moz-do-not-send="true" href="tel:24.05.2014%2001" value="+12405201401" target="_blank">24.05.2014 01:59, Muhammad Shahzad Shafi wrote:

To be honest, i have stopped using rtpproxy for over 2 years now. It is not evolving as fast as it should be, specially in the context of ICE and WebRTC technologies.

I would like to suggest that opensips team should consider adding support for rtpengine from SIPWise,

https://github.com/sipwise/rtpengine

For now mediaproxy from AG Projects is the only good choice for handling media in opensips with ICE support (though it still lacks WebRTC features).

Thank you.

 

On 2014-05-23 14:55, Bogdan-Andrei Iancu wrote:

Going for a public exposure on this question to Maxim, maybe we will get an answer here.


-------- Original Message --------
Subject: RTPproxy project
Date: Mon, 14 Apr 2014 15:03:31 +0300
From: Bogdan-Andrei Iancu
To: Maxim Sobolev
CC: Razvan Crainea


Hello Maxim,

Long time, no talks, but I hope everything is fine on your side.

I'm reaching you in order to ask about your future plans in regards to 
the rtpproxy project? We see no much activity around it and other media 
relays are popping around.

RTPP is an essential component for us, we invested a lot of work, we 
have many patches (extensions) for it (which we want to push to the 
public tree, but there is no answer on this) and we are also looking for 
investing a lot into big future plans (as adding more functionalities).

Now, my question is - what is your commitment and disponibility for the 
RTPP project ? depending on that we what to re-position ourselves, as we 
do not want to waste time and work on things which are out of control.

Best regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


-- 
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: <a moz-do-not-send="true" href="tel:%2B49%20176%2099%2083%2010%2085" value="+4917699831085" target="_blank">+49 176 99 83 10 85
MSN: [hidden email]
Email: [hidden email]


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] Fwd: RTPproxy project

Saúl Ibarra Corretgé

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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] Fwd: RTPproxy project

Bogdan-Andrei Iancu-2
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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] Fwd: RTPproxy project

Adrian Georgescu
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 <[hidden email]> 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
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>
> _______________________________________________
> Devel mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] Fwd: RTPproxy project

Adrian Georgescu
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, [hidden email] 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>>
>
>
> _______________________________________________
> Devel mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Product Question....

Ozz Nixon
I am wanting to see if OpenSIPS is what I need, or is there something else I should be using, thanks:

Q. I want to have multiple asterisk/freePBX boxes send/receive calls...
        i. The uplink's SIP Trunk is pushing all INVITEs to my server.
        ii. However, all Asterisk/PBX systems reside on other networks.

        So, I would like to check my "Is Online" type DB, if it is only - redirect the SIP/RTP to the PBX.

        If not online, redirect to a CATCH-ALL PBX.

        iii. On outbound, if in my "Is Online" then redirect to the uplink's SIP Trunk.

My goal to support thousands of calls, without being in the middle for the RTP streams - just for the SIP.

Is that possible, or is there a better product for this???

Thanks again!
O.
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] Fwd: RTPproxy project

Bogdan-Andrei Iancu-2
In reply to this post by Adrian Georgescu
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, [hidden email] 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
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] Fwd: RTPproxy project

Adrian Georgescu
Not me. But most of the people are buying these in flocks!

On 28 May 2014, at 13:26, Bogdan-Andrei Iancu <[hidden email]> 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, [hidden email] 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
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] Fwd: RTPproxy project

Maxim Sobolev
In reply to this post by Brett Nemeroff
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 <[hidden email]> 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 <[hidden email]> 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 controlling the stream (audio /video), ability to set timeouts and onhold with no conflicts, ability to generates events on timeout, more flexibility in handling symmetric / asymmetric NATs, ability to do media injection (playback), ability to do call recording

What neither  mediaproxy, nor rtpengine have is a mechanism for implementing RTP failover (for ongoing calls) or restart persistence . This is something we want to look into. I would love to have ICE and WebRTC on my media relay, for the HA and persistence are more important I would say.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On <a href="tel:24.05.2014%2001" value="+12405201401" target="_blank">24.05.2014 01:59, Muhammad Shahzad Shafi wrote:

To be honest, i have stopped using rtpproxy for over 2 years now. It is not evolving as fast as it should be, specially in the context of ICE and WebRTC technologies.

I would like to suggest that opensips team should consider adding support for rtpengine from SIPWise,

https://github.com/sipwise/rtpengine

For now mediaproxy from AG Projects is the only good choice for handling media in opensips with ICE support (though it still lacks WebRTC features).

Thank you.

 

On 2014-05-23 14:55, Bogdan-Andrei Iancu wrote:

Going for a public exposure on this question to Maxim, maybe we will get an answer here.


-------- Original Message --------
Subject: RTPproxy project
Date: Mon, 14 Apr 2014 15:03:31 +0300
From: Bogdan-Andrei Iancu
To: Maxim Sobolev
CC: Razvan Crainea


Hello Maxim,

Long time, no talks, but I hope everything is fine on your side.

I'm reaching you in order to ask about your future plans in regards to 
the rtpproxy project? We see no much activity around it and other media 
relays are popping around.

RTPP is an essential component for us, we invested a lot of work, we 
have many patches (extensions) for it (which we want to push to the 
public tree, but there is no answer on this) and we are also looking for 
investing a lot into big future plans (as adding more functionalities).

Now, my question is - what is your commitment and disponibility for the 
RTPP project ? depending on that we what to re-position ourselves, as we 
do not want to waste time and work on things which are out of control.

Best regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


-- 
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: <a href="tel:%2B49%20176%2099%2083%2010%2085" value="+4917699831085" target="_blank">+49 176 99 83 10 85
MSN: [hidden email]
Email: [hidden email]


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel




--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: [hidden email]
Skype: SippySoft

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] Fwd: RTPproxy project

Bogdan-Andrei Iancu-2
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 <[hidden email]> 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 <[hidden email]> 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 controlling the stream (audio /video), ability to set timeouts and onhold with no conflicts, ability to generates events on timeout, more flexibility in handling symmetric / asymmetric NATs, ability to do media injection (playback), ability to do call recording

What neither  mediaproxy, nor rtpengine have is a mechanism for implementing RTP failover (for ongoing calls) or restart persistence . This is something we want to look into. I would love to have ICE and WebRTC on my media relay, for the HA and persistence are more important I would say.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On <a moz-do-not-send="true" href="tel:24.05.2014%2001" value="+12405201401" target="_blank">24.05.2014 01:59, Muhammad Shahzad Shafi wrote:

To be honest, i have stopped using rtpproxy for over 2 years now. It is not evolving as fast as it should be, specially in the context of ICE and WebRTC technologies.

I would like to suggest that opensips team should consider adding support for rtpengine from SIPWise,

https://github.com/sipwise/rtpengine

For now mediaproxy from AG Projects is the only good choice for handling media in opensips with ICE support (though it still lacks WebRTC features).

Thank you.

 

On 2014-05-23 14:55, Bogdan-Andrei Iancu wrote:

Going for a public exposure on this question to Maxim, maybe we will get an answer here.


-------- Original Message --------
Subject: RTPproxy project
Date: Mon, 14 Apr 2014 15:03:31 +0300
From: Bogdan-Andrei Iancu
To: Maxim Sobolev
CC: Razvan Crainea


Hello Maxim,

Long time, no talks, but I hope everything is fine on your side.

I'm reaching you in order to ask about your future plans in regards to 
the rtpproxy project? We see no much activity around it and other media 
relays are popping around.

RTPP is an essential component for us, we invested a lot of work, we 
have many patches (extensions) for it (which we want to push to the 
public tree, but there is no answer on this) and we are also looking for 
investing a lot into big future plans (as adding more functionalities).

Now, my question is - what is your commitment and disponibility for the 
RTPP project ? depending on that we what to re-position ourselves, as we 
do not want to waste time and work on things which are out of control.

Best regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


-- 
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: <a moz-do-not-send="true" href="tel:%2B49%20176%2099%2083%2010%2085" value="+4917699831085" target="_blank">+49 176 99 83 10 85
MSN: [hidden email]
Email: [hidden email]


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel




--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: [hidden email]
Skype: SippySoft


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] Fwd: RTPproxy project

Adrian Georgescu
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 controlling the stream (audio /video), ability to set timeouts and onhold with no conflicts, ability to generates events on timeout, more flexibility in handling symmetric / asymmetric NATs, ability to do media injection (playback), ability to do call recording

What neither  mediaproxy, nor rtpengine have is a mechanism for implementing RTP failover (for ongoing calls) or restart persistence . This is something we want to look into. I would love to have ICE and WebRTC on my media relay, for the HA and persistence are more important I would say.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On <a moz-do-not-send="true" href="tel:24.05.2014%2001" value="+12405201401" target="_blank">24.05.2014 01:59, Muhammad Shahzad Shafi wrote:

To be honest, i have stopped using rtpproxy for over 2 years now. It is not evolving as fast as it should be, specially in the context of ICE and WebRTC technologies.

I would like to suggest that opensips team should consider adding support for rtpengine from SIPWise,

https://github.com/sipwise/rtpengine

For now mediaproxy from AG Projects is the only good choice for handling media in opensips with ICE support (though it still lacks WebRTC features).

Thank you.

 

On 2014-05-23 14:55, Bogdan-Andrei Iancu wrote:

Going for a public exposure on this question to Maxim, maybe we will get an answer here.


-------- Original Message --------
Subject: RTPproxy project
Date: Mon, 14 Apr 2014 15:03:31 +0300
From: Bogdan-Andrei Iancu
To: Maxim Sobolev
CC: Razvan Crainea


Hello Maxim,

Long time, no talks, but I hope everything is fine on your side.

I'm reaching you in order to ask about your future plans in regards to 
the rtpproxy project? We see no much activity around it and other media 
relays are popping around.

RTPP is an essential component for us, we invested a lot of work, we 
have many patches (extensions) for it (which we want to push to the 
public tree, but there is no answer on this) and we are also looking for 
investing a lot into big future plans (as adding more functionalities).

Now, my question is - what is your commitment and disponibility for the 
RTPP project ? depending on that we what to re-position ourselves, as we 
do not want to waste time and work on things which are out of control.

Best regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


-- 
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: <a moz-do-not-send="true" href="tel:%2B49%20176%2099%2083%2010%2085" value="+4917699831085" target="_blank">+49 176 99 83 10 85
MSN: [hidden email]
Email: [hidden email]


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel




--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: [hidden email]
Skype: SippySoft

_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] Fwd: RTPproxy project

fabio4prez
For us, transcoding support, being able to fork rtcp to a reporting server (or even better, becoming an rtcp client), and (in a distant third) SRTP termination would be the big features we're looking for.  We would love to be able to do something around the nathelper API/rtpproxy API to offload to a transcoder only when we need it, similar to OpenSIPS added sangoma support, only with rtpproxy.  If the mechanism was added, we'd probably contribute to some codec translation tables (remember, g711 and ilbc are eerily similar in frame size).  FreeSWITCH does it by converting everything down to a common binary format before transcode, which is how I'd envision this would work.  Transcoding in software only is a huge value-add gain for us, because it allows us to continue with a software only solution and scale easier.

We engineer around losing an rtpproxy on the wire (which almost never happens), with a few strategies around re-INVITE, silence packet detection, etc.  It's not perfect, but it's well within the SLA we'd present our end users and it's probably an area of the system where we get the least complaints.  A dropped call every few weeks is beyond acceptable from the generation that's used to going from 4 bars to 0 in a subway tunnel.

And rtp_cluster has been great for us, solely for the ability to tag an instance as down and bleed sessions off of it before terminating it.  The load balancing is on parity with the features added to the rtpproxy module via opensips, with exception of this:  multiple opensips instances can talk to the same rtp_cluster, meaning that you get a distributed session state map can be highly available, instead of relying upon what's in memory with opensips.  That's how we achieve the failover features that I think the community want added.  Maybe adding rtpproxy session replication through the binary data interface recently introduced to opensips could help with some of this.

So yes, feature parity is important, but it's also important that we maintain reliable performance.  I know Maxim has worked on some stuff around threading that has helped us move forward to better reliability with rtpp (separating command protocol from packet processing), so there's some progress there.  The last time we did a comparison and made a decision between the two major entities, we just found rtpproxy to be much better performant at handling multiple sessions per instance, in the 50-60% better range.  We can squeeze around 6000 established "sessions" (if you come from an eSBC world) on an m3.xlarge ec2 instance and not break a sweat.

Ultimately, I think it's good for all of the community to show that a project is in active development.  I think it's a win for both sides, and discussions on where something is going are well warranted.

And this is coming from the SP with a capital V.




On Fri, Jun 13, 2014 at 1:55 PM, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 controlling the stream (audio /video), ability to set timeouts and onhold with no conflicts, ability to generates events on timeout, more flexibility in handling symmetric / asymmetric NATs, ability to do media injection (playback), ability to do call recording

What neither  mediaproxy, nor rtpengine have is a mechanism for implementing RTP failover (for ongoing calls) or restart persistence . This is something we want to look into. I would love to have ICE and WebRTC on my media relay, for the HA and persistence are more important I would say.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On <a href="tel:24.05.2014%2001" value="+12405201401" target="_blank">24.05.2014 01:59, Muhammad Shahzad Shafi wrote:

To be honest, i have stopped using rtpproxy for over 2 years now. It is not evolving as fast as it should be, specially in the context of ICE and WebRTC technologies.

I would like to suggest that opensips team should consider adding support for rtpengine from SIPWise,

https://github.com/sipwise/rtpengine

For now mediaproxy from AG Projects is the only good choice for handling media in opensips with ICE support (though it still lacks WebRTC features).

Thank you.

 

On 2014-05-23 14:55, Bogdan-Andrei Iancu wrote:

Going for a public exposure on this question to Maxim, maybe we will get an answer here.


-------- Original Message --------
Subject: RTPproxy project
Date: Mon, 14 Apr 2014 15:03:31 +0300
From: Bogdan-Andrei Iancu
To: Maxim Sobolev
CC: Razvan Crainea


Hello Maxim,

Long time, no talks, but I hope everything is fine on your side.

I'm reaching you in order to ask about your future plans in regards to 
the rtpproxy project? We see no much activity around it and other media 
relays are popping around.

RTPP is an essential component for us, we invested a lot of work, we 
have many patches (extensions) for it (which we want to push to the 
public tree, but there is no answer on this) and we are also looking for 
investing a lot into big future plans (as adding more functionalities).

Now, my question is - what is your commitment and disponibility for the 
RTPP project ? depending on that we what to re-position ourselves, as we 
do not want to waste time and work on things which are out of control.

Best regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


-- 
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: <a href="tel:%2B49%20176%2099%2083%2010%2085" value="+4917699831085" target="_blank">+49 176 99 83 10 85
MSN: [hidden email]
Email: [hidden email]


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel




--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): <a href="tel:%2B1-778-783-0474" value="+17787830474" target="_blank">+1-778-783-0474
Tel (Toll-Free): <a href="tel:%2B1-855-747-7779" value="+18557477779" target="_blank">+1-855-747-7779
Fax: <a href="tel:%2B1-866-857-6942" value="+18668576942" target="_blank">+1-866-857-6942
Web: http://www.sippysoft.com
MSN: [hidden email]
Skype: SippySoft

_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] Fwd: RTPproxy project

Bogdan-Andrei Iancu-2
In reply to this post by Adrian Georgescu
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, [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 controlling the stream (audio /video), ability to set timeouts and onhold with no conflicts, ability to generates events on timeout, more flexibility in handling symmetric / asymmetric NATs, ability to do media injection (playback), ability to do call recording

What neither  mediaproxy, nor rtpengine have is a mechanism for implementing RTP failover (for ongoing calls) or restart persistence . This is something we want to look into. I would love to have ICE and WebRTC on my media relay, for the HA and persistence are more important I would say.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On <a moz-do-not-send="true" href="tel:24.05.2014%2001" value="+12405201401" target="_blank">24.05.2014 01:59, Muhammad Shahzad Shafi wrote:

To be honest, i have stopped using rtpproxy for over 2 years now. It is not evolving as fast as it should be, specially in the context of ICE and WebRTC technologies.

I would like to suggest that opensips team should consider adding support for rtpengine from SIPWise,

https://github.com/sipwise/rtpengine

For now mediaproxy from AG Projects is the only good choice for handling media in opensips with ICE support (though it still lacks WebRTC features).

Thank you.

 

On 2014-05-23 14:55, Bogdan-Andrei Iancu wrote:

Going for a public exposure on this question to Maxim, maybe we will get an answer here.


-------- Original Message --------
Subject: RTPproxy project
Date: Mon, 14 Apr 2014 15:03:31 +0300
From: Bogdan-Andrei Iancu
To: Maxim Sobolev
CC: Razvan Crainea


Hello Maxim,

Long time, no talks, but I hope everything is fine on your side.

I'm reaching you in order to ask about your future plans in regards to 
the rtpproxy project? We see no much activity around it and other media 
relays are popping around.

RTPP is an essential component for us, we invested a lot of work, we 
have many patches (extensions) for it (which we want to push to the 
public tree, but there is no answer on this) and we are also looking for 
investing a lot into big future plans (as adding more functionalities).

Now, my question is - what is your commitment and disponibility for the 
RTPP project ? depending on that we what to re-position ourselves, as we 
do not want to waste time and work on things which are out of control.

Best regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


-- 
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: <a moz-do-not-send="true" href="tel:%2B49%20176%2099%2083%2010%2085" value="+4917699831085" target="_blank">+49 176 99 83 10 85
MSN: [hidden email]
Email: [hidden email]


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel




--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: [hidden email]
Skype: SippySoft

_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] Fwd: RTPproxy project

Bogdan-Andrei Iancu-2
In reply to this post by fabio4prez
Hey Bobby,

Thank you for the your input.

I have also a long list of goodies to be added to a rtpproxy (fixes in multi-stream handling, new features, etc) and this is why I started this discussion around the RTPproxy - I wanted to understand what are the plans for the future.

To be honest I was not aware of the latest work Maxim did on rtpproxy (it is not so transparent via the rtpproxy.org site or mailing lists) - but it looks interesting and before doing any steps further I will need to look into that.

As it is not clear for me, could you detail a bit on:

"
multiple opensips instances can talk to the same rtp_cluster, meaning that you get a distributed session state map can be highly available"
What do you mean by "
session state map can be highly available" ?

Also , on :
"
Maybe adding rtpproxy session replication through the binary data interface recently introduced to opensips could help with some of this"
You mean to replicate the info on sessions between multiple rtpproxy instances ?


Thanks and regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 14.06.2014 16:17, Bobby Smith wrote:
For us, transcoding support, being able to fork rtcp to a reporting server (or even better, becoming an rtcp client), and (in a distant third) SRTP termination would be the big features we're looking for.  We would love to be able to do something around the nathelper API/rtpproxy API to offload to a transcoder only when we need it, similar to OpenSIPS added sangoma support, only with rtpproxy.  If the mechanism was added, we'd probably contribute to some codec translation tables (remember, g711 and ilbc are eerily similar in frame size).  FreeSWITCH does it by converting everything down to a common binary format before transcode, which is how I'd envision this would work.  Transcoding in software only is a huge value-add gain for us, because it allows us to continue with a software only solution and scale easier.

We engineer around losing an rtpproxy on the wire (which almost never happens), with a few strategies around re-INVITE, silence packet detection, etc.  It's not perfect, but it's well within the SLA we'd present our end users and it's probably an area of the system where we get the least complaints.  A dropped call every few weeks is beyond acceptable from the generation that's used to going from 4 bars to 0 in a subway tunnel.

And rtp_cluster has been great for us, solely for the ability to tag an instance as down and bleed sessions off of it before terminating it.  The load balancing is on parity with the features added to the rtpproxy module via opensips, with exception of this:  multiple opensips instances can talk to the same rtp_cluster, meaning that you get a distributed session state map can be highly available, instead of relying upon what's in memory with opensips.  That's how we achieve the failover features that I think the community want added.  Maybe adding rtpproxy session replication through the binary data interface recently introduced to opensips could help with some of this.

So yes, feature parity is important, but it's also important that we maintain reliable performance.  I know Maxim has worked on some stuff around threading that has helped us move forward to better reliability with rtpp (separating command protocol from packet processing), so there's some progress there.  The last time we did a comparison and made a decision between the two major entities, we just found rtpproxy to be much better performant at handling multiple sessions per instance, in the 50-60% better range.  We can squeeze around 6000 established "sessions" (if you come from an eSBC world) on an m3.xlarge ec2 instance and not break a sweat.

Ultimately, I think it's good for all of the community to show that a project is in active development.  I think it's a win for both sides, and discussions on where something is going are well warranted.

And this is coming from the SP with a capital V.




On Fri, Jun 13, 2014 at 1:55 PM, <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 controlling the stream (audio /video), ability to set timeouts and onhold with no conflicts, ability to generates events on timeout, more flexibility in handling symmetric / asymmetric NATs, ability to do media injection (playback), ability to do call recording

What neither  mediaproxy, nor rtpengine have is a mechanism for implementing RTP failover (for ongoing calls) or restart persistence . This is something we want to look into. I would love to have ICE and WebRTC on my media relay, for the HA and persistence are more important I would say.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On <a moz-do-not-send="true" href="tel:24.05.2014%2001" value="+12405201401" target="_blank">24.05.2014 01:59, Muhammad Shahzad Shafi wrote:

To be honest, i have stopped using rtpproxy for over 2 years now. It is not evolving as fast as it should be, specially in the context of ICE and WebRTC technologies.

I would like to suggest that opensips team should consider adding support for rtpengine from SIPWise,

https://github.com/sipwise/rtpengine

For now mediaproxy from AG Projects is the only good choice for handling media in opensips with ICE support (though it still lacks WebRTC features).

Thank you.

 

On 2014-05-23 14:55, Bogdan-Andrei Iancu wrote:

Going for a public exposure on this question to Maxim, maybe we will get an answer here.


-------- Original Message --------
Subject: RTPproxy project
Date: Mon, 14 Apr 2014 15:03:31 +0300
From: Bogdan-Andrei Iancu
To: Maxim Sobolev
CC: Razvan Crainea


Hello Maxim,

Long time, no talks, but I hope everything is fine on your side.

I'm reaching you in order to ask about your future plans in regards to 
the rtpproxy project? We see no much activity around it and other media 
relays are popping around.

RTPP is an essential component for us, we invested a lot of work, we 
have many patches (extensions) for it (which we want to push to the 
public tree, but there is no answer on this) and we are also looking for 
investing a lot into big future plans (as adding more functionalities).

Now, my question is - what is your commitment and disponibility for the 
RTPP project ? depending on that we what to re-position ourselves, as we 
do not want to waste time and work on things which are out of control.

Best regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


-- 
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: <a moz-do-not-send="true" href="tel:%2B49%20176%2099%2083%2010%2085" value="+4917699831085" target="_blank">+49 176 99 83 10 85
MSN: [hidden email]
Email: [hidden email]


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel




--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): <a moz-do-not-send="true" href="tel:%2B1-778-783-0474" value="+17787830474" target="_blank">+1-778-783-0474
Tel (Toll-Free): <a moz-do-not-send="true" href="tel:%2B1-855-747-7779" value="+18557477779" target="_blank">+1-855-747-7779
Fax: <a moz-do-not-send="true" href="tel:%2B1-866-857-6942" value="+18668576942" target="_blank">+1-866-857-6942
Web: http://www.sippysoft.com
MSN: [hidden email]
Skype: SippySoft

_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users




_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: [OpenSIPS-Devel] Fwd: RTPproxy project

Adrian Georgescu
In reply to this post by Bogdan-Andrei Iancu-2
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 <[hidden email]> 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, [hidden email] 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 controlling the stream (audio /video), ability to set timeouts and onhold with no conflicts, ability to generates events on timeout, more flexibility in handling symmetric / asymmetric NATs, ability to do media injection (playback), ability to do call recording

What neither  mediaproxy, nor rtpengine have is a mechanism for implementing RTP failover (for ongoing calls) or restart persistence . This is something we want to look into. I would love to have ICE and WebRTC on my media relay, for the HA and persistence are more important I would say.

Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On <a moz-do-not-send="true" href="tel:24.05.2014%2001" value="+12405201401" target="_blank">24.05.2014 01:59, Muhammad Shahzad Shafi wrote:

To be honest, i have stopped using rtpproxy for over 2 years now. It is not evolving as fast as it should be, specially in the context of ICE and WebRTC technologies.

I would like to suggest that opensips team should consider adding support for rtpengine from SIPWise,

https://github.com/sipwise/rtpengine

For now mediaproxy from AG Projects is the only good choice for handling media in opensips with ICE support (though it still lacks WebRTC features).

Thank you.

 

On 2014-05-23 14:55, Bogdan-Andrei Iancu wrote:

Going for a public exposure on this question to Maxim, maybe we will get an answer here.


-------- Original Message --------
Subject: RTPproxy project
Date: Mon, 14 Apr 2014 15:03:31 +0300
From: Bogdan-Andrei Iancu
To: Maxim Sobolev
CC: Razvan Crainea


Hello Maxim,

Long time, no talks, but I hope everything is fine on your side.

I'm reaching you in order to ask about your future plans in regards to 
the rtpproxy project? We see no much activity around it and other media 
relays are popping around.

RTPP is an essential component for us, we invested a lot of work, we 
have many patches (extensions) for it (which we want to push to the 
public tree, but there is no answer on this) and we are also looking for 
investing a lot into big future plans (as adding more functionalities).

Now, my question is - what is your commitment and disponibility for the 
RTPP project ? depending on that we what to re-position ourselves, as we 
do not want to waste time and work on things which are out of control.

Best regards,

-- 
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


-- 
Mit freundlichen Grüßen
Muhammad Shahzad
-----------------------------------
CISCO Rich Media Communication Specialist (CRMCS)
CISCO Certified Network Associate (CCNA)
Cell: <a moz-do-not-send="true" href="tel:%2B49%20176%2099%2083%2010%2085" value="+4917699831085" target="_blank">+49 176 99 83 10 85
MSN: [hidden email]
Email: [hidden email]


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel




--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: [hidden email]
Skype: SippySoft

_______________________________________________
Devel mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel



_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users