Multimedia Communications Spring 2006-07 Session Level Advances - - PowerPoint PPT Presentation

Session Level Advances

(SDP – RFC 2327, SAP, SIP – RFC 2543)

Shahab Baqai LUMS

CS 584 / CMPE 584

Multimedia Communications

Spring 2006-07

2

SDP In the context of a multimedia multicast Internet, a session directory tool is used to:

– advertise multimedia conferences – communicate the conference addresses – Conference tool-specific information necessary for participation

SDP is designed to convey such information

– Does not incorporate a transport protocol but uses different transport protocols as appropriate including:

SAP (Session Announcement Protocol) Email using MIME extensions www (HTTP – HyperText Transport Protocol)

3

Definitions

• Conference:

– Two or more communicating users along with the software they are using to communicate

• Session:

– a set of multimedia senders & receivers and the data streams flowing from the senders to receivers

E.g. a multimedia conference

• Session Announcement or Advertisement:

– a mechanism by which a session description is conveyed to users in a pro-active fashion

i.e. session description is sent without being explicitly requested by users

• Session Description:

– a well defined format for conveying sufficient information to users for them to discover and participate in a multimedia session

4

SDP Usage: Multicast Announcements

A user announces a conference by periodically sending an SDP packet to a well-known multicast address and port

– using Session Announcement Protocol (SAP)

SAP packets are UDP packets

– containing a header & text payload

The header is a SAP header

– described in the SAP draft document

The text payload is an SDP session description:

– should not exceed 1 Kbytes in length – Only one session description is allowed per SAP packet

5

SDP Usage: Email & WWW Announcements MIME content type should be set to:

– “application/sdp” – The www client or mail reader automatically launches the appropriate application for participation in the session

Announcements by email or www:

– do not guarantee that the user is able to receive the session as the scope of the session may be more limited than email reception or www access

6

Session Information The session info carried in SDP messages include:

– Session name & purpose – Time(s) the session is active

Session is defined as a set of multimedia streams that exist for some duration of time

• The times these streams are active need not be continuous

– The media comprised in the stream – Information to receive these media:

Addresses, ports, formats, etc

– Additional information that might be useful such as:

Information about the bandwidth used by the conference Contact information for the person responsible for the conference

7

Timing Information Sessions may be bounded or unbounded in their time duration, however they may only be active at specified times SDP conveys:

– An arbitrary list of start & stop times bounding the session active time – For each bound, repeat times are indicated such as “every Tue 6:45”

The timing info is globally consistent irrespective of the zone or daylight saving time

8

Media Information The SDP includes the following info for each media:

– Type (audio, video, …) – Transport protocol (RTP, UDP, IP, H.320, …) – Format (H.261, MPEG1, G.711, …) – For IP multicast sessions the following is specified:

Destination multicast address for stream Destination transport port of stream

– For IP unicast sessions the following is specified:

Remote address Transport port for contact address Semantics of the address & port depend on the type of media & transport protocol defined. Default is remote port & remote address to send data, and Remote address & local port for receiving data

• Some media types may choose to use the address & port to

establish a control channel for the actual media transfer

9

Other issues

Private sessions

– Encrypt the session description before distributing it – Private session announcements may convey encryption keys for decoding of the different media types that constitute the session including indication of encryption scheme used for each media type

More info about the session can be conveyed through additional pointers in the form of Universal Resources Indicator (URI) Categorization of session is supported by SDP

– Allows filtering of session announcements according to user interests

Internationalization is supported by allowing the usage character sets other than that used for coding extended ASCII characters

10

Session Description

SDP sessions description are entirely textual

– Allows the use of a variety of transport methods & of flexible text-based toolkits

A compact encoding scheme is used to reduce the bandwidth usage SDP has a strict order & formatting rules

– Allow detection of errors which result in mal-formatting of announcements

A session description consists of a session-level section (that applies to the whole session & to all media streams) followed by zero or more media-level descriptions (details that apply to the particular media stream)

11

Session Description Syntax (1) Session Description syntax consists of a number of text lines of the form Type=<value>

– No space between the = sign & other fields is allowed – Type field is one character & case significant – Value is a free-format text string or a series of text strings separated by a single space character – The session-level description starts with a “v=“ line & ends at the first media-level section encountered – The media-level description starts with a “m=“ line & ends at the next media level section encountered or at the end of the whole session description

