[OpenSIPS-Devel] [opensips] makefile: Move checks around for documentation dependencies. (#248)

2014-06-13 Thread Walter Doekes
The patch speaks for itself.

Mainly it adds the `-z quot;$(DBHTMLXSL)quot;` check, so I don#39;t get 
unexplainable errors.
You can merge this Pull Request by running:

  git pull https://github.com/wdoekes/opensips wjd-warn-if-no-docbook

Or you can view, comment on it, or merge it online at:

  https://github.com/OpenSIPS/opensips/pull/248

-- Commit Summary --

  * makefile: Move checks around for documentation dependencies.

-- File Changes --

M Makefile (55)

-- Patch Links --

https://github.com/OpenSIPS/opensips/pull/248.patch
https://github.com/OpenSIPS/opensips/pull/248.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/248
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


[OpenSIPS-Devel] [opensips] Port topoh.so (topology hiding without dialog.so) from kamailio. (#249)

2014-06-13 Thread Walter Doekes
See the three commits. The changes were trivial.

I don#39;t know about copyright and stuff though.
You can merge this Pull Request by running:

  git pull https://github.com/wdoekes/opensips wjd-topoh-from-kamailio

Or you can view, comment on it, or merge it online at:

  https://github.com/OpenSIPS/opensips/pull/249

-- Commit Summary --

  * topoh: Add kamailio topo hiding module.
  * topoh: Port changes to opensips.
  * topoh: Make more opensips-ish. Fix README.

-- File Changes --

A modules/topoh/Makefile (10)
A modules/topoh/README (185)
A modules/topoh/doc/Makefile (4)
A modules/topoh/doc/topoh.xml (39)
A modules/topoh/doc/topoh_admin.xml (228)
A modules/topoh/th_mask.c (182)
A modules/topoh/th_mask.h (38)
A modules/topoh/th_msg.c (1084)
A modules/topoh/th_msg.h (55)
A modules/topoh/topoh_mod.c (434)

-- Patch Links --

https://github.com/OpenSIPS/opensips/pull/249.patch
https://github.com/OpenSIPS/opensips/pull/249.diff

---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/pull/249
___
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel


Re: [OpenSIPS-Devel] [OpenSIPS-Users] Fwd: RTPproxy project

2014-06-13 Thread Bogdan-Andrei Iancu

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 
mailto: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 mailto: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 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 tel:24.05.2014%2001: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