1 Apr
2013
1 Apr
'13
5:03 p.m.
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
1 Apr
1 Apr
5:23 p.m.
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 <aftnix(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Dani Popa
2 Apr
2 Apr
3:13 p.m.
On Mon, Apr 1, 2013 at 8:23 PM, Dani Popa <dani.popa(a)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 <aftnix(a)gmail.com> wrote:
--
-aft
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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
4:05 p.m.
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
4:15 p.m.
On Tue, Apr 2, 2013 at 7:05 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
Hi,
On 04/01/13 10:03, Aft nix wrote:
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?
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
-aft
4:44 p.m.
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
5:02 p.m.
On Tue, Apr 2, 2013 at 7:44 PM, Richard Fuchs <rfuchs(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
-aft
5:42 p.m.
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
5:54 p.m.
On Tue, Apr 2, 2013 at 8:42 PM, Richard Fuchs <rfuchs(a)sipwise.com> 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?
--
-aft
On 04/02/13 10:02, aft wrote:
Thanks for the reply. I have successfully built it.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
6:13 p.m.
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
3 Apr
3 Apr
12:39 a.m.
On Tue, Apr 2, 2013 at 9:13 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 04/02/13 10:54, 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.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
-aft
2:50 a.m.
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
2:52 p.m.
On Wed, Apr 3, 2013 at 5:50 AM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 04/02/13 17:39, aft wrote:
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.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
-aft
2 Apr
2 Apr
6:14 p.m.
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 <aftnix(a)gmail.com> wrote:
On Tue, Apr 2, 2013 at 8:42 PM, Richard Fuchs
<rfuchs(a)sipwise.com> 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?
--
-aft
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Dani Popa
On 04/02/13 10:02, aft wrote:
Thanks for the reply. I have successfully built it.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users 
6:46 p.m.
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
9:35 p.m.
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
3 Apr
3 Apr
2:57 p.m.
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:
--
---------------------------------------
Marek Cervenka
=======================================
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users 
4 Apr
4 Apr
9:58 p.m.
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 -
10:15 p.m.
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
5 Apr
5 Apr
10:53 a.m.
Hello,
On 4/4/13 9:15 PM, Richard Fuchs wrote:
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 -
Hi,
On 04/04/13 14:58, 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.
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.
3:06 p.m.
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
8:34 p.m.
fascinating stuff.
On Apr 5, 2013 6:06 PM, "Richard Fuchs" <rfuchs(a)sipwise.com> wrote:
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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
10 Apr
10 Apr
11:17 a.m.
On 02.04.2013 15:05, Richard Fuchs wrote:
Hi,
On 04/01/13 10:03, Aft nix wrote:
I think it is a bad idea to name the relay "mediaproxy-ng" and the
corresponding Kamailio module "rtpproxy-ng".
regards
Klaus
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. 
12:02 p.m.
El Wed, 10 Apr 2013 10:17:18 +0200
Klaus Darilion <klaus.mailinglists(a)pernau.at> escribió:
On 02.04.2013 15:05, Richard Fuchs wrote:
Indeed
Hi,
On 04/01/13 10:03, Aft nix wrote:
I think it is a bad idea to name the relay "mediaproxy-ng" and the
corresponding Kamailio module "rtpproxy-ng".
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.
12:32 p.m.
Hi,
On 04/10/2013 11:02 AM, Jon Bonilla (Manwe) wrote:
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
I think it is
a bad idea to name the relay "mediaproxy-ng" and the
corresponding Kamailio module "rtpproxy-ng".
Indeed
3:38 p.m.
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
3:41 p.m.
10 apr 2013 kl. 14:38 skrev Richard Fuchs <rfuchs(a)sipwise.com>om>:
On 04/10/13 04:17, Klaus Darilion wrote:
Let's just call both "Bert" and find a good reason why.
Or "chrome". ;-)
/O
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.
5:24 p.m.
El Wed, 10 Apr 2013 14:41:33 +0200
"Olle E. Johansson" <oej(a)edvina.net> escribió:
10 apr 2013 kl. 14:38 skrev Richard Fuchs <rfuchs(a)sipwise.com>om>:
+1 to chrome :)
On 04/10/13 04:17, Klaus Darilion wrote:
Let's just call both "Bert" and find a good reason why.
Or "chrome". ;-)
/O
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.
3:54 p.m.
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
5:22 p.m.
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
4248
days inactive
4257
days old
29 comments
11 participants
participants (11)
-
aft -
Aft nix
-
Andreas Granig -
Dani Popa -
Daniel-Constantin Mierla -
Jon Bonilla -
Juha Heinanen -
Klaus Darilion -
Marek Červenka -
Olle E. Johansson -
Richard Fuchs