SIP protocol in a nutshell
At the very beginning I feel obligated to provide a disclaimer: This post contains an extremely simplified case study to give you a rough view of what SIP protocol is used for and what is it's role in your VoIP business. As it is primarily targeted at non-technical people, I reduced the case to a bare minimum, leaving out many details important to make anything technically useful. My intention was to make it understandable by non-tech people wanting to start a VoIP business so that they get an idea about the technical aspect of the whole thing.
The core of any VoIP wholesale business is connecting your vendor (your partner who does call termination to destination networks and whom you pay for the traffic) with your customer (your partner who originates the calls to the destination network and pays you for the traffic). The important fact here is - you are the middleman, the traffic flows through your equipment, you charge your customer by the minute of traffic, your vendor charges you by the minute of traffic. Your revenue is the difference in the price per minute multiplied by the number of minutes that got trough your equipment. The customer never knows who the vendor is (and vice versa) because, obviously, if they did you're out of the game.
Now the question is, how do you connect your partners (vendors and customers) to your equipment so that the voice traffic can flow? Every party considered here will have some kind of equipment that we'll call a softswitch. The softswitch is actually a computer somewhere on the internet, having reliable network connection, with software that is capable of routing voice traffic. For simplicity we'll consider having only one customer and one vendor (and you of course). So a simplified topology of such a setup will look like this:
Every softswitch shown on the diagram will have a public IP address that will be used to access it from the internet, in this particular case to exchange voice traffic with another softswitch. The links between two softswitches are called trunks.
Now that we have established a simplified network topology for this case study, the question arises: how do the softswitches exchange voice traffic? The answer is (in almost all cases nowadays): using SIP protocol (Session Initiation Protocol). To keep things simple, I'm not going to dig into the internals of the SIP protocol because my intention is to give you a simplified overview of how things work at the technical level. (Anyway, if you feel masochistic or just extremely curious, you can find all the details in RFC documents relevant to SIP protocol at https://tools.ietf.org/wg/sip/ )
So let's take a look what happens when a voice call takes place using the SIP protocol. At first, we'll consider only the left side of the above diagram, where the customer is the originator of the call and you are the terminator of the call (we'll call them simply originator and terminator). The whole process can be divided into three phases (if the call is successful and we take into account that what follows is a dramatically simplified explanation of the process):
Let's examine every phase:
1. Session initiation
Originator sends the initial SIP INVITE message to the terminator. This message initiates a SIP dialog with the intent to establish a call. This message is strictly structured following relevant RFC standards, but not to bother you with all the technical details let's simplify things considerably and say that this message contains following information:
The core of any VoIP wholesale business is connecting your vendor (your partner who does call termination to destination networks and whom you pay for the traffic) with your customer (your partner who originates the calls to the destination network and pays you for the traffic). The important fact here is - you are the middleman, the traffic flows through your equipment, you charge your customer by the minute of traffic, your vendor charges you by the minute of traffic. Your revenue is the difference in the price per minute multiplied by the number of minutes that got trough your equipment. The customer never knows who the vendor is (and vice versa) because, obviously, if they did you're out of the game.
Now the question is, how do you connect your partners (vendors and customers) to your equipment so that the voice traffic can flow? Every party considered here will have some kind of equipment that we'll call a softswitch. The softswitch is actually a computer somewhere on the internet, having reliable network connection, with software that is capable of routing voice traffic. For simplicity we'll consider having only one customer and one vendor (and you of course). So a simplified topology of such a setup will look like this:
Every softswitch shown on the diagram will have a public IP address that will be used to access it from the internet, in this particular case to exchange voice traffic with another softswitch. The links between two softswitches are called trunks.
Now that we have established a simplified network topology for this case study, the question arises: how do the softswitches exchange voice traffic? The answer is (in almost all cases nowadays): using SIP protocol (Session Initiation Protocol). To keep things simple, I'm not going to dig into the internals of the SIP protocol because my intention is to give you a simplified overview of how things work at the technical level. (Anyway, if you feel masochistic or just extremely curious, you can find all the details in RFC documents relevant to SIP protocol at https://tools.ietf.org/wg/sip/ )
So let's take a look what happens when a voice call takes place using the SIP protocol. At first, we'll consider only the left side of the above diagram, where the customer is the originator of the call and you are the terminator of the call (we'll call them simply originator and terminator). The whole process can be divided into three phases (if the call is successful and we take into account that what follows is a dramatically simplified explanation of the process):
- Session initiation - here the two parties exchange information about the details of the call, the caller and callee phone numbers, codecs used for voice transmission in the second phase and similar stuff.
- Call in progress (if call is answered) - as the call is established, voice packets start to flow between the two softswitches over RTP protocol (Real Time Protocol). This is now possible because all the RTP settings (like IP addresses, ports, codecs etc) are already negotiated in the first phase.
- Session termination - one of the parties hangs up, the RTP traffic stops flowing and a SIP message signalling the end of the call is exchanged between the softswitches.
Let's examine every phase:
1. Session initiation
Originator sends the initial SIP INVITE message to the terminator. This message initiates a SIP dialog with the intent to establish a call. This message is strictly structured following relevant RFC standards, but not to bother you with all the technical details let's simplify things considerably and say that this message contains following information:
- the caller SIP address - containing information about the initiator of the call, holding the caller ID number of the caller (among other things) - consider this very similar to the From: header field in e-mails
- the callee SIP address - containing information about the targeted receiver of the call, holding the dialled phone number (among other things) - again, similar to the To: header field in e-mails
- the session description - containing information relevant for establishing the voice call.
Terminator answers with one of SIP response codes. For simplicity's sake let's say the terminator successfully routed the call and the destination phone is ringing. The response would be 180 Ringing.
As the callee picks up, terminator sends another response code: 200 OK. Now the call is established.
For billing purposes, it is important to mention that the call starting time should be the moment at which the SIP 200 OK message was exchanged.
2. Call in progress
As the call is established RTP traffic starts to flow between two softswitches, enabling the caller and the callee to hear each other. The IP addresses, ports, codecs, DTMF standards used and similar stuff are already defined in the first phase and as such are used here.
3. Session termination
One of the parties hangs up. As this happens, the softswitch where the hangup party is connected to sends a SIP BYE message to the other softswitch, informing it that the call is terminated.
For billing purposes, it is important that the call termination time should be the moment at which the SIP BYE message has been exchanged.
Now, we covered the left side of the diagram. Let's take a look at the whole picture, and see what happens as your customer initiates the call, and you route it to your vendor. It's actually the same process described above, but executed twice. So what happens is this:
- Customer sends INVITE to you
- You send INVITE to your vendor
- Vendor routes the call further and sends you 180 RINGING (if the target phone is ringing)
- You send 180 RINGING to the customer, so that the caller hears the ringing tone
- As the callee answers vendor sends you 200 OK
- You send 200 OK to the customer
- Now two RTP paths are established (between you and customer and between you and vendor)
- Call is in progress, RTP traffic flows through your softswitch
- Caller hangs up, customer sends you BYE
- You send BYE to the vendor
- Call is considered terminated
Simple enough, right? :)
Let me emphasize again: this post is not even close to a complete SIP protocol description. It is only meant to give you a rough overview of what happens when a call takes place. To successfully run a VoIP wholesale business you don't need to know all the SIP internals, your NOC staff will handle that.
Or, if you start small, as I encouraged you in one of my previous posts, you can always outsource an expert that will take care of the technical aspects of your business!

Comments
Post a Comment