I'd be curious to know if your performance might actually be higher, owing to improved CPUs since the study was done, hyperthreading, more frames per NIC interrupt, etc.
-- Alex
-- Sent from my Samsung mobile, and thus lacking in the refinement one might expect from a proper keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/Mino Haluz mino.haluz@gmail.com wrote:Thank you, setting ulimits worked! And the performance is the same as stated in the document I mentioned! :)
One more thing, I found these errors in syslog:
Sep 13 18:38:18 perftest kamailio[5268]: ERROR: <core> [parser/sdp/sdp.c:211]: Invalid payload location Sep 13 18:38:18 perftest kamailio[5268]: ERROR: <core> [parser/sdp/sdp.c:227]: Invalid payload location Sep 13 18:38:18 perftest kamailio[5270]: ERROR: <core> [parser/sdp/sdp.c:227]: Invalid payload location
This is possibly something related to my sipp scenario, this is the INVITE sent from sipp
<![CDATA[
INVITE sip:800@perftest.vm SIP/2.0 Via: SIP/2.0/[transport] 10.0.2.36:[local_port];branch=[branch] From: "700" sip:500@10.0.2.36;tag=[call_number] To: sip:800@perftest.vm Call-ID: [call_id] CSeq: 1 INVITE Contact: "700" sip:700@10.0.2.36:[local_port] Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: [len]
v=0 o=user1 53655765 2353687637 IN IP[local_ip_type] 10.0.2.36 s=- c=IN IP[local_ip_type] 10.0.2.36 t=0 0 m=audio [auto_media_port] RTP/AVP 8 a=rtpmap:8 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11,16 ]]>
Do you see something that could cause this error ? Otherwise the call is initiated ok, but I really dont understand what is so strange to kamailio in this INVITE.
On Thu, Sep 13, 2012 at 6:37 PM, Peter Lemenkov lemenkov@gmail.com wrote:
2012/9/13 Mino Haluz mino.haluz@gmail.com:
You mean on the proxy side? I'm running rtpproxy as root, limits are still applied ? ulimit -s unlimited should do the trick ?
Yes, they usually applied even for superuser, and yes - this should help (if that's the issue).
-- With best regards, Peter Lemenkov.
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
_______________________________________________ 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
CPU E5504 Xeon 4MB cache 2GHz 800 concurrent calls with 92% CPU usage So 400-450 calls for 1GHz (with 99% CPU usage, in fact I cannot get it to 100% dunno why)
They had 325 calls per 1GHz, so yes, there must be some improvement ;)
On Thu, Sep 13, 2012 at 7:22 PM, Alex Balashov abalashov@evaristesys.com wrote:
I'd be curious to know if your performance might actually be higher, owing to improved CPUs since the study was done, hyperthreading, more frames per NIC interrupt, etc.
-- Alex
-- Sent from my Samsung mobile, and thus lacking in the refinement one might expect from a proper keyboard.
Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 Tel: +1-678-954-0670 Web: http://www.evaristesys.com/
Mino Haluz mino.haluz@gmail.com wrote: Thank you, setting ulimits worked! And the performance is the same as stated in the document I mentioned! :)
One more thing, I found these errors in syslog:
Sep 13 18:38:18 perftest kamailio[5268]: ERROR: <core> [parser/sdp/sdp.c:211]: Invalid payload location Sep 13 18:38:18 perftest kamailio[5268]: ERROR: <core> [parser/sdp/sdp.c:227]: Invalid payload location Sep 13 18:38:18 perftest kamailio[5270]: ERROR: <core> [parser/sdp/sdp.c:227]: Invalid payload location
This is possibly something related to my sipp scenario, this is the INVITE sent from sipp
<![CDATA[ INVITE sip:800@perftest.vm SIP/2.0 Via: SIP/2.0/[transport] 10.0.2.36:[local_port];branch=[branch] From: "700" <sip:500@10.0.2.36>;tag=[call_number] To: <sip:800@perftest.vm> Call-ID: [call_id] CSeq: 1 INVITE Contact: "700" <sip:700@10.0.2.36:[local_port]> Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: [len] v=0 o=user1 53655765 2353687637 IN IP[local_ip_type] 10.0.2.36 s=- c=IN IP[local_ip_type] 10.0.2.36 t=0 0 m=audio [auto_media_port] RTP/AVP 8 a=rtpmap:8 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-11,16 ]]>
Do you see something that could cause this error ? Otherwise the call is initiated ok, but I really dont understand what is so strange to kamailio in this INVITE.
On Thu, Sep 13, 2012 at 6:37 PM, Peter Lemenkov lemenkov@gmail.com wrote:
2012/9/13 Mino Haluz mino.haluz@gmail.com:
You mean on the proxy side? I'm running rtpproxy as root, limits are still applied ? ulimit -s unlimited should do the trick ?
Yes, they usually applied even for superuser, and yes - this should help (if that's the issue).
-- With best regards, Peter Lemenkov.
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
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
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
El Thu, 13 Sep 2012 19:39:43 +0200 Mino Haluz mino.haluz@gmail.com escribió:
CPU E5504 Xeon 4MB cache 2GHz 800 concurrent calls with 92% CPU usage So 400-450 calls for 1GHz (with 99% CPU usage, in fact I cannot get it to 100% dunno why)
They had 325 calls per 1GHz, so yes, there must be some improvement ;)
There's another rtpproxy replacement which is compatible with kamailio's rtpproxy module (no configuration changes needed in kamailio)
This one is threaded, works in kernel space with userspace failover and shoud improve rtpproxy's performance.
At the moment there are binaries only for debian amd64 but you could compile it yourself if you're interested in testing it:
http://deb.sipwise.com/spce/2.6/pool/main/n/ngcp-mediaproxy-ng/
Jon Bonilla (Manwe) writes:
There's another rtpproxy replacement which is compatible with kamailio's rtpproxy module (no configuration changes needed in kamailio)
This one is threaded, works in kernel space with userspace failover and shoud improve rtpproxy's performance.
how does that compare to ag-projects mediaproxy that also runs in kernel space?
-- juha
El Fri, 14 Sep 2012 08:29:42 +0300 Juha Heinanen jh@tutpro.com escribió:
Jon Bonilla (Manwe) writes:
There's another rtpproxy replacement which is compatible with kamailio's rtpproxy module (no configuration changes needed in kamailio)
This one is threaded, works in kernel space with userspace failover and shoud improve rtpproxy's performance.
how does that compare to ag-projects mediaproxy that also runs in kernel space?
Although this is called mediaproxy, it was updated to use rtpproxy protocol. We used it to replace rtpproxy in our installations.
Regarding features, I'm not familiar with mediaproxy. Can't compare them.
Hi Jon,
questions: - Can i also use it for IPv4/IPv6 Translation and Bridging? I did not find any internal/external ip-Parameters as in the old RTP-Proxy - Does it also support the basic media functions, such as recording and playback? - Are the sources somewhere available?
Thanks, Carsten
2012/9/13 Jon Bonilla manwe@aholab.ehu.es:
El Thu, 13 Sep 2012 19:39:43 +0200 Mino Haluz mino.haluz@gmail.com escribió:
CPU E5504 Xeon 4MB cache 2GHz 800 concurrent calls with 92% CPU usage So 400-450 calls for 1GHz (with 99% CPU usage, in fact I cannot get it to 100% dunno why)
They had 325 calls per 1GHz, so yes, there must be some improvement ;)
There's another rtpproxy replacement which is compatible with kamailio's rtpproxy module (no configuration changes needed in kamailio)
This one is threaded, works in kernel space with userspace failover and shoud improve rtpproxy's performance.
At the moment there are binaries only for debian amd64 but you could compile it yourself if you're interested in testing it:
http://deb.sipwise.com/spce/2.6/pool/main/n/ngcp-mediaproxy-ng/
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
El Sun, 16 Sep 2012 04:43:42 +0200 Carsten Bock carsten@ng-voice.com escribió:
questions:
- Can i also use it for IPv4/IPv6 Translation and Bridging? I did not
find any internal/external ip-Parameters as in the old RTP-Proxy
Yes. Ipv4/Ipv6 translation and bridging is fully supported. There's no internal/external IP parameters because you can bridge between any interface, not only two.
I'm CC-ing the mail to the developer, Richard Fuchs. I'm not sure he reads this mailing list.
- Does it also support the basic media functions, such as recording
and playback?
No AFAIK.
- Are the sources somewhere available?
We'll move the project to github soon. Meanwhile you have a tgz of the current version in our debian repo
http://deb.sipwise.com/spce/2.6/pool/main/n/ngcp-mediaproxy-ng/ngcp-mediapro...
On 09/17/12 03:20, Jon Bonilla (Manwe) wrote:
El Sun, 16 Sep 2012 04:43:42 +0200 Carsten Bock carsten@ng-voice.com escribió:
questions:
- Can i also use it for IPv4/IPv6 Translation and Bridging? I did not
find any internal/external ip-Parameters as in the old RTP-Proxy
Yes. Ipv4/Ipv6 translation and bridging is fully supported. There's no internal/external IP parameters because you can bridge between any interface, not only two.
I'm CC-ing the mail to the developer, Richard Fuchs. I'm not sure he reads this mailing list.
I do, but didn't want to interrupt. ;)
We use the internal and external flags for slightly different purposes: to make a distinction between IPv4 and IPv6 in the initial offer. Mediaproxy has no notion of an internal or external interface, but needs to know whether to return an IPv4 or an IPv6 address for the INVITE. So we use the "I" and "E" flags for the calling and the called party to specify whether that endpoint is on IPv4 or IPv6, respectively. It's really only needed for the called party, but hey, why not keep it consistent if we can, right?
- Does it also support the basic media functions, such as recording
and playback?
No AFAIK.
Correct, we've had no need for that so far. The low-level code does support a "mirror" destination for single packet streams, meaning it will duplicate all packets to a second destination, but that's still an unused feature as of yet.
BR
Hi Richard,
i've noticed the use of the i and e flags for your mediaproxy implementation. Right now i'm testing a minor patch for the RTPProxy module to allow automatic selection of "ie" or "ei" just for this use case based on the media-ip type (e.g. always set "ie" if you have an IPv4 address in the SDP, always set "ei", if you have an IPv6 address).
Carsten
2012/9/17 Richard Fuchs rfuchs@sipwise.com:
On 09/17/12 03:20, Jon Bonilla (Manwe) wrote:
El Sun, 16 Sep 2012 04:43:42 +0200 Carsten Bock carsten@ng-voice.com escribió:
questions:
- Can i also use it for IPv4/IPv6 Translation and Bridging? I did not
find any internal/external ip-Parameters as in the old RTP-Proxy
Yes. Ipv4/Ipv6 translation and bridging is fully supported. There's no internal/external IP parameters because you can bridge between any interface, not only two.
I'm CC-ing the mail to the developer, Richard Fuchs. I'm not sure he reads this mailing list.
I do, but didn't want to interrupt. ;)
We use the internal and external flags for slightly different purposes: to make a distinction between IPv4 and IPv6 in the initial offer. Mediaproxy has no notion of an internal or external interface, but needs to know whether to return an IPv4 or an IPv6 address for the INVITE. So we use the "I" and "E" flags for the calling and the called party to specify whether that endpoint is on IPv4 or IPv6, respectively. It's really only needed for the called party, but hey, why not keep it consistent if we can, right?
- Does it also support the basic media functions, such as recording
and playback?
No AFAIK.
Correct, we've had no need for that so far. The low-level code does support a "mirror" destination for single packet streams, meaning it will duplicate all packets to a second destination, but that's still an unused feature as of yet.
BR
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 09/17/12 11:03, Carsten Bock wrote:
Hi Richard,
i've noticed the use of the i and e flags for your mediaproxy implementation. Right now i'm testing a minor patch for the RTPProxy module to allow automatic selection of "ie" or "ei" just for this use case based on the media-ip type (e.g. always set "ie" if you have an IPv4 address in the SDP, always set "ei", if you have an IPv6 address).
This may work if those use cases are the only ones you're going to run into, but here we also use it for the "II" and "EE" cases, i.e. all calls and not only those where v4/6 translation is required. This is especially important for IPv4 NAT traversal.
BR
Hi,
short question: The provided Debian-Packages are Version 2.0.2, while the source (and the containing debian/changelog) states to be version 2.0.1. I hope, that minor change wasn't a major bug-fix? ;-) Are there any differences between 2.0.2 and 2.0.1?
Thanks, Carsten
2012/9/17 Jon Bonilla manwe@aholab.ehu.es:
El Sun, 16 Sep 2012 04:43:42 +0200 Carsten Bock carsten@ng-voice.com escribió:
questions:
- Can i also use it for IPv4/IPv6 Translation and Bridging? I did not
find any internal/external ip-Parameters as in the old RTP-Proxy
Yes. Ipv4/Ipv6 translation and bridging is fully supported. There's no internal/external IP parameters because you can bridge between any interface, not only two.
I'm CC-ing the mail to the developer, Richard Fuchs. I'm not sure he reads this mailing list.
- Does it also support the basic media functions, such as recording
and playback?
No AFAIK.
- Are the sources somewhere available?
We'll move the project to github soon. Meanwhile you have a tgz of the current version in our debian repo
http://deb.sipwise.com/spce/2.6/pool/main/n/ngcp-mediaproxy-ng/ngcp-mediapro...
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
El Tue, 6 Nov 2012 18:30:07 +0100 Carsten Bock carsten@ng-voice.com escribió:
Hi,
short question: The provided Debian-Packages are Version 2.0.2, while the source (and the containing debian/changelog) states to be version 2.0.1. I hope, that minor change wasn't a major bug-fix? ;-) Are there any differences between 2.0.2 and 2.0.1?
It contains a couple of bugfixes. Somehow the source is not being synced during the release process. I'll ask and publish the latest ones.
thanks
Jon
Hi Jon, Hi Richard,
i wanted to say thankyou for this great piece software! I installed it on a Intel Atom Server (x86) last week, which is working as a P-CSCF in the Point-of-Presence (PoP) of a customer. Perfect! I'll make some loadtests on that system next week and i'll let you know the results.
However, some questions remain: - any update on the 2.0.2 sources? This URL http://deb.sipwise.com/spce/2.6/pool/main/n/ngcp-mediaproxy-ng/ still has only the 2.0.1 sources... - is there a changelog availabe somewhere? - i haven't looked at the sources, but can i query the RTP-Stats in Release 2.0.2 ($rtpstat as in rtpproxy.org)? I get an error from the ngcp-mediaproxy-ng, if query for the RTP-Stats...
Kind regards & thank you, Carsten
2012/11/6 Jon Bonilla manwe@aholab.ehu.es:
El Tue, 6 Nov 2012 18:30:07 +0100 Carsten Bock carsten@ng-voice.com escribió:
Hi,
short question: The provided Debian-Packages are Version 2.0.2, while the source (and the containing debian/changelog) states to be version 2.0.1. I hope, that minor change wasn't a major bug-fix? ;-) Are there any differences between 2.0.2 and 2.0.1?
It contains a couple of bugfixes. Somehow the source is not being synced during the release process. I'll ask and publish the latest ones.
thanks
Jon
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
El Mon, 12 Nov 2012 19:57:18 +0100 Carsten Bock carsten@ng-voice.com escribió:
Hi Jon, Hi Richard,
i wanted to say thankyou for this great piece software! I installed it on a Intel Atom Server (x86) last week, which is working as a P-CSCF in the Point-of-Presence (PoP) of a customer. Perfect! I'll make some loadtests on that system next week and i'll let you know the results.
However, some questions remain:
- any update on the 2.0.2 sources? This URL
http://deb.sipwise.com/spce/2.6/pool/main/n/ngcp-mediaproxy-ng/ still has only the 2.0.1 sources...
- is there a changelog availabe somewhere?
- i haven't looked at the sources, but can i query the RTP-Stats in
Release 2.0.2 ($rtpstat as in rtpproxy.org)? I get an error from the ngcp-mediaproxy-ng, if query for the RTP-Stats...
Kind regards & thank you, Carsten
Hi Carsten. The problem with the source and bin packages has been solved. They are back in sync. You can apt-get source ngcp-mediaproxy-ng to get the source or download it from
http://deb.sipwise.com/spce/2.6/pool/main/n/ngcp-mediaproxy-ng/
I "promise" (hopefully as it does not depend on me 100%) that we'll have the github-jenkins-automated_tests glue ready by the end of the year (after our 2.7 version has been released) so the code will be available in github in a much more accesible and open way.
Hi,
On 11/12/12 13:57, Carsten Bock wrote:
- is there a changelog availabe somewhere?
The changelog is installed through the debian packages in /usr/share/doc/$PACKAGE/changelog.gz, while the source .tgz contains it in the ../debian/changelog file.
- i haven't looked at the sources, but can i query the RTP-Stats in
Release 2.0.2 ($rtpstat as in rtpproxy.org)? I get an error from the ngcp-mediaproxy-ng, if query for the RTP-Stats...
That command isn't currently implemented, but it should be fairly easy to do, so I'll see if I can include it in the next version.
cheerse
-
Alex Balashov -
Carsten Bock -
Jon Bonilla -
Juha Heinanen -
Mino Haluz -
Richard Fuchs