Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-10 Thread Klaus Darilion



On 02.04.2013 15:05, Richard Fuchs wrote:

Hi,

On 04/01/13 10:03, Aft nix wrote:


I stumbled upon this git://github.com/sipwise/mediaproxy-ng.git which
looked very neat to me. Its said that it can be used with kamailio. It
seems like its backed sipwise inc.

But no documentation is given there. Anyone know of a
tutorial/documentation for how to use it?


It comes bundled with our NGCP product and is fully integrated there.
Despite its name, it's intended to be used with the Kamailio rtpproxy
module (not mediaproxy) and except for a few unsupported features (like
media recording) it can be used as a drop-in replacement RTP proxy.

The newest version supports a new control protocol, which is facilitated
through a new Kamailio module rtpproxy-ng.


I think it is a bad idea to name the relay mediaproxy-ng and the 
corresponding Kamailio module rtpproxy-ng.


regards
Klaus

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-10 Thread Manwe
El Wed, 10 Apr 2013 10:17:18 +0200
Klaus Darilion klaus.mailingli...@pernau.at escribió:

 
 
 On 02.04.2013 15:05, Richard Fuchs wrote:
  Hi,
 
  On 04/01/13 10:03, Aft nix wrote:
 
  I stumbled upon this git://github.com/sipwise/mediaproxy-ng.git which
  looked very neat to me. Its said that it can be used with kamailio. It
  seems like its backed sipwise inc.
 
  But no documentation is given there. Anyone know of a
  tutorial/documentation for how to use it?
 
  It comes bundled with our NGCP product and is fully integrated there.
  Despite its name, it's intended to be used with the Kamailio rtpproxy
  module (not mediaproxy) and except for a few unsupported features (like
  media recording) it can be used as a drop-in replacement RTP proxy.
 
  The newest version supports a new control protocol, which is facilitated
  through a new Kamailio module rtpproxy-ng.
 
 I think it is a bad idea to name the relay mediaproxy-ng and the 
 corresponding Kamailio module rtpproxy-ng.
 

Indeed


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-10 Thread Andreas Granig

Hi,

On 04/10/2013 11:02 AM, Jon Bonilla (Manwe) wrote:

I think it is a bad idea to name the relay mediaproxy-ng and the
corresponding Kamailio module rtpproxy-ng.



Indeed


Well, the point is that it's just an enhancement of the rtpproxy 
module. In the past, the rtpproxy module was used to communicate with 
mediaproxy-ng (and can still be used that way), as mediaproxy-ng 
implements the rtpproxy protocol.


The idea behind rtpproxy-ng was to provide a reference implementation of 
an easily extensible control protocol (as we needed it for our ICE 
handling anyways), because there were some discussions and plans to 
rework rtpproxy towards such a kind of protocol as well (JSON was one of 
the formats, but we rather went with bencode as it's faster to parse and 
still somewhat human readable). Mind you we're still working on the 
protocol documentation.


Now the real question is whether it makes sense to extend rtpproxy to 
use this protocol as well, and in this case rtpproxy-ng as a module name 
makes perfect sense. It would probably be a good idea to merge it to 
rtpproxy module and just use that at some point (requiring to upgrade 
rtpproxy along with kamailio though, or control the protocol version via 
a module parameter).


If there are no intentions to develop rtpproxy further, it would make 
sense to name our module mediaproxy-ng instead of rtpproxy-ng. The 
module is still only in our repo and not pushed upstream exactly because 
of this kind of naming decision (besides the lack of documentation).


Andreas


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-10 Thread Richard Fuchs
On 04/10/13 04:17, Klaus Darilion wrote:

 I think it is a bad idea to name the relay mediaproxy-ng and the
 corresponding Kamailio module rtpproxy-ng.

I've considered that. Apart from the other reasons already mentioned,
for me the deciding factor was that the new module forms a drop-in
replacement (at least for the time being) for the rtpproxy module and
not the mediaproxy module. All you have to do is append -ng in your
config and you're done. Plus, I hope we won't remain the only ones
providing an RTP proxy solution that works with the new protocol.

cheers



