Wisdom of Helios


5 Comments

Basics of Session Initiation Protocol (SIP) (part-5)

The previous posts were –

Basics of Session Initiation Protocol (part – 1)

Basics of Session Initiation Protocol  (part-2)

Basics of Session Initiation Protocol  (part-3)

Basics of Session Initiation Protocol  (part-4)

A Typical example of SIP:

Let us consider an example user Alice wants to communicate with user  Bob . Proxy 1 and Proxy 2 help to setup the session on behalf of the users. This common arrangement of the proxies and the end-users is called “SIP Trapezoid”.

The messages appear vertically in the order they appear i.e. the message on top comes first followed by others. The direction of arrows shows the sender and recipient of each message.

The transaction starts with Alice making an INVITE request for Bob. But Alice doesn’t know the exact location of Bob in the IP network. So it passes the request to Proxy1. Proxy1 on behalf of Alice forwards an INVITE request for Bob to Proxy2. It sends a TRYING response to Alice informing that it is trying to reach Bob. The response could have been different.

Receiving INVITE X2 from Proxy1, Proxy2 works in a similar fashion as Proxy1. It forwards an INVITE request to Bob(note: Here Proxy2 knows the location of Bob. If it didn’t know the location, it would have forwarded it to another proxy server. So an INVITE request may travel through several proxies before reaching the recipient). After forwarding INVITE X3 Proxy2 issues a TRYING response to Proxy1.

Bob’s SIP/Soft phone, on receiving the INVITE request, starts ringing informing Bob that a call request has come. It sends a RINGING response back to Proxy2 which reaches Alice through Proxy1. So Alice gets a feedback that Bob has received the INVITE request.

Bob at this point has a choice to accept or decline the call. Let’s assume that he decides to accept it. As soon as he accepts the call, a 200 OK response is sent by the phone to Proxy2. Retracing the route of INVITE, it reaches Alice. The softphone of Alice sends an ACK message to confirm the setup of the call. This 3-way-handshaking (INVITE+OK+ACK) is used for reliable call setup. Note that the ACK message is not using the proxies to reach Bob as by now Alice knows the exact location of Bob.

Once the connection has been setup, media flows between the two endpoints. Media flow is controlled using protocols different from SIP e.g.  SDP, RTP etc.

When one party in the session decides to disconnect, it (Bob in this case) sends a BYE message to the other party. The other party sends a 200 OK message to confirm the termination of the session.

This part is unabashedly copied form here . SIP Tutorial has written a nice topic on it.

Relation among Call, Dialog, Transaction & Message

If you are confused with the relation among Call, Dialog, Transaction & Message, you are not alone. Quite a good number of people get confused regarding the relation in the beginning.

Messages are the individual textual bodies exchanged between a server and a client. There can be two types of messages. They are – Requests and Responses.

Transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction.

Dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is identified by a Call-ID, a local tag and a remote tag. A dialog used to be referred as a ‘call leg’.

Call of a callee comprises of all the dialogs it is involved in. I think a Call is same as a Session.

My Aritcle is over here. It was just for the beginners. I will recommend further reading on SIP .


5 Comments

Basics of Session Initiation Protocol (SIP) (part-4)

The previous posts were –

Basics of Session Initiation Protocol (part – 1)

Basics of Session Initiation Protocol  (part-2)

Basics of Session Initiation Protocol  (part-3)

SIP Message Samples:

The following samples show the message exchange between two User Agents for the purpose of setting up a voice call. SIP user alice@mssys.com invites SIP user bob@msinfo.com to a call for the purpose of discussing lunch. Alice sends an INVITE request containing an SDP body. Bob replies with a 200 OK response also containing an SDP body.

Request Commands:

Request Message Line

Description