A value at the media -evel overrides that at the equivalent session- level value for the particular media type

12

Session Description Syntax (2) When SDP is carried by SAP only one session description is allowed per packet When email / www is used to transport SDP, many session descriptions may be concatenated together

– The “v=“ line that starts a session description ends the previous one

Some lines in the description are required while the

• thers are optional but all must appear in the exact
• rder given

– An “*” next to an item indicates that it is optional

13

Session Description Syntax (3)

Session description

– v= protocol version – o=

• wner / creator & session number

– s= session name – i=* session information – u=* URI of description – e=* email address – p=* phone number – c=* connection information – optional if included in all media – b=* bandwidth information – >>

• ne or more time descriptions

– z=* time zone adjustments – k=* encryption key – a=* zero or more session attribute lines – >> zero or more media descriptions

14

Session Description Syntax (4)

Time description

– t= time the session is active – r=* zero or more repeat times

Media descriptions

– m= media name & transport address – i=* media title – c=* connection info – optional if included at session-level – b=* zero or more repeat times – k=* encryption key – a=* zero or more session attribute lines

The type set is small & not intended to be extensible

– SDP parser must ignore any announcement type that they do not recognize

15

Session Description Syntax (5)

The attribute mechanism is used to tailor SDP to particular application or media

– some attributes are specified n the document & have a defined meaning, but others may be added on an application-, media-, or session-specific basis. – session directory must ignore any attribute value it does not understand

Text records, such as the session name & info, may contain any printable ISO 8859-1 (the character set supporting extended ASCII) character except 0x0A (newline) & 0x0D (carriage return).

– 0x0A is used as end of record – 0x0D is forbidden

16

Session Description Syntax (6)

Example session description

– v=0 – o=baqai 2890844526 2890842807 IN IPv4 203.128.1.240 – s=SDP Lecture – i=A lecture on SDP – u=http://suraj.lums.edu.pk/~cs584s05/sdp.03.pdf – e=baqai@lums.edu.pk (Shahab Baqai) – c=IN IP4 224.2.17.12/127 – t=2873397496 2873404696 – a=recvonly – m=audio 3456 RTP/AVP 0 – m=video 2232 RTP/AVP 31 – m=whiteboard 32416 udp wb – a=orient.portrait

17

Session Description Syntax (7) the different line syntaxes are:

– v: version number – o: originator information

<username> <sessionid> <version> <network type> <address type> <address>

– s: must have one & only one per announcement

<session name>

– i: labeling information, no more than one for session-level, a single I field can also be used for every media-level description

<session description>

– u: URI as used by www clients. No more than one per session description

<URI>

– e: email address of person responsible

<email address>

18

Session Description Syntax (8)

– p: phone number of person responsible for the conference

<phone number>

– c: connection data

<network type> <address type> <connection address>

– b: bandwidth, modifier value is CT (conference total) or AS (application specific maximum) or a experimental modifier (should start with X-)

<modifier>:<bandwidth-value>

– t: start & stop time of conference session

<start time> <stop time>

– r: repeat times of a session

<repeat interval> <active duration> <list of offsets from start time>

– z: list of time zone & daylight saving adjustments

<adjustment time> <offset> <adjustment time> <offset> …

19

Session Description Syntax (9)

– k: encryption keys

<method>:<encryption keys>

– a: attributes

<attribute>:<value>

– m: media announcements

<media> <port> <transport protocol> <media format list>

20

Session Announcement Protocol (SAP) a session directory is used to advertise multimedia conferences & communicate:

– session addresses (multicast or unicast) – conference-tool specific information

An instance of such a session directory periodically multicasts packets containing a complete description of a multimedia session SAP is an announcement protocol for multicast conference sessions

– distribution mechanism – packet format

21

SAP (1) SAP client periodically multicasts an announcement packet to a well-known multicast address & port Announcement is multicast with the same scope (TTL) as the session it is announcing

– important for the scalability of the protocol

Time period between announcements depends on

– scope – number of sessions being announced by other session directory clients – goal: keep total bandwidth below predefined level

22

Time Interval Between Announcements

