23 May
2018
23 May
'18
4:25 p.m.
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
23 May
23 May
4:52 p.m.
Pinter, Gerd. <g.pinter(a)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.rtp…
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
--
Mikko
5:02 p.m.
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).
5:57 p.m.
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(a)lists.kamailio.org> Im Auftrag von Daniel Tryba
Gesendet: Mittwoch, 23. Mai 2018 16:03
An: Kamailio (SER) - Users Mailing List <sr-users(a)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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
24 May
24 May
9:44 a.m.
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
11:52 a.m.
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.
2378
days inactive
2379
days old
5 comments
4 participants
participants (4)
-
Daniel Tryba -
Henning Westerholt -
Mikko Lehto -
Pinter, Gerd.