INVITE sip:bob@msinfo.com SIP/2.0 Request line: Method type, request URI (SIP address of called party), SIP version.
Via: SIP/2.0/UDP Address of previous hop. It contains the local address of alice (initiator)i.e. mssys.com where it is expecting the responses to come.
Max Forward : 70 It is used to limit the number of hops that this request may take before reaching the recipient (Here is 70). It is decreased by one at each hop. It is necessary to prevent the request from traveling forever in case it is trapped in a loop.
From: Alice <sip:alice@mssys.com> User originating this request
TO :  Bob< sip:bob@msinfo.com>tag=1928301774; User being invited, as specified originally. It also optionally contains a tag which is a pseudo-random sequence inserted by the SIP application. It works as an identifier of the caller in the dialog.
Call-ID: 2388990012@alice_ws.mssys.com Globally unique ID of this call. It is  generated as the combination of a pseudo-random string and the softphone’s IP address.
CSeq: 1243 INVITE Command sequence. Identifies transaction. It contains an integer and a method name. When a transaction starts, the first message is given a random CSeq. After that it is incremented by one with each new message. It is used to detect non-delivery of a message or out-of-order delivery of messages.
Contact< sip:alice@mssys.com > It contains a SIP or SIPS URI that is a direct route to alice. It contains a username and a fully qualified domain name(FQDN). It may also have an IP address. (Via field is used to send the response to the request. Contact field is used to send future requests. That is why the 200 OK response from user2 goes to user1 through proxies. But when user2 generates a BYE request (a new request and not a response to INVITE), it goes directly to user1 bypassing the proxies)
Subject: Lunch today. Call subject and/or nature.
Content-Type: application/SDP Type of body—in this case SDP.(This is beyond the scope of SIP and is controlled by SDP which will be discussed later )
Content-Length: 182 Number of bytes in the body. If the transport type is UDP, then the Content-Length header is not mandatory. It is, however, mandatory for TCP.
Blank line marks end of SIP headers and beginning of body.

Response Commands:

SIP/2.0 200 OK
Via: SIP/2.0/UDP site4.server2.com;branch=z9hG4bKnashds8;received=192.0.2.3
Via: SIP/2.0/UDP site3.server1.com;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2
Via: SIP/2.0/UDP pc33.server1.com;branch=z9hG4bK776asdhds;received=192.0.2.1
To: user2 <sip:user2@server2.com>;tag=a6c85cf
From: user1 <sip:user1@server1.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.server1.com
CSeq: 314159 INVITE
Contact: <sip:user2@192.0.2.4>
Content-Type: application/sdp
Content-Length: 131

—- User2 Message Body Not Shown —-

The header fields that follow the status line are similar to those in a request. I will just mention the differences-

Via

There are more than one via field. This is because each element through which the INVITE request has passed has added its identity in the Via field. Three Via fields are added by softphone of user1, server1 the first proxy and server2 the second proxy. The response retraces the path of INVITE using the Via fields. On its way back, each element removes the corresponding Via field before forwarding it back to the caller.

To:

Note that the To field now contains a tag. This tag is used to represent the callee in a dialog.

Contact:

It contains the exact address of user2. So user1 doesn’t need to use the proxy servers to find user2 in the future.

It is a 2xx response. However responses can be different depending on particular situations.

Next  post related to SIP –

Basics of Session Initiation Protocol  (part-5)


Leave a comment

Basics of Session Initiation Protocol (SIP) (part-3)

The previous posts were –

Basics of Session Initiation Protocol (part – 1)

Basics of Session Initiation Protocol  (part-2)

SIP Message Parts:

A SIP Message usually has 3 parts-

Start/First Line.

Header.

Body/Content.

Start Line—Conveys the message type(request or response).

Start Line  = Method for Request or Response Code for Response + Protocol version.

A Request’s Start Line(Request Line) uses the following format:

<Request method><URI><Protocol version>

URI indicates the user/service to which the request is addressed. This address/URI can be re-written by the Proxy Servers.

An Example of Request Line is –

REGISTER sip:arstechnica.com SIP/2.0

A Response’s Start Line (Status Line) uses the following format:

<Protocol  version><Response Code><Reason phrase>

The reason phrase could be any text describing the nature of the response.

An Example of Status Line is –

SIP/2.0 200 OK

 

Header—Conveys the message attributes and modifies the meaning of the message. Very similar to the HTTP Headers.

All headers maintains the format-

<name>:<value>

Headers can span multiple lines. Some SIP headers such as Via, Contact, Route and Request-Route can appear multiple times in a message or, alternatively, can take multiple comma-separated values in a single header occurrence.

An Example of Header is –

Contact: sip:gilad@voxisoft.com;Expires=2000

Contact is the header name, sip:gilad@voxisoft.com is the value, and expires=2000 is a parameter. Other parameters may appear separated by semicolons.

Body(Content)— Describes the Session to be initiated (for example, in a multimedia session this may include audio and video codec types, sampling rates etc.), or alternatively it may be used to contain opaque textual or binary data of any type which relates in some way to the session. Message bodies can appear both in request and in response messages. SIP makes a clear distinction between signaling information, conveyed in the SIP Start Line and headers, and the session description information, which is outside the scope of SIP.

Possible body types include:

ü   SDP—Session Description Protocol (SDP).

ü   Multipurpose Internet Mail Extensions (MIME).