• Base time interval = max(300, (8* no_of_ads_size) /limit
• Add random value +/- ⅓ of base interval

TTL Bandwidth 1-15 2 kbps 16-63 1 kbps 64-127 1 kbps 128-255 200 bps

23

SAP (2) SAP functions

– Session announcement – Session deletion – Session modification

Session announcement contains

– Session description (may be encrypted) – Authentication header

24

SAP (3)

Session deletion

– Explicit timeout

Session description contains start & end times for each session announcement

– Implicit timeout

SA message should arrive periodically. Period may be predicted by the received from the set of sessions currently being announced Lack of SA message after max(10 intervals, 30 minutes)

– Explicit deletion

Session deletion packet specifying the version of the session to be deleted Same IP source address as that from which the session announcement was

• riginally advertised

If authentication header is cached, the deletion packet must have a signature with the same key

25

SAP (4) Session modification

– By announcing modified description – Version hash in SAP header could be changed to indicate packet must be parsed – Session itself is uniquely identified by the SDP origin field in the payload and not by the version hash in the SDP header – Same rules as for session deletion regarding authentication & source address information

If not satisfied, modified announcement is displayed in addition to the preexisting announcement

26

SDP Announcement by Periodic Multicast Appropriate address determined by scope mechanisms in force at the sites of the intended participants TTL scoped

– One well known address & port used for all TTL-scoped announcements

Administratively scoped

– One well known address (within corresponding scope zone) & port used for each administrative scope zone

27

SDP Announcement (cont.) An instance of the session directory should:

– Listen to multiple multicast addresses – Normally only need to send a particular announcement to the single multicast address corresponding to the scope of the session being described

Discovery of administrative scope zones is

• utside the scope of SAP draft

– Assumed that each instance of the session directory within a particular scope zone is aware of that scope zone address, port, TTL, & session addresses allocated

28

TTL-Scoped Announcements

Address 224.2.127.254, port 9875 Same TTL as the conference session If different media in an announcement are given different TTLs, multiple announcements are necessary

– E.g. audio TTL = 127, video TTL = 63 – Announce bioth sessions at TTL = 63, only announce audio at TTL = 127 – Up to the receiving station to parse both announcements as same (identified by SDP origin field)

Each announcement must carry authentication header signed by the same key, otherwise treated as separate announcements

29

Administrative-Scoped Announcements Information to be known

– Multicast address to be used for announcement – Highest multicast address in the relevant administrative scope

E.g. range [239.16.32.0. 239.16.33.255] Choose 239.16.33.255

– UDP port – TTL (large enough to reach all sites in administrative domain) – Address range to be used (contiguous range) – Total bandwidth to be used by the session directory

Recommended default = 500 bps

30

Other Matters Encrypted announcements

– Encrypting announcements – Decrypting announcements

Security considerations

31

Session Initiation Protocol (SIP) SIP is a protocol designed to enable the invitation of users to participate in a multimedia session

– Not tied to a specific conference control scheme – Supports loosely coupled or tightly controlled sessions – Enables user mobility by relaying and redirecting invitations to a user’s current location

32

SIP (cont.) SIP is an application layer control protocol for creating, modifying, & terminating sessions with

• ne or more participants. Example sessions are:

– Internet telephone calls – Internet multimedia conferences – Internet multimedia distribution

Communication among members in a session may be via

– Multicast – Mesh of unicast “relations” – A combination of the above

33

Functional Features Allows participants to agree on a set of compatible media types Supports user mobility by proxying & redirecting requests to the user’s current location Can be extended with additional capabilities It is not tied to any particular conference control protocol It is independent of the lower layer transport protocol

34

Call Setup

Initial phase

– Requesting client tries to ascertain the address where should it contact the remote user

Subsequent phases

– Implement request-response protocol – Session description is sent with an invitation to join

Status code responses

– Informational – request received, continuing process – Success – action successfully received, understood, & accepted – Redirection – further action must be taken in order to complete the request – Client error – request contains bad syntax – Server error – server failed to complete an apparently valid request

35

Big Picture

36

Addressing SIP addresses are URLs: user@host

– user: username or telephone number – host: domain name or numeric IP address

Examples

– sip:baqai@lums.edu.pk:5067 – sip:765-497-9858@gateway

To send a message, a SIP client can send it to a pre-configured proxy, or use DNS:

– Check for DNS SRV records – Then check for MX records – Finally, use an A record

37

Components (1) Clients

– End systems – Send SIP requests – Usually contain SIP user agent server (UAS)

Listen for call requests Prompts user or executes program to determine response

Proxy server

– Poxies request to another server – Possibly translates & rewrites request – Can “fork” request to multiple servers, creating a search tree

38

Components (2) Redirect server

– Redirects user to try another server

user agent may act as redirect server

Location server (or service)

– Used by SIP redirect or proxy server to obtain information about a user’s possible location(s) – May be co-located with a SIP server but the manner in which a SIP server request location services is beyond the scope of SIP – May be anything

LDAP, whois Local file Result of program execution

39

Components (3) Registrar

– A server that accepts REGISTER requests – Typically co-located with a proxy or redirect server – Allows a client to let the proxy or redirect server know at which address(es) it can be reached

40

Methods

There are 6 methods in SIP

– Invite

Invites a participant to a conference Conference can be unicast, multicast, new or in existence

– Bye

Ends a client participation in a call

– Cancel

Terminates a search

– Options

Queries a participant about their media capabilities, and finds them, but does not invite

– Ack

Call acceptance Reliability

– Register

Informs a SIP server about the location of a user

41

Responses There are 6 types of status codes returned by the recipient of a request

– 1xx informational

Request received, continuing to process request E.g.: 100 trying, 180 ringing, 181 call is being forwarded, 182 queued

– 2xx success

Action successfully received, understood, & accepted E.g.: 200 OK

– 3xx redirection

Further action must be taken in order to complete the request E.g.: 300 multiple choices, 301 moved permanently, 302 moved temporarily, 305 use proxy

42

Responses (cont.)

– 4xx client error

Request contains bad syntax E.g.: 400 bad request, 401 unauthorized, 402 payment required

– 5xx server error

Server failed to fulfill an apparently valid request E.g.: 500 internal server error, 501 not implemented, 502 bad gateway

– 6xx global failure

The request cannot be fulfilled at any server E.g.: 600 busy everywhere, 604 does not exist anywhere, 606 not acceptable

43

Message Syntax

Text based Many header fields from http Some new ones

– also – replaces – via

Payload must contain media description

– Typically uses SDP

INVITE sip:baqai@lums.edu.pk SIP/2.0 From: sip:zartash@lums.edu.pk To: baqai@lums.edu.pk Call-ID: 20060321@sheranwala.lums Cseq: 10 INVITE v=0

• =user1 12345 6789 IN IPv4 172.28.0.6

s=Multimedia Communications i=Presentation Multimedia Comm. e=baqai@multimedia.lums.edu.pk c=IN IP4 224.2.0.1/127 t=0 0 m=audio 3456 RTP:AVP 0

44

Basic Operation

Client sends request to locally configured proxy server

• r obtains domain server IP address from the URL

(using DNS) Call initiator contacts SIP server for domain Location server contacts SIP server for domain Location server locates receiver Call is established

– Initiator sends an INVITE request – Invited party answers (agrees) – Initiator receives OK indication – Initiator sends an ACK request

45

Proxy Example

46

Redirect Example

47

Other Features

• Multiple call acceptances

– Client control – Client selection – Multiparty conferencing

• Multicast signaling

– Group invitation – Reach first

• Security

– Encryption authentication end-to-end – Uses existing mechanisms

• SIP servers can be stateless

– Stateful to stateless transition at any time – Robust & scalibility – Flexibility

• Third party call control

– Several simple mechanisms

48

Services

Call forwarding Hold Transfer

– Blind – With notification – Operator assisted

Full mesh unicast conferences Multicast conferences Authenticated Caller ID Camp-on Local services: call waiting, mute, DND, …

49

Advantages

Simplicity

– Fast operation, supports UDP based transactions – Single RTT needed for call setup, teardown or state change

Modularity Scalability

– Hierarchical feature – DNS based addressing – Multicast signaling – Big servers may be stateless, call state maybe stored in end systems

Extensibility Framework for services

– Many services possible – Provides basic primitives with well defined behavior