The Contact header is mandatory to exist in the INVITE and 200 OK message, and can also be included in a REGISTER message or other responses such as 1xx, 2xx, 3xx. It consists of a display name (optional), the URI of the originator User Agent (UA) and may also contain parameters. An example of a Contact header can seen below:
Contact: A <sip:email@example.com>
where A is the display name and sip:firstname.lastname@example.org is the SIP URI of A.
But what is the use of the Contact header? The Contact header basically contains the SIP URI of the caller, that the called party can use to send future requests to. That is, requests that belong to the same dialog, such as re-INVITE, BYE and ACK messages. In other words, it says where a party can be reached. Let’s see how Contact is used within particular messages:
As VoIP services are growing, traditional (PSTN) and IP telephony need to co-exist. Users can belong either to one or the other network, and inter-working between the two technologies is necessary. That requires translation between the different protocols used, which is provided by signaling/media gateways. This post makes first a quick introduction to the signaling process of a PSTN call, and then it describes a call scenario where a PSTN subscriber calls a VoIP user.
Traditional telephony (PSTN network) uses a signaling protocol called ISDN User Part (ISUP). When a user initiates a call, an Initial Address Message (IAM) is sent in order to reserve a circuit for the call. Continue reading
The To and From are two mandatory headers of a SIP INVITE request. This post describes the format of these headers and how they are used during the signaling process.
The To header field contains the contact information/address-of-record of the recipient of this request. According to RFC 3261 the user specified in the To header may or may not be the end-party of the call. The To header consists of a display name (optional) and the SIP URI of the recipient and it must not contain a tag parameter for out-of-dialog requests (such as an INVITE request for the establishment of a new session). Continue reading
During the establishment, maintenance and termination of a SIP session, signaling messages are exchanged between the two SIP endpoints. There are two different kinds of signaling “conversations” that those messages take part in: transactions and dialogs.
A transaction is a SIP message exchange between two user-agents that starts with a request and ends with its final response (it can also contain zero or more provisional responses in between). For example, during the termination of a SIP session, one user releases the call by sending a BYE request and the other party replies back with a 200 OK response. This message exchange is called a transaction.
But what happens in the case of the INVITE request? Continue reading
The INVITE is the first SIP message that a caller will send to the recipient in order to establish a call. This post focuses in the first line of the INVITE and describes its components and usage.
This first line is actually called “Request-line” and it consists of three components: the method name, Request-URI (R-URI), and the protocol version.
Assuming that A calls B, the Request-line of A’s INVITE will look like this: Continue reading
There are many different SIP scenarios and call flows in a VoIP environment. This post describes a very basic SIP call flow case where A is the caller and B is the recipient. Users A and B probably have a SIP proxy server each handling the signaling on behalf of them.
When A wants to initiate a new call, it sends an initial INVITE to B. This INVITE contains various headers with signaling information such as A’s and B’s addresses/phone numbers, SIP path information, etc. The INVITE also carriers a Session Description Protocol (SDP) body with information regarding the media settings that A supports/prefers e.g. codecs and media addresses. Continue reading
The Session Initiation Protocol (SIP) is the dominant signaling protocol used in VoIP today. It is responsible for the establishment, control and termination of sessions by exchanging ASCII-text-based messages between the endpoints. This post goes through the basic components of SIP: messages and logical entities.
There are two types of SIP messages: requests and responses. The table below summarizes the most important SIP requests and the types of SIP responses: Continue reading