Danh mục tài liệu

Chapter 4 - Session Control on the Internet

Số trang: 51      Loại file: pdf      Dung lượng: 3.50 MB      Lượt xem: 15      Lượt tải: 0    
Xem trước 6 trang đầu tiên của tài liệu này:

Thông tin tài liệu:

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.
Nội dung trích xuất từ tài liệu:
Chapter 4 - Session Control on the Internet Chapter 4Session Control on the InternetMany think that the most important component of the signaling plane is the protocol thatperforms session control. The protocol chosen to perform this task in the IMS is the SessionInitiation Protocol (SIP) (defined in RFC 3261 [286]). SIP was originally developed within the SIP working group in the IETF. Even thoughSIP was initially designed to invite users to existing multimedia conferences, today it ismainly used to create, modify and terminate multimedia sessions. In addition, there existSIP extensions to deliver instant messages and to handle subscriptions to events. We will firstlook at the core protocol (used to manage multimedia sessions), and then we will deal withthe most important extensions.4.1 SIP FunctionalityProtocols developed by the IETF have a well-defined scope. The functionality to be providedby a particular protocol is carefully defined in advance before any working group startsworking on it. In our case the main goal of SIP is to deliver a session description to a user attheir current location. Once the user has been located and the initial session descriptiondelivered, SIP can deliver new session descriptions to modify the characteristics of theongoing sessions and terminate the session whenever the user wants.4.1.1 Session Descriptions and SDPA 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 sessionsover the Internet this information includes the IP address and port number where the medianeeds 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 formatfor describing multimedia sessions is the Session Description Protocol (SDP), defined inRFC 2327 [160]. Note that although the “P” in SDP stands for “Protocol”, SDP is simplya textual format to describe multimedia sessions. Figure 4.1 shows an example of an SDPsession description that Alice sent to Bob. It contains, among other things, the subject of theconversation (swimming techniques), Alice’s IP address (192.0.0.1), the port number whereAlice wants to receive audio (20000), the port number where Alice wants to receive videoThe 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds Third EditionGonzalo Camarillo and Miguel A . Garc ıa-Mart´n ´ ı© 2008 John Wiley & Sons, Ltd. ISBN: 978-0-470-51662-1 CHAPTER 4. SESSION CONTROL ON THE INTERNET60 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 codecG.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-levelinformation and media-level information. The session-level information applies to the wholesession and comes before the m= lines. In our example, the first five lines correspond tosession-level information. They provide version and user identifiers (v= and o= lines), thesubject 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 sessiondescription 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 anumber of optional a= lines that provide further information about the media stream. Ourexample has two media streams and, thus, has two m= lines. The a= lines indicate that thestreams 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, wheretype 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 notdepend on it. SIP is session-description format independent. That is, SIP can deliver adescription of a session written in SDP or in any other format. For example, after the videoconversation above about swimming techniques, Alice feels like inviting Bob to a real trainingsession this evening in the swimming pool next to her place. She uses a session descriptionformat 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 theobjects it transports. Those objects may be session descriptions written in different formatsor any other piece of information. We will see in subsequent sections that SIP is also used todeliver instant messages, which of course are written using a different format from SDP andfrom our description format for swimming sessions.4.1.2 The Offer/Answer ModelIn the SDP example in Figure 4.1, Alice sent a session description to Bob that containedAlice’s transport addresses (IP address plus port numbers). Obviously, this is not enough toestablish 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 (whichis described in RFC 3264 [283]). One of the users (the offerer) generates a session description4.1. SIP FUNCTIONALITY ...