PDA

View Full Version : VOIP discussion


metallicafan
06-29-2006, 10:06 AM
I'll admit right off the bat here that I have no experience with VoIP. I have done a couple searches on here and on Google, and while I have found several websites that try to explain what VoIP is and how it works many of them are somewhat confusing to me. I was hoping that we could have a VoIP discussion for VoIP noobs so that those of us not familiar with it can learn about it.

So let me start off with a couple VERY general questions.

1. Is VoIP just a general term for any voice being transfered over a digital network or is there some certian protocal that is associated with VoIP?

2. What makes VoIP work? For instance with web pages they are generally coded in HMTL and then transfered with TCP/IP over a network. What are the standards like this with VoIP?

If anyone else would like to jump in with questions please feel free to do so. Thanks.

moetop
06-29-2006, 10:26 AM
I'll admit right off the bat here that I have no experience with VoIP. I have done a couple searches on here and on Google, and while I have found several websites that try to explain what VoIP is and how it works many of them are somewhat confusing to me. I was hoping that we could have a VoIP discussion for VoIP noobs so that those of us not familiar with it can learn about it.

So let me start off with a couple VERY general questions.

1. Is VoIP just a general term for any voice being transfered over a digital network or is there some certian protocal that is associated with VoIP?

2. What makes VoIP work? For instance with web pages they are generally coded in HMTL and then transfered with TCP/IP over a network. What are the standards like this with VoIP?

If anyone else would like to jump in with questions please feel free to do so. Thanks.

1. Basically Yes, VoIP is a generic term. There are several protocols that can carry it. SIP being a very common one. There are others (http://www.protocols.com/pbook/VoIP.htm)

2. It's the protocol as mentioned above that carries the packet

If anyone reading has an extra PC laying around or can run VMware, you may want to mess around with Asterisk. It's free and very powerful. The Trixbox distribution of Linux with Asterisk (http://www.trixbox.org/) is particularly easy to install and get running

metallicafan
06-29-2006, 10:49 AM
Are there different codecs used for the voice "digitalization" ( if thats a word :D )?

Is VoIP encrypted or compressed during transport in any way?

PHUNBALL
06-29-2006, 12:09 PM
Honestly, a great place to start is to understand how traditional circuit switched telephone networks operate then you can translate that over to VoIP.

But, to answer your last question, yes there are different codecs, G.711 and G.729 being two of the more common. The actual media stream (RTSP) can be encrypted (Secure RTSP), but usually is not...

-(Xyphox)-
06-29-2006, 12:18 PM
one thing to remember about voip it will eat up bandwidth bigtime
And if you do not have a decent connection the quaility will suck
Will have delay's and such..
When i worked for my former employeer being an ISP i did a few installs of VOIP
And the people with the slower high speeds did not like the voip at all
Just some a little more info

Arch
06-29-2006, 12:34 PM
VoIP can work just fine over a slow connection. You can pump a G729 call through a 56k link without a problem assuming you have the proper QoS end-to-end.

XOR != OR
06-29-2006, 12:43 PM
VoIP can work just fine over a slow connection. You can pump a G729 call through a 56k link without a problem assuming you have the proper QoS end-to-end.
Eh, you'd be pushing it. Any latency over 150ms, and you start getting the walky talky effect. However, as far as actual bandwidth consumed, it's not so bad.

The thing to remember with some protocols is that they are not quite what you might be used to. For example, let's take SIP: SIP is just a signalling protocol, the actual data for the conversation travels over RTP on high number, random ports.

Funky, eh? It gets worse. A lot of the VoIP is a direct correlation to the old switched POTS system, which if you have ever worked with the POTS system, is fucked up.

Now, let's talk bandwidth. The most commonly used codec is 711.u ( or a, can't remember which ). This takes up 64kbit by itself. Add in overhead, and we're talking ~80-90kbit for a conversation. This is uncompressed unencrypted data. g729 is also popular, and it uses far less bandwidth ( 16kbit? 24kbit? don't remember ), however g729 requires a license per connection.

PHUNBALL
06-29-2006, 12:50 PM
one thing to remember about voip it will eat up bandwidth bigtime
And if you do not have a decent connection the quaility will suck
Will have delay's and such..
When i worked for my former employeer being an ISP i did a few installs of VOIP
And the people with the slower high speeds did not like the voip at all
Just some a little more info

I'm not sure where this information comes from regarding Voice bandwidth (it seems to pop up once a week), but it has been discussed here numerous times and it does not consume that much unless you consider 64k + overhead (100k for G.711 over a frame connection) a lot of bandwidth...

Arch
06-29-2006, 12:58 PM
Eh, you'd be pushing it. Any latency over 150ms, and you start getting the walky talky effect. However, as far as actual bandwidth consumed, it's not so bad.

The latency won't be bad using something like ppp multilink with fragmentation and interleaving.

metallicafan
06-29-2006, 01:06 PM
The thing to remember with some protocols is that they are not quite what you might be used to. For example, let's take SIP: SIP is just a signalling protocol, the actual data for the conversation travels over RTP on high number, random ports.


So when you say its just the signaling protocol - Does that mean that SIP just sets up the connections and then RTP accually transports the data(voice)? Why does it use random ports? Wouldnt this make setting up VoIP behind firewalls much more difficult?

RTP ( Real-time Transport Protocol ) - Works on top on UDP?
http://www.webopedia.com/TERM/R/RTP.html

Arch
06-29-2006, 06:20 PM
VoIP calls can be set up using any number of protocols. This is simply for connecting the devices together. Choices are:

SIP
MGCP
H.323
SCCP (Cisco proprietary)

The above are the four most common signaling protocols.

As you mentioned, the actual voice traffic is transported via RTP. RTP by default is unencrypted which means anyone who can sniff the traffic can reassemble the packets and listen to the conversation. In fact, Ethereal (or Wiresnake, whatever its called now) can do this for G711 calls with very little effort. G729 calls can be decoded with a number of commerical programs such as Acterna's suite of VoIP analysis tools. Secure RTP can encrypt the voice traffic. There are also a variety of secure method for the actual call signaling.

The random ports are not that big of a deal. Cisco VoIP uses 16384-32767 by default. Different vendors use different ports. Most firewalls, enterprise grade anyway, can handle H.323 / SIP / SCCP fixup, not sure on MGCP fixup.

Arch
06-29-2006, 06:25 PM
...A lot of the VoIP is a direct correlation to the old switched POTS system, which if you have ever worked with the POTS system, is fucked up.

Not sure what you mean by this? Can you elaborate as to what parts of VoIP resemble any part of the POTS?

XOR != OR
06-29-2006, 06:54 PM
Not sure what you mean by this? Can you elaborate as to what parts of VoIP resemble any part of the POTS?
I was thinking of SIP specifically. Setting up a seperate control line from the data isn't necessary in VoIP, it's a carry over from PRI-T1s. I think.

Arch
06-29-2006, 07:22 PM
I was thinking of SIP specifically. Setting up a seperate control line from the data isn't necessary in VoIP, it's a carry over from PRI-T1s. I think.

Well, it is, actually. All of the VoIP protocols, and many other TCP/IP programs use a separate control channel. MGCP, H.323 and SIP all use out of band signalling. There's nothing wrong with that, and it makes things such as QoS easier to configure. There's no point in classifying call control packets in the same priority queue as voice packets. You can always resend a control packet, you can't resend a voice packet.