| 2 Introduction | |
The purpose of the Session Initiation Protocol is described below.The text has been taken directly from the abstract of the SIP Specification, RFC 2543 [2]:
The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these.
SIP invitations used to create sessions carry session descriptions, which allow participants to agree on a set of compatible media types.SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities.
SIP client is an application program that sends SIP requests. SIP server is an application program that accepts SIP requests. In order to service requests SIP server sends back SIP responses for those requests. SIP is a peer-to-peer protocol, as opposed to a master-slave protocol. A SIP client could be a server in another transaction. SIP allows a client to send messages to any SIP-enabled server without being aware of the type of server that it is communicating with. The behavior of SIP client is based on the responses without considering where the responses came from. The different types of SIP servers include User Agent, Proxy, Redirect and Registrar.
The objective of the JAIN SIP API specification is to specify a Java API that will provide the interfaces and classes required for an application to instantiate objects. These objects expose and implement the JAIN SIP API that allows the application to interact through the API with the SIP stack encapsulated by these objects.
An architecture that depicts the role of SIP relative to that of other packet-based protocols (e.g. MGCP, etc.) is shown in Figure 2: Converged Network Architecture.
Figure 2: Converged Network Architecture
Note: Not all of the possible types of SIP endpoints have been shown. Only control protocols have been shown; media streams between edge devices have been omitted for sake of clarity.
|
Softswitches (SS) or Media Gateway Controllers (MGC)
|
The devices that control the different types of
Media Gateways (MG) listed below.
|
|
Media Gateways (MG)
|
There are many types of gateways that can be directly
SIP enabled, however it is likely that the SIP User Agent will reside on
the MGC. MGs include:
|
|
Etherphones
|
Hardware IP phone.
|
|
PC based phones
|
Software IP phone that runs on a PC client.
|
|
End-user devices
|
Hand-held IP phone devices.
|
|
Intelligent screen phones
|
Smart SIP endpoints with graphics displays.
|
An example of a SIP call setup and tear down between a User Agent Client (caller) and a User Agent Server (callee), traversing a SIP Proxy Server is show below in Figure 3: Simple SIP Call Setup and Tear Down, Via a SIP Proxy Server.
Figure 3: Simple SIP Call Setup and Tear Down, Via a SIP Proxy Server
In the Figure above, steps 1-9 represent call setup and steps 10-11 represent call tear down. The following table explains, in detail, the messages, which are passes between the User Agent Client and User Agent Server.
|
1 INVITE
|
The User Agent Client initiates a call with the
User Agent Server, via the Proxy Server by sending an INVITE message to
the Proxy Server that is destine for the User Agent Server.
|
|
2 100/TRYING
|
The Proxy Server responds immediately with a 100
response to confirm that it has received the message.
|
|
3 INVITE
|
The Proxy Server forwards the INVITE message to
the User Agent Server, now that it has located that user.
|
|
4 100/TRYING
|
The User Agent Server responds immediately with
a 100 response to confirm that it has received the message.
|
|
5 180/RINGING
|
After processing the INVITE, and notifying the end
user that a call has arrived, the User Agent Server responds with a 180
response to indicate that the terminating side it ringing.
|
|
6 180/RINGING
|
The Proxy Server forwards the 180 response to the
User Agent Client that originated the INVITE request.
|
|
7 200/OK
|
After the user accepts the connection, the User
Agent Server sends a 200 response to the Proxy Server, indicating that
the call has been accepted.
|
|
8 200/OK
|
The Proxy Server forwards the 200 response to the
User Agent Client that originated the INVITE request.
|
|
9 ACK
|
The User Agent Client acknowledges that receipt
of the final response to the INVITE message by sending an ACK.
|
|
(media stream)
|
After the ACK, the media stream is set up and
the session is in progress.
|
|
10 BYE
|
When either side wants to end the session, it sends
a BYE request to the other side. This, as with the ACK, typically will
not traverse the Proxy Server (unless the Proxy Server specifically requests
this, as is the case with a Firewall Proxy Server) since the network path
is already established.
|
|
11 200/OK
|
The User Agent Client sends a 200 response to the
User Agent Server that originated the INVITE request.
|
If you have any comments or queries, please mail them to JAIN-SIP-interest@sun.com
