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
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@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
On Mon, Apr 1, 2013 at 8:23 PM, Dani Popa dani.popa@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@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
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
On Tue, Apr 2, 2013 at 7:05 PM, Richard Fuchs rfuchs@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
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
On Tue, Apr 2, 2013 at 7:44 PM, Richard Fuchs rfuchs@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
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
On Tue, Apr 2, 2013 at 8:42 PM, Richard Fuchs rfuchs@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
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
On Tue, Apr 2, 2013 at 9:13 PM, Richard Fuchs rfuchs@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
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
On Wed, Apr 3, 2013 at 5:50 AM, Richard Fuchs rfuchs@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
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@gmail.com wrote:
On Tue, Apr 2, 2013 at 8:42 PM, Richard Fuchs rfuchs@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
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
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
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
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
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
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
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
fascinating stuff. On Apr 5, 2013 6:06 PM, "Richard Fuchs" rfuchs@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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
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
El Wed, 10 Apr 2013 10:17:18 +0200 Klaus Darilion klaus.mailinglists@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
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
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
10 apr 2013 kl. 14:38 skrev Richard Fuchs rfuchs@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
El Wed, 10 Apr 2013 14:41:33 +0200 "Olle E. Johansson" oej@edvina.net escribió:
10 apr 2013 kl. 14:38 skrev Richard Fuchs rfuchs@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 :)
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
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
-
aft -
Aft nix
-
Andreas Granig -
Dani Popa -
Daniel-Constantin Mierla -
Jon Bonilla -
Juha Heinanen -
Klaus Darilion -
Marek Červenka -
Olle E. Johansson -
Richard Fuchs