signature.asc
Description: OpenPGP digital signature
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-10 Thread Olle E. Johansson

10 apr 2013 kl. 14:38 skrev Richard Fuchs rfu...@sipwise.com:

 On 04/10/13 04:17, Klaus Darilion wrote:
 
 I think it is a bad idea to name the relay mediaproxy-ng and the
 corresponding Kamailio module rtpproxy-ng.
 
 I've considered that. Apart from the other reasons already mentioned,
 for me the deciding factor was that the new module forms a drop-in
 replacement (at least for the time being) for the rtpproxy module and
 not the mediaproxy module. All you have to do is append -ng in your
 config and you're done. Plus, I hope we won't remain the only ones
 providing an RTP proxy solution that works with the new protocol.

Let's just call both Bert and find a good reason why.

Or chrome. ;-)
/O

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-10 Thread Juha Heinanen
i consider it a bad idea to call the new media proxy mediaproxy-ng,
because it gives impression that this is a new incarnation of ag projects
mediaproxy that has existed for years.

-- juha

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-10 Thread Manwe
El Wed, 10 Apr 2013 14:41:33 +0200
Olle E. Johansson o...@edvina.net escribió:

 
 10 apr 2013 kl. 14:38 skrev Richard Fuchs rfu...@sipwise.com:
 
  On 04/10/13 04:17, Klaus Darilion wrote:
  
  I think it is a bad idea to name the relay mediaproxy-ng and the
  corresponding Kamailio module rtpproxy-ng.
  
  I've considered that. Apart from the other reasons already mentioned,
  for me the deciding factor was that the new module forms a drop-in
  replacement (at least for the time being) for the rtpproxy module and
  not the mediaproxy module. All you have to do is append -ng in your
  config and you're done. Plus, I hope we won't remain the only ones
  providing an RTP proxy solution that works with the new protocol.
 
 Let's just call both Bert and find a good reason why.
 
 Or chrome. ;-)
 /O


+1 to chrome :)


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-10 Thread Andreas Granig

Hi,

On 04/10/2013 02:54 PM, Juha Heinanen wrote:

i consider it a bad idea to call the new media proxy mediaproxy-ng,
because it gives impression that this is a new incarnation of ag projects
mediaproxy that has existed for years.


mediaproxy-ng also exists for years (since 2007, prior to the redesign 
of mediaproxy to become kernel based as well) and in fact was a 
replacement of the relay part of the mediaproxy project. It used and 
relied on the dispatcher-part and its control protocol of mediaproxy.


We additionally implemented support for the rtpproxy protocol in 2010 or 
so (but never worked on adapting it to any newer mediaproxy control 
protocols), and now it also supports a completely new control protocol 
implemented in rtpproxy-ng.


So basically it evolved from replacing a part of the mediaproxy project 
into a drop-in replacement of rtpproxy and since a few weeks could exist 
on its own with the rtpproxy-ng module. It just never changed its name.


Andreas


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-05 Thread Daniel-Constantin Mierla

Hello,

On 4/4/13 9:15 PM, Richard Fuchs wrote:

Hi,

On 04/04/13 14:58, Daniel-Constantin Mierla wrote:


quite interesting, I didn't know it has two operations modes: user space
forwarding and kernel forwarding.

Is there any plan in supporting more one mode (or dropping the other) in
the future?

Not per se, kernel mode forwarding (at least for the primitive case with
no modifications to the packets) will always be the primary means of
forwarding packets. At the same time, user-space forwarding will also
always be available, since at least the first few packets must always be
processed by the daemon. As such, it doesn't really have two modes of
operation, it will simply fall back to user-space processing if the
kernel modules fails to do its job for whatever reason. It's designed to
use the functionality of the kernel module if possible, but also not to
rely on it.


She fallback to user space can happen even during a call? Or is just 
about when the call is initialized, the application detects is some 
problem when setting up forwarding rules in the kernel and goes for user 
space.





Have you done some measurements to see the benefits of
kernel forwarding vs user space?

