8/13/2019 RFC 2327 - SDP

1/34

Network Working Group M. HandleRequest for Comments: 2327 . !a"o#sonCategor$: %tandards &ra"k '%'()*N +pril ,--

SDP: Session Description Protocol

Status of this Memo

This document specifies an Internet standards track protocol for the Internetcommunity, and requests discussion and suggestions for improvements. Please referto the current edition of the "Internet Official Protocol Standards" (ST ! for thestandardi#ation stat and status of this protocol. istri$ution of this memo isunlimited.

Copyright Notice

%opyright (% The Internet Society (!&&' . ll )ights )eserved.

Abstract

This document defines the Session escription Protocol, S P. S P is intended fordescri$ing multimedia sessions for the purposes of session announcement, sessioninvitation, 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 and1orthe authors.

8/13/2019 RFC 2327 - SDP

2/34

1 Introduction.......................................................................................................................32 Background.......................................................................................................................33 Glossary of Term .............................................................................................................3

3.1 Terminology...............................................................................................................44 SDP Usage........................................................................................................................4

4.1 ulticast !nnouncement ..........................................................................................44.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 S ecification ............................................................................................................0(.1 ommunicating onference ontrol Policy............................................................24

0 Security onsideration ...................................................................................................24 ! endi ! SDP Grammar...........................................................................................2(5 ! endi B Guidelines for registering SDP names 6it- I!7!...................................3818 ! endi !ut-ors9 !ddresses .................................................................................3311 !ckno6ledgment .........................................................................................................3312 &eferences ....................................................................................................................3313 ,ull o yrig-t Statement .............................................................................................34

2

8/13/2019 RFC 2327 - SDP

3/34

1 Introduction

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

2 ac!ground

The *$one is the part of the internet that supports IP multicast, and thus permitsefficient many2to2many communication. It is use e3tensively for multimediaconferencing. Such conferences usually have the property that tight coordination ofconference 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 + Pports for the conference data streams.

Session directories assist the advertisement of conference session and communicatethe relevant conference setup information to prospective participants. S P isdesigned to convey such information to recipients. S P is purely a format for sessiondescription 2 it does not incorporate a transport protocol, and is intended to usedifferent transport protocols as appropriate including the Session nnouncementProtocol 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 ofnet ork environments and applications than :ust multicast session directories.9o ever, it is not intended t support negotiation of session content or mediaencodings 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 theconte3t of this document.

Conference: multimedia conference is a set of t o or more communicating useralong ith the soft are they are using to communicate.

Session: multimedia session is a set of multimedia senders and receivers and thedata streams flo ing from senders to receivers. multimedia conference is ane3ample of a multimedia session.

Session Advertisement: See session announcement.

Session Announcement: session announcement is a mechanism $y hich a sessiondescription 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 todiscover and participate in a multimedia session.

3

8/13/2019 RFC 2327 - SDP

4/34

"%1 $erminology

The key ords "*+ST", "*+ST ;OT", ")-", and "OPTIO; =" in thisdocument are to $e interpreted as descri$ed in ) % 8!!&.

& SDP 'sage

&%1 Multicast Announcement

S P is a session description protocol for multimedia sessions. common mode ofusage is for a client to announce a conference session $y periodically multicasting anannouncement 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 eader//00000000000000000000// te t pa$load //((((((((((

The header is the Session nnouncement Protocol header. S P is descri$ed in moredetail in a companion memo 567.

The te3t payload is an S P session description, as descri$ed in this memo. The te3tpayload 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 *** Announcementlternative 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*- contenttype "application1sdp" should $e used. This ena$les the automatic launching ofapplication for participation in the session from the AAA client or mail reader in astandard manner.

;ote that announcements of multicast sessions made only via email of the AorldAide Ae$ (AAA do not have the property that the receive of a sessionannouncement can necessarily receive the session $ecause the multicast sessionsmay $e restricted in scope, and access to the AAA server or reception of email ispossi$le outside this scope. S P announcements do not suffer from this mismatch.

4

8/13/2019 RFC 2327 - SDP

5/34

+ ,e-uirements and ,ecommendation

The purpose of S P is to convey information a$out media streams in multimediasessions 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 sufficientlygeneral that it can descri$e conferences in other net ork environments.

multimedia session, for these purposes, is defined as a set of media streams thate3ist for some duration of time. *edia stream can $e many2to2many. The timesduring hich the session is active need not $e continuous.

Thus far, multicast $ased sessions on the Internet have differed fro many otherforms of conferencing in that anyone receiving the traffic can :oin the session (unlessthe session traffic is encrypted . In such an environment, S P serves t o primarypurposes. It is a mean to communicate the e3istence of a session, and is a means toconvey sufficient information to ena$le :oining and participating in the session. In aunicast 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 additionalinformation 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 ( iththe possi$le e3ception of encryption keys and to announce the resources to $e usedto 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 themulticast stream, hether $eing sent, received, or $oth.

%

8/13/2019 RFC 2327 - SDP

6/34

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 protocoldefined. 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, somemedia may define to use these to esta$lish a control channel for the actual mediaflo .

+%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 ordaylight 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 todistri$ute it. The details of ho encryption is performed are dependent on themechanism used to convey S P 2 see 567 for ho this is done for sessionannouncements.

If a session announcement is private it is possi$le to use that private announcementto convey encryption keys necessary to decode each of the media in a conference,including enough information to kno hich encryption scheme is used for eachmedia.

+%& /btaining 0urther Information about a Session

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

+%+ Categori ation

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

(

8/13/2019 RFC 2327 - SDP

7/34

+% Internationali ation

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 tofree2te3t fields (session name and $ackground information , and not to S P as ahole.

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$setof +T 2', $ut te3tual fields and attri$ute values may use the full ISO !CD6Dcharacter set. the te3tual form, as opposed to a $inary encoding such as S;1! orH ), 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$asedtoolkits (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 strictlylimited, the encoding is deli$erately compact. lso, since announcements may $etransported via very unrelia$le means (e.g., email or damaged $y an intermediatecaching server, the encoding ay designed ith strict order and formatting rules sothat most error ould result in malformed announcements hich could $e detectedeasily and discarded. This also allo s rapid discarding of encrypted announcementsfor 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 formtypeJK valueJ typeJ is al ays e3actly one character and is case2significant.valueJ is a structured te3t string hose format depends on typeJ. It also ill $e

case2significant unless specific field defines other ise. Ahitespace is not permitted

either side of the LK/ sign. In general valueJ 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 thehole 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 media2level sections. The session2level part starts ith LvK/ line and continues to the firstmedia2level section. The media description starts ith an LmK/ line and continues tothe ne3t media description or end of the hole session description. In general,session2level values are the default for all media unless overridden $y an equivalentmedia2level 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 $econcatenated together (the LvK/ line indicating the start of a session descriptionterminates the previous description . Some lines in each description are required andsome are optional $ut all must appear in e3actly the order given here (the fi3edorder greatly enhances error detection and allo s for a simple parser . Optionalitems are marked ith a LM/.

0

8/13/2019 RFC 2327 - SDP

8/34

Session descriptionvK (protocol versionoK (o ner1creator and session identifier .sK (session nameiKM (session information

uKM (+)I of descriptioneKM (email addresspKM (phone num$ercKM (connection information 2 not required if included in all media$KM ($and idth informationOne or more time descriptions (see $elo#KM (time #one ad:ustmentskKM (encryption keyaKM (#ero or more session attri$ute linesNero or more media descriptions (see $elo

Time descriptiontK (time the session is activerKM (#ero or more repeat times

*edia descriptionmK (media name and transport addressiKM (media titlecKM (connection information 2 optional if included at session2level$KM ($and idth informationkKM (encryption keyaKM (#ero or more media attri$ute lines

The set of Ltype/ letters is deli$erately small and not intended to $e e3tensi$le 22S 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 theprimary 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 othersmay $e added on an application2, media2 of session2specific $asis. sessiondirectory must ignore an attri$ute it doesn/t understand.

The connection (LcK/ and attri$ute (LaK/ information in the session2level sectionapplies to all the media of that session unless overridden $y connection informationor an attri$ute of the same name in the media description. or instance, in thee3ample $elo , each media $ehaves as if it ere given a Lrecvonly/ attri$ute.

8/13/2019 RFC 2327 - SDP

9/34

n e3ample S P description is?

456o5m andle$ 2 -6 829 2 -6 2 67 'N '1 ,29.,9.9 .s5% 1 %eminai5+ %eminar on t e session des"ription proto"ol

u5 ttp:((www."s.u"l.a".uk(staff(M.Handle$(sdp.63.pse5m; "5'N '1 22 .2.,7.,2(,27t52 733-7 -9 2 73 6 9-9a5re"4onlm5audio -,76 R&1(+ 1 6m54ideo 8,372 R&1(+ 1 3,m5appli"ation 32 ,9 udp w#a5orient:portrait

Te3t records such as the session name and information are $yte strings hich maycontain 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 singlene 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 ersionvKC

The "vK" field gives the version of the Session escription Protocol.There is no minor version num$er.

OriginoK usernameJ session idJ versionJ net ork typeJ address typeJ

addressJ

The "oK" field gives the originator of the session (their username and theaddress of the user/s host plus a session id and session version num$er.

usernameJ is the user/s login on the originating host, or it is "2" if theoriginating host does not support the concept of user ids. usernameJ mustnot contain spaces. session idJ is a numeric string such that the tuple of

usernameJ, session idJ, net ork typeJ, address typeJ andaddressJ form a glo$ally unique identifier for the session.

The method of session idJ allocation is up to the creating tool, $ut it has$een suggested that a ;et ork Time Protocol (;TP timestamp $e used toensure uniqueness 5!7.

versionJ is a version num$er for this announcement. It is needed for pro3yannouncements to detect hich of several announcements for the samesession is the most recent. gain its usage is up to the creating tool, so longas versionJ is increased hen a modification is made to the session data.

gain, it is recommended ($ut no mandatory that an ;TP timestamp is used.

net ork typeJ is a te3t string giving the type of net ork. Initially "I;" isdefined to have the meaning "Internet".

5

8/13/2019 RFC 2327 - SDP

10/34

address typeJ is a te3t string giving the type of the address that follo s.Initially "IP6" and "IPD" are defined.

addressJ is the glo$ally unique address of the machine from hich thesession as created.

or an address type of IP6, this is either the fully2qualified domain name ofthe machine, or the dotted2decimal representation of the IP version 6 addressof the machine. or an address type of IPD, this is either the fully2qualifieddomain name of the machine, or the compressed te3tual representation of theIP version D address of the machine. or $oth IP6 and IPD, the fully2qualifieddomain 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 thescope in hich the address is meaningful.

In general, the "oK" field serves as a glo$ally unique identifier for this versionof this session description, and the su$fields e3cepting the version takentogether identify the session irrespective of an modifications.

Session ;amesK session nameJ

The "sK" field is the session name. There must $e one and only on "sK" fieldper session description, and it must contain ISO !CD6D characters ($ut seealso the Lcharset/ attri$ute $elo .

Session and *edia InformationiK session 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 permedia. lthough it may $e omitted, this is discouraged for sessionannouncements, and user interfaces for composing sessions should requirete3t to $e entered. If it is present it must contain ISO !CD6D characters ($utsee also the Lcharset/ attri$ute $elo .

single "iK" field can also $e used for each media definition. If mediadefinitions, "iK" fields are primarily intended for la$eling media streams. ssuch, they are most likely to $e useful hen single session has more than onedistinct media stream of the same media type. n e3ample ould $e t odifferent hite$oards, one for slides and one for feed$ack and questions.

+)IuK +)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

8/13/2019 RFC 2327 - SDP

11/34

-mail ddress and Phone ;um$ereK email addressJpK phone num$erJ

These specify contact information for the person responsi$le for theconference. 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 " Q and the international country code. There must $e a spaceor a hyphen ("2" $et een the country code and the rest of the phonenum$er. Spaces and hyphens may $e used to split up a phone field to aidreada$ility if desired. for e3ample?p5? 0,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. ore3ample?

e5m;

The alternative ) %'88 name quoting convention is also allo ed for $othemail addresses and phone num$ers. or e3ample,

e5Mark Handle$ @m;

8/13/2019 RFC 2327 - SDP

12/34

or IP6 addresses, the connection address is defined as follo s?

o Typically the connection address ill $e a class2 IP multicast groupaddress. If the session is not multicast, then the connection addresscontains the fully2qualified domain name or the unicast IP address of

the e3pected data source or data relay of data sink as determined $yadditional attri$ute fields. It is not e3pected that fully2qualified domainnames or unicast addresses ill $e given in a session description thatis communicated $y multicast announcement, though this is notprohi$ited. If unicast data stream is to pass through a net ork addresstranslator, the use of a fully2qualified domain name rather than aunicast IP address is )-%O**-; - . In other cases, the use of a IPaddress to specify a particular interface on a multi2homed host might$e required. Thus this specification leaves the decision as to hich touse up to the individual application, $ut all applications *+ST $e a$leto cope ith receiving $oth formats.

o %onferences using an IP multicast connection address must also havea time to live (TT= value present in addition to the multicastaddress. The TT= and the address together define the scope ith hichmulticast 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 aseparator. n e3ample is?

cKI; IP6 886.8.!.!1!8R

9ierarchical or layered encoding schemes are data streams here theencoding from a single media source is split into a num$er of layers.

The receiver can choose the desired quality (and hence $and idth $yonly su$scri$ing to a su$set of these layers. Such layered encodingsare normally transmitted in multiple multicast groups to allomulticast pruning. This technique keeps un anted traffic from sitesonly requiring certain levels of the hierarchy.

or applications requiring multiple multicast groups, e allo thefollo ing notation to $e used for the connection address?

$ase multicast addressJ1 ttlJ1 num$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 includingmultiple "cK" lines in a media description?

12

8/13/2019 RFC 2327 - SDP

13/34

cKI; IP6 886.8.!.!1!8RcKI; IP6 886.8.!.81!8RcKI; 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 IPunicast addresses.

Fand idth$K modifierJ? $and idth2valueJ

This specifies the proposed $and idth to $e used $y the session or media,and is optional.

$and idth2valueJ is in kilo$its per second modifierJ 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 ofa session or media in a session is different from the $and idth implicit from thescope, a L$K%T?.../ line should $e supplied for the session giving the proposedupper limit to the $and idth used. The primary purpose of this is to give anappro3imate idea as to hether t o or more conferences can co2e3istsimultaneously.

AS Application-Specific Maximum: The $and idth is interpreted to $eapplication2specific, 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. Sgives a $and idth figure for a single media at single site, although there may $emany sites sending simultaneously.

-3tension *echanism? Tool riters can define e3perimental $and idthmodifiers $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

8/13/2019 RFC 2327 - SDP

14/34

Times, )epeat Times and Time NonetK start timeJ stop 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 multipleirregularly spaced times4 each additional "tK" field specifies an

additional period of time for hich the session ill $e active. If thesession is active at regular times, an "rK" field (see $elo should $eused 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.

o The first and second su$2fields give the start and stop times for theconference respectively. These values are the decimal representationof ;et ork Time Protocol (;TP time values in seconds 5!7. To convertthese values to +;IH time, su$tract decimal 88C'&'''CC.

o If the stop2time is set to #ero, then the session is not $ounded, thoughit ill not $ecome active until after the start2time. If the start2time isalso #ero, the session is regarded as permanent.

+ser interfaces should strongly discourage the creation of un$oundedand permanent sessions as they give no information a$out hen thesession is actually going to terminate, and so make scheduling difficult.

The general assumption may $e made, hen displaying un$oundedsessions that have not timed out to the user, that an un$oundedsession ill only $e active until half an hour from the current time orthe session start time, hichever is the later. If $ehavior other thanthis is required, an end2time should $e give and modified asappropriate hen ne information $ecomes availa$le a$out hen thesession should really end.

Permanent sessions may $e sho n to the user as never $eing activeunless there are associated repeat times hich state precisely henthe session ill $e active. In general, permanent sessions should not$e created for any session e3pected to have a duration of les than 8months, and should $e discouraged for sessions e3pected to have aduration of less than D months.

rK repeat intervalJ active durationJ list of offsets from start2timeJ

o "rK" fields specify repeat times for a session. or e3ample, in a sessionis active at !Cam on *onday and !!am on Tuesday for one hour each

eek for three months, then the start timeJ in the corresponding"tK" field ould $e the ;TP representation of !Cam of the first*onday, the repeat intervalJ ould $e ! eek, the activedurationJ ould $e ! hour, and the offsets ould $e #ero and 8Ghours. The corresponding "tK" field stop time ould $e the ;TPrepresentation of the end of the last session three month later. Fydefault all fields are in seconds, so the "rK" and "tK" fields might $e?

tKBCB668BD!& BC686D86!&

14

8/13/2019 RFC 2327 - SDP

15/34

rKDC6'CC BDCC C &CCCC

To make announcements more compact, times may also $e given inunit of days, hours or minutes. The synta3 for these is a num$erimmediately follo ed $y a single case2sensitive character. ractionalunits 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 secondsh 2 minutes (BDCC secondsm 2 minutes (DC secondss 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 itha single S P repeat time 2 instead separate "t" fields should $e used toe3plicitly list the session times.

#K ad:ustment timeJ offsetJ ad:ustment timeJ offsetJ ....

o To schedule a repeated session hich spans a change from daylight2saving time to standard time or vice2versa, it is necessary to specifyoffsets from the $ase repeat times. This is require $ecause differenttime #ones change time at different times of day, different countrieschange to or from daylight time on different dates, and some countriesdo 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 hosetime #one a session is scheduled. To simplify this task for receivers, eallo the sender to specify the ;TP time that a time #one ad:ustmenthappens and the offset from the time hen the session as firstscheduled. The "#" field allo s the sender to specify a list of thesead: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 thesession/s repeat times are calculated is shifted $ack $y ! hour, andthat 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 arenot cumulative.

o If a session is likely to last several years, it is e3pected that thesession announcement ill $e modified periodically rather thantransmit several years orth of ad:ustments in one announcement.

-ncryption @ey

1%

8/13/2019 RFC 2327 - SDP

16/34

kK methodJkK methodJ? encryption keyJ

o The session description protocol may $e used to convey encryptionkeys. key field is permitted $efore the first media entry (in hichcase it applies to all media in the session , or for each media entry as

required.

o The format of keys and their usage is outside the scope of thisdocument, $ut see 5B7.

o The method indicates the mechanism to $e used to o$tain a usa$lekey $y e3ternal means, or from the encoded encryption key given.The follo ing methods are defined?

k=clear: encryption keyJThe encryption key (as descri$ed in 5B7 for )TP media stream underthe profile is included untransformed in this key field.

k=base64: encoded encryption keyJThe encryption key (as descri$ed in 5B7 for )TP media stream underthe profile is included in this key field $ut has $een $aseD6encoded $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 mayrequire additional authentication $efore the key can $e returned. Ahena request is made to the given +)I, the *I*- content2type of the replyspecifies the encoding for the key in the reply. The key should not $eo$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 mediastream referred to $y this key field is encrypted. The user should $eprompted for the key hen attempting to :oin the session, and thisuser2supplied key should then $e used to decrypt the media streams.

ttri$utesaK attri$uteJaK attri$uteJ? valueJ

ttri$utes are the primary means for e3tending S P. ttri$utes may $edefined to $e used as "session2level" attri$utes, "media2level" attri$utes, or$oth.

media description may have any num$er of attri$utes ("aK" fields hichare media specific. These are referred to as "media2level" attri$utes and addinformation a$out the media stream. ttri$ute fields can also $e added $eforethe first media field4 these "session2level" attri$utes convey additionalinformation that applied to the conference as a hole rather than to individualmedia4 an e3ample might $e the conference/s floor control policy.

1(

8/13/2019 RFC 2327 - SDP

17/34

ttri$ute fields may $e of t o forms?

o property attri$utes. property attri$ute is simply of the form"aK flagJ". These are $inary attri$utes, and the presence of theattri$ute conveys that the attri$ute is a property of the session. n

e3ample might $e "aKrecvonly".

o value attri$utes. value attri$ute is of the for"aK attri$uteJ? valueJ". n e3ample might $e that a hite$oardcould have the value attri$ute "aKorient?landscape"

ttri$ute interpretation depends on the media tool $eing invoked. Thusreceivers of session descriptions should $e configura$le in their interpretationof 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 $einterpreted as in ISO2!CD6D character set ith +T 2' encoding. +nlike otherte3t 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 charset2dependent, in hich case it/s value should $e interpreted in the sessioncharset rather than in ISO2!CD6D.

ttri$utes that ill $e commonly used can $e registered ith I ; (seeppendi3 F . +nregistered attri$utes should $egin ith "H2" to prevent

inadvertent collision ith registered attri$utes. In either case, if an attri$ute isreceived that is not understood, it should simply $e ignored $y the receiver.

*edia nnouncementmK mediaJ portJ transportJ fmt listJ

session description may contain a num$er of media descriptions. -achmedia description starts ith an "mK" field, and is terminate $y either thene3t "mK" field or $y the end of the session description. media field alsohas several su$2fields?

o The first su$2field is the media type. %urrently defined media are"audio", "video", "application", "data" and "control", though this listmay $e e3tended as ne communication modalities emerge (e.g.,telepresense . The difference $et een "application" and "data" is thatthe former is a media flo such as hite$oard information, an thelatter is $ulk2data transfer such as multicasting of programe3ecuta$les hich ill not typically $e displayed to the user. "control"is used to specify an additional conference control channel for thesession.

o The second su$2field is the transport port to hich the media streamill $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

8/13/2019 RFC 2327 - SDP

18/34

protocol defined in the third su$2field. Other ports used $y the mediaapplication (such as the )T%P port, see 587 should $e derivedalgorithmically 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 sentto a unicast address, it may $e necessary to specify multipletransport ports. This is done using a similar notation to that used for IPmulticast addresses in the "cK" field?

mK mediaJ portJ1 num$er of portsJ transportJ fmt 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 one2higher odd port is used for )T%P. or e3ample?

mKvideo 6&!RC18 )TP1 P B!

ould specify that ports 6&!RC and 6&!R! form one )TP1)T%P pair an6&!R8 and 6&!RB form the second )TP1)T%P pair. )TP1 P is thetransport protocol and B! is the format (see $elo .

It is illegal for $oth multiple addresses to $e specified in the "cK" fieldand for multiple ports to $e specified in the "mK" field in the samesession description.

o The third su$2field is the transport protocol. The transport protocolvalues 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 carriedas )TP over + P. The follo ing transport protocols are preliminarilydefined, $ut may $e e3tended through registration of ne protocols

ith I ; ?

2 )TP1 P 2 the I-T /s )ealtime Transport Protocol using theudio1 ideo profile carried over + P.

2 udp 2 +ser atagram Protocol

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

1

8/13/2019 RFC 2327 - SDP

19/34

The main reason to specify the transport2protocol in addition to themedia format is that the same standard media formats may $ecarried over different transport protocols even hen the net orkprotocol is the same 2 a historical e3ample is vat P%* audio an )TPP%* audio. In addition, relays and monitoring tools that aretransport2protocol2specific $ut format2independent are possi$le.

or )TP media streams operating under the )TP udio1 ideo Profile5B7, the protocol field is ")TP1 P". Should other )TP profiles $edefined in the future, their profiles ill $e specified in the same ay.

or e3ample, the protocol field ")TP1H>N" ould specify )T operatingunder a profile hose short name is "H>N".

o The fourth and su$sequent su$2fields are media formats. or audioand video, these ill normally $e a media payload type as define in the)TP udio1 ideo Profile.

Ahen a list of payload formats is given, this implies that all of theseformats may $e used in the session, $ut the first of these formats isthe default format for the session.

or media hose transport protocol is not )TP or + P the format fieldis protocol specific. Such formats should $e defined in an additionalspecification document.

or media hose transport protocol is )TP, S P can $e used to providea dynamic $inding of media encoding to )TP payload type. Theencoding names in the )TP Profile do not specify unique audioencodings (in terms of clock rate and num$er of audio channels , andso they are not used directly in S P format fields. Instead, the payloadtype num$er should $e used to specify the format for static payload

types and the payload type num$er along ith additional encodinginformation should $e used for dynamically allocated payload types.

n e3ample of a static payload type is u2la P%* coded single channelaudio sampled at '@9#. This is completely defined in the )TP

udio1 ideo profile as payload type C, so the media field for such astream sent to + P port 6&8B8 is?

mKvideo 6&8B8 )TP1 P C

n e3ample of a dynamic payload type is !D $it linear encoded stereoaudio sampled at !D@9#. If e ish to use dynamic )TP1 payloadtype &' for such a stream, additional information is required to decodeit?

mKvideo 6&8B8 )TP1 P &'aKrtpmap?&' =!D1!DCCC18

The general form of an rtpmap attri$ute is?

15

8/13/2019 RFC 2327 - SDP

20/34

aKrtpmap? payload typeJ encoding nameJ1 clockrateJ51 encoding parametersJ7

or audio streams, encoding parametersJ may specify the num$er ofaudio channels. This parameter may $e omitted if the num$er ofchannels 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 codecspecificparameters should not $e added. Parameters added to an rtpmapattri$ute should only $e those required for a session directory to makethe choice of appropriate media too to participate in a session. %odec2specific parameters should $e added in other attri$utes.

+p to one rtpmap attri$ute can $e defined for each media formatspecified. Thus e might have?

mKaudio 6&8BC )TP1 P &D &R &'aKrtpmap?&D ='1'CCCaKrtpmap?&R =!D1'CCCaKrtpmap?&' =!D1!!C8G18

)TP profiles that specify the use of dynamic payload types must definethe set of valid encoding names and1or a means to registed encodingnames 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 audiostream called ES*=P% using dynamic payload type && could $especified as?

mKvideo 6&8B8 )TP1 P &&aKrtpmap?&& H2ES*=P%1'CCC

Such an e3perimental encoding requires that any site ishing toreceive the media stream has relevant configured state in it sessiondirectory to kno hich tools are appropriate.

;ote that )TP audio formats typically do not include information a$outthe num$er of samples per packet. If a non2default (a defined in the)TP udio1 ideo 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*- contenttypes as descri$ed in ppendi3 F. or e3ample, the =F= hite$oardapplication might $e registered as *I*- content2type application1 $

ith encoding considerations specifying that it operates over + P, ithno appropriate file format. In S P this ould then $e e3pressed usinga com$ination of the "media" field and the "fmt" field, as follo s?

28

8/13/2019 RFC 2327 - SDP

21/34

mKapplication B86!D udp

Suggested ttri$ute

The follo ing attri$utes are suggested. Since application riter may add neattri$utes as they are required, this list is no e3haustive.

a=cat: cate&or$% This attri$ute gives the dot2separated hierarchicalcategory of the session. This is to ena$le a receiver to filter un antedsessions $y category. It ould pro$a$ly have $een a compulsory separatefield, e3cept for its e3perimental nature at this time. It is a session2levelattri$ute, and is not dependent on charset.

a=ke$'ds: ke$'ords% =ike the cat attri$ute, this is to assist identifyinganted 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 asession2level attri$ute. It is a charset dependent attri$ute, meaning that itsvalue should $e interpreted in the charset specified for the session descriptionif 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$erof the tool used to create the session description. It is a session2levelattri$ute, and is not dependent on charset.

a=ptime: packet time% This gives the length of time in millisecondsrepresented $y the media in a packet. This is pro$a$ly only meaningful foraudio data. It should not $e necessary to kno ptime to decode )TP of vataudio, and it is intended as a recommendation for the encoding1packetisationof 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 notdependent on charset.

a=sendrec This specifies that the tools should $e started in send an receivemode. This is necessary for interactive conferences ith tools such as $

hich defaults to receive only mode. It can $e either a session or mediaattri$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 mediadescriptions may $e use, one sendonly an one recvonly. It can $e either asession or media attri$ute, $ut ould normally only $e used as a mediaattri$ute, and is no dependent on charset.

a=orient: '(iteboard orientation% ;ormally this is only used in a hite$oardmedia specification. It specifies the orientation of a the hite$oard on thescreen. It is a media attri$ute. Permitted values are Lportrait/, Llandscape/and Lseascape/ (upside do n landscape . It is not dependent on charseta=t$pe: conference t$pe% This specifies the type of the conference.Suggested values are L$roadcast/, Lmeeting/, Lmoderated/, Ltest/ andL9BB8/.

21

8/13/2019 RFC 2327 - SDP

22/34

Lrecvonly/ should $e the default for Ltype?$roadcast/ sessions,Ltype?meeting/ should imply Lsendrecv/ and Ltype?moderated/ should indicatethe 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. *ediatools should $e started Lrecvonly/.

Specifying the attri$ute type?test is suggested as a hint that, unless e3plicitlyrequested other ise, receivers can safely avoid displaying this sessiondescription to users.

The type attri$ute is a session2level attri$ute, and is no dependent oncharset.

a=c(arset: c(aracter set% This specifies the character set to $e used todisplay the session name and information data. Fy default, the ISO2!CD6Dcharacter set in +T 2' encoding is used. If a more compact representation isrequired, other character sets may $e used such as ISO2''G&2! for ;orthern-uropean languages. In particular, the ISO ''G&2! is specified ith thefollo ing S P attri$ute?

aKcharset?ISO2''G&2!

This is a session2level attri$ute4 if this attri$ute is present, it must $e $eforethe 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%IIstring and *+ST $e compared against the I ; identifiers using a case2insensitive comparison. If the identifier is not recogni#ed or no supported, allstrings 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 thesecharacters *+ST define a quoting mechanism that prevents these $ytesappearing ithin te3t fields.

a=sdplan&: lan&ua&e ta&% This can $e a session level attri$ute or a medialevel attri$ute. s a session level attri$ute, it specifies the language for thesession description. s a media level attri$ute, it specifies the language forany media2level S P information field associate ith that media. *ultiplesdplang attri$utes can $e provide either at session or media level if multiplelanguages in the session description or media use multiple languages, in

hich case the order of the attri$utes indicates the order of importance of thevarious languages in the session or media from most important to leastimportant.

In general, sending session descriptions consisting of multiple languagesshould $e discouraged. Instead, multiple description should $e sent descri$ingthe session, one in each language. 9o ever this is not possi$le ith alltransport mechanisms, and so multiple sdplang attri$utes are allo edalthough not recommended.

22

8/13/2019 RFC 2327 - SDP

23/34

The sdplang attri$ute value must $e a single ) % !RDD language tag in +S2S%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 herethe 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 levelattri$ute. s a session level attri$ute, it specifies the default language for thesession $eing descri$ed. s a media level attri$ute, it specifies the languagefor that media, overriding any session2level language specified. *ultiple langattri$utes can $e provided either at session or media level if multiplelanguage if the session description or media use multiple languages, in hichcase the order of the attri$utes indicates the order of importance of thevarious languages in the session or media fro most important to leastimportant.

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+= $especified hen a session is of sufficient scope to cross geographic $oundaries

here the language of recipients cannot $e assumed, or here the session isin a different language from the locally assumed norm.

a=framerate: frame rate% This gives the ma3imum video frame rate inframes1sec. It is intended as a recommendation for the encoding of videodata. ecimal representations of fractional values using the notation" integerJ. fractionJ" are allo ed. It is a media attri$ute, is only defined forvideo media, and is not dependent on charset.

a=)ualit$: )ualit$% This gives a suggestion for the quality of the encoding asan integer value.

The intention of the quality attri$ute for video is to specify non2default trade2off $et een frame2rate and still2image quality. or video, the value in therange 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 sparameters that are specific to particular format to $e conveyed in a ay thatS P doesn/t have to understand them. The format must $e one of the formatspecified for the media. ormat2specific parameters may $e any set ofparameters required to $e conveyed $y S P and give unchanged to the mediatool that ill use this format.

It is a media attri$ute, and is not dependent on charset.

23

8/13/2019 RFC 2327 - SDP

24/34

8/13/2019 RFC 2327 - SDP

25/34

8/13/2019 RFC 2327 - SDP

26/34

4 Appendi5 A: SDP #rammar

& is appendi pro4ides an +ugmented *NB grammar for % 1. +*NB isdefined in RBC 223 .

announ"ement 5 proto04ersion origin0field session0name0field information0field uri0field email0fields p one0fields "onne"tion0field #andwidt 0fields time0fields ke$0field attri#ute0fields media0des"riptions

proto04ersion 5 45 ,D 'G'& CR)B Et is memo des"ri#es 4ersion 6

origin0field 5 o5 username spa"e sess0id spa"e sess04ersion spa"e nett$pe spa"e addrt$pe spa"e addr CR)B

session0name0field 5 s5 te t CR)B

information0field 5 F i5 te t CR)B

uri0field 5 F u5 uri CR)B

email0fields 5 D= e5 email0address CR)B>

p one0fields 5 D= p5 p one0num#er CR)B>

"onne"tion0field 5 F "5 nett$pe spa"e addrt$pe spa"e "onne"tion0address CR)B Ea "onne"tion field must #e present Ein e4er$ media des"ription or at t e Esession0le4el

#andwidt 0fields 5 D= #5 #wt$pe : #andwidt CR)B>

time0fields 5 ,D= t5 start0time spa"e stop0time D=CR)B repeat0fields> CR)B> F one0ad;ustments CR)B

repeat0fields 5 r5 repeat0inter4al spa"e t$ped0time ,D=spa"e t$ped0time>

one0ad;ustments 5 time spa"e F 0 t$ped0time D=spa"e time spa"e F 0 t$ped0time>

2(

8/13/2019 RFC 2327 - SDP

27/34

ke$0field 5 F k5 ke$0t$pe CR)B

ke$0t$pe 5 prompt / "lear: ke$0data / #ase9 : ke$0data / uri: uri

ke$0data 5 email0safe / I /

attri#ute0fields 5 D= a5 attri#ute CR)B>

media0des"riptions 5 D= media0field information0field D="onne"tion0field> #andwidt 0fields ke$0field attri#ute0fields >

media0field 5 m5 media spa"e port F ( integer spa"e proto ,D=spa"e fmt> CR)B

media 5 ,D=alp a0numeri"> Et$pi"all$ audio J 4ideo J appli"ation Eor data

fmt 5 ,D=alp a0numeri"> Et$pi"all$ an R&1 pa$load t$pe for audio Eand 4ideo media

proto 5 ,D=alp a0numeri"> Et$pi"all$ R&1(+ 1 or udp for '1

port 5 ,D= 'G'&> Es ould in t e range ,62 to 98838 in"lusi4e Efor K 1 #ased media

attri#ute 5 =att0field : att04alue> / att0field

att0field 5 ,D=alp a0numeri">

att04alue 5 #$te0string

sess0id 5 ,D= 'G'&> Es ould #e unique for t is originating

username( ost

sess04ersion 5 ,D= 'G'&> E6 is a new session

"onne"tion0address 5 multi"ast0address / addr

multi"ast0address 5 3D=de"imal0u" ar . > de"imal0u" ar ( ttl F ( integer Emulti"ast addresses ma$ #e in t e range E22 .6.6.6 to 23-.288.288.288

20

8/13/2019 RFC 2327 - SDP

28/34

ttl 5 de"imal0u" ar

start0time 5 time / 6

stop0time 5 time / 6

time 5 1L%0 'G'& -D= 'G'&> Esuffi"ient for 2 more "enturies

repeat0inter4al 5 t$ped0time

t$ped0time 5 ,D= 'G'&> Ffi ed0len0time0unit

fi ed0len0time0unit 5 d / / m / s

#wt$pe 5 ,D=alp a0numeri">

#andwidt 5 ,D= 'G'&>

username 5 safe

Eprett$ wide definitionJ #ut doesn t in"ludespa"e

email0address 5 email / email = email0safe > / email0safe @ email A

email 5 Edefined in RBC 22

uri5 Edefined in RBC,936

p one0num#er 5 p one / p one = email0safe > / email0safe @ p one A

p one 5 ? 1L%0 'G'& ,D=spa"e / 0 / 'G'&> Et ere must #e a spa"e or $p en #etween t e Einternational "ode and t e rest of t e

num#er.

nett$pe 5 'N Elist to #e e tended

addrt$pe 5 '1 / '19 Elist to #e e tended

addr 5 B N / uni"ast0address

B N 5 D=alp a0numeri"/ 0 / . > Efull$ qualified domain name as spe"ified in

RBC,638

uni"ast0address 5 '1 0address / '190address

'1 0address 5 #, . de"imal0u" ar . de"imal0u" ar . # #, 5 de"imal0u" ar Eless t an 22 E not 6 or ,27 # 5 de"imal0u" ar Enot 6

2

8/13/2019 RFC 2327 - SDP

29/34

'190address 5 Eto #e defined

te t 5 #$te0string Edefault is to interpret t is as '%60,69 9

K&B E'%L 8-0, requires a a5" arset:'%L0 8-0, Esession0le4el attri#ute to #e used

#$te0string 5 ,D=6 6,..6 6-/6 6#/6 6"/6 6e..6 ff> Ean$ #$te e "ept NK)J CR or )B

de"imal0u" ar 5 'G'& / 1L%0 'G'& 'G'& / = , 2D= 'G'&>> / = 2 = 6 / , / 2 / 3 / > 'G'&> / = 2 8 = 6 / , / 2 / 3 / / 8 >>

integer 5 1L%0 'G'& D= 'G'&>

alp a0numeri" 5 +)1H+ / 'G'&

'G'& 5 6 / 1L%0 'G'&

1L%0 'G'& 5 , / 2 / 3 / / 8 / 9 / 7 / / -

+)1H+ 5 a / # / " / d / e / f / g / / i / ; / k / l / m / n / o / p / q / r / s / t / u / 4 / w / / $ / / + / * / C / / O / B / G / H / ' / ! / P / ) / M / N / L / 1 / / R / % / & / K / / W / Q / / S

email0safe 5 safe / spa"e / ta#

safe 5 alp a0numeri" / / / 0 / . / ( / : / T / / U / V / / D / E / 5 / < / F / / X / Y / Z / [ / / / \ / ? / I /

spa"e 5 ]d32 ta# 5 ]d- CR)B 5 ]d,3.,6

25

8/13/2019 RFC 2327 - SDP

30/34

8/13/2019 RFC 2327 - SDP

31/34

is the *I*- su$type only (the top2level *I* content type is specified $y themedia parameter . The *I*- type registration S9O+= reference astandards2track ) % hich descri$es the transport protocol for this mediatype. If there is an e3isting *I*- type for this format, the *I*- registrationshould $e augmented to reference the transport specification for this mediatype. 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 notcompulsory, and unkno n attri$utes are simply ignored.

Ahen an attri$ute is registered, it must $e accompanied $y $rief specificationstating the follo ing?

o contact name, email address and telephone num$ero attri$ute2name (as it ill appear in S Po long2form attri$ute name in -nglisho type of attri$ute (session level, media level, or $otho 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 thatthey do not clash ith e3isting registrations.

lthough the a$ove is the minimum that I ; ill accept, if the attri$ute ise3pected to see idespread use and interopera$ility is an issue, authors areencouraged to produce a standards2track ) % that specifies the attri$utemore precisely.

Su$mitters of registrations should ensure that the specification is in the spiritof S P attri$utes, most nota$ly that the attri$ute is platform independent inthe sense that it makes no implicit assumptions a$out operating systems anddoes not name specific pieces of soft are in a manner that might inhi$itinteropera$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 idthspecifier precisely, and indicating hen it should $e used, and hy thee3isting 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 inthe conte3t of non2internet environments. Ahilst these are not normally thepreserve of I ; , there may $e circumstance hen an Internet application

31

8/13/2019 RFC 2327 - SDP

32/34

needs to interoperate ith a non2internet application, such as hengate aying an internet telephony call into the PST;. The num$er of net orktypes should $e small and should $e rarely e3tended. ne net ork typecannot $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 onlymeaningful in the conte3t of a net ork type, and a registration of an addresstype *+ST specify a registered net ork type, or $e su$mitted along ith anet ork type registration. ne address type registration *+ST reference an) % giving details of the synta3 of the address type. Such an ) % * > $eInformational. 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 requiredlevel of documentation that is required. The registration itself should $e sent toI ; . ttri$ute registration should include the information given a$ove. Otherregistration 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 orkinggroup for revie , and may request revisions to $e mad $efore a registration ill $emade.

32

8/13/2019 RFC 2327 - SDP

33/34

18 Appendi5 C: Authors9 Addresses

*ark 9andleInformation Sciences Institutec1o *IT =a$oratory for %omputer SciencG6G Technology Square%am$ridge, * C8!B&+nited Stateselectronic mail? m:h0isi.ed

an Uaco$son *S 6Da2!!8!=a rence Ferkeley =a$oratoryFerkeley, % &6R8C+nited Stateselectronic mail? van0ee.l$l.go

11 Ac!no7ledgment

*any people in the I-T **+SI% orking group have made comments andsuggestions contri$uting to this document. In particular, e ould like to thank -veSchooler, 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 . Uaco$son, ")TP? Transport Protocol for )eal2Time pplications", ) % !''&, Uanuar !&&D.

5B7 Schul#rinne, 9., ")TP Profile for udio and ideo %onference ith *inimal%ontrol", ) % !'&C, Uanuary !&&D

567 9andley, *., "S P 2 Session nnouncement Protocol", Aork in Progress.

5G7 . Uaco$son, S. *c%anne, "vat 2 H!!2$ased audio teleconferencing tool" vatmanual page, =a rence Ferkeley =a$oratory, !&&6.

5D7 The +nicode %onsortium, "The +nicode Standard 22 ersion 8.C",ddison2Aesley, !&&D.

5R7 ISO1I-% !CD6D2!?!&&B. International Standard 22 Information technology 22

+niversal *ultiple2Octet %oded %haracter Set (+%S 22Part !? rchitecture and Fasic *ultilingual Plane. ive amendment and a technicalcorrigendum have $een pu$lished up to no . +T 2'is descri$ed in nne3 ), pu$lished as mendment 8.

5'7 Eoldsmith, ., and *. avis, "+sing +nicode ith *I*-", ) % !D6!,Uuly !&&6.

33

8/13/2019 RFC 2327 - SDP

34/34

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 )eceivingInternet2$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, andderivative orks that comment on or other ise e3plain it or assist in itsimplementation may $e prepared, copied, pu$lished and distri$uted, in hole or inpart, ithout restriction of an kind, provided that the a$ove copyright notice and thisparagraph are included on all such copies and derivative orks. 9o ever, thisdocument itself may not $e modified in any ay, such as $y removing the copyrightnotice or references to the Internet Society or other Internet organi#ations, e3ceptas needed for the purpose of developing Internet standards in hich case theprocedures for copyrights defined in the Internet Standards process must $efollo 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 theInternet 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*IT-

TO ;> A )) ;T> T9 T T9- +S- O T9- I; O)* TIO 9-)-I; AI== ;OTI; )I;E- ;> )IE9TS O) ;> I*P=I- A )) ;TI-S of *-)%9 ;T FI=IT> O)

IT;-SS O) P )TI%+= ) P+)POS-.