ü  Others—to be defined in the IETF and in specific

Other posts related to SIP –

Basics of Session Initiation Protocol  (part-4)

Basics of Session Initiation Protocol  (part-5)


Leave a comment

Basics of Session Initiation Protocol (SIP) (part-2)

The previous post was –

Basics of Session Initiation Protocol (part – 1)

Components of a SIP

Entities interacting  in SIP scenario are called User Agents (UA).

Each entity has specific functions and participates in SIP communication as a client (initiates requests), as a server (responds to requests), or as both. One “physical device” can have the functionality of more than one logical SIP entity. For example, a network server working as a Proxy server can also function as a Registrar at the same time.

User Agents may operate in two fashions –

  • User Agent Client (UAC) : It generates requests and send those requests to servers.
  • User Agent Server (UAS) : It gets requests, processes those requests and generate responses.

Note: A single UA may function as both.

Clients:

It may be a softphone application running on your PC or a messaging device in your IP phone. It generates a request when you try to call another person over the network and sends the request to a server (generally a proxy server).

Servers:

Servers are in general part of the network. They possess a predefined set of rules to handle the requests sent by clients.
Servers can be of several types –

Proxy Server:  When a request is generated, the exact address of the recipient is not known in advance. So the client sends the request to a proxy server. The server on behalf of the client (as if giving a proxy for it) forwards the request to another proxy server or the recipient itself.

Redirect  Server:  Redirects the request back to the client indicating that the client needs to try a different route to get to the recipient. It generally happens when a recipient has moved from its original position either temporarily or permanently. Unlike Proxy servers the redirect server does not forward requests to other servers.

Registrar  Server:  Users have to register their locations to a Registrar server. Users from time to time refresh their locations by registering (sending a special type of message) to a Register server.

Location Server:  The addresses registered to a Registrar are stored in a Location Server.

Message Types and Commands of a SIP

There are two types of SIP messages:

Requests—sent from the client to the server.

Responses—sent from the server to the client.

Request Commands:

Command/Method

Description

INVITE Invites a user to call
ACK Confirms a final response to a INVITE
BYE Terminates a Call
CANCEL Cancel searching and ringing
OPTION Queries the capabilities of Sever/Other side
REGISTER Register the Location Service
INFO Send the mid-session info that will not modify the Session state

Response Commands: Response Message  contains numeric response codes. There are 2 types of Response  Commands and 6 classes –

2 Types :-

Provisional (1xx class)—provisional responses are used by the server to indicate progress, but they do not terminate SIP transactions.

 Final (2xx, 3xx, 4xx, 5xx, 6xx classes)—final responses terminate SIP transactions.

6 Classes:-

1xx : Provisional,Searcing,Quering,Ringing.

2xx : Success.

3xx : Redirection,Forwarding

4xx : Request Failure(client mistakes).

5xx : Server failure.

6xx : Global failure(busy,refusal,not available anywhere).

Other posts related to SIP –

Basics of Session Initiation Protocol  (part-3)

Basics of Session Initiation Protocol  (part-4)

Basics of Session Initiation Protocol  (part-5)


Leave a comment

Basics of Session Initiation Protocol (SIP) (part-1)

It is a big topic . So I decided to publish it as a series. The intended  viewers are the beginners only who want to wet their feet with SIP, VoIP and IMS(Internet Multimedia SubSystem) based application development. So , Lets go ———

What is SIP and where it is ?

SIP (Session Initiation Protocol) is a signaling protocol used to create, manage and terminate sessions in an IP based network. A session could be a simple two-way telephone call or it could be a collaborative multi-media conference session.

It is an application-layer control protocol.

SIP sessions involve one or more participants and can use unicast or multicast communication. Borrowing from ubiquitous Internet protocols, such as HTTP and SMTP, SIP is text-encoded and highly extensible. SIP may be extended to accommodate features and services such as call control services, mobility, interoperability with existing telephony systems, and more.

Can and Can’t by SIP

The job of SIP is limited to only the setup and control of sessions. The details of the data exchange within a session e.g. the encoding or codec related to an audio/video media is not controlled by SIP and is taken care of by other protocols.

There are mainly 4 types of functions that a SIP performs –

  1. Establishment of user location (i.e. translating from a user’s name to their current network address).
  2. Negotiating the provided features among participants in a session.
  3. Call management – for example adding, dropping, or transferring participants.
  4. Changing the features of a session while in progress.

SIP is not a resource reservation protocol and it has nothing to do with quality of service (QoS).

SIP can work in a framework with other protocols to make sure these roles are played out – but SIP does not do them.

