Thư viện tri thức trực tuyến
Kho tài liệu với 50,000+ tài liệu học thuật
© 2023 Siêu thị PDF - Kho tài liệu học thuật hàng đầu Việt Nam
Chapter 4 - Session Control on the Internet pps
Nội dung xem thử
Mô tả chi tiết
Chapter 4
Session Control on the Internet
Many think that the most important component of the signaling plane is the protocol that
performs session control. The protocol chosen to perform this task in the IMS is the Session
Initiation Protocol (SIP) (defined in RFC 3261 [286]).
SIP was originally developed within the SIP working group in the IETF. Even though
SIP was initially designed to invite users to existing multimedia conferences, today it is
mainly used to create, modify and terminate multimedia sessions. In addition, there exist
SIP extensions to deliver instant messages and to handle subscriptions to events. We will first
look at the core protocol (used to manage multimedia sessions), and then we will deal with
the most important extensions.
4.1 SIP Functionality
Protocols developed by the IETF have a well-defined scope. The functionality to be provided
by a particular protocol is carefully defined in advance before any working group starts
working on it. In our case the main goal of SIP is to deliver a session description to a user at
their current location. Once the user has been located and the initial session description
delivered, SIP can deliver new session descriptions to modify the characteristics of the
ongoing sessions and terminate the session whenever the user wants.
4.1.1 Session Descriptions and SDP
A session description is, as its name indicates, a description of the session to be established.
It contains enough information for the remote user to join the session. In multimedia sessions
over the Internet this information includes the IP address and port number where the media
needs to be sent, and the codecs used to encode the voice and the images of the participants.
Session descriptions are created using standard formats. The most common format
for describing multimedia sessions is the Session Description Protocol (SDP), defined in
RFC 2327 [160]. Note that although the “P” in SDP stands for “Protocol”, SDP is simply
a textual format to describe multimedia sessions. Figure 4.1 shows an example of an SDP
session description that Alice sent to Bob. It contains, among other things, the subject of the
conversation (swimming techniques), Alice’s IP address (192.0.0.1), the port number where
Alice wants to receive audio (20000), the port number where Alice wants to receive video
ıa- ´ Martın´
The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third Edition
Gonzalo Camarillo and Miguel A. Garc
© 2008 John Wiley & Sons, Ltd. ISBN: 978- 0- 470- 51662- 1
60 CHAPTER 4. SESSION CONTROL ON THE INTERNET
v=0
o=Alice 2790844676 2867892807 IN IP4 192.0.0.1
s=Let’s talk about swimming techniques
c=IN IP4 192.0.0.1
t=0 0
m=audio 20000 RTP/AVP 0
a=sendrecv
m=video 20002 RTP/AVP 31
a=sendrecv
Figure 4.1: Example of an SDP session description
(20002), and the audio and video codecs that Alice supports (0 corresponds to the audio codec
G.711 µ-law and 31 corresponds to the video codec H.261).
As we can see in Figure 4.1 an SDP description consists of two parts: session-level
information and media-level information. The session-level information applies to the whole
session and comes before the m= lines. In our example, the first five lines correspond to
session-level information. They provide version and user identifiers (v= and o= lines), the
subject of the session (s= line), Alice’s IP address (c= line), and the time of the session
(t= line). Note that this session is supposed to take place at the moment when this session
description is received. That is why the t= line is t=0 0.
The media-level information is media-stream specific and consists of an m= line and a
number of optional a= lines that provide further information about the media stream. Our
example has two media streams and, thus, has two m= lines. The a= lines indicate that the
streams are bidirectional (i.e., users send and receive media).
As Figure 4.1 illustrates, the format of all the SDP lines consists of type=value, where
type is always one character long. Table 4.1 shows all the types defined by SDP.
Even if SDP is the most common format to describe multimedia sessions, SIP does not
depend on it. SIP is session-description format independent. That is, SIP can deliver a
description of a session written in SDP or in any other format. For example, after the video
conversation above about swimming techniques, Alice feels like inviting Bob to a real training
session this evening in the swimming pool next to her place. She uses a session description
format for swimming sessions to create a session description and uses SIP to send it to Bob.
Alice’s session description looks something like the one in Figure 4.2.
This example is intended to stress that SIP is completely independent of the format of the
objects it transports. Those objects may be session descriptions written in different formats
or any other piece of information. We will see in subsequent sections that SIP is also used to
deliver instant messages, which of course are written using a different format from SDP and
from our description format for swimming sessions.
4.1.2 The Offer/Answer Model
In the SDP example in Figure 4.1, Alice sent a session description to Bob that contained
Alice’s transport addresses (IP address plus port numbers). Obviously, this is not enough to
establish a session between them. Alice needs to know Bob’s transport addresses as well.
SIP provides a two-way session-description exchange called the offer/answer model (which
is described in RFC 3264 [283]). One of the users (the offerer) generates a session description
4.1. SIP FUNCTIONALITY 61
Table 4.1: SDP types
Type Meaning
v Protocol version
b Bandwidth information
o Owner of the session and session identifier
z Time zone adjustments
s Name of the session
k Encryption key
i Information about the session
a Attribute lines
u URL containing a description of the session
t Time when the session is active
e Email address to obtain information about the session
t Times when the session will be repeated
p Phone number to obtain information about the session
m Media line
c Connection information
i Information about the media line
Subject: Swimming Training Session
Time: Today from 20:00 to 21:00
Place: Lane number 4 of the swimming-pool near my place
Figure 4.2: Example of a session description without SDP being used
(the offer) and sends it to the remote user (the answerer), who then generates a new session
description (the answer) and sends it to the offerer.
RFC 3264 [283] provides the rules for offer and answer generation. After the offer/answer
exchange, both users have a common view of the session to be established. They know, at
least, the formats they can use (i.e., formats that the remote end understands) and the transport
addresses for the session. The offer/answer exchange can also provide extra information, such
as cryptographic keys to encrypt traffic.
Figure 4.3 shows the answer that Bob sent to Alice after having received Alice’s offer in
Figure 4.1. Bob’s IP address is 192.0.0.2, the port number where Bob will receive audio is
30000, the port number where Bob will receive video is 30002, and, fortunately, Bob supports
the same audio and video codecs as Alice (G.711 µ-law and H.261). After this offer/answer
exchange, all they have left to do is to have a nice video conversation.
4.1.3 SIP and SIPS URIs
SIP identifies users using SIP URIs, which are similar to email addresses; they consist of a
username and a domain name. In addition, SIP URIs can contain a number of parameters
62 CHAPTER 4. SESSION CONTROL ON THE INTERNET
v=0
o=Bob 234562566 236376607 IN IP4 192.0.0.2
s=Let’s talk about swimming techniques
c=IN IP4 192.0.0.2
t=0 0
m=audio 30000 RTP/AVP 0
a=sendrecv
m=video 30002 RTP/AVP 31
a=sendrecv
Figure 4.3: Bob’s SDP session description
(e.g., transport), which are encoded using semicolons. The following are examples of SIP
URIs:
sip:[email protected];transport=tcp
In addition, users can be identified using SIPS URIs. Entities contacting a SIPS URI use
TLS (Transport Layer Security, see Section 11.3) to secure their messages. The following are
examples of SIPS URIs:
URI}sips:[email protected]
URI}sips:[email protected]
4.1.4 User Location
We said earlier that the main purpose of SIP is to deliver a session description to a user at
their current location, and we have already seen what a session description looks like. Now
let us look at how SIP tracks the location of a given user.
SIP provides personal mobility. That is, users can be reached using the same identifier no
matter where they are. For example, Alice can be reached at
regardless of her current location. This is her public URI, also known as her AoR (Address
of Record).
Nevertheless, when Alice is logged in at work her SIP URI is
and when she is working at her computer at the university her SIP URI is
Therefore, we need a way to map Alice’s public URI
to her current URI (at work or at the university) at any given moment.
4.2. SIP ENTITIES 63
To do this, SIP introduces a network element called the registrar of a particular domain.
A registrar handles requests addressed to its domain. Thus, SIP requests sent to
will be handled by the SIP registrar at domain.com.
Every time Alice logs into a new location, she registers her new location with the registrar
at domain.com, as shown in Figure 4.4. This way the registrar at domain.com can always
forward incoming requests to Alice wherever she is.
Registrar at
domain.com
sip:[email protected] REGISTER
Figure 4.4: Alice registers her location with the domain.com registrar
On reception of the registration the registrar at domain.com can store the mapping
between Alice’s public URI and her current location in two ways: it can use a local database
or it can upload this mapping into a location server. If the registrar uses a location server, it
will need to consult it when it receives a request for Alice. Note that the interface between
the registrar and the location server is not based on SIP, but on other protocols.
4.2 SIP Entities
Besides the registrars, which were introduced in the previous section, SIP defines user agents,
proxy servers, and redirect servers. UAs (user agents) are SIP endpoints that are usually
handled by a user. In any case, user agents can also establish sessions automatically with
no user intervention (e.g., a SIP voicemail). Sessions are typically established between user
agents.
User agents come in all types of flavors. Some are software running on a computer, others,
like the commercial SIP phones shown in Figure 4.5, look like desktop phones, and others
still are embedded in mobile devices like laptops, PDAs, or mobile phones. Some of them
are not even used for telephony and do not have speakers or microphones.
Proxy servers, typically referred to as proxies, are SIP routers. A proxy receives a
SIP message from a user agent or from another proxy and routes it toward its destination.