CS Spring 2011 CS 414 – Multimedia Systems Design Lecture 20 – Multimedia Session Protocols Klara Nahrstedt Spring 2011

Midterm Results Average = 66.7 Median = 66.0 Standard deviation = Max = 91.5 Min = 34 Count = 35 Midterm Grade Allocation Below 36: F 36 – 48: D Range 48 – 60: C Range 60 – 72: B Range 72 – 84: A Range 84 and above A+ CS Spring 2011

MP1 Results / HW1 Results MP1 Scores Count: 36 Maximum: 114 Minimum: 64 (will post statistics after class, since the stats have to be calculated on the score – mandatory part only) HW1 Scores Count: 36 Average: 83.1 Median: 84.5 Maximum: 98 Minimum: 56 Standard Deviation: 10:93 CS Spring 2011

Administrative MP2  Posted: March 7, 2011  Deadline: March 30, 2011, 11:59pm (Compass time).  Submission: via compass (see homework specification) Help Session: March 11, 7-8pm, SC1111 No class on March 11 due to EOH CS Spring 2011

Outline Multimedia Protocols – Standards  RTSP  SIP  SDP  SAP CS Spring 2011

Internet Multimedia Protocol Stack CS Spring 2011 AAL3/4 IP Version 4, IP Version 6 UDP Media encaps (H.264, MPEG-4) RTP ATM/Fiber Optics Ethernet/WiFi TCP SIP RTSPRSVPRTCP AAL5 KERNEL APPLICATION Layer 4 (Transport) Layer 3 (Network) Layer 2 (Link/MAC) Layer 5 (Session) MPLS

Real-Time Streaming Protocol (RTSP) Application Protocol for Control of multimedia streams This is not an application data transmission protocol, just remote control protocol between client and server CS Spring 2011 SERVER CLIENT RTP RTSP Session Control Audio video Coder Audio Video Decoder

RTSP Approved as Internet Draft, February 2, 1998, authors H. Schulzrinne, A. Rao, R. Lanphier Enables controlled, on-demand delivery of real- time data such as audio and video Intends to control multiple data delivery sessions Provides means for choosing delivery channels  UDP  Multicast UDP,  TCP CS Spring 2011

RTSP Methods RequestDirectionDescription OPTIONSS CDetermine capabilities of server (S) or client (C) DESCRIBEC -> SGet description of media stream ANNOUNCES CAnnounce new session description SETUPC -> SCreate media session RECORDC -> SStart media recording PLAYC -> SStart media delivery PAUSEC -> SPause media delivery REDIRECTS -> CUse other server TEARDOWNC -> SDestroy media session SET_PARAMETERS CSet server or client parameter GET_PARAMETERS CRead server or client parameter CS Spring 2011

RTSP – Aggregate and Stream Control CS Spring 2011 SERVER CLIENT RTP CoderDecoder DESCRIBE (aggregate stream) SETUP SID RTSP PLAY ESTABLISH PLAY

Streaming media: meta files CS Spring 2011 RTSP Presentation by H. Schulzrinne, 2001 client

Streaming Media: RTSP CS Spring 2011 RTSP Presentation by H. Schulzrinne, 2001

RTSP Operation CS Spring 2011 RTSP Presentation by H. Schulzrinne, 2001

Session Description Protocol (SDP) SDP is Text Format for describing multimedia sessions Not really a protocol (similar to markup language like HTML) Can be carried in any protocol, e.g., RTSP or SIP Describes unicast and multicast sessions CS Spring 2011

SDP There are five terms related to multimedia session description:  Conference: It is a set of two or more communicating users along with the software they are using.  Session : Session is the multimedia sender and receiver and the flowing stream of data.  Session Announcement: A session announcement is a mechanism by which a session description is conveyed to users in a proactive fashion, i.e., the session description was not explicitly requested by the user.  Session Advertisement : same as session announcement  Session Description : A well defined format for conveying sufficient information to discover and participate in a multimedia session. CS Spring 2011

