VOIP Vs VPN

NetworkNerd

Good luck

By far the easiest option will be to create a direct tunnel.

This is the way to go for sure. I can tell you I am running 4 sites (soon to be 5) from a single PBX at my main site, so if you're able to follow Scott's advice above, it can work very, very well for you. All of my sites are in the same metro area, and each remote site is connected via site-to-site vpn back to the main site. We have QoS configured at every firewall. And we do not filter / inspect SIP traffic as that can cause you a world of hurt.

Lost_Signal773

@NetworkNerd I'd like to point a few things. 1

QoS over the internet means nothing. Your carrier is not going to respect your tags unless its on a P2P or MPLS circuit.
Your carrier can't read tags on traffic if you encrypt it all together.

Lost_Signal773

Wrapping real time UDP based protocals with TCP is in general a waste of bandwidth (your going to retransmit data that will actually make the quality worse if it is processed out of order).

scottalanmiller

@Lost_Signal773 said:

Wrapping real time UDP based protocals with TCP is in general a waste of bandwidth (your going to retransmit data that will actually make the quality worse if it is processed out of order).

Yeah, not a good idea.

scottalanmiller

@Lost_Signal773 said:

@NetworkNerd I'd like to point a few things. 1

QoS over the internet means nothing. Your carrier is not going to respect your tags unless its on a P2P or MPLS circuit.

No, but QoS before it hits the Internet does the majority of what most people need. It is normally your own WAN link that is the choke point, not the open Internet. If it was, nothing we expect to work would work.

NetworkNerd

@scottalanmiller said:

@Lost_Signal773 said:

@NetworkNerd I'd like to point a few things. 1

QoS over the internet means nothing. Your carrier is not going to respect your tags unless its on a P2P or MPLS circuit.

No, but QoS before it hits the Internet does the majority of what most people need. It is normally your own WAN link that is the choke point, not the open Internet. If it was, nothing we expect to work would work.

Yep - that is how I should have worded it. Sorry if that was not clear from my post.

IT-ADMIN

Hi guys

i was unclear in my previous posts, what i have to say is :
when a sip client 192.168.1.10 want to talk with sip client 10.10.10.6 the following happen :
since we are connected via openvpn tunnel no NAT happen actually, because i run wireshark in both machine (remote vpnclient and IP PBX) and i saw that the packets carry the real IP of the sip phone not the public ip (source ip : 10.10.10.6 --- destination ip : 192.168.1.10)
what happened actually is routing not Nating, because there is a virtual tunnel between vpn client and vpn server and the vpn server route the packets to it destination (in this case 192.168.1.10 )
so the RTP traffic should be established without any issue since there is not NAT in the tunnel

i find the solution and now i have 2 site connected via openvpn and both location can call each other, the problem occur because i had wrong setting (in Ozeki server), before i set Discover public IP address using STUN server: stun.ekiga.net, this what created problem for me, i change it to my local IP PBX (Ozeki server) then everything work fine except sound quality, both side can hear each other but the sound was not totally clear (mixed with some noise),

any suggestion to improve sound quality knowing that in the main office the download speed is 4 mbs and upload speed is 0.5 mbs , and in the branch office we have download speed is 10 mbs and upload speed is 2 mbs ,
i think that my connection speed which decrease sound quality ????? or maybe something else ??? any suggestion ??

thank you all for you answers

scottalanmiller

That is a very tiny network connection. With only .5MB you will almost certainly have issues.

scottalanmiller

What codec are you using!

IT-ADMIN

hiiiiiiiiiiiiiiiii Mr Scott, how are you doing

first of all, the available audio codec that i have in my PBX system is:
PCMA (8)
PCMU (0)
telephone-event (101)
iLBC (98)
G722 (9)
GSM (3)
SPEEX (97)
SPEEX (100)
SPEEX (108)
L16 (103)
L16 (11)
L16 (10)
G728 (15)
G723 (4)
G726-16 (104)
G726-24 (105)
G726-32 (106)
G726-40 (107)

i select only 3 : PCMA (8) + PCMU (0) + GSM(3)

best regard

IT-ADMIN

i tried to select only GSM(3) since it is compatible with low bandwith but the call cannot be established, so i selected the additional 2 codec

scottalanmiller

Try g.723 and make it preferred so that that is tried first.

IT-ADMIN

unfortunatlly i don't have this option of preference,
which are the other codec that i have to select with this codec, can i select it only or other additional codec has to be selected alongside ???

thanks

scottalanmiller

You can enforce a codec by removing all others.

IT-ADMIN

aaah you mean i select only one codec (g.723)
ok i got it
thanks

scottalanmiller

Yes. That's not ideal but should work fine, at least for testing.

scottalanmiller

I have had good luck with iLBC as well.

IT-ADMIN

great, is there any other thing that affect QOS ?? separating voice and data (VLANs) maybe a good idea (hhhhhh i know that you hate VLANs) i'm joking Mr scott

have a great day Sir

scottalanmiller

QoS on the WAN links is definitely a big deal.

IT-ADMIN

@scottalanmiller

but i have no control over the wan traffic, after the packets come out from the wan interface i can't control it !!!