I can't quote any specific numbers, but we've seen several times in the
past that the overhead of pushing packets back and forth between kernel
and user space is quite significant. I suppose I could try to set up
some simple tests to get some unscientific ballpark numbers if people
are interested.
Indeed, this is kind of general feeling, at least based on theoretical 
aspects, but I haven't seen any kind of numbers just to compare and see 
how much is worth to go for kernel forwarding.


Cheers,
Daniel

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
 - http://conference.kamailio.com -


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-05 Thread Richard Fuchs
On 04/05/13 03:53, Daniel-Constantin Mierla wrote:

 She fallback to user space can happen even during a call? Or is just
 about when the call is initialized, the application detects is some
 problem when setting up forwarding rules in the kernel and goes for user
 space.

It can happen any time. The socket remains open and the daemon continues
to listen for packets on it. If the daemon receives a packet, it will
process it, which in the normal case will result in it being forwarded.
With the kernel module active and working, the daemon will simply not
see the packets coming in on the socket.

 Indeed, this is kind of general feeling, at least based on theoretical
 aspects, but I haven't seen any kind of numbers just to compare and see
 how much is worth to go for kernel forwarding.

I did a very simple test, one pseudo-call (one port in, one port out)
with about 35,000 UDP packets per second going each way. Each packet had
150 bytes payload and the test was done on an 8-core Xeon 2.53 GHz
machine running kernel 2.6.32. Under this workload, the daemon registers
with about 90% single-CPU load without kernel forwarding. The daemon is
multi-threaded and so can use multiple cores, but if it weren't, then it
would be about maxed out at this point. Averaged over the 8 cores this
leaves the system around 88% idle. With kernel forwarding enabled,
system CPU usage drops to 99% idle.

cheers



signature.asc
Description: OpenPGP digital signature
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-04 Thread Marek Červenka

updated http://www.voip-info.org/wiki/view/MediaProxy+Comparison

Dne 2.4.2013 16:42, Richard Fuchs napsal(a):
On 04/02/13 10:02, aft wrote:

Daemon installation failed with the following :

call.c:15:27: fatal error: xmlrpc_client.h: No such file or directory

