Wisdom of Helios

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


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=
Via: SIP/2.0/UDP site3.server1.com;branch=z9hG4bK77ef4c2312983.1;received=
Via: SIP/2.0/UDP pc33.server1.com;branch=z9hG4bK776asdhds;received=
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@>
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-


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.


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


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)

Author: Munir

I'm good for nothing

5 thoughts on “Basics of Session Initiation Protocol (SIP) (part-4)

  1. Pingback: Basics of Session Initiation Protocol (SIP) (part-5) | Wisdom of Helios

  2. Pingback: Basics of Session Initiation Protocol (SIP) (part-1) | Wisdom of Helios

  3. Pingback: Basics of Session Initiation Protocol (SIP) (part-2) | Wisdom of Helios

  4. Pingback: Basics of Session Initiation Protocol (SIP) (part-3) | Wisdom of Helios

  5. Hi there i am kavin, its my first occasion to commenting anyplace,
    when i read this article i thought i could also create comment due to this good paragraph.

    The Mentalist Season 5 Episode 6 Cherry Picked

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s