SIP can function with SOAP, HTTP, XML, VXML , WSDL, UDDI, SDP and others. Everyone has a role to play!

Other posts related to SIP –

Basics of Session Initiation Protocol  (part-2)

Basics of Session Initiation Protocol  (part-3)

Basics of Session Initiation Protocol  (part-4)

Basics of Session Initiation Protocol  (part-5)


Leave a comment

Packet Switching & Circuit Switching

There are mainly two methodologies for transmitting data over the computer network – 1. Packet Switching  and   2. Circuit Switching.

Packet Switching :

A digital networking communications method that groups all transmitted data – regardless of content, type, or structure – into suitably sized blocks, called packet.

In packet-switching, the packets are sent towards the destination irrespective of each other. Each packet has to find its own route to the destination. There is no predetermined path; the decision as to which node to hop to in the next step is taken only when a node is reached. Each packet finds its way using the information it carries, such as the source and destination IP addresses.

If a packet switch does not have enough resources, it sends a Connect Reject and the Connection Establishment Fails.

 

Advantage of Packet Switching:

More efficient use of overall network bandwidth due to flexibility in routing the smaller packets over shared links. Packet switching networks are often cheaper to build as less equipment is needed given this ability to share.

Another benefit of packet switching is known as “pipelining”.

Disadvantage of Packet Switching:

Longer delays in receiving messages due to the time required to package and route packets. For many applications, delays are not long enough to be significant, but for high-performance applications like real-time video, additional data compression and QoS technology is often required to achieve the required performance levels.

Potential for network security risks due to the use of shared physical links. Protocols and other related elements on packet switching networks must designed with the appropriate security precautions.

Circuit Switching :

Circuit-switched is a type of network in which a physical path is obtained for and dedicated to a single connection between two end-points in the network for the duration of the connection.

Ordinary voice phone service is circuit-switched. The telephone company reserves a specific physical path to the number you are calling for the duration of your call. During that time, no one else can use the physical lines involved.

Traditional PSTN phone system uses circuit switching while VoIP uses packet switching.

  Difference Between Packet and Circuit Switching :

Packet Switching Circuit Switching
Variable rate data stream(packed) over a shared connection Constant rate data stream(packed) over some dedicated connection
characterized by a fee per unit of information. characterized by a fee per time unit of connection time, even when no data is transferred
Low reliable , subject to congestion Highly reliable

There are 2 modes of Packet switching –

  1. Connectionless Packet Switching  /  Datagram Switching.
  2. Connection Oriented Packet Switching  /  Virtual Circuit Switching.

Connectionless Packet Switching  /  Datagram Switching :

Transmission of packets are made on Per-Packet basis.

  1. Each packet routes individually.
  2. Packets may route in different paths and sometimes may be out of order.
  3. Each packet contains the complete addressing of their routed paths sometimes of sequence number of the packet.
  4. The packets may arrive at the destination machine in an order different from the transmission order.
  5. Routers in Connectionless switching network maintain a simple but long routing table that contains two columns  – Destination Address and Output Port.

Example : Ethernet , IP , UDP.

Connection Oriented Packet Switching  /  Virtual Circuit Switching :

Transmission of packets are made on Per-Packet basis.

  1. Transmission of packets from a source machine to a destination machine is done on a per source‐destination pair basis, meaning that all packets from the same source going to the same destination are transmitted over the same routes and through the same routers
  2. Different packet reached their destination in order.
  3. Having almost constant delay in packet transmission .
  4. The packets include a connection identifier rather than address information. This identifier is changed every time when the packet is transmitted. Address information is only transferred to each node during a connection set-up phase, when the route to the destination is discovered and an entry is added to the switching table in each network node through which the connection passes

Example : X.25 , Frame Relay

VCI (Virtual Circuit Identifier) are local to each switch or link.

1)  more VC can be assigned 

2)  searching for an unused VCI is simple 

The format of the Virtual Circuit Switching Table has four columns  –  Input Port    Input VCI    Output Port    Output VCI    

 

Advantages of  Virtual Circuit Switching :

Shorter headers are required for VC (VCI is shorter than full network address: VCI may have a length of 1 or 2 bytes, while Full IP address has length of 4 bytes for IPv4 and 12 bytes of IPv6).

Faster because no routing is done (VCI list is shorter and all packets are made to follow each other along  the same path by simply looking up the VC table) .

Resources are set up in advance for the VC (reserve buffers and some bandwidth at each switch) .

Disadvantages of  Virtual Circuit Switching :

When a failure occurs, all virtual circuits must be set up again.