SDP Information Session description  v= (protocol version) ; o= (originator and session identifier)  s= (session name) ; i=* (session information)  u=* (URI of description) ; e=* ( address) p  =* (phone number) ; c=* (connection information -- not required if included in all media) ; b=* (zero or more bandwidth information lines)  One or more time descriptions ("t=" and "r=" lines; see below) z=* (time zone adjustments) k=* (encryption key) a=* (zero or more session attribute lines) Time description  t= (time the session is active) ; r=* (zero or more repeat times) Media description, if present  m= (media name and transport address) ; i=* (media title)  c=* (connection information -- optional if included at session level)  b=* (zero or more bandwidth information lines)  k=* (encryption key) a=* (zero or more media attribute lines) CS Spring 2011

Signaling for IP Telephony Internet Telephone – needs ability of one party to signal to other party to initiate a new call Call – association between a number of participants  Note: there is no physical channel or network resources associated with the session layer connection, the connection exists only as signaling state at two end points CS Spring 2011

IP Telephony Signaling Protocol (Requirements) Name translations and user location  Mapping between names of different levels of abstraction  address to IP address of host Feature negotiation  Group of end systems must agree on what media to exchange ad their respective parameters  Different encodings, rates Call Participant Management Invite participants to existing call, transfer call and hold other users CS Spring 2011

IP Telephony Signaling (Requirements) Feature change  Adjust composition of media sessions during the course of call Add or reduce functionality Impose or remove constraints due to addition or removal of participants Two signaling protocols:  SIP (IETF Standard)  H.323 (ITU Standard) CS Spring 2011

SIP (Session Initiation Protocol) SIP Goal: invite new participants to call Client-Server protocol at the application level Protocol:  User/Client creates requests and sends to server;  User agent server responds; SIP requests can traverse many proxy servers Server may act as redirect server Proxies or redirect servers cannot accept/reject requests, only user agent server can Requests/Responses are textual CS Spring 2011

Call Setup Process using SIP CS Spring 2011 (1)INVITE (8) 200 OK SIP user agent Location Service SIP Server (2) INVITE (3) Where is johnsmith? (4) At Jsmith ( 5) INVITE Jsmith (6) 200 OK (7) 200 OK (9) ACK (10) RTP Audio/Video data SIP Server

SIP Redirect Server Operation CS Spring 2011 (1)INVITE SIP user agent Location Service (2) Where is johnsmith? (3) At play play (4) 302 Moved temporarily (7) RTP Audio/Video data (5) INVITE (6) 200 OK

SIP - Message Calls in SIP – have unique call ID (carried in Call-ID header field of SIP message) Call identifier is created by the caller and used by all participants SIP messages have information  Logical connection source  Logical connection destination  Media destination  Media capabilities (use SDP) CS Spring 2011

SIP – Addressing and Naming To be invited and identified, called party must be named SIP chooses -like identifier     SIP’s address: part of SIP URL   URL can be placed on web page Interactive audio/video requests translation  to CS Spring 2011

SIP Requests/Methods INVITE—Indicates a client is being invited to participate in a call session. ACK—Confirms that the client has received a final response to an INVITE request. BYE—Terminates a call and can be sent by either the caller or the callee. CANCEL—Cancels any pending searches but does not terminate a call that has already been accepted. OPTIONS—Queries the capabilities of servers. REGISTER—Registers the address listed in the To header field with a SIP server. CS Spring 2011

SIP Responses 1xx—Informational Responses  100 Trying (extended search being performed may take a significant time so a forking proxy must send a 100 Trying response)  180 Ringing  181 Call Is Being Forwarded  182 Queued  183 Session Progress 2xx—Successful Responses  200 OK  202 accepted: It Indicates that the request has been understood but actually can't be processed 3xx—Redirection Responses  300 Multiple Choices  301 Moved Permanently  302 Moved Temporarily CS Spring 2011

SAP – Session Announcement Protocol RTSP and SIP are designed for one-on-one session SAP is multicast announcement protocol Protocol  Distributed servers periodically send multicast packets (advertisements) containing descriptions of sessions generated by local sources  Advertisements are received by multicast receivers on well-known, static multicast address/port Advertisement contains SDP information to start media tools needed in the session CS Spring 2011

Conclusion Internet protocol suite has now basic ingredients to support streaming audio and video  Both for distribution and communication applications Challenges:  No session control protocol that can be used to perform floor control in distributed multimedia conferences  Network reliability and deployment multicast of services with predictable quality-of-service are major hurdles beyond need for continuous upgrades in network capacity CS Spring 2011