An Overview of SIP

This article provides an overview of common SIP (Session Initiation Protocol) messages you may encounter in the wild.

SIP Request Methods


SIP PRACK (Provisional Acknowledgement) is a way to enable reliability for SIP 1xx provisional messages (excluding 100 Trying) like 180 ringing and 183 session in progress. PRACK messages are sent from the calling party to to called party, to acknowledge the receipt of a 1xx message. The called party will acknowledge and PRACK message with a 200OK.

180 Ringing –>


200OK –>


100rel support/required allows the calling or called party to show its support for, or requirement for PRACK messages, and is included in INVITE and subsequent 1xx messages.


REQUIRED: 100rel


The NOTIFY request typically contains modified session description.

During the subscription period, the Gateway may, from time to time, send a spontaneous NOTIFY request to the entity indicated in the Contact: header of the “opening” SUBSCRIBE request. Normally this will happen as a result of any change in the status of the service session for which the Requestor has subscribed. The receiving user agent server MUST acknowledge this by returning a final response (normally a “200 OK”).


SIP implements a three-way handshake.

  • The caller sends an INVITE
  • The callee sends an 200 OK to accept the call
  • The caller sends an ACK to indicate that the handshake is done and a call is going to be setup

SIP Header Fields


The Request-Line-URI includes the destination of the call. It contains the same information as the To field, omitting the display name.


Every proxy in the request path adds to top of the “Via” the address and port on which it received the message, than forwards it onwards. When processing responses, each proxy in the return path processes the contents of the “Via” field in reverse order, removing its address from the top.


The “From” header field indicates the identity of the initiator of the request from the point of view of the PBX Server – similar in construction to email addresses (user@domain – where “user” is, for example, the extension number, and “domain” is the server domain or IP address). Like the “To” header field, it contains a URI and optionally a display name. It is used to determine which processing rules to apply to a request.

From the SIP RFC 3261: The “From” header field allows for a display name. A UAC (i.e a phone) SHOULD use the display name “Anonymous”, along with a syntactically correct, but otherwise meaningless URI (e.g. From: “Anonymous” <sip:[email protected]>), if the identity of the client is to remain hidden.

Typically, the host IP Address will be the internal IP address of the PBX Server.


The “To” header field first and foremost specifies the desired “logical” recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or may not be the ultimate recipient of the request. The “To” header field MAY contain a SIP URI, but it may also make use of other URI schemes (the tel URL (RFC 2806 [9]), for example) when appropriate. All SIP implementations MUST support the SIP URI scheme.

The To header field allows for a display name (e.g. To: “Target User” <sip:[email protected]>).

Typically, the “To” field contains a SIP URI that points to the first (next) hop (proxy) that will process the request, but not necessarily the SIP URI of the eventual recipient.


The “Contact” header field provides a single SIP URI that can be used to contact the sender of the INVITE for subsequent requests. The Contact header field MUST be present and contain exactly one SIP URI in any request that can result in the establishment of a dialog – in this case, specifically a SIP INVITE. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the sender is expecting to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs (in our case, meaning established calls).


This field lists, in comma-separated format, the SIP Methods that the caller can support and use. SIP defines the following methods: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER, SUBSCRIBE, UPDATE


A SIP-URI identifies a communications resource. SIP URI’s resemble an e-mail address and are written in the following format:sip:<user info>@<domain>:<optional: port>;<optional: URI parameters>

Note: If you do not specify a port, the default sip port will be assumed (5060).


A telephone number is represented as a SIP URI in the form sip:<user info>@<domain>:<port>;user=phone. Port is optional, and if not specified the default of 5060 will be used.

The “user=phone” parameter indicates that the user portion of the URI (the part to the left of the @ sign) should be treated as a tel URI, so “sip:[email protected];user=phone” should be treated as tel:+6495005000″.

Tel URI parameters (such as phone-context) are included in the user info, not the SIP URI itself, i.e “sip:95005000;[email protected];user=phone” is the same as “tel:95005000;phone-context=+64”


  • In-band
  • Out-of-band
  • RFC 2833


Leaves the DTMF tones in-band as encoded audio

Out-of-band (SIP INFO)

Carries DTMF in the signaling protocol (SIP or H.323) as SIP INFO messages

RFC 2833

RFC 2833 Encodes DTMF into RTP using a format and payload type distinct from the audio encoding
Telephone event 101 in a SIP trace specifies that RFC2833 was in use. When you see the ff lines in your SDP, then you are doing RFC2833:
a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16


Calls are placed on hold by a SIP re-INVITE (an INVITE in the same SIP dialog) being sent which includes the SDP field a=sendonly, and expects a 200OK from the recipient which has the SDP field a=recvonly. You may also notice the initiating User Agent includes the ;+sip.rendering=”no” tag on the SIP header contact field in the re-INVITE, to indicate that media is not being rendered.
When the call comes off hold a new re-INVITE is sent that does not include the SDP field a=sendonly, and is accepted by a 200OK which doesnt include SDP field a=recvonly.
Call hold is unidirectional, however the initiating User Agent will generally stop sending audio and could use the SDP field a=inactive to signal this.
Hold Example:



In a transfer a SIP User Agent has actually established a dialog with the callee, and then initiates setting up a new dialog between the callee and another User Agent.Call transfers are initiated by a SIP REFER and can be unattended or attended. An unattended transfer is a direct transfer with no consultation, whereas an attended transfer allows for consultation by essentially putting the call on hold while you announce it, then transferring it once accepted by other party.


<– 202 Accepted


<– 200 OK

Unattended Transfer Example:


A redirect is when a User Agent doesn’t answer the call, but simply informs the callee to resend the INVITE to another SIP URI.When a call is redirected a 181 Call is Being Forwarded message is sent to the caller, and a second call leg is established to the forwarding destination.




Please enter your comment!
Please enter your name here