How do VoIP calls work?

I was looking at something related to this, this week, and it occurred to me when I was, that most just have no idea, they might think the dial tone generated by the ATA comes from the VoIP provider for example.

So, How does VoIP work?

Setting up an outbound call

Your ATA is registered to the VoIP provider, you have the right settings in the ATA, you’ve got a dial plan entered that is Australian compatible, and so, you pick up the handset.

As you’ve adjusted the regional settings to match that of Australia, you hear your usual Aussie dial tone, and begin to push the numbers of the destination you want to reach.

The ATA has timers setup in it, such that it will wait for a certain time, such as 5 seconds, before generating the call.

Once the timer has been reached, the digits that have been dialled, and the information it already has (such as user name, password, and outbound proxy), are formed into an INVITE packet, this INVITE packet is sent to the VoIP provider, inviting it to setup a call to the destination.

The VoIP server, reads this packet, and if you’ve given it the right details, should respond with a “TRYING” packet, advising your ATA that yep, I got your request, I’m trying to see if I can do it.

Then, the VoIP server upon successfully parsing the packet, and proceeding through to either an upstream carrier, or terminating on it’s own equipment, will respond with either an “OK”, “BUSY”, or “SESSION PROGRESS”, advising the ATA that either – the call is answered and ongoing, failed, or progress (as in ringing, or in cases such as Mobile, message service to send your number).

This packet can also contain data on “RTP”, which is the audio stream used, and the ATA will connect to that RTP audio stream, and send / receive audio via that stream.

Upon successfully setting up the call, the reply should be “OK”, meaning the Invite sent was accepted, the remote party answered, and the call is ongoing. Assuming your ATA is reachable, and the packets contain correct RTP information, and everything else is in order, the call is setup and works.

So, SIP is used for ‘signalling’, and RTP is used for audio.

Setting up an inbound call

Incoming calls are not unlike the above outbound calls.

The server receives (either via an upstream provider, or it’s own termination equipment), a invite request, inviting it to setup a call with a user it should be responsible for.

The server checks it’s lists, much like Santa, and if it finds you on that list, it will then find out if you are registered, and the ‘contact’ line from the last register packet your ATA sent to the server.

Depending on it’s configuration, it could send the call to your ATA, route it elsewhere (such as call forwarding), IVRs, Voicemail, reject and call back.. the list is endless. In typical consumer cases, the call is first sent to the Contact line in the Register packet.

The VoIP server should then send an Invite packet to the VoIP ATA, using the last Contact line as the point to send the call.

The ATA when not in use should respond with RINGING, meaning that it’s trying to alert the user to the presence of the call. This follows it’s path back to the VoIP provider, and there is then a ringing signal sent to the caller’s provider – so they know the call is trying to work.

When you answer, the INVITE the VoIP server sent to you is then replied with an “OK” packet, and the VoIP server specifies the RTP stream, and the call is setup.

But, what if I am already on a call? Well, that depends on the configuration. If your ATA has Call Waiting enabled, the call is attempted, you hear the call waiting tones, and the same process for ‘ringing’ is followed.

The process for call waiting with SIP involves putting one audio stream into ‘hold’, and the other into ‘active’, they do this by using SIP packets to the VoIP server specifying an RTP option of ‘active’ or ‘inactive’. When a call is RTP  set to ‘inactive’, the call should be put on hold, where hold music is typically played (from the VoIP server).

If you don’t have call waiting enabled, there is a reply back to the VoIP server “BUSY HERE”, meaning the call can’t be accepted. It might also be a “DECLINE” packet – it should have the same effect.

The VoIP server then decides the next step based on configuration. If you have Voicemail enabled, the call should be sent to Voicemail. If you don’t, then the next natural step is for the provider to echo your busy reply, with a busy tone back to the server.