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

SIP Request Methods

PRACK

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 –>

<– PRACK

200OK –>

100rel

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.

SUPPORTED: 100rel

REQUIRED: 100rel

NOTIFY

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”).

ACK

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

Request-Line-URI

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

Via

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.

From

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.

To

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.

Contact

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).

Allow

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

SIP URI

Tel URI

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”

DTMF

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

In-band

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

Hold

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:

 

Transfer

• in2EPS
• VoIP Info – SIP URI
• IANA – Session Initiation Protocol (SIP) Parameters
• 3CX – The main SIP INVITE Header Fields explained