Check out the list of dependencies in the debian/control file. One of
them is libxmlrpc-c3 (from http://xmlrpc-c.sourceforge.net/).


What is this kernel based forwarding? why its useful?

It provides better performance than doing it through the daemon, less
CPU overhead and lower jitter.


Does this mediaproxy-ng supports repacketization of rtp packets?

No that's not supported yet.

cheers

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



--
---
Marek Cervenka
===


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-04 Thread Daniel-Constantin Mierla

Hello,

On 4/2/13 3:44 PM, Richard Fuchs wrote:

[...]

If the kernel module isn't
loaded, the daemon will print a warning but will continue to function
normally.
quite interesting, I didn't know it has two operations modes: user space 
forwarding and kernel forwarding.


Is there any plan in supporting more one mode (or dropping the other) in 
the future? Have you done some measurements to see the benefits of 
kernel forwarding vs user space?


Cheers,
Daniel

--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, April 16-17, 2013, Berlin
 - http://conference.kamailio.com -


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-04 Thread Richard Fuchs
Hi,

On 04/04/13 14:58, Daniel-Constantin Mierla wrote:

 quite interesting, I didn't know it has two operations modes: user space
 forwarding and kernel forwarding.
 
 Is there any plan in supporting more one mode (or dropping the other) in
 the future? 

Not per se, kernel mode forwarding (at least for the primitive case with
no modifications to the packets) will always be the primary means of
forwarding packets. At the same time, user-space forwarding will also
always be available, since at least the first few packets must always be
processed by the daemon. As such, it doesn't really have two modes of
operation, it will simply fall back to user-space processing if the
kernel modules fails to do its job for whatever reason. It's designed to
use the functionality of the kernel module if possible, but also not to
rely on it.

 Have you done some measurements to see the benefits of
 kernel forwarding vs user space?

I can't quote any specific numbers, but we've seen several times in the
past that the overhead of pushing packets back and forth between kernel
and user space is quite significant. I suppose I could try to set up
some simple tests to get some unscientific ballpark numbers if people
are interested.

cheers



signature.asc
Description: OpenPGP digital signature
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-03 Thread aft
On Wed, Apr 3, 2013 at 5:50 AM, Richard Fuchs rfu...@sipwise.com wrote:
 On 04/02/13 17:39, aft wrote:

 So the bottom line is i have to include the code in both places.

 Another thing is i'm assuming you know much about the development of this 
 media
 relay. So i'm asking, is there any plan for including repacketization 
 feature?

 Its very crucial for our operation, so if there is no plan for it,
 then i wish to do it
 myself. Although i know nothing of its codebase, but if active developers 
 help,
 i think i can do it.

 Yes and no. Repacketization isn't a priority for us, but we do have
 definitive plans on supporting other modifications to the RTP packets in
 the near future, most notably bridging between different RTP profiles
 (such as RTP to SRTP). Repacketization would fit in there well. However,
 I can't give a time line for this, and I also can't tell yet if we want
 to support these operations in kernel mode at all. The CPU time required
 might make the additional CPU overhead of passing packets back and forth
 between user space and kernel space negligible. Or it might not, it's
 hard to tell at this point.

Thanks for the reply. I've started reading the code to understand what it does.

We had a software which was all kernel to do these modification. Although
That software is not a media relay, rather than it sits right on top
of a existing
media relay to do modifications. That software, also implemented as
kernel module(not
GPLed at this moment), performed well.


 cheers

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



--
-aft

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-02 Thread aft
On Mon, Apr 1, 2013 at 8:23 PM, Dani Popa dani.p...@gmail.com wrote:
 what is mediaproxy-ng ? it's another media proxy?  What are the diff between
 mediaproxy and mediaproxy-ng ?


Its different from mediaproxy. Its developed by sipwise and is kernel
based rather than a userland software. The sipwise patched kamailio
source has a module mediaproxy-ng to use mediaproxy-ng with kamailio.



 dani


 On Mon, Apr 1, 2013 at 5:03 PM, Aft nix aft...@gmail.com wrote:

 Hi,

 I stumbled upon this git://github.com/sipwise/mediaproxy-ng.git which
 looked very neat to me. Its said that it can be used with kamailio. It
 seems like its backed sipwise inc.

 But no documentation is given there. Anyone know of a
 tutorial/documentation for how to use it?
 --
 -aft

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users




 --
 Dani Popa

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users




--
-aft

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-02 Thread Richard Fuchs
Hi,

On 04/01/13 10:03, Aft nix wrote:

 I stumbled upon this git://github.com/sipwise/mediaproxy-ng.git which
 looked very neat to me. Its said that it can be used with kamailio. It
 seems like its backed sipwise inc.
 
 But no documentation is given there. Anyone know of a
 tutorial/documentation for how to use it?

It comes bundled with our NGCP product and is fully integrated there.
Despite its name, it's intended to be used with the Kamailio rtpproxy
module (not mediaproxy) and except for a few unsupported features (like
media recording) it can be used as a drop-in replacement RTP proxy.

The newest version supports a new control protocol, which is facilitated
through a new Kamailio module rtpproxy-ng. For now, this module is a
drop-in replacement for the old rtpproxy module and supports the same
stuff, plus some ICE options. It's not included in the regular Kamailio
git tree yet, but soon will be. In the meantime, the module is available
from our github Kamailio tree.

cheers

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-02 Thread aft
On Tue, Apr 2, 2013 at 7:05 PM, Richard Fuchs rfu...@sipwise.com wrote:
 Hi,

 On 04/01/13 10:03, Aft nix wrote:

 I stumbled upon this git://github.com/sipwise/mediaproxy-ng.git which
 looked very neat to me. Its said that it can be used with kamailio. It
 seems like its backed sipwise inc.

 But no documentation is given there. Anyone know of a
 tutorial/documentation for how to use it?

 It comes bundled with our NGCP product and is fully integrated there.
 Despite its name, it's intended to be used with the Kamailio rtpproxy
 module (not mediaproxy) and except for a few unsupported features (like
 media recording) it can be used as a drop-in replacement RTP proxy.


I have gone through the module documentation page of rtpproxy-ng in
sipwise's github tree.

My confusion is about the the mediaproxy-ng itself. There is nothing mentioned
in the README file.

https://github.com/aftnix/mediaproxy-ng/blob/master/README.md

So i was asking how to install mediaproxy-ng itself?


 The newest version supports a new control protocol, which is facilitated
 through a new Kamailio module rtpproxy-ng. For now, this module is a
 drop-in replacement for the old rtpproxy module and supports the same
 stuff, plus some ICE options. It's not included in the regular Kamailio
 git tree yet, but soon will be. In the meantime, the module is available
 from our github Kamailio tree.

 cheers

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



--
-aft

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-02 Thread Richard Fuchs
On 04/02/13 09:15, aft wrote:

 So i was asking how to install mediaproxy-ng itself?

If you're on a Debian system, you can simply issue dpkg-buildpackage and
then install the packages it produces. Otherwise you can compile the
sources yourself. A simple make in each one of the 3 subdirectories
(daemon, iptables-extension and kernel-module) should do the trick,
provided all the dependencies are installed. You need to have at least
the daemon compiled, the other 2 components are optional and required
only if you wish to utilize kernel-based packet forwarding.

The daemon is a single binary and will print usage information if
executed. The minimum required parameters are listening socket/port
(udp for rtpproxy module, ng for rtpproxy-ng module; tcp is a
legacy protocol not in use any more), local IP address(es) and a kernel
table ID. The kernel table ID is required even if you don't use kernel
forwarding and is usually set as zero. If the kernel module isn't
loaded, the daemon will print a warning but will continue to function
normally.

To enable kernel-based forwarding, you need to load the kernel module
and add an iptables rule to use it, for example:
iptables -I INPUT -p udp -j MEDIAPROXY --id $ID
with $ID being the same ID as you used when starting the daemon
(normally zero). With this in place, incoming packets are delivered to
the kernel module, which then can forward them if instructed to do so by
the daemon.

And that's all there is to it really.

cheers

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-02 Thread aft
On Tue, Apr 2, 2013 at 7:44 PM, Richard Fuchs rfu...@sipwise.com wrote:
 On 04/02/13 09:15, aft wrote:

 So i was asking how to install mediaproxy-ng itself?


 If you're on a Debian system, you can simply issue dpkg-buildpackage and
 then install the packages it produces. Otherwise you can compile the
 sources yourself. A simple make in each one of the 3 subdirectories
 (daemon, iptables-extension and kernel-module) should do the trick,

First of all thanks for the answer.

Daemon installation failed with the following :

call.c:15:27: fatal error: xmlrpc_client.h: No such file or directory


 provided all the dependencies are installed. You need to have at least
 the daemon compiled, the other 2 components are optional and required
 only if you wish to utilize kernel-based packet forwarding.

What is this kernel based forwarding? why its useful?


Does this mediaproxy-ng supports repacketization of rtp packets?

 The daemon is a single binary and will print usage information if
 executed. The minimum required parameters are listening socket/port
 (udp for rtpproxy module, ng for rtpproxy-ng module; tcp is a
 legacy protocol not in use any more), local IP address(es) and a kernel
 table ID. The kernel table ID is required even if you don't use kernel
 forwarding and is usually set as zero. If the kernel module isn't
 loaded, the daemon will print a warning but will continue to function
 normally.

 To enable kernel-based forwarding, you need to load the kernel module
 and add an iptables rule to use it, for example:
 iptables -I INPUT -p udp -j MEDIAPROXY --id $ID
 with $ID being the same ID as you used when starting the daemon
 (normally zero). With this in place, incoming packets are delivered to
 the kernel module, which then can forward them if instructed to do so by
 the daemon.

 And that's all there is to it really.

 cheers

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



--
-aft

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-02 Thread Richard Fuchs
On 04/02/13 10:02, aft wrote:

 Daemon installation failed with the following :
 
 call.c:15:27: fatal error: xmlrpc_client.h: No such file or directory

Check out the list of dependencies in the debian/control file. One of
them is libxmlrpc-c3 (from http://xmlrpc-c.sourceforge.net/).

 What is this kernel based forwarding? why its useful?

It provides better performance than doing it through the daemon, less
CPU overhead and lower jitter.

 Does this mediaproxy-ng supports repacketization of rtp packets?

No that's not supported yet.

cheers

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-02 Thread aft
On Tue, Apr 2, 2013 at 8:42 PM, Richard Fuchs rfu...@sipwise.com wrote:
 On 04/02/13 10:02, aft wrote:

 Daemon installation failed with the following :

 call.c:15:27: fatal error: xmlrpc_client.h: No such file or directory

 Check out the list of dependencies in the debian/control file. One of
 them is libxmlrpc-c3 (from http://xmlrpc-c.sourceforge.net/).

Thanks for the reply. I have successfully built it.


 What is this kernel based forwarding? why its useful?

 It provides better performance than doing it through the daemon, less
 CPU overhead and lower jitter.

I was actually asking How it works? I mean when there is kernel based
forwarding is enabled, what does the daemon do compared to when the kernel
based forwarding is not enabled?

If i want do some modifications on rtp packets and intend to use kernel
based forwarding then where should i put my code? in daemon part or
the xtable module given there?

I was confused about the architecture of the package. When there is no kernel
based forwarding, Then the daemon should work like a simple udp relay. But
when there is kernel based forwarding, if the packets never comes up
to the userland,
then what does daemon do in that scenario?

 Does this mediaproxy-ng supports repacketization of rtp packets?

 No that's not supported yet.

 cheers

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



--
-aft

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-02 Thread Richard Fuchs
On 04/02/13 10:54, aft wrote:

 I was actually asking How it works? I mean when there is kernel based
 forwarding is enabled, what does the daemon do compared to when the kernel
 based forwarding is not enabled?
 
 If i want do some modifications on rtp packets and intend to use kernel
 based forwarding then where should i put my code? in daemon part or
 the xtable module given there?
 
 I was confused about the architecture of the package. When there is no kernel
 based forwarding, Then the daemon should work like a simple udp relay. But
 when there is kernel based forwarding, if the packets never comes up
 to the userland,
 then what does daemon do in that scenario?

Packet forwarding always happens in the userspace daemon during the
initial stages of a newly established media stream. This is to make sure
that the daemon can learn the correct media endpoints from the actual
RTP packets (they may be different than what was advertised in the SDP,
e.g. in NAT cases). Once the daemon is sufficiently satisfied with the
endpoints that it has learned (after a few seconds of media flowing both
ways), it will try to enable kernel forwarding for those streams. This
involves the daemon sending a command to the kernel module which
includes all the required parameters for packet forwarding, such as
local UDP port, source address/port and destination address/port. From
this point on, the kernel module will take over UDP packets arriving at
this local port, will not pass them up to userspace any more and instead
will send them right out again, towards their specified destination. The
daemon will never get to see those packets (with the exception of STUN
packets, a requirement for ICE) even though the userspace UDP socket
remains open. The daemon becomes a controlling entity, telling the
kernel what to do with those packets. It will periodically query the
kernel module for statistics on all established streams (packet counts
etc) to update its own internal stream statistics, which is important
for timeout handling. When the media stream is torn down, or in case of
re-invites or any other changes to the stream configuration, the daemon
sends another command to the kernel module to stop forwarding packets
arriving at these local UDP ports, at which point the packets will be
passed up to userspace again.

Therefore, if you wish to manipulate RTP packets, the code would
definitely have to be present in the daemon. If manipulation is required
for a particular stream, then the daemon can either choose not to enable
kernel forwarding for those streams, or the kernel module would have to
support the same manipulation of the RTP packets. In the latter case,
the control protocol between the daemon and the kernel module would have
to be extended to include details about which manipulations are to be
performed on the packets.

cheers

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-02 Thread Dani Popa
as far as i know, mediaproxy by AG Projects it's also kernel based
forwarding, so i don't understand what is the reasons to use another
mediaproxy let's say mediaproxy-ng.

dani

On Tue, Apr 2, 2013 at 5:54 PM, aft aft...@gmail.com wrote:

 On Tue, Apr 2, 2013 at 8:42 PM, Richard Fuchs rfu...@sipwise.com wrote:
  On 04/02/13 10:02, aft wrote:
 
  Daemon installation failed with the following :
 
  call.c:15:27: fatal error: xmlrpc_client.h: No such file or directory
 
  Check out the list of dependencies in the debian/control file. One of
  them is libxmlrpc-c3 (from http://xmlrpc-c.sourceforge.net/).

 Thanks for the reply. I have successfully built it.

 
  What is this kernel based forwarding? why its useful?
 
  It provides better performance than doing it through the daemon, less
  CPU overhead and lower jitter.

 I was actually asking How it works? I mean when there is kernel based
 forwarding is enabled, what does the daemon do compared to when the kernel
 based forwarding is not enabled?

 If i want do some modifications on rtp packets and intend to use kernel
 based forwarding then where should i put my code? in daemon part or
 the xtable module given there?

 I was confused about the architecture of the package. When there is no
 kernel
 based forwarding, Then the daemon should work like a simple udp relay. But
 when there is kernel based forwarding, if the packets never comes up
 to the userland,
 then what does daemon do in that scenario?
 
  Does this mediaproxy-ng supports repacketization of rtp packets?
 
  No that's not supported yet.
 
  cheers
 
  ___
  SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
  sr-users@lists.sip-router.org
  http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



 --
 -aft

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users




-- 
Dani Popa
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-02 Thread Andreas Granig

Hi,

On 04/02/2013 05:14 PM, Dani Popa wrote:

as far as i know, mediaproxy by AG Projects it's also kernel based
forwarding, so i don't understand what is the reasons to use another
mediaproxy let's say mediaproxy-ng.


Well, mediaproxy-ng development has started like 6 years ago as a 
replacement for mediaproxy (which at that point was python based and 
didn't do any kernel stuff) in our commercial solutions. This is the 
reason why there is still the tcp option in mediaproxy-ng to support 
the old control protocol used by kamailio's mediaproxy module. Around 
2-3 years ago we made it open source along with the sip:provider CE 
appliance.


The mediaproxy project has since evolved also to a kernel based project, 
and afaik the control protocol has changed as well, so both projects are 
not compatible anymore. I can't tell for sure the status of mediaproxy 
as we didn't use it since years. They are more opensips focused, but it 
probably works with kamailio as well (don't know though).


Since we switched to rtpproxy control protocol, it's a drop-in 
replacement for the rtpproxy project, which is pure user-space. There is 
some other rtpproxy control protocol compatible media replay 
(ipt_rtpproxy?) which I haven't used myself either.


So all in all, it's just about diversity, choose whatever suits you 
best. The only thing I can say for that matter is that Sipwise actively 
implements new features on top of mediaproxy-ng (with the new 
rtpproxy-ng kamailio module using a dictionary-based control protocol, 
which makes extending the protocol much easier in the future, and which 
passes back and forth the whole SDP body instead of just passing in some 
parameters and getting back out a new IP and port, which allows for 
advanced stuff like ICE manipulation, and in the future also transcoding 
etc).


Andreas

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-02 Thread Juha Heinanen
Dani Popa writes:

 as far as i know, mediaproxy by AG Projects it's also kernel based
 forwarding, so i don't understand what is the reasons to use another
 mediaproxy let's say mediaproxy-ng.

there are some differences:  ag projects mediaproxy does not support
ipv6.  on the other hand, it has web interface that shows active
mediaproxy sessions, which i'm not sure if mediaproxy-ng has.  neither
supports recording of calls, which is supported by rtpproxy.  so you can
make your decision based on what you need.

-- juha

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-02 Thread aft
On Tue, Apr 2, 2013 at 9:13 PM, Richard Fuchs rfu...@sipwise.com wrote:
 On 04/02/13 10:54, aft wrote:

 I was actually asking How it works? I mean when there is kernel based
 forwarding is enabled, what does the daemon do compared to when the kernel
 based forwarding is not enabled?

 If i want do some modifications on rtp packets and intend to use kernel
 based forwarding then where should i put my code? in daemon part or
 the xtable module given there?

 I was confused about the architecture of the package. When there is no kernel
 based forwarding, Then the daemon should work like a simple udp relay. But
 when there is kernel based forwarding, if the packets never comes up
 to the userland,
 then what does daemon do in that scenario?

 Packet forwarding always happens in the userspace daemon during the
 initial stages of a newly established media stream. This is to make sure
 that the daemon can learn the correct media endpoints from the actual
 RTP packets (they may be different than what was advertised in the SDP,
 e.g. in NAT cases). Once the daemon is sufficiently satisfied with the
 endpoints that it has learned (after a few seconds of media flowing both
 ways), it will try to enable kernel forwarding for those streams. This
 involves the daemon sending a command to the kernel module which
 includes all the required parameters for packet forwarding, such as
 local UDP port, source address/port and destination address/port. From
 this point on, the kernel module will take over UDP packets arriving at
 this local port, will not pass them up to userspace any more and instead
 will send them right out again, towards their specified destination. The
 daemon will never get to see those packets (with the exception of STUN
 packets, a requirement for ICE) even though the userspace UDP socket
 remains open. The daemon becomes a controlling entity, telling the
 kernel what to do with those packets. It will periodically query the
 kernel module for statistics on all established streams (packet counts
 etc) to update its own internal stream statistics, which is important
 for timeout handling. When the media stream is torn down, or in case of
 re-invites or any other changes to the stream configuration, the daemon
 sends another command to the kernel module to stop forwarding packets
 arriving at these local UDP ports, at which point the packets will be
 passed up to userspace again.

 Therefore, if you wish to manipulate RTP packets, the code would
 definitely have to be present in the daemon. If manipulation is required
 for a particular stream, then the daemon can either choose not to enable
 kernel forwarding for those streams, or the kernel module would have to
 support the same manipulation of the RTP packets. In the latter case,
 the control protocol between the daemon and the kernel module would have
 to be extended to include details about which manipulations are to be
 performed on the packets.


So the bottom line is i have to include the code in both places.

Another thing is i'm assuming you know much about the development of this media
relay. So i'm asking, is there any plan for including repacketization feature?

Its very crucial for our operation, so if there is no plan for it,
then i wish to do it
myself. Although i know nothing of its codebase, but if active developers help,
i think i can do it.

 cheers

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



--
-aft

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-02 Thread Richard Fuchs
On 04/02/13 17:39, aft wrote:

 So the bottom line is i have to include the code in both places.
 
 Another thing is i'm assuming you know much about the development of this 
 media
 relay. So i'm asking, is there any plan for including repacketization 
 feature?
 
 Its very crucial for our operation, so if there is no plan for it,
 then i wish to do it
 myself. Although i know nothing of its codebase, but if active developers 
 help,
 i think i can do it.

Yes and no. Repacketization isn't a priority for us, but we do have
definitive plans on supporting other modifications to the RTP packets in
the near future, most notably bridging between different RTP profiles
(such as RTP to SRTP). Repacketization would fit in there well. However,
I can't give a time line for this, and I also can't tell yet if we want
to support these operations in kernel mode at all. The CPU time required
might make the additional CPU overhead of passing packets back and forth
between user space and kernel space negligible. Or it might not, it's
hard to tell at this point.

cheers

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


Re: [SR-Users] mediaproxy-ng Tutorial

2013-04-01 Thread Dani Popa
what is mediaproxy-ng ? it's another media proxy?  What are the diff
between mediaproxy and mediaproxy-ng ?

dani


On Mon, Apr 1, 2013 at 5:03 PM, Aft nix aft...@gmail.com wrote:

 Hi,

 I stumbled upon this git://github.com/sipwise/mediaproxy-ng.git which
 looked very neat to me. Its said that it can be used with kamailio. It
 seems like its backed sipwise inc.

 But no documentation is given there. Anyone know of a
 tutorial/documentation for how to use it?
 --
 -aft

 ___
 SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
 sr-users@lists.sip-router.org
 http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users




-- 
Dani Popa
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users