Hallo there,
we are a Broadcasting Network with about 50 Stations and try to establish our own SIP Network for high quality Audio over IP with Bitrates of 192-256 kbit for transmitting an accurate stereo signal. Since we encountered problems with connections via mobile Networks we set up our SIP Server as RTP Proxy which resolved all those multiple NAT issues. But on the other hand we pay for that with a higher jitter rate. The question is, if anyone has experience if this issue maybe can be solved by running the Sip Server on a standalone hardware plugged into network Port on our Hardware Firewall, instead of a virtual Machine running on VM with virtual switches and so on. The current SIP Server has a Public IP Address, but all the Traffic runs thru Firewall, VPN, Hardware Switches and Virtual Switches. What you think?
Thanks a Lot
Nice regards Gerhard Pinter
Pinter, Gerd. g.pinter@radionrw.de wrote:
Since we encountered problems with connections via mobile Networks we set up our SIP Server as RTP Proxy which resolved all those multiple NAT issues. But on the other hand we pay for that with a higher jitter rate. The question is, if anyone has experience if this issue maybe can be solved by running the Sip Server on a standalone hardware plugged into network Port on our Hardware Firewall, instead of a virtual Machine running on VM with virtual switches and so on. The current SIP Server has a Public IP Address, but all the Traffic runs thru Firewall, VPN, Hardware Switches and Virtual Switches. What you think?
Hi
Are you asking if RTP proxy can work in some other node than the same where Kamailio SIP proxy instance is running?
If so, answer to that is yes. See rtpproxy module parameter rtpproxy_sock: http://kamailio.org/docs/modules/5.1.x/modules/rtpproxy.html#rtpproxy.p.rtpp...
With that parameter you can set RTP proxy in HW and still have SIP proxy in VM.
If on the other hand you are asking about resource management to gain better jitter and such in virtual environment, then I have no clue.
Hope this helps
On Wed, May 23, 2018 at 01:25:58PM +0000, Pinter, Gerd. wrote:
The question is, if anyone has experience if this issue maybe can be solved by running the Sip Server on a standalone hardware plugged into network Port on our Hardware Firewall, instead of a virtual Machine running on VM with virtual switches and so on. The current SIP Server has a Public IP Address, but all the Traffic runs thru Firewall, VPN, Hardware Switches and Virtual Switches. What you think?
Virtualisation can/will add some jitter, but if you configure your setup correctly it will work fine for normal phone calls [*]. For example in VMware there is something caller NIC interrupt coalescing. AFAIK this is enable by default but introduces latency for RTP streams.
But have bare hardware with a rtpproxy will perform better, without any tuning a recent machine relayed 900Mbit/s (simulated RTP packets) with ease, running vmware a single cpu guest instance was limited to about 40Mbit/s, 2 CPUs in the guest topped out at about 90Mbit/s before jitter and eventual loss occured (with coalescing disabled).
*: jitter introduced by rtpengine is negligible compared to the jitter introduced by the endpoints themselves (either devices or network setup).
Thank you very much, this underpins my consideration. How to tell my Boss :o
Nice Regards
Gerd
-----Ursprüngliche Nachricht----- Von: sr-users sr-users-bounces@lists.kamailio.org Im Auftrag von Daniel Tryba Gesendet: Mittwoch, 23. Mai 2018 16:03 An: Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org Betreff: Re: [SR-Users] SIP Server Hardware or VM ??
On Wed, May 23, 2018 at 01:25:58PM +0000, Pinter, Gerd. wrote:
The question is, if anyone has experience if this issue maybe can be solved by running the Sip Server on a standalone hardware plugged into network Port on our Hardware Firewall, instead of a virtual Machine running on VM with virtual switches and so on. The current SIP Server has a Public IP Address, but all the Traffic runs thru Firewall, VPN, Hardware Switches and Virtual Switches. What you think?
Virtualisation can/will add some jitter, but if you configure your setup correctly it will work fine for normal phone calls [*]. For example in VMware there is something caller NIC interrupt coalescing. AFAIK this is enable by default but introduces latency for RTP streams.
But have bare hardware with a rtpproxy will perform better, without any tuning a recent machine relayed 900Mbit/s (simulated RTP packets) with ease, running vmware a single cpu guest instance was limited to about 40Mbit/s, 2 CPUs in the guest topped out at about 90Mbit/s before jitter and eventual loss occured (with coalescing disabled).
*: jitter introduced by rtpengine is negligible compared to the jitter introduced by the endpoints themselves (either devices or network setup).
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Am Mittwoch, 23. Mai 2018, 16:57:57 CEST schrieb Pinter, Gerd.:
Thank you very much, this underpins my consideration. How to tell my Boss :o
Nice Regards
Hello Gerd,
to help to convince your boss I would try to underline your thoughts with some measurements.
Something like this: if you get higher load on the e.g. VMWare Vcenter physical machines, then the jitter also increases etc.. Maybe you can test this during a time where the effect is also not that visible.
Maybe the talk from Alex Balashov at this year Kamailio World (available on youtube) about cloud environment restrictions and other things is also interesting for you, to give some arguments.
Best regards,
Henning
On Wed, May 23, 2018 at 02:57:57PM +0000, Pinter, Gerd. wrote:
Thank you very much, this underpins my consideration. How to tell my Boss :o
Since I wasn't explicit in my reply: we are running rtpengine in vmware. The test I did bare metal vs. vmware was to confirm there is no problem with vmware guests if you limit the amount of traffic per instance and make sure not to overprovision.
Sure rtpengine on bare metal will be better since there is no resource contention, but in my case that would mean multiple dedicated machines in multiple datacentra essentially wasting 90% of resources ideling.
-
Daniel Tryba -
Henning Westerholt -
Mikko Lehto -
Pinter, Gerd.