Session initiation protocol (SIP)
Session Initiation Protocol (SIP) was designed from the bottom up to connect people and devices whenever and wherever they are in order to engage in a (possibly lengthy) exchange of information. Existing protocols, such as HTTP and SMTP, were not purpose-built for this essential human activity, and so SIP was born to fill the gap. However, SIP borrows from these two other protocols heavily: from using HTTP's message exchange pattern, message format and encoding, to SMTP's URI scheme.
In 2002 a revised version of the SIP standard was formalised into the Internet Engineering Task Force's (IEFT) standardisation process as RFC3261. Because of the open nature of the IETF standards process, the fact SIP is text based and shares many features with existing specifications, it has been readily understood, extended and implemented.
Since its emergence SIP has gained traction as a facilitator of instant messaging (e.g. Windows Messenger) and VoIP (e.g. most well-known platforms apart from Sykpe).
Entities
A SIP environment consists of a number of connected entities.
A User Agent (UA) is the entity which represents an end user in a client device. It usually operates in two modes: a User Agent Client (UAC) sends the initial request messages and processes responses; and a User Agent Server (UAS) accepts requests and sends responses.
Proxy Servers are involved in routing the SIP messages to the correct endpoint. Stateful proxies sometime make use of User Agents in a logical entity called a Back-To-Back-User-Agent.
Redirect Servers provide a new address or different route path to the recipient. The server may make use of a Location Server to persist location information.
A Registrar acts as current repository of a client's attachment to the network.
It is the User Agent that tends to reside on the end user's device. The other entities provide essential support services in many scenarios.
Messages
SIP messages come in two flavours.
Request: sent from client to a server and define the operation sought by the client.
Response: sent from server to a client and provide the status of that request.
Read more: Codeproject
Session Initiation Protocol (SIP) was designed from the bottom up to connect people and devices whenever and wherever they are in order to engage in a (possibly lengthy) exchange of information. Existing protocols, such as HTTP and SMTP, were not purpose-built for this essential human activity, and so SIP was born to fill the gap. However, SIP borrows from these two other protocols heavily: from using HTTP's message exchange pattern, message format and encoding, to SMTP's URI scheme.
In 2002 a revised version of the SIP standard was formalised into the Internet Engineering Task Force's (IEFT) standardisation process as RFC3261. Because of the open nature of the IETF standards process, the fact SIP is text based and shares many features with existing specifications, it has been readily understood, extended and implemented.
Since its emergence SIP has gained traction as a facilitator of instant messaging (e.g. Windows Messenger) and VoIP (e.g. most well-known platforms apart from Sykpe).
Entities
A SIP environment consists of a number of connected entities.
A User Agent (UA) is the entity which represents an end user in a client device. It usually operates in two modes: a User Agent Client (UAC) sends the initial request messages and processes responses; and a User Agent Server (UAS) accepts requests and sends responses.
Proxy Servers are involved in routing the SIP messages to the correct endpoint. Stateful proxies sometime make use of User Agents in a logical entity called a Back-To-Back-User-Agent.
Redirect Servers provide a new address or different route path to the recipient. The server may make use of a Location Server to persist location information.
A Registrar acts as current repository of a client's attachment to the network.
It is the User Agent that tends to reside on the end user's device. The other entities provide essential support services in many scenarios.
Messages
SIP messages come in two flavours.
Request: sent from client to a server and define the operation sought by the client.
Response: sent from server to a client and provide the status of that request.
Read more: Codeproject