Network Working Group Request for Comments: 2327 Categor$: %tandards &ra"k

M. Handle . !a"o#son '%'()*N +pril ,--.

SDP: Session Description Protocol

Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (ST !" for the standardi#ation stat and status of this protocol. istri$ution of this memo is unlimited. Copyright Notice %opyright (%" The Internet Society (!&&'". (ll )ights )eserved. Abstract This document defines the Session escription Protocol, S P. S P is intended for descri$ing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document is a product of the *ultiparty *ultimedia Session %ontrol (**+SI%" ,orking group of the Internet -ngineering Task .orce. %omments are solicited and should $e addressed to the ,orking group/s mailing list at confctrl0isi.edu and1or the authors.

1 Introduction.......................................................................................................................3 2 Background.......................................................................................................................3 3 Glossary of Term .............................................................................................................3 3.1 Terminology...............................................................................................................4 4 SDP Usage........................................................................................................................4 4.1 ulticast !nnouncement ..........................................................................................4 4.2 "#mail and $$$ !nnouncement ...........................................................................4 % &e'uirements and &ecommendation ...............................................................................% %.1 edia Information.....................................................................................................% %.2 Timing Information....................................................................................................( %.3 Pri)ate Session ..........................................................................................................( %.4 *+taining ,urt-er Information a+out a Session ........................................................( %.% .ategori/ation ...........................................................................................................( %.( Internationali/ation ...................................................................................................0 ( SDP S1ecification ............................................................................................................0 (.1 .ommunicating .onference .ontrol Policy............................................................24 0 Security .onsideration ...................................................................................................24 2 !11endi3 !4 SDP Grammar...........................................................................................2( 5 !11endi3 B4 Guidelines for registering SDP names 6it- I!7!...................................38 18 !11endi3 .4 !ut-ors9 !ddresses .................................................................................33 11 !ckno6ledgment .........................................................................................................33 12 &eferences ....................................................................................................................33 13 ,ull .o1yrig-t Statement .............................................................................................34

Introduction

On the Internet multicast $ack$one (*$one", a session directory too is used to advertise multimedia conferences and communicate the conference addresses and conference tool2specific information necessary for participation. This document defines a session description protocol for this purpose, and for general real2time multimedia session description purposes. This memo does not descri$e multicast address allocation or the distri$ution of S P messages in detail. These are descri$ed in accompanying memos. S P is not intended for negotiation of media encodings.

ac!ground

The *$one is the part of the internet that supports IP multicast, and thus permits efficient many2to2many communication. It is use e3tensively for multimedia conferencing. Such conferences usually have the property that tight coordination of conference mem$ership is not necessary4 to receive a conference, a user at an *$one site only has to kno, the conference/s multicast group address and the + P ports for the conference data streams. Session directories assist the advertisement of conference session and communicate the relevant conference setup information to prospective participants. S P is designed to convey such information to recipients. S P is purely a format for session description 2 it does not incorporate a transport protocol, and is intended to use different transport protocols as appropriate including the Session (nnouncement Protocol 567, Session Initiation Protocol 5!!7, )eal2Time Streaming Protocol 5!87, electronic mail using the *I* e3tensions, and the 9yperte3t Transport Protocol. S P is intended to $e general purpose so that it can $e used for ,ider range of net,ork environments and applications than :ust multicast session directories. 9o,ever, it is not intended t support negotiation of session content or media encodings 2 this is vie,ed as outside the scope of session description.

"

#lossary of $erm

The follo,ing terms are used in this document, and have specific meaning ,ithin the conte3t of this document. Conference: ( multimedia conference is a set of t,o or more communicating user along ,ith the soft,are they are using to communicate. Session: ( multimedia session is a set of multimedia senders and receivers and the data streams flo,ing from senders to receivers. ( multimedia conference is an e3ample of a multimedia session. Session Advertisement: See session announcement. Session Announcement: ( session announcement is a mechanism $y ,hich a session description is conveyed to users in a proactive fashion, i.e., the session description ,as not e3plicitly requested $y the user. Session Description: ( ,ell defined format for conveying sufficient information to discover and participate in a multimedia session.

"%1

$erminology

The key ,ords "*+ST", "*+ST ;OT", ")-<+I)- ", "S9(==", "S9(== ;OT", "S9O+= ", "S9O+= ;OT", ")-%O**-; - ", "*(>", and "OPTIO;(=" in this document are to $e interpreted as descri$ed in ).% 8!!&.

&
&%1

SDP 'sage
Multicast Announcement

S P is a session description protocol for multimedia sessions. common mode of usage is for a client to announce a conference session $y periodically multicasting an announcement packet to a ,ell kno, multicast address and port using the Session (nnouncement Protocol (S(P". S(P packets are + P packets ,ith the follo,ing format? /00000000000000000000/ / %+1 2eader/ /00000000000000000000/ / te3t pa$load / /(((((((((( The header is the Session (nnouncement Protocol header. S(P is descri$ed in more detail in a companion memo 567. The te3t payload is an S P session description, as descri$ed in this memo. The te3t payload should $e no greater than ! @$yte in length. If announced $y S(P, only one session announcement is permitted in single packet. &%2 ()mail and *** Announcement

(lternative means of conveying session descriptions include electronic mail and the Aorld Aide Ae$. .or $oth email and AA distri$ution, the use of the *I*- content type "application1sdp" should $e used. This ena$les the automatic launching of application for participation in the session from the AAA client or mail reader in a standard manner. ;ote that announcements of multicast sessions made only via email of the Aorld Aide Ae$ (AAA" do not have the property that the receive of a session announcement can necessarily receive the session $ecause the multicast sessions may $e restricted in scope, and access to the AAA server or reception of email is possi$le outside this scope. S(P announcements do not suffer from this mismatch.

,e-uirements and ,ecommendation

The purpose of S P is to convey information a$out media streams in multimedia sessions to allo, the recipients of a session description to participate in the session. S P is primarily intended for use in an internet,ork, although it is sufficiently general that it can descri$e conferences in other net,ork environments. ( multimedia session, for these purposes, is defined as a set of media streams that e3ist for some duration of time. *edia stream can $e many2to2many. The times during ,hich the session is active need not $e continuous. Thus far, multicast $ased sessions on the Internet have differed fro many other forms of conferencing in that anyone receiving the traffic can :oin the session (unless the session traffic is encrypted". In such an environment, S P serves t,o primary purposes. It is a mean to communicate the e3istence of a session, and is a means to convey sufficient information to ena$le :oining and participating in the session. In a unicast environment, only the latter purpose is likely to $e relevant. Thus S P includes? Session name and purpose Time(s" the session is active The media comprising the session Information to receive those media (addresses, ports, formats and so on"

(s resources necessary to participate in a session may $e limited, some additional information may also $e desira$le? Information a$out the $and,idth to $e used $y the conference %ontact information for the person responsi$le for the session

In general, S P must convey sufficient information to $e a$le to :oin a session (,ith the possi$le e3ception of encryption keys" and to announce the resources to $e used to non2participants that may need to kno,. +%1 Media Information

S P includes? The type of media (video, audio, etc" The transport protocol ()TP1+ P1IP, 9.B8C, etc" The format of the media (9.8D! video, *P-E video, etc"

.or an IP multicast session, the follo,ing are also conveyed? *ulticast address for media Transport Port for media

This address and port are the destination address and destination port of the multicast stream, ,hether $eing sent, received, or $oth.

.or an IP unicast session, the follo,ing are conveyed? )emote address for media Transport port for contact address

The semantics of this address and port depend on the media and transport protocol defined. Fy default, this is the remote address and remote port to ,hich data is sent, and the remote address an local port on ,hich to receive data. 9o,ever, some media may define to use these to esta$lish a control channel for the actual media flo,. +%2 $iming Information

Sessions may either $e $ounded or un$ounded in time. Ahether or not they are $ounded, they may $e only active at specific times. S P can convey? (n ar$itrary list of start and stop times $ounding the session .or each $ound, repeat times such as "every Aednesday at !Cam for one hour"

This timing information is glo$ally consistent, irrespective of local time #one or daylight saving time. +%" Pri.ate Session

It is possi$le to create $oth pu$lic sessions and private sessions. Private sessions ,ill typically $e conveyed $y encrypting the session description to distri$ute it. The details of ho, encryption is performed are dependent on the mechanism used to convey S P 2 see 567 for ho, this is done for session announcements. If a session announcement is private it is possi$le to use that private announcement to convey encryption keys necessary to decode each of the media in a conference, including enough information to kno, ,hich encryption scheme is used for each media. +%& /btaining 0urther Information about a Session

( session description should convey enough information to decide ,hether or not to participate in a session. S P may include additional pointers in the form of +niversal )esources Identifier (+)Is" for more information a$out the session. +%+ Categori1ation

Ahen many session descriptions are $eing distri$uted $y S(P or an other advertisement mechanism, it may $e desira$le to filter announcements that are of interest from those that are not. S P supports a categori#ation mechanism for sessions that is capa$le of $eing automated.

+%2

Internationali1ation

The S P specification recommends the use of the ISO !CD6D character sets in the +T.2' encoding ().% 8C66" to allo, many different languages to $e represented. 9o,ever, to assist in compact representations, S P also allo,s other character sets such as ISO ''G&2! to $e used ,hen desired. Internationali#ation only applies to free2te3t fields (session name and $ackground information", and not to S P as a ,hole.

SDP Specification

S P session descriptions are entirely te3tual using the ISO !CD6D character set in +T.2' encoding. S P field names and attri$utes name use only the +S2(S%II su$set of +T.2', $ut te3tual fields and attri$ute values may use the full ISO !CD6D character set. the te3tual form, as opposed to a $inary encoding such as (S;1! or H ), ,as chosen to enhance porta$ility, to ena$le a variety of transport to $e used (e.g., session description in a *I*- email message" and to allo, fle3i$le, te3t2$ased toolkits (e.g., Tcl1Tk " to $e used to generate and to process session descriptions. 9o,ever, since the total $and,idth allocated to all S(P announcements is strictly limited, the encoding is deli$erately compact. (lso, since announcements may $e transported via very unrelia$le means (e.g., email" or damaged $y an intermediate caching server, the encoding ,ay designed ,ith strict order and formatting rules so that most error ,ould result in malformed announcements ,hich could $e detected easily and discarded. This also allo,s rapid discarding of encrypted announcements for ,hich a receiver does not have the correct key. (n S P session description consists of a num$er of lines of te3t or the form ItypeJKIvalueJ ItypeJ is al,ays e3actly one character and is case2significant. IvalueJ is a structured te3t string ,hose format depends on ItypeJ. It also ,ill $e case2significant unless specific field defines other,ise. Ahitespace is not permitted either side of the LK/ sign. In general IvalueJ is either a num$er of field delimited $y a single space character or a free format string. ( session description consists of a session2level description (details that apply to the ,hole session and all media streams" an optionally several media2level descriptions (details that apply ont to a single media stream". (n announcement consists of a session2level section follo,ed $y #ero or more media2 level sections. The session2level part starts ,ith LvK/ line and continues to the first media2level section. The media description starts ,ith an LmK/ line and continues to the ne3t media description or end of the ,hole session description. In general, session2level values are the default for all media unless overridden $y an equivalent media2level value. Ahen S P is conveyed $y S(P, only one session description is allo,ed per packet. Ahen S P is conveyed $y other means, many S P session descriptions may $e concatenated together (the LvK/ line indicating the start of a session description terminates the previous description". Some lines in each description are required and some are optional $ut all must appear in e3actly the order given here (the fi3ed order greatly enhances error detection and allo,s for a simple parser". Optional items are marked ,ith a LM/.

Session description vK (protocol version" oK (o,ner1creator and session identifier". sK (session name" iKM (session information" uKM (+)I of description" eKM (email address" pKM (phone num$er" cKM (connection information 2 not required if included in all media" $KM ($and,idth information" One or more time descriptions (see $elo," #KM (time #one ad:ustments" kKM (encryption key" aKM (#ero or more session attri$ute lines" Nero or more media descriptions (see $elo," Time description tK (time the session is active" rKM (#ero or more repeat times" *edia description mK (media name and transport address" iKM (media title" cKM (connection information 2 optional if included at session2level" $KM ($and,idth information" kKM (encryption key" aKM (#ero or more media attri$ute lines" The set of Ltype/ letters is deli$erately small and not intended to $e e3tensi$le 22 S P parsers must completely ignore any announcement that contains a Ltype/ letter that it does not understand. The Lattri$ute/ mechanism ("aK" descri$ed $elo," is the primary means for e3tending S P and tailoring it to particular applications or media. Some attri$utes (the ones listed in this document" have a define meaning $ut others may $e added on an application2, media2 of session2specific $asis. ( session directory must ignore an attri$ute it doesn/t understand. The connection (LcK/" and attri$ute (LaK/" information in the session2level section applies to all the media of that session unless overridden $y connection information or an attri$ute of the same name in the media description. .or instance, in the e3ample $elo,, each media $ehaves as if it ,ere given a Lrecvonly/ attri$ute.

(n e3ample S P description is? 456 o5m2andle$ 2.-6.77829 2.-6.72.67 'N '17 ,29.,9.97.7 s5%:1 %emina i5+ %eminar on t2e session des"ription proto"ol u52ttp:((www."s.u"l.a".uk(staff(M.Handle$(sdp.63.ps e5m;2<isi.edu =Mark Handle$> "5'N '17 227.2.,7.,2(,27 t52.733-77-9 2.737679-9 a5re"4onl m5audio 7-,76 R&1(+ 1 6 m54ideo 8,372 R&1(+ 1 3, m5appli"ation 327,9 udp w# a5orient:portrait Te3t records such as the session name and information are $yte strings ,hich may contain any $yte ,ith the e3ceptions of C3CC (;ul", C3Ca ((S%II ne,line" and C3Cd ((S%II carriage return". The sequence %)=. (C3CdCa" is used to end a record, although parsers should $e tolerant and also accept records terminated ,ith a single ne,line character. Fy default these $yte strings contain ISO2!CD6D characters in +T.2' encoding, $ut this default may $e changed using the Lcharset/ attri$ute. Protocol Oersion vKC The "vK" field gives the version of the Session There is no minor version num$er. Origin oKIusernameJ Isession idJ IversionJ Inet,ork typeJ Iaddress typeJ IaddressJ The "oK" field gives the originator of the session (their username and the address of the user/s host" plus a session id and session version num$er. IusernameJ is the user/s login on the originating host, or it is "2" if the originating host does not support the concept of user ids. IusernameJ must not contain spaces. Isession idJ is a numeric string such that the tuple of IusernameJ, Isession idJ, Inet,ork typeJ, Iaddress typeJ and IaddressJ form a glo$ally unique identifier for the session. The method of Isession idJ allocation is up to the creating tool, $ut it has $een suggested that a ;et,ork Time Protocol (;TP" timestamp $e used to ensure uniqueness 5!7. IversionJ is a version num$er for this announcement. It is needed for pro3y announcements to detect ,hich of several announcements for the same session is the most recent. (gain its usage is up to the creating tool, so long as IversionJ is increased ,hen a modification is made to the session data. (gain, it is recommended ($ut no mandatory" that an ;TP timestamp is used. Inet,ork typeJ is a te3t string giving the type of net,ork. Initially "I;" is defined to have the meaning "Internet". escription Protocol.

Iaddress typeJ is a te3t string giving the type of the address that follo,s. Initially "IP6" and "IPD" are defined. IaddressJ is the glo$ally unique address of the machine from ,hich the session ,as created. .or an address type of IP6, this is either the fully2qualified domain name of the machine, or the dotted2decimal representation of the IP version 6 address of the machine. .or an address type of IPD, this is either the fully2qualified domain name of the machine, or the compressed te3tual representation of the IP version D address of the machine. .or $oth IP6 and IPD, the fully2qualified domain name in the form that S9O+= $e given unless this is unavaila$le, in ,hich case the glo$ally unique address may $e su$stituted. ( local IP address *+ST ;OT $e used in any conte3t ,here the S P description might leave the scope in ,hich the address is meaningful. In general, the "oK" field serves as a glo$ally unique identifier for this version of this session description, and the su$fields e3cepting the version taken together identify the session irrespective of an modifications. Session ;ame sKIsession nameJ The "sK" field is the session name. There must $e one and only on "sK" field per session description, and it must contain ISO !CD6D characters ($ut see also the Lcharset/ attri$ute $elo,". Session and *edia Information iKIsession descriptionJ The "iK" field is information a$out the session. There may $e a most one session2level "iK" field per session description, and a most one "iK" field per media. (lthough it may $e omitted, this is discouraged for session announcements, and user interfaces for composing sessions should require te3t to $e entered. If it is present it must contain ISO !CD6D characters ($ut see also the Lcharset/ attri$ute $elo,". ( single "iK" field can also $e used for each media definition. If media definitions, "iK" fields are primarily intended for la$eling media streams. (s such, they are most likely to $e useful ,hen single session has more than one distinct media stream of the same media type. (n e3ample ,ould $e t,o different ,hite$oards, one for slides and one for feed$ack and questions. +)I uKI+)IJ ( +)I is a +niversal )esource Identifier as used $y AAA client The +)I should $e a pointer to additional information a$out the conference This field is optional, $ut if it is present it should $e specified $efore the first media field ;o more than one +)I field is allo,ed per session description

18

-mail (ddress and Phone ;um$er eKIemail addressJ pKIphone num$erJ These specify contact information for the person responsi$le for the conference. This is not necessarily the same person that created the conference announcement. -ither an email field or a phone field must $e specified. (dditional email and phone fields are allo,ed. If these are present, they should $e specified $efore the first media field. *ore than one email or phone field can $e given for a session description. Phone num$ers should $e given in the conventional international format 2 preceded $y a "PQ and the international country code. There must $e a space or a hyphen ("2"" $et,een the country code and the rest of the phone num$er. Spaces and hyphens may $e used to split up a phone field to aid reada$ility if desired. for e3ample? p5?770,7,03.607777 or p5?, 9,7 283 96,, Foth email addresses and phone num$ers can have an optional free te3t string associated ,ith them, normally giving the name of the person ,ho may $e contacted. This should $e enclosed in parenthesis if it is present. .or e3ample? e5m;2<isi.edu =Mark Handle$> The alternative ).%'88 name quoting convention is also allo,ed for $oth email addresses and phone num$ers. .or e3ample, e5Mark Handle$ @m;2<isi.eduA The free te3t string should $e in the ISO2!CD6D character set ,ith +T.2' encoding, or alternatively in ISO2''G&2! or other encoding if the appropriate charset session2level attri$ute is set. %onnection ata cKInet,ork typeJ Iaddress typeJ Iconnection addressJ The "cK" field contains connection data. ( session announcement must contain one "cK" field in each media description (see $elo," or a "cK" field at the session2level. It may contain a session2level "cK" field and one additional "cK" field per media description, in ,hich case the per2media values override the session2level settings for the relevant media. The first su$2field is the net,ork type, ,hich is a te3t string giving the type of net,ork. Initially "I;" is defined to have the meaning "Internet". The second su$2field is the address type. This allo,s S P to $e use for sessions that are not IP $ased. %urrently only IP6 is defined. The third su$2field is the connection address. Optional e3tra su$fields may $e added after the connection address depending on the value of the Iaddress typeJ field.

11

.or IP6 addresses, the connection address is defined as follo,s? o Typically the connection address ,ill $e a class2 IP multicast group address. If the session is not multicast, then the connection address contains the fully2qualified domain name or the unicast IP address of the e3pected data source or data relay of data sink as determined $y additional attri$ute fields. It is not e3pected that fully2qualified domain names or unicast addresses ,ill $e given in a session description that is communicated $y multicast announcement, though this is not prohi$ited. If unicast data stream is to pass through a net,ork address translator, the use of a fully2qualified domain name rather than a unicast IP address is )-%O**-; - . In other cases, the use of a IP address to specify a particular interface on a multi2homed host might $e required. Thus this specification leaves the decision as to ,hich to use up to the individual application, $ut all applications *+ST $e a$le to cope ,ith receiving $oth formats. %onferences using an IP multicast connection address must also have a time to live (TT=" value present in addition to the multicast address. The TT= and the address together define the scope ,ith ,hich multicast packets sent in this conference ,ill $e sent. TT= values must $e in the range C28GG. The TT= for the session is appended to the address using a slash as a separator. (n e3ample is? cKI; IP6 886.8.!.!1!8R 9ierarchical or layered encoding schemes are data streams ,here the encoding from a single media source is split into a num$er of layers. The receiver can choose the desired quality (and hence $and,idth" $y only su$scri$ing to a su$set of these layers. Such layered encodings are normally transmitted in multiple multicast groups to allo, multicast pruning. This technique keeps un,anted traffic from sites only requiring certain levels of the hierarchy. .or applications requiring multiple multicast groups, ,e allo, the follo,ing notation to $e used for the connection address? I$ase multicast addressJ1IttlJ1Inum$er of addressesJ If the num$er of addresses is not given it is assumed to $e one. *ulticast addresses so assigned are contiguously allocated a$ove the $ase address, so that, for e3ample? cKI; IP6 886.8.!.!1!8R1B ,ould state that addresses 886.8.!.!, 886.8.!.8 and 886.8.!.B are to $e used at a ttl of !8R. This is semantically identical to including multiple "cK" lines in a media description?

12

cKI; IP6 886.8.!.!1!8R cKI; IP6 886.8.!.81!8R cKI; IP6 886.8.!.B1!8R *ultiple addresses or "cK" lines can only $e specified on a per2media $asis, and not for a session2level "cK" field. It is illegal for the slash notation descri$ed a$ove to $e used for IP unicast addresses. Fand,idth $KImodifierJ?I$and,idth2valueJ This specifies the proposed $and,idth to $e used $y the session or media, and is optional. I$and,idth2valueJ is in kilo$its per second ImodifierJ is a single alphanumeric ,ord giving the meaning of the $and,idth figure. T,o modifiers are initially defined?

CT Conference Total: (n implicit ma3imum $and,idth is associated ,ith each TT= on the *$one or ,ithin a particular multicast administrative scope region (the *$one $and,idth vs. TT= limits are given in the *Fone .(<". If the $and,idth of a session or media in a session is different from the $and,idth implicit from the scope, a L$K%T?.../ line should $e supplied for the session giving the proposed upper limit to the $and,idth used. The primary purpose of this is to give an appro3imate idea as to ,hether t,o or more conferences can co2e3ist simultaneously. AS Application-Specific Maximum: The $and,idth is interpreted to $e application2specific, i.e., ,ill $e the application/s concept of ma3imum $and,idth. ;ormally this ,ill coincide ,ith ,hat is set of the application/s "ma3imum $and,idth" control if applica$le. ;ote that %T gives a total $and,idth figure for all the media and all sites. (S gives a $and,idth figure for a single media at single site, although there may $e many sites sending simultaneously. -3tension *echanism? Tool ,riters can define e3perimental $and,idth modifiers $y prefi3ing their modifier ,ith "H2". .or e3ample? $KH2>N?!8' S P parsers should ignore $and,idth fields ,ith unkno,n modifiers. *odifiers should $e alpha2numeric and, although no length limit is given, they are recommended to $e short.

13

Times, )epeat Times and Time None tKIstart timeJ Istop timeJ o "tK" fields specify the start and stop times for a conference session. *ultiple "tK" fields may $e used if a session is active at multiple irregularly spaced times4 each additional "tK" field specifies an additional period of time for ,hich the session ,ill $e active. If the session is active at regular times, an "rK" field (see $elo," should $e used in addition to and follo,ing "tK" field 2 in ,hich case the "tK" field specifies the start an stop times of the repeat sequence. The first and second su$2fields give the start and stop times for the conference respectively. These values are the decimal representation of ;et,ork Time Protocol (;TP" time values in seconds 5!7. To convert these values to +;IH time, su$tract decimal 88C'&'''CC. If the stop2time is set to #ero, then the session is not $ounded, though it ,ill not $ecome active until after the start2time. If the start2time is also #ero, the session is regarded as permanent. +ser interfaces should strongly discourage the creation of un$ounded and permanent sessions as they give no information a$out ,hen the session is actually going to terminate, and so make scheduling difficult. The general assumption may $e made, ,hen displaying un$ounded sessions that have not timed out to the user, that an un$ounded session ,ill only $e active until half an hour from the current time or the session start time, ,hichever is the later. If $ehavior other than this is required, an end2time should $e give and modified as appropriate ,hen ne, information $ecomes availa$le a$out ,hen the session should really end. Permanent sessions may $e sho,n to the user as never $eing active unless there are associated repeat times ,hich state precisely ,hen the session ,ill $e active. In general, permanent sessions should not $e created for any session e3pected to have a duration of les than 8 months, and should $e discouraged for sessions e3pected to have a duration of less than D months. rKIrepeat intervalJ Iactive durationJ Ilist of offsets from start2timeJ o "rK" fields specify repeat times for a session. .or e3ample, in a session is active at !Cam on *onday and !!am on Tuesday for one hour each ,eek for three months, then the Istart timeJ in the corresponding "tK" field ,ould $e the ;TP representation of !Cam of the first *onday, the Irepeat intervalJ ,ould $e ! ,eek, the Iactive durationJ ,ould $e ! hour, and the offsets ,ould $e #ero and 8G hours. The corresponding "tK" field stop time ,ould $e the ;TP representation of the end of the last session three month later. Fy default all fields are in seconds, so the "rK" and "tK" fields might $e? tKBCB668BD!& BC686D86!&

14

rKDC6'CC BDCC C &CCCC To make announcements more compact, times may also $e given in unit of days, hours or minutes. The synta3 for these is a num$er immediately follo,ed $y a single case2sensitive character. .ractional units are not allo,ed 2 a smaller unit should $e use instead. The follo,ing unit specification characters are allo,ed? d 2 days ('D6CC seconds" h 2 minutes (BDCC seconds" m 2 minutes (DC seconds" s 2 seconds (allo,ed for completeness $ut not recommended" Thus, the a$ove announcement could also have $een ,ritten? rKRd !h C 8G *onthly and yearly repeats cannot currently $e directly specified ,ith a single S P repeat time 2 instead separate "t" fields should $e used to e3plicitly list the session times. #KIad:ustment timeJ IoffsetJ Iad:ustment timeJ IoffsetJ .... o To schedule a repeated session ,hich spans a change from daylight2 saving time to standard time or vice2versa, it is necessary to specify offsets from the $ase repeat times. This is require $ecause different time #ones change time at different times of day, different countries change to or from daylight time on different dates, and some countries do not have daylight saving time at all. Thus in order to schedule a session that is at the same time ,inter and summer, it must $e possi$le to specify unam$iguously $y ,hose time #one a session is scheduled. To simplify this task for receivers, ,e allo, the sender to specify the ;TP time that a time #one ad:ustment happens and the offset from the time ,hen the session ,as first scheduled. The "#" field allo,s the sender to specify a list of these ad:ustment times and offsets from the $ase time. (n e3ample might $e? #K8''8'66G8D 2!h 8'&''6'CRC C This specifies that at time 8''8'66G8D the time $ase $y ,hich the session/s repeat times are calculated is shifted $ack $y ! hour, and that at time 8'&''6'CRC the session/s original time $ase is restored. (d:ustments are al,ays relative to the specified start time 2 they are not cumulative. o If a session is likely to last several years, it is e3pected that the session announcement ,ill $e modified periodically rather than transmit several years ,orth of ad:ustments in one announcement.

-ncryption @ey

1%

kKImethodJ kKImethodJ?Iencryption keyJ o The session description protocol may $e used to convey encryption keys. ( key field is permitted $efore the first media entry (in ,hich case it applies to all media in the session", or for each media entry as required. The format of keys and their usage is outside the scope of this document, $ut see 5B7. The method indicates the mechanism to $e used to o$tain a usa$le key $y e3ternal means, or from the encoded encryption key given. The follo,ing methods are defined? k=clear:Iencryption keyJ The encryption key (as descri$ed in 5B7 for )TP media stream under the (O profile" is included untransformed in this key field. k=base64:Iencoded encryption keyJ The encryption key (as descri$ed in 5B7 for )TP media stream under the (O profile" is included in this key field $ut has $een $aseD6 encoded $ecause it includes characters that are prohi$ited in S P. k=uri: !"# to obtain ke$% ( +niversal )esource Identifier as used $y AAA clients is included in this key field. The +)I refers to the data containing the key, and may require additional authentication $efore the key can $e returned. Ahen a request is made to the given +)I, the *I*- content2type of the reply specifies the encoding for the key in the reply. The key should not $e o$tained until the user ,ishes to :oin the session to reduce synchroni#ation of requests to the AAA server(s". k=prompt ;o key is included in this S P description, $ut the session of media stream referred to $y this key field is encrypted. The user should $e prompted for the key ,hen attempting to :oin the session, and this user2supplied key should then $e used to decrypt the media streams. (ttri$utes aKIattri$uteJ aKIattri$uteJ?IvalueJ (ttri$utes are the primary means for e3tending S P. (ttri$utes may $e defined to $e used as "session2level" attri$utes, "media2level" attri$utes, or $oth. ( media description may have any num$er of attri$utes ("aK" fields" ,hich are media specific. These are referred to as "media2level" attri$utes and add information a$out the media stream. (ttri$ute fields can also $e added $efore the first media field4 these "session2level" attri$utes convey additional information that applied to the conference as a ,hole rather than to individual media4 an e3ample might $e the conference/s floor control policy.

1(

(ttri$ute fields may $e of t,o forms? o property attri$utes. ( property attri$ute is simply of the form "aKIflagJ". These are $inary attri$utes, and the presence of the attri$ute conveys that the attri$ute is a property of the session. (n e3ample might $e "aKrecvonly". value attri$utes. ( value attri$ute is of the for "aKIattri$uteJ?IvalueJ". (n e3ample might $e that a ,hite$oard could have the value attri$ute "aKorient?landscape"

(ttri$ute interpretation depends on the media tool $eing invoked. Thus receivers of session descriptions should $e configura$le in their interpretation of announcements in general and of attri$utes in particular. (ttri$ute names must $e in the +S2(S%II su$set of ISO2!CD6D1+T.2'. (ttri$ute values are $yte strings, and *(> use any $yte value e3cept C3CC (;ul", C3C( (=.", and C3C (%)". Fy default, attri$ute value are to $e interpreted as in ISO2!CD6D character set ,ith +T.2' encoding. +nlike other te3t fields, attri$ute values are ;O normally affected $y the Lcharset/ attri$ute as this ,ould make comparisons against kno,n values pro$lematic. 9o,ever, ,hen a attri$ute is defined, it can $e defined to $e charset2 dependent, in ,hich case it/s value should $e interpreted in the session charset rather than in ISO2!CD6D. (ttri$utes that ,ill $e commonly used can $e registered ,ith I(; (see (ppendi3 F". +nregistered attri$utes should $egin ,ith "H2" to prevent inadvertent collision ,ith registered attri$utes. In either case, if an attri$ute is received that is not understood, it should simply $e ignored $y the receiver. *edia (nnouncement mKImediaJ IportJ ItransportJ Ifmt listJ ( session description may contain a num$er of media descriptions. -ach media description starts ,ith an "mK" field, and is terminate $y either the ne3t "mK" field or $y the end of the session description. ( media field also has several su$2fields? o The first su$2field is the media type. %urrently defined media are "audio", "video", "application", "data" and "control", though this list may $e e3tended as ne, communication modalities emerge (e.g., telepresense". The difference $et,een "application" and "data" is that the former is a media flo, such as ,hite$oard information, an the latter is $ulk2data transfer such as multicasting of program e3ecuta$les ,hich ,ill not typically $e displayed to the user. "control" is used to specify an additional conference control channel for the session. The second su$2field is the transport port to ,hich the media stream ,ill $e sent. The meaning of the transport port depends of the net,ork $eing used as specified in the relevant "c" field and on the transport

10

protocol defined in the third su$2field. Other ports used $y the media application (such as the )T%P port, see 587" should $e derived algorithmically from the $ase media port. ;ote? .or transports $ased on + P, the value should $e in the range !C86 to DGGBG inclusive. .or )TP compliance it should $e an even num$er. .or applications ,here hierarchically encoded streams are $eing sent to a unicast address, it may $e necessary to specify multiple transport ports. This is done using a similar notation to that used for IP multicast addresses in the "cK" field? mKImediaJ IportJ1Inum$er of portsJ ItransportJ Ifmt listJ In such a case, the ports used depend on the transport protocol. .or )TP, only the even ports are used for data and the corresponding one2 higher odd port is used for )T%P. .or e3ample? mKvideo 6&!RC18 )TP1(OP B! ,ould specify that ports 6&!RC and 6&!R! form one )TP1)T%P pair an 6&!R8 and 6&!RB form the second )TP1)T%P pair. )TP1(OP is the transport protocol and B! is the format (see $elo,". It is illegal for $oth multiple addresses to $e specified in the "cK" field and for multiple ports to $e specified in the "mK" field in the same session description. o The third su$2field is the transport protocol. The transport protocol values are dependent on the address2type field in the "cK" fields. Thus a "cK" field of IP6 defines that the transport protocol runs over IP6. .or IP6, it is normally e3pected that most media traffic ,ill $e carried as )TP over + P. The follo,ing transport protocols are preliminarily defined, $ut may $e e3tended through registration of ne, protocols ,ith I(;(? 2 )TP1(OP 2 the I-T./s )ealtime Transport Protocol using the (udio1Oideo profile carried over + P. 2 udp 2 +ser atagram Protocol

If an application uses a single com$ined proprietary media format and transport protocol over + P, then simply specifying the transport protocol as udp and using the format field to distinguish the com$ined protocol is recommended. If a transport protocol is used over + P to carry several distinct media types that need to $e distinguished $y a session directory, then specifying the transport protocol and media format separately is necessary. )TP is a e3ample of a transport2 protocol that carries multiple payload formats that must $e distinguished $y the session directory for it to kno, ho, to start appropriate tools, relays, mi3ers of recorders.

12

The main reason to specify the transport2protocol in addition to the media format is that the same standard media formats may $e carried over different transport protocols even ,hen the net,ork protocol is the same 2 a historical e3ample is vat P%* audio an )TP P%* audio. In addition, relays and monitoring tools that are transport2protocol2specific $ut format2independent are possi$le. .or )TP media streams operating under the )TP (udio1Oideo Profile 5B7, the protocol field is ")TP1(OP". Should other )TP profiles $e defined in the future, their profiles ,ill $e specified in the same ,ay. .or e3ample, the protocol field ")TP1H>N" ,ould specify )T operating under a profile ,hose short name is "H>N". o The fourth and su$sequent su$2fields are media formats. .or audio and video, these ,ill normally $e a media payload type as define in the )TP (udio1Oideo Profile. Ahen a list of payload formats is given, this implies that all of these formats may $e used in the session, $ut the first of these formats is the default format for the session. .or media ,hose transport protocol is not )TP or + P the format field is protocol specific. Such formats should $e defined in an additional specification document. .or media ,hose transport protocol is )TP, S P can $e used to provide a dynamic $inding of media encoding to )TP payload type. The encoding names in the )TP (O Profile do not specify unique audio encodings (in terms of clock rate and num$er of audio channels", and so they are not used directly in S P format fields. Instead, the payload type num$er should $e used to specify the format for static payload types and the payload type num$er along ,ith additional encoding information should $e used for dynamically allocated payload types. (n e3ample of a static payload type is u2la, P%* coded single channel audio sampled at '@9#. This is completely defined in the )TP (udio1Oideo profile as payload type C, so the media field for such a stream sent to + P port 6&8B8 is? mKvideo 6&8B8 )TP1(OP C (n e3ample of a dynamic payload type is !D $it linear encoded stereo audio sampled at !D@9#. If ,e ,ish to use dynamic )TP1(O payload type &' for such a stream, additional information is required to decode it? mKvideo 6&8B8 )TP1(OP &' aKrtpmap?&' =!D1!DCCC18 The general form of an rtpmap attri$ute is?

15

aKrtpmap?Ipayload typeJ Iencoding nameJ1Iclock rateJ51Iencoding parametersJ7 .or audio streams, Iencoding parametersJ may specify the num$er of audio channels. This parameter may $e omitted if the num$er of channels is one provided no additional parameters are needed. .or video streams, no encoding parameters are currently specified. (dditional parameters may $e defined in the future, $ut codecspecific parameters should not $e added. Parameters added to an rtpmap attri$ute should only $e those required for a session directory to make the choice of appropriate media too to participate in a session. %odec2 specific parameters should $e added in other attri$utes. +p to one rtpmap attri$ute can $e defined for each media format specified. Thus ,e might have? mKaudio 6&8BC )TP1(OP &D &R &' aKrtpmap?&D ='1'CCC aKrtpmap?&R =!D1'CCC aKrtpmap?&' =!D1!!C8G18 )TP profiles that specify the use of dynamic payload types must define the set of valid encoding names and1or a means to registed encoding names if that profile is to $e used ,ith S P. -3perimental encoding formats can also $e specified using rtpmap. )TP formats that are not registered as standard format names must $e preceded $y "H2". Thus a ne, e3perimental redundant audio stream called ES*=P% using dynamic payload type && could $e specified as? mKvideo 6&8B8 )TP1(OP && aKrtpmap?&& H2ES*=P%1'CCC Such an e3perimental encoding requires that any site ,ishing to receive the media stream has relevant configured state in it session directory to kno, ,hich tools are appropriate. ;ote that )TP audio formats typically do not include information a$out the num$er of samples per packet. If a non2default (a defined in the )TP (udio1Oideo Profile" packetisation is required, the "ptime" attri$ute is used as given $elo,. .or more details on )TP audio and video formats, see 5B7. o .ormats for non2)TP media should $e registered as *I*- content types as descri$ed in (ppendi3 F. .or e3ample, the =F= ,hite$oard application might $e registered as *I*- content2type application1,$ ,ith encoding considerations specifying that it operates over + P, ,ith no appropriate file format. In S P this ,ould then $e e3pressed using a com$ination of the "media" field and the "fmt" field, as follo,s?

28

mKapplication B86!D udp , Suggested (ttri$ute The follo,ing attri$utes are suggested. Since application ,riter may add ne, attri$utes as they are required, this list is no e3haustive. a=cat: cate&or$% This attri$ute gives the dot2separated hierarchical category of the session. This is to ena$le a receiver to filter un,anted sessions $y category. It ,ould pro$a$ly have $een a compulsory separate field, e3cept for its e3perimental nature at this time. It is a session2level attri$ute, and is not dependent on charset. a=ke$'ds: ke$'ords% =ike the cat attri$ute, this is to assist identifying ,anted sessions at the receiver. This allo,s a receiver to select interesting session $ased on key,ords descri$ing the purpose of the session. It is a session2level attri$ute. It is a charset dependent attri$ute, meaning that its value should $e interpreted in the charset specified for the session description if one is specified, or $y default in ISO !CD6D1+T.2'. a=tool: name and version of tool% This gives the name and version num$er of the tool used to create the session description. It is a session2level attri$ute, and is not dependent on charset. a=ptime: packet time% This gives the length of time in milliseconds represented $y the media in a packet. This is pro$a$ly only meaningful for audio data. It should not $e necessary to kno, ptime to decode )TP of vat audio, and it is intended as a recommendation for the encoding1packetisation of audio. It is a media attri$ute, and is not dependent on charset. a=recvonl This specifies that the tools should $e started in receive2only mode ,here applica$le. It can $e either a session or media attri$ute, and is not dependent on charset. a=sendrec This specifies that the tools should $e started in send an receive mode. This is necessary for interactive conferences ,ith tools such as ,$ ,hich defaults to receive only mode. It can $e either a session or media attri$ute, and is not dependent of charset. a=sendonl This specifies that the tools should $e started in send2only mode. (n e3ample may $e ,here a different unicast address is to $e used for a traffic destination than for a traffic source. If such a case, t,o media descriptions may $e use, one sendonly an one recvonly. It can $e either a session or media attri$ute, $ut ,ould normally only $e used as a media attri$ute, and is no dependent on charset. a=orient: '(iteboard orientation% ;ormally this is only used in a ,hite$oard media specification. It specifies the orientation of a the ,hite$oard on the screen. It is a media attri$ute. Permitted values are Lportrait/, Llandscape/ and Lseascape/ (upside do,n landscape". It is not dependent on charset a=t$pe: conference t$pe% This specifies the type of the conference. Suggested values are L$roadcast/, Lmeeting/, Lmoderated/, Ltest/ and L9BB8/.

21

Lrecvonly/ should $e the default for Ltype?$roadcast/ sessions, Ltype?meeting/ should imply Lsendrecv/ and Ltype?moderated/ should indicate the use of a floor control tool and that the media tools are started so as to "mute" ne, sites :oining the conference. Specifying the attri$ute type?9BB8 indicates that this loosely coupled session is part of a 9.BB8 session as defined in the IT 9.BB8 specification 5!C7. *edia tools should $e started Lrecvonly/. Specifying the attri$ute type?test is suggested as a hint that, unless e3plicitly requested other,ise, receivers can safely avoid displaying this session description to users. The type attri$ute is a session2level attri$ute, and is no dependent on charset. a=c(arset: c(aracter set% This specifies the character set to $e used to display the session name and information data. Fy default, the ISO2!CD6D character set in +T.2' encoding is used. If a more compact representation is required, other character sets may $e used such as ISO2''G&2! for ;orthern -uropean languages. In particular, the ISO ''G&2! is specified ,ith the follo,ing S P attri$ute? aKcharset?ISO2''G&2! This is a session2level attri$ute4 if this attri$ute is present, it must $e $efore the first media field. The charset specified *+ST $e one of those registered ,ith I(;(, such as ISO2''G&2!. The character set identifier is a +S2(S%II string and *+ST $e compared against the I(;( identifiers using a case2 insensitive comparison. If the identifier is not recogni#ed or no supported, all strings that are affected $y it S9O+= $e regarded as $yte strings. ;ote that a character set specified *+ST still prohi$it the use of $ytes C3CC (;ul", C3C( (=." and C3Cd (%)". %haracter set requiring the use of these characters *+ST define a quoting mechanism that prevents these $ytes appearing ,ithin te3t fields. a=sdplan&: lan&ua&e ta&% This can $e a session level attri$ute or a media level attri$ute. (s a session level attri$ute, it specifies the language for the session description. (s a media level attri$ute, it specifies the language for any media2level S P information field associate ,ith that media. *ultiple sdplang attri$utes can $e provide either at session or media level if multiple languages in the session description or media use multiple languages, in ,hich case the order of the attri$utes indicates the order of importance of the various languages in the session or media from most important to least important. In general, sending session descriptions consisting of multiple languages should $e discouraged. Instead, multiple description should $e sent descri$ing the session, one in each language. 9o,ever this is not possi$le ,ith all transport mechanisms, and so multiple sdplang attri$utes are allo,ed although not recommended.

22

The sdplang attri$ute value must $e a single ).% !RDD language tag in +S2 (S%II. It is not dependent on the charset attri$ute. (n sdplang attri$ute S9O+= $e specified ,hen a session is of sufficient scope to cross geographic $oundaries ,here the language of recipients cannot $e assumed, or ,here the session is in a different language from the locally assumed norm. a=lan&: lan&ua&e ta&% This can $e a session level attri$ute or a media level attri$ute. (s a session level attri$ute, it specifies the default language for the session $eing descri$ed. (s a media level attri$ute, it specifies the language for that media, overriding any session2level language specified. *ultiple lang attri$utes can $e provided either at session or media level if multiple language if the session description or media use multiple languages, in ,hich case the order of the attri$utes indicates the order of importance of the various languages in the session or media fro most important to least important. The lang attri$ute value must $e a single ).% !RDD language tag in +S2(S%II. It is not dependent on the charset attri$ute. lang attri$ute S9O+= $e specified ,hen a session is of sufficient scope to cross geographic $oundaries ,here the language of recipients cannot $e assumed, or ,here the session is in a different language from the locally assumed norm. a=framerate: frame rate% This gives the ma3imum video frame rate in frames1sec. It is intended as a recommendation for the encoding of video data. ecimal representations of fractional values using the notation "IintegerJ.IfractionJ" are allo,ed. It is a media attri$ute, is only defined for video media, and is not dependent on charset. a=)ualit$: )ualit$% This gives a suggestion for the quality of the encoding as an integer value. The intention of the quality attri$ute for video is to specify non2default trade2 off $et,een frame2rate and still2image quality. .or video, the value in the range C to !C, ,ith the follo,ing suggested meaning? !C 2 the $est still2image quality the compression scheme can give. G 2 the default $ehavior given no quality suggestion. C 2 the ,orst still2image quality the codec designer thinks is still usa$le. It is a media attri$ute, and is not dependent on charset. a=fmtp: format% format specific parameters% This attri$ute allo,s parameters that are specific to particular format to $e conveyed in a ,ay that S P doesn/t have to understand them. The format must $e one of the format specified for the media. .ormat2specific parameters may $e any set of parameters required to $e conveyed $y S P and give unchanged to the media tool that ,ill use this format. It is a media attri$ute, and is not dependent on charset.

23

2%1

Communicating Conference Control Policy

There is some de$ate over the ,ay conference control policy should $e communicated. In general, the authors $elieve that an implicit declarative style of specifying conference control is desira$le ,here possi$le. ( simple declarative style uses a single conference attri$ute field $efore the first media field, possi$ly supplemented $y properties such as Lrecvonly/ for some of the media tools. This conference attri$ute conveys the conference control policy. (n e3ample might $e? aKtype?moderate In some cases, ho,ever, it is possi$le that this may $e insufficient to communicate the details of an unusual conference control policy. If this is the case, then a conference attri$ute specifying e3ternal control might $e set, and then one or more "media" fields might $e used to specify the conference control tools and configuration data for those tools. (n e3ample is an IT+ 9.BB8 session? cKI; IP6 886.G.D.R aKtype?9BB8 mKaudio 6&8BC )TP1(OP C mKvideo 6&8B8 )TP1(OP B! mKapplication !8B6& udp , mKcontrol 6&8B6 9B8B m cKI; IP6 !B6.!B6.!GR.'! In this e3ample, a general conference attri$ute (type?9BB8" is specified stating that conference control ,ill $e provided $y a e3ternal 9.BB8 tool, and a contact addresses for the 9.B8B session multipoint controller is given. In this document, only the declarative style of conference control declaration is specified. Other forms of conference control should specify an appropriate type attri$ute, and should define the implications this has for control media.

Security Consideration

S P is a session description format that descri$es multimedia sessions. ( session description should not $e trusted unless it ha $een o$tained $y an authenticated transport protocol from a trusted source. *any different transport protocols may $e used to distri$ute session description, and the nature of the authentication ,ill differ from transport to transport. One transport that ,ill frequently $e used to distri$ute session descriptions is the Session (nnouncement Protocol (S(P". S(P provides $oth encryption and authentication mechanisms $ut due to the nature of session announcements it is likely that there are many occasions ,here the originator of a session announcement cannot $e authenticated $ecause they are previously unkno,n to the receiver of the announcement and $ecause no common pu$lic key infrastructure is availa$le. On receiving a session description over an unauthenticated transport mechanism or from an untrusted party, soft,are parsing the session should take a fe, precautions. Session description contain information required to start soft,are on the receivers system. Soft,are that parses a session description *+ST not $e a$le to start other soft,are e3cept that ,hich is specifically configured a appropriate soft,are to

24

participate in multimedia sessions. It is normally considered I;(PP)OP)I(T- for soft,are parsing a session description to start, on a user/s system, soft,are that is appropriate to participate in multimedia sessions, ,ithout the use first $eing informed that such soft,are ,ill $e started and giving their consent. Thus a session description arriving $y session announcement, email, session invitation, or AAA page S9O+= no deliver the user into an Sit interactiveT multimedia session ,ithout the user $eing a,are that this ,ill happen. (s it is not al,ays simple to tell ,hether a session is interactive or not, application that are unsure should assume sessions are interactive. In this specification, there are no attri$utes ,hich ,ould allo, the recipient of a session description to $e informed to start multimedia tools in a mode ,here they default to transmitting. +nder some circumstances it might $e appropriate to define such attri$utes. I this is done an application parsing a session description containing such attri$utes S9O+= either ignore them, or inform the user that :oining this session ,ill result in the automatic transmission of multimedia data. The default $ehavior for an unkno,n attri$ute is to ignore it. Session descriptions may $e parsed at intermediate systems such a fire,alls for the purposes of opening a hole in the fire,all to allo, the participation in multimedia sessions. It is considered I;(PP)OP)I(T- for a fire,all to open such holes for unicast data streams unless the session description comes in a request from inside the fire,all. .or multicast sessions, it is likely that local administrators ,ill apply their o,n policies, $ut the e3clusive use of "local" or "site2local" administrative scope ,ithin the fire,all and the refusal of the fire,all to open a hole for such scopes ,ill provide separation of glo$al multicast sessions from local ones.

2%

Appendi5 A: SDP #rammar

&2is appendi3 pro4ides an +ugmented *NB grammar for %:1. +*NB is defined in RBC 2237. announ"ement 5 proto04ersion origin0field session0name0field information0field uri0field email0fields p2one0fields "onne"tion0field #andwidt20fields time0fields ke$0field attri#ute0fields media0des"riptions C45C ,D:'G'& CR)B Et2is memo des"ri#es 4ersion 6 Co5C username spa"e sess0id spa"e sess04ersion spa"e nett$pe spa"e addrt$pe spa"e addr CR)B Cs5C te3t CR)B FCi5C te3t CR)BG FCu5C uri CR)BG D=Ce5C email0address CR)B> D=Cp5C p2one0num#er CR)B> FC"5C nett$pe spa"e addrt$pe spa"e "onne"tion0address CR)BG Ea "onne"tion field must #e present Ein e4er$ media des"ription or at t2e Esession0le4el D=C#5C #wt$pe C:C #andwidt2 CR)B> ,D= Ct5C start0time spa"e stop0time D=CR)B repeat0fields> CR)B> FHone0ad;ustments CR)BG Cr5C repeat0inter4al spa"e t$ped0time ,D=spa"e t$ped0time> time spa"e FC0CG t$ped0time D=spa"e time spa"e FC0CG t$ped0time>

proto04ersion 5 origin0field 5

session0name0field 5 information0field 5 uri0field 5 email0fields 5 p2one0fields 5 "onne"tion0field 5

#andwidt20fields 5 time0fields 5

repeat0fields 5 Hone0ad;ustments 5

2(

ke$0field 5 ke$0t$pe 5

FCk5C ke$0t$pe CR)BG CpromptC / C"lear:C ke$0data / C#ase97:C ke$0data / Curi:C uri email0safe / CIC / C D=Ca5C attri#ute CR)B> D= media0field information0field D="onne"tion0field> #andwidt20fields ke$0field attri#ute0fields > Cm5C media spa"e port FC(C integerG spa"e proto ,D=spa"e fmt> CR)B ,D=alp2a0numeri"> Et$pi"all$ CaudioCJ C4ideoCJ Cappli"ationC Eor CdataC ,D=alp2a0numeri"> Et$pi"all$ an R&1 pa$load t$pe for audio Eand 4ideo media ,D=alp2a0numeri"> Et$pi"all$ CR&1(+ 1C or CudpC for '17 ,D=:'G'&> Es2ould in t2e range C,627C to C98838C in"lusi4e Efor K:1 #ased media =att0field C:C att04alue> / att0field ,D=alp2a0numeri"> #$te0string ,D=:'G'&> Es2ould #e unique for t2is originating username(2ost ,D=:'G'&> E6 is a new session multi"ast0address / addr 3D=de"imal0u"2ar C.C> de"imal0u"2ar C(C ttl F C(C integer G Emulti"ast addresses ma$ #e in t2e range E227.6.6.6 to 23-.288.288.288

ke$0data 5 attri#ute0fields 5 media0des"riptions 5

media0field 5 media 5

fmt 5

proto 5 port 5

attri#ute 5 att0field 5 att04alue 5 sess0id 5

sess04ersion 5 "onne"tion0address 5 multi"ast0address 5

20

ttl 5 start0time 5 stop0time 5 time 5 repeat0inter4al 5 t$ped0time 5

de"imal0u"2ar time / C6C time / C6C 1L%0:'G'& -D=:'G'&> Esuffi"ient for 2 more "enturies t$ped0time ,D=:'G'&> Ffi3ed0len0time0unitG

fi3ed0len0time0unit 5 CdC / C2C / CmC / CsC #wt$pe 5 #andwidt2 5 username 5 ,D=alp2a0numeri"> ,D=:'G'&> safe Eprett$ wide definitionJ #ut doesnMt in"lude spa"e email / email C=C email0safe C>C / email0safe C@C email CAC Edefined in RBC.22 Edefined in RBC,936 p2one / p2one C=C email0safe C>C / email0safe C@C p2one CAC C?C 1L%0:'G'& ,D=spa"e / C0C / :'G'&> Et2ere must #e a spa"e or 2$p2en #etween t2e Einternational "ode and t2e rest of t2e num#er. C'NC Elist to #e e3tended C'17C / C'19C Elist to #e e3tended BN:N / uni"ast0address 7D=alp2a0numeri"/C0C/C.C> Efull$ qualified domain name as spe"ified in RBC,638 '170address / '190address #, C.C de"imal0u"2ar C.C de"imal0u"2ar C.C #7 de"imal0u"2ar Eless t2an C227CE not C6C or C,27C de"imal0u"2ar Enot C6C

email0address 5 email 5 uri5 p2one0num#er 5 p2one 5

nett$pe 5 addrt$pe 5 addr 5 BN:N 5

uni"ast0address 5 '170address 5 #, 5 #7 5

22

'190address 5 te3t 5

Eto #e defined #$te0string Edefault is to interpret t2is as '%60,6979 K&B. E'%L ..8-0, requires a Ca5"2arset:'%L0..8-0,C Esession0le4el attri#ute to #e used ,D=636,..636-/636#/636"/636e..63ff> Ean$ #$te e3"ept NK)J CR or )B :'G'& / 1L%0:'G'& :'G'& / =C,C 2D=:'G'&>> / =C2C =C6C/C,C/C2C/C3C/C7C> :'G'&> / =C2C C8C =C6C/C,C/C2C/C3C/C7C/C8C>> 1L%0:'G'& D=:'G'&> +)1H+ / :'G'& C6C / 1L%0:'G'& C,C/C2C/C3C/C7C/C8C/C9C/C7C/C.C/C-C CaC/C#C/C"C/CdC/CeC/CfC/CgC/C2C/CiC/C;C/CkC/ ClC/CmC/CnC/Co C/CpC/CqC/CrC/CsC/CtC/CuC/C4C/ CwC/C3C/C$C/CHC/C+C/C*C/CC C/C:C/COC/CBC/CGC/ CHC/C'C/C!C/CPC/C)C/CMC/CNC/CLC/C1C/C NC/CRC/ C%C/C&C/CKC/C C/CWC/CQC/CRC/CSC safe / spa"e / ta# alp2a0numeri" / CMC / CMC / C0C / C.C / C(C / C:C / CTC / CCC / CUC / CVC / CWC / CDC / CEC / C5C / C<C / CFC / CGC / CXC / CYC / CZC / C[C / C/C / C\C / C?C / CIC / C ]d32 ]d]d,3.,6

#$te0string 5 de"imal0u"2ar 5

integer 5 alp2a0numeri" 5 :'G'& 5 1L%0:'G'& 5 +)1H+ 5

email0safe 5 safe 5

spa"e 5 ta# 5 CR)B 5

25

Appendi5 IANA

: #uidelines for registering SDP names 7ith

There are seven field names that may $e registered ,ith I(;(. +sing the terminology in the S P specification F;., they are "media", "proto", "fmt", "att2 field", "$,type", "nettype" and "addrtype". "media" (e.g., audio, video, application, data". Packeti#ed media types, such as those used $y )TP, share the namespace used $y media types registry 5).% 8C6'7 (i.e. "*I* types"". The list of valid media names is the set of top2level *I*- content types. The set of media is intended to $e small an not to $e e3tended e3cept under rare circumstances. (The *I* su$type corresponds to the "fmt" parameter $elo,". "proto" In general this should $e an I-T. standards2track transport protocol identifier such as )TP1(OP (rfc !''& under the rfc !'&C profile". 9o,ever, people ,ill ,ant to invent their o,n proprietary transport protocols. Some of these should $e registered as "fmt" using "udp" as the protocol and some of ,hich pro$a$ly can/t $e. Ahere the protocol and the application are intimately linked, such as ,ith the =F= ,hite$oard ,$ ,hich used a proprietary an special purpose protocol over + P, the protocol name should $e "udp" and the format name that should $e registered is ",$". The rules for formats (see $elo," apply to such registrations. Ahere the proprietary transport protocol really carries man different data formats, it is possi$le to register a ne, protocol name ,ith I(;(. In such a case, an ).% *+ST $e produced descri$ing the protocol and referenced in the registration. Such an ).% *(> $e informational, although it is prefera$le if it is standards2track. "fmt" The format namespace is dependent on the conte3t of the "proto" field, so a format cannot $e registered ,ithout specifying one of more transport protocols that it applies to. .ormats cover all the possi$le encodings that might ,ant to $e transported in a multimedia session. .or )TP formats that have $een assigned static payload types, the payload type num$er is used. .or )TP formats using a dynamic payload type num$er, the dynamic payload type num$er is given a the format and an additional "rtpmap" attri$ute specifies the format and parameters. .or non2)TP formats, any unregistered format name may $e registered through the *I*-2type registration process 5).% 8C6'7. The type given here

38

is the *I*- su$type only (the top2level *I* content type is specified $y the media parameter". The *I*- type registration S9O+= reference a standards2track ).% ,hich descri$es the transport protocol for this media type. If there is an e3isting *I*- type for this format, the *I*- registration should $e augmented to reference the transport specification for this media type. If there is not an e3isting *I*- type for this format, and there e3ists no appropriate file format, this should $e noted in the encoding considerations as "no appropriate file format". "att2field" ((ttri$ute names" (ttri$ute field names *(> $e registered ,ith I(;(, although this is not compulsory, and unkno,n attri$utes are simply ignored. Ahen an attri$ute is registered, it must $e accompanied $y $rief specification stating the follo,ing? o contact name, email address and telephone num$er o attri$ute2name (as it ,ill appear in S P" o long2form attri$ute name in -nglish o type of attri$ute (session level, media level, or $oth" o ,hether the attri$ute value is su$:ect to the charset attri$ute. o a one paragraph e3planation of the purpose of the attri$ute. o a specification of appropriate attri$ute values for this attri$ute. I(;( ,ill not sanity check such attri$ute registrations e3cept to ensure that they do not clash ,ith e3isting registrations. (lthough the a$ove is the minimum that I(;( ,ill accept, if the attri$ute is e3pected to see ,idespread use and interopera$ility is an issue, authors are encouraged to produce a standards2track ).% that specifies the attri$ute more precisely. Su$mitters of registrations should ensure that the specification is in the spirit of S P attri$utes, most nota$ly that the attri$ute is platform independent in the sense that it makes no implicit assumptions a$out operating systems and does not name specific pieces of soft,are in a manner that might inhi$it interopera$ility. "$,type" ($and,idth specifiers" ( proliferation of $and,idth specifiers is strongly discouraged. ;e, $and,idth specifiers may $e registered ,ith I(;(. The su$mission *+ST reference a standards2track ).% specifying the semantics of the $and,idth specifier precisely, and indicating ,hen it should $e used, and ,hy the e3isting registered $and,idth specifiers do not suffice. "nettype" (;et,ork Type" ;e, net,ork types may $e registered ,ith I(;( if S P needs to $e used in the conte3t of non2internet environments. Ahilst these are not normally the preserve of I(;(, there may $e circumstance ,hen an Internet application

31

needs to interoperate ,ith a non2internet application, such as ,hen gate,aying an internet telephony call into the PST;. The num$er of net,ork types should $e small and should $e rarely e3tended. ( ne, net,ork type cannot $e registered ,ithout registering at least one address type to $e used ,ith that net,ork type. ( ne, net,ork type registration *+ST reference an ).% ,hich gives details of the net,ork type and address type and specifies ho, and ,hen the ,ould $e used. Such an ).% *(> $e Informational. "addrtype" ((ddress Type" ;e, address types may $e registered ,ith I(;(. (n address type is only meaningful in the conte3t of a net,ork type, and a registration of an address type *+ST specify a registered net,ork type, or $e su$mitted along ,ith a net,ork type registration. ( ne, address type registration *+ST reference an ).% giving details of the synta3 of the address type. Such an ).% *(> $e Informational. (ddress types are not e3pected to $e registered frequently. )egistration Procedure To register a name the a$ove guidelines should $e follo,ed regarding the required level of documentation that is required. The registration itself should $e sent to I(;(. (ttri$ute registration should include the information given a$ove. Other registration should include the follo,ing additional information? contact name, email address and telephone num$er name $eing registered (as it ,ill appear in S P" long2form name in -nglish type of name ("media", "proto", "fmt", "$,type", "nettype", or "addrtype"" a one paragraph e3planation of the purpose of the registered name. a reference to the specification (e.g. ).% num$er" of the registered name.

I(;( may refer any registration to the I-SE or to any appropriate I-T. ,orking group for revie,, and may request revisions to $e mad $efore a registration ,ill $e made.

32

18 Appendi5 C: Authors9 Addresses

*ark 9andle Information Sciences Institute c1o *IT =a$oratory for %omputer Scienc G6G Technology Square %am$ridge, *( C8!B& +nited States electronic mail? m:h0isi.ed Oan Uaco$son *S 6Da2!!8! =a,rence Ferkeley =a$oratory Ferkeley, %( &6R8C +nited States electronic mail? van0ee.l$l.go

11 Ac!no7ledgment
*any people in the I-T. **+SI% ,orking group have made comments and suggestions contri$uting to this document. In particular, ,e ,ould like to thank -ve Schooler, Steve %asner, Fill .enner, (lliso *ankin, )oss .inlayson, Peter Parnes, Uoerg Ott, %arsten Formann, )o =anphier and Steve 9anna.

12 ,eferences
5!7 *ills, ., ";et,ork Time Protocol (version B" specification an implementation", ).% !BCG, *arch !&&8. 587 Schul#rinne, 9., %asner, S., .rederick, ). and O. Uaco$son, ")TP? ( Transport Protocol for )eal2Time (pplications", ).% !''&, Uanuar !&&D. 5B7 Schul#rinne, 9., ")TP Profile for (udio and Oideo %onference ,ith *inimal %ontrol", ).% !'&C, Uanuary !&&D 567 9andley, *., "S(P 2 Session (nnouncement Protocol", Aork in Progress. 5G7 O. Uaco$son, S. *c%anne, "vat 2 H!!2$ased audio teleconferencing tool" vat manual page, =a,rence Ferkeley =a$oratory, !&&6. 5D7 The +nicode %onsortium, "The +nicode Standard 22 Oersion 8.C", (ddison2Aesley, !&&D. 5R7 ISO1I-% !CD6D2!?!&&B. International Standard 22 Information technology 22 +niversal *ultiple2Octet %oded %haracter Set (+%S" 22 Part !? (rchitecture and Fasic *ultilingual Plane. .ive amendment and a technical corrigendum have $een pu$lished up to no,. +T.2' is descri$ed in (nne3 ), pu$lished as (mendment 8. 5'7 Eoldsmith, Uuly !&&6. ., and *. avis, "+sing +nicode ,ith *I*-", ).% !D6!,

33

5&7 >ergeau, .., "+T.2', a transformation format of +nicode and IS !CD6D", ).% 8C66, Octo$er !&&D. 5!C7 IT+2T )ecommendation 9.BB8 (!&&'"? "*ultimedia Terminal for )eceiving Internet2$ased 9.B8B %onferences", IT+, Eeneva. 5!!7 9andley, *., Schooler, -., and 9. Schul#rinne, "Session Initiation Protocol (SIP"", Aork in Progress. 5!87 Schul#rinne, 9., )ao, (., and ). =anphier, ")eal Time Streaming Protocol ()TSP"", ).% 8B8D, (pril !&&'.

1" 0ull Copyright Statement

%opyright (%" The Internet Society (!&&'". (ll )ights )eserved. This document and translations of it may $e copied and furnished t others, and derivative ,orks that comment on or other,ise e3plain it or assist in its implementation may $e prepared, copied, pu$lished and distri$uted, in ,hole or in part, ,ithout restriction of an kind, provided that the a$ove copyright notice and this paragraph are included on all such copies and derivative ,orks. 9o,ever, this document itself may not $e modified in any ,ay, such as $y removing the copyright notice or references to the Internet Society or other Internet organi#ations, e3cept as needed for the purpose of developing Internet standards in ,hich case the procedures for copyrights defined in the Internet Standards process must $e follo,ed, or as required to translate it into languages other than -nglish. The limited permissions granted a$ove are perpetual and ,ill not $e revoked $y the Internet Society or its successors or assigns. This document and the information contained herein is provided on a "(S IS" $asis and T9- I;T-);-T SO%I-T> (; T9- I;T-);-T -;EI;--)I; T(S@ .O)%IS%=(I*S (== A())(;TI-S, -HP)-SS O) I*P=I- , I;%=+ I; F+T ;OT =I*ITTO (;> A())(;T> T9(T T9- +S- O. T9- I;.O)*(TIO 9-)-I; AI== ;OT I;.)I;E- (;> )IE9TS O) (;> I*P=I- A())(;TI-S of *-)%9(;T(FI=IT> O) .IT;-SS .O) ( P()TI%+=() P+)POS-.

34