RFC 2327 - SDP - Session Description Protocol

11/16/2015
RFC2327SDP:SessionDescriptionProtocol
NetworkWorkingGroupM.Handley
RequestforComments:2327V.Jacobson
Category:StandardsTrackISI/LBNL
April1998
SDP:SessionDescriptionProtocol
StatusofthisMemo
ThisdocumentspecifiesanInternetstandardstrackprotocolforthe
Internetcommunity,andrequestsdiscussionandsuggestionsfor
improvements.Pleaserefertothecurrenteditionofthe"Internet
OfficialProtocolStandards"(STD1)forthestandardizationstate
andstatusofthisprotocol.Distributionofthismemoisunlimited.
CopyrightNotice
Copyright(C)TheInternetSociety(1998).AllRightsReserved.
Abstract
ThisdocumentdefinestheSessionDescriptionProtocol,SDP.SDPis
intendedfordescribingmultimediasessionsforthepurposesof
sessionannouncement,sessioninvitation,andotherformsof
multimediasessioninitiation.
ThisdocumentisaproductoftheMultipartyMultimediaSession
Control(MMUSIC)workinggroupoftheInternetEngineeringTask
Force.Commentsaresolicitedandshouldbeaddressedtotheworking
group'smailinglistatconfctrl@isi.eduand/ortheauthors.
1.Introduction
OntheInternetmulticastbackbone(Mbone),asessiondirectorytool
isusedtoadvertisemultimediaconferencesandcommunicatethe
conferenceaddressesandconferencetoolspecificinformation
necessaryforparticipation.Thisdocumentdefinesasession
descriptionprotocolforthispurpose,andforgeneralrealtime
multimediasessiondescriptionpurposes.Thismemodoesnotdescribe
multicastaddressallocationorthedistributionofSDPmessagesin
detail.Thesearedescribedinaccompanyingmemos.SDPisnot
intendedfornegotiationofmediaencodings.
https://tools.ietf.org/html/rfc2327
1/84
11/16/2015
Handley&JacobsonStandardsTrack[Page1]
2/84
11/16/2015
RFC2327SDPApril1998
2.Background
TheMboneisthepartoftheinternetthatsupportsIPmulticast,and
thuspermitsefficientmanytomanycommunication.Itisused
extensivelyformultimediaconferencing.Suchconferencesusually
havethepropertythattightcoordinationofconferencemembershipis
notnecessary;toreceiveaconference,auseratanMbonesiteonly
hastoknowtheconference'smulticastgroupaddressandtheUDP
portsfortheconferencedatastreams.
Sessiondirectoriesassisttheadvertisementofconferencesessions
andcommunicatetherelevantconferencesetupinformationto
prospectiveparticipants.SDPisdesignedtoconveysuchinformation
torecipients.SDPispurelyaformatforsessiondescriptionit
doesnotincorporateatransportprotocol,andisintendedtouse
differenttransportprotocolsasappropriateincludingtheSession
AnnouncementProtocol[4],SessionInitiationProtocol[11],Real
TimeStreamingProtocol[12],electronicmailusingtheMIME
extensions,andtheHypertextTransportProtocol.
SDPisintendedtobegeneralpurposesothatitcanbeusedfora
widerrangeofnetworkenvironmentsandapplicationsthanjust
multicastsessiondirectories.However,itisnotintendedto
supportnegotiationofsessioncontentormediaencodingsthisis
viewedasoutsidethescopeofsessiondescription.
3.GlossaryofTerms
Thefollowingtermsareusedinthisdocument,andhavespecific
meaningwithinthecontextofthisdocument.
Conference
Amultimediaconferenceisasetoftwoormorecommunicatingusers
alongwiththesoftwaretheyareusingtocommunicate.
Session
Amultimediasessionisasetofmultimediasendersandreceivers
andthedatastreamsflowingfromsenderstoreceivers.A
multimediaconferenceisanexampleofamultimediasession.
SessionAdvertisement
Seesessionannouncement.
SessionAnnouncement
Asessionannouncementisamechanismbywhichasession
descriptionisconveyedtousersinaproactivefashion,i.e.,the
sessiondescriptionwasnotexplicitlyrequestedbytheuser.
3/84
11/16/2015
4/84
11/16/2015
RFC2327SDPApril1998
SessionDescription
Awelldefinedformatforconveyingsufficientinformationto
discoverandparticipateinamultimediasession.
3.1.Terminology
Thekeywords"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT",
"SHOULD","SHOULDNOT","RECOMMENDED","MAY",and"OPTIONAL"inthis
documentaretobeinterpretedasdescribedinRFC2119.
4.SDPUsage
4.1.MulticastAnnouncements
SDPisasessiondescriptionprotocolformultimediasessions.A
commonmodeofusageisforaclienttoannounceaconferencesession
byperiodicallymulticastinganannouncementpackettoawellknown
multicastaddressandportusingtheSessionAnnouncementProtocol
(SAP).
SAPpacketsareUDPpacketswiththefollowingformat:
||
|SAPheader|
||
|textpayload|
|//////////
TheheaderistheSessionAnnouncementProtocolheader.SAPis
describedinmoredetailinacompanionmemo[4]
ThetextpayloadisanSDPsessiondescription,asdescribedinthis
memo.Thetextpayloadshouldbenogreaterthan1Kbyteinlength.
IfannouncedbySAP,onlyonesessionannouncementispermittedina
singlepacket.
4.2.EmailandWWWAnnouncements
Alternativemeansofconveyingsessiondescriptionsinclude
electronicmailandtheWorldWideWeb.ForbothemailandWWW
distribution,theuseoftheMIMEcontenttype"application/sdp"
shouldbeused.Thisenablestheautomaticlaunchingofapplications
forparticipationinthesessionfromtheWWWclientormailreader
inastandardmanner.
5/84
11/16/2015
6/84
11/16/2015
RFC2327SDPApril1998
Notethatannouncementsofmulticastsessionsmadeonlyviaemailor
theWorldWideWeb(WWW)donothavethepropertythatthereceiver
ofasessionannouncementcannecessarilyreceivethesessionbecause
themulticastsessionsmayberestrictedinscope,andaccesstothe
WWWserverorreceptionofemailispossibleoutsidethisscope.SAP
announcementsdonotsufferfromthismismatch.
5.RequirementsandRecommendations
ThepurposeofSDPistoconveyinformationaboutmediastreamsin
multimediasessionstoallowtherecipientsofasessiondescription
toparticipateinthesession.SDPisprimarilyintendedforusein
aninternetwork,althoughitissufficientlygeneralthatitcan
describeconferencesinothernetworkenvironments.
Amultimediasession,forthesepurposes,isdefinedasasetof
mediastreamsthatexistforsomedurationoftime.Mediastreams
canbemanytomany.Thetimesduringwhichthesessionisactive
neednotbecontinuous.
Thusfar,multicastbasedsessionsontheInternethavedifferedfrom
manyotherformsofconferencinginthatanyonereceivingthetraffic
canjointhesession(unlessthesessiontrafficisencrypted).In
suchanenvironment,SDPservestwoprimarypurposes.Itisameans
tocommunicatetheexistenceofasession,andisameanstoconvey
sufficientinformationtoenablejoiningandparticipatinginthe
session.Inaunicastenvironment,onlythelatterpurposeislikely
toberelevant.
ThusSDPincludes:
oSessionnameandpurpose
oTime(s)thesessionisactive
oThemediacomprisingthesession
oInformationtoreceivethosemedia(addresses,ports,formatsand
soon)
Asresourcesnecessarytoparticipateinasessionmaybelimited,
someadditionalinformationmayalsobedesirable:
oInformationaboutthebandwidthtobeusedbytheconference
oContactinformationforthepersonresponsibleforthesession
7/84
11/16/2015
8/84
11/16/2015
RFC2327SDPApril1998
Ingeneral,SDPmustconveysufficientinformationtobeabletojoin
asession(withthepossibleexceptionofencryptionkeys)andto
announcetheresourcestobeusedtononparticipantsthatmayneed
toknow.
5.1.MediaInformation
SDPincludes:
oThetypeofmedia(video,audio,etc)
oThetransportprotocol(RTP/UDP/IP,H.320,etc)
oTheformatofthemedia(H.261video,MPEGvideo,etc)
ForanIPmulticastsession,thefollowingarealsoconveyed:
oMulticastaddressformedia
oTransportPortformedia
Thisaddressandportarethedestinationaddressanddestination
portofthemulticaststream,whetherbeingsent,received,orboth.
ForanIPunicastsession,thefollowingareconveyed:
oRemoteaddressformedia
oTransportportforcontactaddress
Thesemanticsofthisaddressandportdependonthemediaand
transportprotocoldefined.Bydefault,thisistheremoteaddress
andremoteporttowhichdataissent,andtheremoteaddressand
localportonwhichtoreceivedata.However,somemediamaydefine
tousethesetoestablishacontrolchannelfortheactualmedia
flow.
5.2.TimingInformation
Sessionsmayeitherbeboundedorunboundedintime.Whetherornot
theyarebounded,theymaybeonlyactiveatspecifictimes.
SDPcanconvey:
oAnarbitrarylistofstartandstoptimesboundingthesession
oForeachbound,repeattimessuchas"everyWednesdayat10amfor
onehour"
9/84
11/16/2015
10/84
11/16/2015
RFC2327SDPApril1998
Thistiminginformationisgloballyconsistent,irrespectiveoflocal
timezoneordaylightsavingtime.
5.3.PrivateSessions
Itispossibletocreatebothpublicsessionsandprivatesessions.
Privatesessionswilltypicallybeconveyedbyencryptingthesession
descriptiontodistributeit.Thedetailsofhowencryptionis
performedaredependentonthemechanismusedtoconveySDPsee[4]
forhowthisisdoneforsessionannouncements.
Ifasessionannouncementisprivateitispossibletousethat
privateannouncementtoconveyencryptionkeysnecessarytodecode
eachofthemediainaconference,includingenoughinformationto
knowwhichencryptionschemeisusedforeachmedia.
5.4.ObtainingFurtherInformationaboutaSession
Asessiondescriptionshouldconveyenoughinformationtodecide
whetherornottoparticipateinasession.SDPmayinclude
additionalpointersintheformofUniversalResourcesIdentifiers
(URIs)formoreinformationaboutthesession.
5.5.Categorisation
WhenmanysessiondescriptionsarebeingdistributedbySAPorany
otheradvertisementmechanism,itmaybedesirabletofilter
announcementsthatareofinterestfromthosethatarenot.SDP
supportsacategorisationmechanismforsessionsthatiscapableof
beingautomated.
5.6.Internationalization
TheSDPspecificationrecommendstheuseoftheISO10646character
setsintheUTF8encoding(RFC2044)toallowmanydifferent
languagestoberepresented.However,toassistincompact
representations,SDPalsoallowsothercharactersetssuchasISO
88591tobeusedwhendesired.Internationalizationonlyappliesto
freetextfields(sessionnameandbackgroundinformation),andnot
toSDPasawhole.
6.SDPSpecification
SDPsessiondescriptionsareentirelytextualusingtheISO10646
charactersetinUTF8encoding.SDPfieldnamesandattributesnames
useonlytheUSASCIIsubsetofUTF8,buttextualfieldsand
attributevaluesmayusethefullISO10646characterset.The
textualform,asopposedtoabinaryencodingsuchasASN/1orXDR,
11/84
11/16/2015
12/84
11/16/2015
RFC2327SDPApril1998
waschosentoenhanceportability,toenableavarietyoftransports
tobeused(e.g,sessiondescriptioninaMIMEemailmessage)andto
allowflexible,textbasedtoolkits(e.g.,Tcl/Tk)tobeusedto
generateandtoprocesssessiondescriptions.However,sincethe
totalbandwidthallocatedtoallSAPannouncementsisstrictly
limited,theencodingisdeliberatelycompact.Also,since
announcementsmaybetransportedviaveryunreliablemeans(e.g.,
email)ordamagedbyanintermediatecachingserver,theencodingwas
designedwithstrictorderandformattingrulessothatmosterrors
wouldresultinmalformedannouncementswhichcouldbedetected
easilyanddiscarded.Thisalsoallowsrapiddiscardingofencrypted
announcementsforwhichareceiverdoesnothavethecorrectkey.
AnSDPsessiondescriptionconsistsofanumberoflinesoftextof
theform<type>=<value><type>isalwaysexactlyonecharacterandis
casesignificant.<value>isastructuredtextstringwhoseformat
dependson<type>.Italsowillbecasesignificantunlessa
specificfielddefinesotherwise.Whitespaceisnotpermittedeither
sideofthe`='sign.Ingeneral<value>iseitheranumberoffields
delimitedbyasinglespacecharacterorafreeformatstring.
Asessiondescriptionconsistsofasessionleveldescription
(detailsthatapplytothewholesessionandallmediastreams)and
optionallyseveralmedialeveldescriptions(detailsthatapplyonto
toasinglemediastream).
Anannouncementconsistsofasessionlevelsectionfollowedbyzero
ormoremedialevelsections.Thesessionlevelpartstartswitha
`v='lineandcontinuestothefirstmedialevelsection.Themedia
descriptionstartswithan`m='lineandcontinuestothenextmedia
descriptionorendofthewholesessiondescription.Ingeneral,
sessionlevelvaluesarethedefaultforallmediaunlessoverridden
byanequivalentmedialevelvalue.
WhenSDPisconveyedbySAP,onlyonesessiondescriptionisallowed
perpacket.WhenSDPisconveyedbyothermeans,manySDPsession
descriptionsmaybeconcatenatedtogether(the`v='lineindicating
thestartofasessiondescriptionterminatestheprevious
description).Somelinesineachdescriptionarerequiredandsome
areoptionalbutallmustappearinexactlytheordergivenhere(the
fixedordergreatlyenhanceserrordetectionandallowsforasimple
parser).Optionalitemsaremarkedwitha`*'.
Sessiondescription
v=(protocolversion)
o=(owner/creatorandsessionidentifier).
s=(sessionname)
i=*(sessioninformation)
13/84
11/16/2015
14/84
11/16/2015
RFC2327SDPApril1998
u=*(URIofdescription)
e=*(emailaddress)
p=*(phonenumber)
c=*(connectioninformationnotrequiredifincludedinallmedia)
b=*(bandwidthinformation)
Oneormoretimedescriptions(seebelow)
z=*(timezoneadjustments)
k=*(encryptionkey)
a=*(zeroormoresessionattributelines)
Zeroormoremediadescriptions(seebelow)
Timedescription
t=(timethesessionisactive)
r=*(zeroormorerepeattimes)
Mediadescription
m=(medianameandtransportaddress)
i=*(mediatitle)
c=*(connectioninformationoptionalifincludedatsessionlevel)
b=*(bandwidthinformation)
k=*(encryptionkey)
a=*(zeroormoremediaattributelines)
Thesetof`type'lettersisdeliberatelysmallandnotintendedto
beextensibleSDPparsersmustcompletelyignoreanyannouncement
thatcontainsa`type'letterthatitdoesnotunderstand.The
`attribute'mechanism("a="describedbelow)istheprimarymeansfor
extendingSDPandtailoringittoparticularapplicationsormedia.
Someattributes(theoneslistedinthisdocument)haveadefined
meaningbutothersmaybeaddedonanapplication,mediaor
sessionspecificbasis.Asessiondirectorymustignoreany
attributeitdoesn'tunderstand.
Theconnection(`c=')andattribute(`a=')informationinthe
sessionlevelsectionappliestoallthemediaofthatsessionunless
overriddenbyconnectioninformationoranattributeofthesamename
inthemediadescription.Forinstance,intheexamplebelow,each
mediabehavesasifitweregivena`recvonly'attribute.
AnexampleSDPdescriptionis:
v=0
o=mhandley28908445262890842807INIP4126.16.64.4
s=SDPSeminar
i=ASeminaronthesessiondescriptionprotocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu(MarkHandley)
c=INIP4224.2.17.12/127
15/84
11/16/2015
16/84
11/16/2015
RFC2327SDPApril1998
t=28733974962873404696
a=recvonly
m=audio49170RTP/AVP0
m=video51372RTP/AVP31
m=application32416udpwb
a=orient:portrait
Textrecordssuchasthesessionnameandinformationarebytes
stringswhichmaycontainanybytewiththeexceptionsof0x00(Nul),
0x0a(ASCIInewline)and0x0d(ASCIIcarriagereturn).Thesequence
CRLF(0x0d0a)isusedtoendarecord,althoughparsersshouldbe
tolerantandalsoacceptrecordsterminatedwithasinglenewline
character.BydefaultthesebytestringscontainISO10646
charactersinUTF8encoding,butthisdefaultmaybechangedusing
the`charset'attribute.
ProtocolVersion
v=0
The"v="fieldgivestheversionoftheSessionDescriptionProtocol.
Thereisnominorversionnumber.
Origin
o=<username><sessionid><version><networktype><addresstype>
<address>
The"o="fieldgivestheoriginatorofthesession(theirusername
andtheaddressoftheuser'shost)plusasessionidandsession
versionnumber.
<username>istheuser'sloginontheoriginatinghost,oritis""
iftheoriginatinghostdoesnotsupporttheconceptofuserids.
<username>mustnotcontainspaces.<sessionid>isanumericstring
suchthatthetupleof<username>,<sessionid>,<networktype>,
<addresstype>and<address>formagloballyuniqueidentifierfor
thesession.
Themethodof<sessionid>allocationisuptothecreatingtool,but
ithasbeensuggestedthataNetworkTimeProtocol(NTP)timestampbe
usedtoensureuniqueness[1].
<version>isaversionnumberforthisannouncement.Itisneeded
forproxyannouncementstodetectwhichofseveralannouncementsfor
thesamesessionisthemostrecent.Againitsusageisuptothe
17/84
11/16/2015
18/84
11/16/2015
RFC2327SDPApril1998
creatingtool,solongas<version>isincreasedwhenamodification
ismadetothesessiondata.Again,itisrecommended(butnot
mandatory)thatanNTPtimestampisused.
<networktype>isatextstringgivingthetypeofnetwork.
Initially"IN"isdefinedtohavethemeaning"Internet".<address
type>isatextstringgivingthetypeoftheaddressthatfollows.
Initially"IP4"and"IP6"aredefined.<address>istheglobally
uniqueaddressofthemachinefromwhichthesessionwascreated.
ForanaddresstypeofIP4,thisiseitherthefullyqualifieddomain
nameofthemachine,orthedotteddecimalrepresentationoftheIP
version4addressofthemachine.ForanaddresstypeofIP6,this
iseitherthefullyqualifieddomainnameofthemachine,orthe
compressedtextualrepresentationoftheIPversion6addressofthe
machine.ForbothIP4andIP6,thefullyqualifieddomainnameis
theformthatSHOULDbegivenunlessthisisunavailable,inwhich
casethegloballyuniqueaddressmaybesubstituted.AlocalIP
addressMUSTNOTbeusedinanycontextwheretheSDPdescription
mightleavethescopeinwhichtheaddressismeaningful.
Ingeneral,the"o="fieldservesasagloballyuniqueidentifierfor
thisversionofthissessiondescription,andthesubfieldsexcepting
theversiontakentogetheridentifythesessionirrespectiveofany
modifications.
SessionName
s=<sessionname>
The"s="fieldisthesessionname.Theremustbeoneandonlyone
"s="fieldpersessiondescription,anditmustcontainISO10646
characters(butseealsothe`charset'attributebelow).
SessionandMediaInformation
i=<sessiondescription>
The"i="fieldisinformationaboutthesession.Theremaybeat
mostonesessionlevel"i="fieldpersessiondescription,andat
mostone"i="fieldpermedia.Althoughitmaybeomitted,thisis
discouragedforsessionannouncements,anduserinterfacesfor
composingsessionsshouldrequiretexttobeentered.Ifitis
presentitmustcontainISO10646characters(butseealsothe
`charset'attributebelow).
Asingle"i="fieldcanalsobeusedforeachmediadefinition.In
mediadefinitions,"i="fieldsareprimarilyintendedforlabeling
mediastreams.Assuch,theyaremostlikelytobeusefulwhena
19/84
11/16/2015
20/84
11/16/2015
RFC2327SDPApril1998
singlesessionhasmorethanonedistinctmediastreamofthesame
mediatype.Anexamplewouldbetwodifferentwhiteboards,onefor
slidesandoneforfeedbackandquestions.
URI
u=<URI>
oAURIisaUniversalResourceIdentifierasusedbyWWWclients
oTheURIshouldbeapointertoadditionalinformationaboutthe
conference
oThisfieldisoptional,butifitispresentitshouldbespecified
beforethefirstmediafield
oNomorethanoneURIfieldisallowedpersessiondescription
EmailAddressandPhoneNumber
e=<emailaddress>
p=<phonenumber>
oThesespecifycontactinformationforthepersonresponsiblefor
theconference.Thisisnotnecessarilythesamepersonthat
createdtheconferenceannouncement.
oEitheranemailfieldoraphonefieldmustbespecified.
Additionalemailandphonefieldsareallowed.
oIfthesearepresent,theyshouldbespecifiedbeforethefirst
mediafield.
oMorethanoneemailorphonefieldcanbegivenforasession
description.
oPhonenumbersshouldbegivenintheconventionalinternational
formatprecededbya"+andtheinternationalcountrycode.
Theremustbeaspaceorahyphen("")betweenthecountrycode
andtherestofthephonenumber.Spacesandhyphensmaybeused
tosplitupaphonefieldtoaidreadabilityifdesired.For
example:
p=+441713807777orp=+16172536011
21/84
11/16/2015
22/84
11/16/2015
RFC2327SDPApril1998
oBothemailaddressesandphonenumberscanhaveanoptionalfree
textstringassociatedwiththem,normallygivingthenameofthe
personwhomaybecontacted.Thisshouldbeenclosedin
parenthesisifitispresent.Forexample:
e=mjh@isi.edu(MarkHandley)
ThealternativeRFC822namequotingconventionisalsoallowedfor
bothemailaddressesandphonenumbers.Forexample,
e=MarkHandley<mjh@isi.edu>
ThefreetextstringshouldbeintheISO10646charactersetwith
UTF8encoding,oralternativelyinISO88591orotherencodings
iftheappropriatecharsetsessionlevelattributeisset.
ConnectionData
c=<networktype><addresstype><connectionaddress>
The"c="fieldcontainsconnectiondata.
Asessionannouncementmustcontainone"c="fieldineachmedia
description(seebelow)ora"c="fieldatthesessionlevel.Itmay
containasessionlevel"c="fieldandoneadditional"c="fieldper
mediadescription,inwhichcasethepermediavaluesoverridethe
sessionlevelsettingsfortherelevantmedia.
Thefirstsubfieldisthenetworktype,whichisatextstring
givingthetypeofnetwork.Initially"IN"isdefinedtohavethe
meaning"Internet".
Thesecondsubfieldistheaddresstype.ThisallowsSDPtobeused
forsessionsthatarenotIPbased.CurrentlyonlyIP4isdefined.
Thethirdsubfieldistheconnectionaddress.Optionalextra
subfieldsmaybeaddedaftertheconnectionaddressdependingonthe
valueofthe<addresstype>field.
ForIP4addresses,theconnectionaddressisdefinedasfollows:
oTypicallytheconnectionaddresswillbeaclassDIPmulticast
groupaddress.Ifthesessionisnotmulticast,thenthe
connectionaddresscontainsthefullyqualifieddomainnameorthe
unicastIPaddressoftheexpecteddatasourceordatarelayor
datasinkasdeterminedbyadditionalattributefields.Itisnot
expectedthatfullyqualifieddomainnamesorunicastaddresses
23/84
11/16/2015
24/84
11/16/2015
RFC2327SDPApril1998
willbegiveninasessiondescriptionthatiscommunicatedbya
multicastannouncement,thoughthisisnotprohibited.Ifa
unicastdatastreamistopassthroughanetworkaddress
translator,theuseofafullyqualifieddomainnameratherthanan
unicastIPaddressisRECOMMENDED.Inothercases,theuseofan
IPaddresstospecifyaparticularinterfaceonamultihomedhost
mightberequired.Thusthisspecificationleavesthedecisionas
towhichtouseuptotheindividualapplication,butall
applicationsMUSTbeabletocopewithreceivingbothformats.
oConferencesusinganIPmulticastconnectionaddressmustalsohave
atimetolive(TTL)valuepresentinadditiontothemulticast
address.TheTTLandtheaddresstogetherdefinethescopewith
whichmulticastpacketssentinthisconferencewillbesent.TTL
valuesmustbeintherange0255.
TheTTLforthesessionisappendedtotheaddressusingaslashas
aseparator.Anexampleis:
c=INIP4224.2.1.1/127
Hierarchicalorlayeredencodingschemesaredatastreamswherethe
encodingfromasinglemediasourceissplitintoanumberof
layers.Thereceivercanchoosethedesiredquality(andhence
bandwidth)byonlysubscribingtoasubsetoftheselayers.Such
layeredencodingsarenormallytransmittedinmultiplemulticast
groupstoallowmulticastpruning.Thistechniquekeepsunwanted
trafficfromsitesonlyrequiringcertainlevelsofthehierarchy.
Forapplicationsrequiringmultiplemulticastgroups,weallowthe
followingnotationtobeusedfortheconnectionaddress:
<basemulticastaddress>/<ttl>/<numberofaddresses>
Ifthenumberofaddressesisnotgivenitisassumedtobeone.
Multicastaddressessoassignedarecontiguouslyallocatedabove
thebaseaddress,sothat,forexample:
c=INIP4224.2.1.1/127/3
wouldstatethataddresses224.2.1.1,224.2.1.2and224.2.1.3are
tobeusedatattlof127.Thisissemanticallyidenticalto
includingmultiple"c="linesinamediadescription:
c=INIP4224.2.1.1/127
c=INIP4224.2.1.2/127
c=INIP4224.2.1.3/127
25/84
11/16/2015
26/84
11/16/2015
RFC2327SDPApril1998
Multipleaddressesor"c="linescanonlybespecifiedonaper
mediabasis,andnotforasessionlevel"c="field.
Itisillegalfortheslashnotationdescribedabovetobeusedfor
IPunicastaddresses.
Bandwidth
b=<modifier>:<bandwidthvalue>
oThisspecifiestheproposedbandwidthtobeusedbythesessionor
media,andisoptional.
o<bandwidthvalue>isinkilobitspersecond
o<modifier>isasinglealphanumericwordgivingthemeaningofthe
bandwidthfigure.
oTwomodifiersareinitiallydefined:
CTConferenceTotal:Animplicitmaximumbandwidthisassociatedwith
eachTTLontheMboneorwithinaparticularmulticast
administrativescoperegion(theMbonebandwidthvs.TTLlimitsare
givenintheMBoneFAQ).Ifthebandwidthofasessionormediain
asessionisdifferentfromthebandwidthimplicitfromthescope,
a`b=CT:...'lineshouldbesuppliedforthesessiongivingthe
proposedupperlimittothebandwidthused.Theprimarypurposeof
thisistogiveanapproximateideaastowhethertwoormore
conferencescancoexistsimultaneously.
ASApplicationSpecificMaximum:Thebandwidthisinterpretedtobe
applicationspecific,i.e.,willbetheapplication'sconceptof
maximumbandwidth.Normallythiswillcoincidewithwhatisseton
theapplication's"maximumbandwidth"controlifapplicable.
NotethatCTgivesatotalbandwidthfigureforallthemediaat
allsites.ASgivesabandwidthfigureforasinglemediaata
singlesite,althoughtheremaybemanysitessending
simultaneously.
oExtensionMechanism:Toolwriterscandefineexperimentalbandwidth
modifiersbyprefixingtheirmodifierwith"X".Forexample:
b=XYZ:128
SDPparsersshouldignorebandwidthfieldswithunknownmodifiers.
Modifiersshouldbealphanumericand,althoughnolengthlimitis
given,theyarerecommendedtobeshort.
27/84
11/16/2015
28/84
11/16/2015
RFC2327SDPApril1998
Times,RepeatTimesandTimeZones
t=<starttime><stoptime>
o"t="fieldsspecifythestartandstoptimesforaconference
session.Multiple"t="fieldsmaybeusedifasessionisactive
atmultipleirregularlyspacedtimes;eachadditional"t="field
specifiesanadditionalperiodoftimeforwhichthesessionwill
beactive.Ifthesessionisactiveatregulartimes,an"r="
field(seebelow)shouldbeusedinadditiontoandfollowinga
"t="fieldinwhichcasethe"t="fieldspecifiesthestartand
stoptimesoftherepeatsequence.
oThefirstandsecondsubfieldsgivethestartandstoptimesfor
theconferencerespectively.Thesevaluesarethedecimal
representationofNetworkTimeProtocol(NTP)timevaluesin
seconds[1].ToconvertthesevaluestoUNIXtime,subtract
decimal2208988800.
oIfthestoptimeissettozero,thenthesessionisnotbounded,
thoughitwillnotbecomeactiveuntilafterthestarttime.If
thestarttimeisalsozero,thesessionisregardedaspermanent.
Userinterfacesshouldstronglydiscouragethecreationof
unboundedandpermanentsessionsastheygivenoinformationabout
whenthesessionisactuallygoingtoterminate,andsomake
schedulingdifficult.
Thegeneralassumptionmaybemade,whendisplayingunbounded
sessionsthathavenottimedouttotheuser,thatanunbounded
sessionwillonlybeactiveuntilhalfanhourfromthecurrent
timeorthesessionstarttime,whicheveristhelater.If
behaviourotherthanthisisrequired,anendtimeshouldbegiven
andmodifiedasappropriatewhennewinformationbecomesavailable
aboutwhenthesessionshouldreallyend.
Permanentsessionsmaybeshowntotheuserasneverbeingactive
unlessthereareassociatedrepeattimeswhichstatepreciselywhen
thesessionwillbeactive.Ingeneral,permanentsessionsshould
notbecreatedforanysessionexpectedtohaveadurationofless
than2months,andshouldbediscouragedforsessionsexpectedto
haveadurationoflessthan6months.
r=<repeatinterval><activeduration><listofoffsetsfromstart
time>
o"r="fieldsspecifyrepeattimesforasession.Forexample,if
asessionisactiveat10amonMondayand11amonTuesdayforone
29/84
11/16/2015
30/84
11/16/2015
RFC2327SDPApril1998
houreachweekforthreemonths,thenthe<starttime>inthe
corresponding"t="fieldwouldbetheNTPrepresentationof10amon
thefirstMonday,the<repeatinterval>wouldbe1week,the
<activeduration>wouldbe1hour,andtheoffsetswouldbezero
and25hours.Thecorresponding"t="fieldstoptimewouldbethe
NTPrepresentationoftheendofthelastsessionthreemonths
later.Bydefaultallfieldsareinseconds,sothe"r="and"t="
fieldsmightbe:
t=30344236193042462419
r=6048003600090000
Tomakeannouncementsmorecompact,timesmayalsobegiveninunits
ofdays,hoursorminutes.Thesyntaxfortheseisanumber
immediatelyfollowedbyasinglecasesensitivecharacter.
Fractionalunitsarenotallowedasmallerunitshouldbeused
instead.Thefollowingunitspecificationcharactersareallowed:
ddays(86400seconds)
hminutes(3600seconds)
mminutes(60seconds)
sseconds(allowedforcompletenessbutnotrecommended)
Thus,theaboveannouncementcouldalsohavebeenwritten:
r=7d1h025h
Monthlyandyearlyrepeatscannotcurrentlybedirectlyspecified
withasingleSDPrepeattimeinsteadseparate"t"fieldsshould
beusedtoexplicitlylistthesessiontimes.
z=<adjustmenttime><offset><adjustmenttime><offset>....
oToschedulearepeatedsessionwhichspansachangefromdaylight
savingtimetostandardtimeorviceversa,itisnecessaryto
specifyoffsetsfromthebaserepeattimes.Thisisrequired
becausedifferenttimezoneschangetimeatdifferenttimesofday,
differentcountrieschangetoorfromdaylighttimeondifferent
dates,andsomecountriesdonothavedaylightsavingtimeatall.
Thusinordertoscheduleasessionthatisatthesametimewinter
andsummer,itmustbepossibletospecifyunambiguouslybywhose
timezoneasessionisscheduled.Tosimplifythistaskfor
receivers,weallowthesendertospecifytheNTPtimethatatime
zoneadjustmenthappensandtheoffsetfromthetimewhenthe
sessionwasfirstscheduled.The"z"fieldallowsthesenderto
specifyalistoftheseadjustmenttimesandoffsetsfromthebase
time.
31/84
11/16/2015
32/84
11/16/2015
RFC2327SDPApril1998
Anexamplemightbe:
z=28828445261h28988480700
Thisspecifiesthatattime2882844526thetimebasebywhichthe
session'srepeattimesarecalculatedisshiftedbackby1hour,
andthatattime2898848070thesession'soriginaltimebaseis
restored.Adjustmentsarealwaysrelativetothespecifiedstart
timetheyarenotcumulative.
oIfasessionislikelytolastseveralyears,itisexpected
that
thesessionannouncementwillbemodifiedperiodicallyratherthan
transmitseveralyearsworthofadjustmentsinoneannouncement.
EncryptionKeys
k=<method>
k=<method>:<encryptionkey>
oThesessiondescriptionprotocolmaybeusedtoconveyencryption
keys.Akeyfieldispermittedbeforethefirstmediaentry(in
whichcaseitappliestoallmediainthesession),orforeach
mediaentryasrequired.
oTheformatofkeysandtheirusageisoutsidethescopeofthis
document,butsee[3].
oThemethodindicatesthemechanismtobeusedtoobtainausable
keybyexternalmeans,orfromtheencodedencryptionkeygiven.
Thefollowingmethodsaredefined:
k=clear:<encryptionkey>
Theencryptionkey(asdescribedin[3]forRTPmediastreams
undertheAVprofile)isincludeduntransformedinthiskey
field.
k=base64:<encodedencryptionkey>
Theencryptionkey(asdescribedin[3]forRTPmediastreams
undertheAVprofile)isincludedinthiskeyfieldbuthasbeen
base64encodedbecauseitincludescharactersthatare
prohibitedinSDP.
k=uri:<URItoobtainkey>
AUniversalResourceIdentifierasusedbyWWWclientsis
includedinthiskeyfield.TheURIreferstothedata
containingthekey,andmayrequireadditionalauthentication
33/84
11/16/2015
34/84
11/16/2015
RFC2327SDPApril1998
beforethekeycanbereturned.Whenarequestismadetothe
givenURI,theMIMEcontenttypeofthereplyspecifiesthe
encodingforthekeyinthereply.Thekeyshouldnotbe
obtaineduntiltheuserwishestojointhesessiontoreduce
synchronisationofrequeststotheWWWserver(s).
k=prompt
NokeyisincludedinthisSDPdescription,butthesessionor
mediastreamreferredtobythiskeyfieldisencrypted.The
usershouldbepromptedforthekeywhenattemptingtojointhe
session,andthisusersuppliedkeyshouldthenbeusedto
decryptthemediastreams.
Attributes
a=<attribute>
a=<attribute>:<value>
AttributesaretheprimarymeansforextendingSDP.Attributesmay
bedefinedtobeusedas"sessionlevel"attributes,"medialevel"
attributes,orboth.
Amediadescriptionmayhaveanynumberofattributes("a="fields)
whicharemediaspecific.Thesearereferredtoas"medialevel"
attributesandaddinformationaboutthemediastream.Attribute
fieldscanalsobeaddedbeforethefirstmediafield;these
"sessionlevel"attributesconveyadditionalinformationthatapplies
totheconferenceasawholeratherthantoindividualmedia;an
examplemightbetheconference'sfloorcontrolpolicy.
Attributefieldsmaybeoftwoforms:
opropertyattributes.Apropertyattributeissimplyoftheform
"a=<flag>".Thesearebinaryattributes,andthepresenceofthe
attributeconveysthattheattributeisapropertyofthesession.
Anexamplemightbe"a=recvonly".
ovalueattributes.Avalueattributeisoftheform
"a=<attribute>:<value>".Anexamplemightbethatawhiteboard
couldhavethevalueattribute"a=orient:landscape"
Attributeinterpretationdependsonthemediatoolbeinginvoked.
Thusreceiversofsessiondescriptionsshouldbeconfigurablein
theirinterpretationofannouncementsingeneralandofattributesin
particular.
AttributenamesmustbeintheUSASCIIsubsetofISO10646/UTF8.
35/84
11/16/2015
36/84
11/16/2015
RFC2327SDPApril1998
Attributevaluesarebytestrings,andMAYuseanybytevalueexcept
0x00(Nul),0x0A(LF),and0x0D(CR).Bydefault,attributevalues
aretobeinterpretedasinISO10646charactersetwithUTF8
encoding.Unlikeothertextfields,attributevaluesareNOT
normallyaffectedbythe`charset'attributeasthiswouldmake
comparisonsagainstknownvaluesproblematic.However,whenan
attributeisdefined,itcanbedefinedtobecharsetdependent,in
whichcaseit'svalueshouldbeinterpretedinthesessioncharset
ratherthaninISO10646.
AttributesthatwillbecommonlyusedcanberegisteredwithIANA
(seeAppendixB).Unregisteredattributesshouldbeginwith"X"to
preventinadvertentcollisionwithregisteredattributes.Ineither
case,ifanattributeisreceivedthatisnotunderstood,itshould
simplybeignoredbythereceiver.
MediaAnnouncements
m=<media><port><transport><fmtlist>
Asessiondescriptionmaycontainanumberofmediadescriptions.
Eachmediadescriptionstartswithan"m="field,andisterminated
byeitherthenext"m="fieldorbytheendofthesession
description.Amediafieldalsohasseveralsubfields:
oThefirstsubfieldisthemediatype.Currentlydefinedmediaare
"audio","video","application","data"and"control",thoughthis
listmaybeextendedasnewcommunicationmodalitiesemerge(e.g.,
telepresense).Thedifferencebetween"application"and"data"is
thattheformerisamediaflowsuchaswhiteboardinformation,and
thelatterisbulkdatatransfersuchasmulticastingofprogram
executableswhichwillnottypicallybedisplayedtotheuser.
"control"isusedtospecifyanadditionalconferencecontrol
channelforthesession.
oThesecondsubfieldisthetransportporttowhichthemedia
streamwillbesent.Themeaningofthetransportportdependson
thenetworkbeingusedasspecifiedintherelevant"c"fieldand
onthetransportprotocoldefinedinthethirdsubfield.Other
portsusedbythemediaapplication(suchastheRTCPport,see
[2])shouldbederivedalgorithmicallyfromthebasemediaport.
Note:FortransportsbasedonUDP,thevalueshouldbeintherange
1024to65535inclusive.ForRTPcomplianceitshouldbeaneven
number.
37/84
11/16/2015
38/84
11/16/2015
RFC2327SDPApril1998
Forapplicationswherehierarchicallyencodedstreamsarebeing
senttoaunicastaddress,itmaybenecessarytospecifymultiple
transportports.Thisisdoneusingasimilarnotationtothat
usedforIPmulticastaddressesinthe"c="field:
m=<media><port>/<numberofports><transport><fmtlist>
Insuchacase,theportsuseddependonthetransportprotocol.
ForRTP,onlytheevenportsareusedfordataandthe
correspondingonehigheroddportisusedforRTCP.Forexample:
m=video49170/2RTP/AVP31
wouldspecifythatports49170and49171formoneRTP/RTCPpairand
49172and49173formthesecondRTP/RTCPpair.RTP/AVPisthe
transportprotocoland31istheformat(seebelow).
Itisillegalforbothmultipleaddressestobespecifiedinthe
"c="fieldandformultipleportstobespecifiedinthe"m="field
inthesamesessiondescription.
oThethirdsubfieldisthetransportprotocol.Thetransport
protocolvaluesaredependentontheaddresstypefieldinthe"c="
fields.Thusa"c="fieldofIP4definesthatthetransport
protocolrunsoverIP4.ForIP4,itisnormallyexpectedthatmost
mediatrafficwillbecarriedasRTPoverUDP.Thefollowing
transportprotocolsarepreliminarilydefined,butmaybeextended
throughregistrationofnewprotocolswithIANA:
RTP/AVPtheIETF'sRealtimeTransportProtocolusingthe
Audio/VideoprofilecarriedoverUDP.
udpUserDatagramProtocol
Ifanapplicationusesasinglecombinedproprietarymediaformat
andtransportprotocoloverUDP,thensimplyspecifyingthe
transportprotocolasudpandusingtheformatfieldtodistinguish
thecombinedprotocolisrecommended.Ifatransportprotocolis
usedoverUDPtocarryseveraldistinctmediatypesthatneedtobe
distinguishedbyasessiondirectory,thenspecifyingthetransport
protocolandmediaformatseparatelyisnecessary.RTPisan
exampleofatransportprotocolthatcarriesmultiplepayload
formatsthatmustbedistinguishedbythesessiondirectoryforit
toknowhowtostartappropriatetools,relays,mixersor
recorders.
39/84
11/16/2015
40/84
11/16/2015
RFC2327SDPApril1998
Themainreasontospecifythetransportprotocolinadditionto
themediaformatisthatthesamestandardmediaformatsmaybe
carriedoverdifferenttransportprotocolsevenwhenthenetwork
protocolisthesameahistoricalexampleisvatPCMaudioand
RTPPCMaudio.Inaddition,relaysandmonitoringtoolsthatare
transportprotocolspecificbutformatindependentarepossible.
ForRTPmediastreamsoperatingundertheRTPAudio/VideoProfile
[3],theprotocolfieldis"RTP/AVP".ShouldotherRTPprofilesbe
definedinthefuture,theirprofileswillbespecifiedinthesame
way.Forexample,theprotocolfield"RTP/XYZ"wouldspecifyRTP
operatingunderaprofilewhoseshortnameis"XYZ".
oThefourthandsubsequentsubfieldsaremediaformats.Foraudio
andvideo,thesewillnormallybeamediapayloadtypeasdefined
intheRTPAudio/VideoProfile.
Whenalistofpayloadformatsisgiven,thisimpliesthatallof
theseformatsmaybeusedinthesession,butthefirstofthese
formatsisthedefaultformatforthesession.
FormediawhosetransportprotocolisnotRTPorUDPtheformat
fieldisprotocolspecific.Suchformatsshouldbedefinedinan
additionalspecificationdocument.
FormediawhosetransportprotocolisRTP,SDPcanbeusedto
provideadynamicbindingofmediaencodingtoRTPpayloadtype.
TheencodingnamesintheRTPAVProfiledonotspecifyunique
audioencodings(intermsofclockrateandnumberofaudio
channels),andsotheyarenotuseddirectlyinSDPformatfields.
Instead,thepayloadtypenumbershouldbeusedtospecifythe
formatforstaticpayloadtypesandthepayloadtypenumberalong
withadditionalencodinginformationshouldbeusedfordynamically
allocatedpayloadtypes.
AnexampleofastaticpayloadtypeisulawPCMcodedsingle
channelaudiosampledat8KHz.Thisiscompletelydefinedinthe
RTPAudio/Videoprofileaspayloadtype0,sothemediafieldfor
suchastreamsenttoUDPport49232is:
Anexampleofadynamicpayloadtypeis16bitlinearencoded
stereoaudiosampledat16KHz.IfwewishtousedynamicRTP/AVP
payloadtype98forsuchastream,additionalinformationis
requiredtodecodeit:
41/84
11/16/2015
42/84
11/16/2015
RFC2327SDPApril1998
a=rtpmap:98L16/16000/2
Thegeneralformofanrtpmapattributeis:
a=rtpmap:<payloadtype><encodingname>/<clockrate>[/<encoding
parameters>]
Foraudiostreams,<encodingparameters>mayspecifythenumberof
audiochannels.Thisparametermaybeomittedifthenumberof
channelsisoneprovidednoadditionalparametersareneeded.For
videostreams,noencodingparametersarecurrentlyspecified.
Additionalparametersmaybedefinedinthefuture,but
codecspecificparametersshouldnotbeadded.Parametersaddedto
anrtpmapattributeshouldonlybethoserequiredforasession
directorytomakethechoiceofappropriatemediatooto
participateinasession.Codecspecificparametersshouldbe
addedinotherattributes.
Uptoonertpmapattributecanbedefinedforeachmediaformat
specified.Thuswemighthave:
a=rtpmap:96L8/8000
a=rtpmap:97L16/8000
a=rtpmap:98L16/11025/2
RTPprofilesthatspecifytheuseofdynamicpayloadtypesmust
definethesetofvalidencodingnamesand/orameanstoregister
encodingnamesifthatprofileistobeusedwithSDP.
Experimentalencodingformatscanalsobespecifiedusingrtpmap.
RTPformatsthatarenotregisteredasstandardformatnamesmust
beprecededby"X".Thusanewexperimentalredundantaudio
streamcalledGSMLPCusingdynamicpayloadtype99couldbe
specifiedas:
a=rtpmap:99XGSMLPC/8000
Suchanexperimentalencodingrequiresthatanysitewishingto
receivethemediastreamhasrelevantconfiguredstateinits
sessiondirectorytoknowwhichtoolsareappropriate.
NotethatRTPaudioformatstypicallydonotincludeinformation
aboutthenumberofsamplesperpacket.Ifanondefault(as
definedintheRTPAudio/VideoProfile)packetisationisrequired,
the"ptime"attributeisusedasgivenbelow.
43/84
11/16/2015
44/84
11/16/2015
RFC2327SDPApril1998
FormoredetailsonRTPaudioandvideoformats,see[3].
oFormatsfornonRTPmediashouldberegisteredasMIMEcontent
typesasdescribedinAppendixB.Forexample,theLBLwhiteboard
applicationmightberegisteredasMIMEcontenttypeapplication/wb
withencodingconsiderationsspecifyingthatitoperatesoverUDP,
withnoappropriatefileformat.InSDPthiswouldthenbe
expressedusingacombinationofthe"media"fieldandthe"fmt"
field,asfollows:
SuggestedAttributes
Thefollowingattributesaresuggested.Sinceapplicationwriters
mayaddnewattributesastheyarerequired,thislistisnot
exhaustive.
a=cat:<category>
Thisattributegivesthedotseparatedhierarchicalcategoryof
thesession.Thisistoenableareceivertofilterunwanted
sessionsbycategory.Itwouldprobablyhavebeenacompulsory
separatefield,exceptforitsexperimentalnatureatthistime.
Itisasessionlevelattribute,andisnotdependentoncharset.
a=keywds:<keywords>
Likethecatattribute,thisistoassistidentifyingwanted
sessionsatthereceiver.Thisallowsareceivertoselect
interestingsessionbasedonkeywordsdescribingthepurposeof
thesession.Itisasessionlevelattribute.Itisacharset
dependentattribute,meaningthatitsvalueshouldbeinterpreted
inthecharsetspecifiedforthesessiondescriptionifoneis
specified,orbydefaultinISO10646/UTF8.
a=tool:<nameandversionoftool>
Thisgivesthenameandversionnumberofthetoolusedtocreate
thesessiondescription.Itisasessionlevelattribute,andis
notdependentoncharset.
a=ptime:<packettime>
Thisgivesthelengthoftimeinmillisecondsrepresentedbythe
mediainapacket.Thisisprobablyonlymeaningfulforaudio
data.ItshouldnotbenecessarytoknowptimetodecodeRTPor
vataudio,anditisintendedasarecommendationforthe
encoding/packetisationofaudio.Itisamediaattribute,andis
notdependentoncharset.
45/84
11/16/2015
46/84
11/16/2015
RFC2327SDPApril1998
a=recvonly
Thisspecifiesthatthetoolsshouldbestartedinreceiveonly
modewhereapplicable.Itcanbeeitherasessionormedia
attribute,andisnotdependentoncharset.
a=sendrecv
Thisspecifiesthatthetoolsshouldbestartedinsendand
receivemode.Thisisnecessaryforinteractiveconferenceswith
toolssuchaswbwhichdefaultstoreceiveonlymode.Itcanbe
eitherasessionormediaattribute,andisnotdependenton
charset.
a=sendonly
Thisspecifiesthatthetoolsshouldbestartedinsendonly
mode.Anexamplemaybewhereadifferentunicastaddressisto
beusedforatrafficdestinationthanforatrafficsource.In
suchacase,twomediadescriptionsmaybeuse,onesendonlyand
onerecvonly.Itcanbeeitherasessionormediaattribute,but
wouldnormallyonlybeusedasamediaattribute,andisnot
dependentoncharset.
a=orient:<whiteboardorientation>
Normallythisisonlyusedinawhiteboardmediaspecification.
Itspecifiestheorientationofathewhiteboardonthescreen.
Itisamediaattribute.Permittedvaluesare`portrait',
`landscape'and`seascape'(upsidedownlandscape).Itisnot
dependentoncharset
a=type:<conferencetype>
Thisspecifiesthetypeoftheconference.Suggestedvaluesare
`broadcast',`meeting',`moderated',`test'and`H332'.
`recvonly'shouldbethedefaultfor`type:broadcast'sessions,
`type:meeting'shouldimply`sendrecv'and`type:moderated'
shouldindicatetheuseofafloorcontroltoolandthatthe
mediatoolsarestartedsoasto"mute"newsitesjoiningthe
conference.
Specifyingtheattributetype:H332indicatesthatthisloosely
coupledsessionispartofaH.332sessionasdefinedintheITU
H.332specification[10].Mediatoolsshouldbestarted
`recvonly'.
Specifyingtheattributetype:testissuggestedasahintthat,
unlessexplicitlyrequestedotherwise,receiverscansafelyavoid
displayingthissessiondescriptiontousers.
Thetypeattributeisasessionlevelattribute,andisnot
dependentoncharset.
47/84
11/16/2015
48/84
11/16/2015
RFC2327SDPApril1998
a=charset:<characterset>
Thisspecifiesthecharactersettobeusedtodisplaythe
sessionnameandinformationdata.Bydefault,theISO10646
charactersetinUTF8encodingisused.Ifamorecompact
representationisrequired,othercharactersetsmaybeusedsuch
asISO88591forNorthernEuropeanlanguages.Inparticular,
theISO88591isspecifiedwiththefollowingSDPattribute:
a=charset:ISO88591
Thisisasessionlevelattribute;ifthisattributeispresent,
itmustbebeforethefirstmediafield.Thecharsetspecified
MUSTbeoneofthoseregisteredwithIANA,suchasISO88591.
ThecharactersetidentifierisaUSASCIIstringandMUSTbe
comparedagainsttheIANAidentifiersusingacaseinsensitive
comparison.Iftheidentifierisnotrecognisedornot
supported,allstringsthatareaffectedbyitSHOULDberegarded
asbytestrings.
NotethatacharactersetspecifiedMUSTstillprohibittheuse
ofbytes0x00(Nul),0x0A(LF)and0x0d(CR).Charactersets
requiringtheuseofthesecharactersMUSTdefineaquoting
mechanismthatpreventsthesebytesappearingwithintextfields.
a=sdplang:<languagetag>
Thiscanbeasessionlevelattributeoramedialevelattribute.
Asasessionlevelattribute,itspecifiesthelanguageforthe
sessiondescription.Asamedialevelattribute,itspecifies
thelanguageforanymedialevelSDPinformationfieldassociated
withthatmedia.Multiplesdplangattributescanbeprovided
eitheratsessionormedialevelifmultiplelanguagesinthe
sessiondescriptionormediausemultiplelanguages,inwhich
casetheorderoftheattributesindicatestheorderof
importanceofthevariouslanguagesinthesessionormediafrom
mostimportanttoleastimportant.
Ingeneral,sendingsessiondescriptionsconsistingofmultiple
languagesshouldbediscouraged.Instead,multipledescriptions
shouldbesentdescribingthesession,oneineachlanguage.
Howeverthisisnotpossiblewithalltransportmechanisms,and
somultiplesdplangattributesareallowedalthoughnot
recommended.
ThesdplangattributevaluemustbeasingleRFC1766language
taginUSASCII.Itisnotdependentonthecharsetattribute.
AnsdplangattributeSHOULDbespecifiedwhenasessionisof
49/84
11/16/2015
50/84
11/16/2015
RFC2327SDPApril1998
sufficientscopetocrossgeographicboundarieswherethe
languageofrecipientscannotbeassumed,orwherethesessionis
inadifferentlanguagefromthelocallyassumednorm.
a=lang:<languagetag>
Thiscanbeasessionlevelattributeoramedialevelattribute.
Asasessionlevelattribute,itspecifiesthedefaultlanguage
forthesessionbeingdescribed.Asamedialevelattribute,it
specifiesthelanguageforthatmedia,overridinganysession
levellanguagespecified.Multiplelangattributescanbe
providedeitheratsessionormedialevelifmultiplelanguages
ifthesessiondescriptionormediausemultiplelanguages,in
whichcasetheorderoftheattributesindicatestheorderof
importanceofthevariouslanguagesinthesessionormediafrom
mostimportanttoleastimportant.
ThelangattributevaluemustbeasingleRFC1766languagetag
inUSASCII.Itisnotdependentonthecharsetattribute.A
langattributeSHOULDbespecifiedwhenasessionisof
sufficientscopetocrossgeographicboundarieswherethe
languageofrecipientscannotbeassumed,orwherethesessionis
inadifferentlanguagefromthelocallyassumednorm.
a=framerate:<framerate>
Thisgivesthemaximumvideoframerateinframes/sec.Itis
intendedasarecommendationfortheencodingofvideodata.
Decimalrepresentationsoffractionalvaluesusingthenotation
"<integer>.<fraction>"areallowed.Itisamediaattribute,is
onlydefinedforvideomedia,andisnotdependentoncharset.
a=quality:<quality>
Thisgivesasuggestionforthequalityoftheencodingasan
integervalue.
Theintentionofthequalityattributeforvideoistospecifya
nondefaulttradeoffbetweenframerateandstillimagequality.
Forvideo,thevalueintherange0to10,withthefollowing
suggestedmeaning:
10thebeststillimagequalitythecompressionschemecan
give.
5thedefaultbehaviourgivennoqualitysuggestion.
0theworststillimagequalitythecodecdesignerthinksis
stillusable.
Itisamediaattribute,andisnotdependentoncharset.
51/84
11/16/2015
52/84
11/16/2015
RFC2327SDPApril1998
a=fmtp:<format><formatspecificparameters>
Thisattributeallowsparametersthatarespecifictoa
particularformattobeconveyedinawaythatSDPdoesn'thave
tounderstandthem.Theformatmustbeoneoftheformats
specifiedforthemedia.Formatspecificparametersmaybeany
setofparametersrequiredtobeconveyedbySDPandgiven
unchangedtothemediatoolthatwillusethisformat.
Itisamediaattribute,andisnotdependentoncharset.
6.1.CommunicatingConferenceControlPolicy
Thereissomedebateoverthewayconferencecontrolpolicyshouldbe
communicated.Ingeneral,theauthorsbelievethatanimplicit
declarativestyleofspecifyingconferencecontrolisdesirablewhere
possible.
Asimpledeclarativestyleusesasingleconferenceattributefield
beforethefirstmediafield,possiblysupplementedbyproperties
suchas`recvonly'forsomeofthemediatools.Thisconference
attributeconveystheconferencecontrolpolicy.Anexamplemightbe:
a=type:moderated
Insomecases,however,itispossiblethatthismaybeinsufficient
tocommunicatethedetailsofanunusualconferencecontrolpolicy.
Ifthisisthecase,thenaconferenceattributespecifyingexternal
controlmightbeset,andthenoneormore"media"fieldsmightbe
usedtospecifytheconferencecontroltoolsandconfigurationdata
forthosetools.AnexampleisanITUH.332session:
c=INIP4224.5.6.7
a=type:H332
m=control49234H323mc
c=INIP4134.134.157.81
Inthisexample,ageneralconferenceattribute(type:H332)is
specifiedstatingthatconferencecontrolwillbeprovidedbyan
externalH.332tool,andacontactaddressesfortheH.323session
multipointcontrollerisgiven.
Inthisdocument,onlythedeclarativestyleofconferencecontrol
declarationisspecified.Otherformsofconferencecontrolshould
specifyanappropriatetypeattribute,andshoulddefinethe
implicationsthishasforcontrolmedia.
53/84
11/16/2015
54/84
11/16/2015
RFC2327SDPApril1998
7.SecurityConsiderations
SDPisasessiondescriptionformatthatdescribesmultimedia
sessions.Asessiondescriptionshouldnotbetrustedunlessithas
beenobtainedbyanauthenticatedtransportprotocolfromatrusted
source.Manydifferenttransportprotocolsmaybeusedtodistribute
sessiondescription,andthenatureoftheauthenticationwilldiffer
fromtransporttotransport.
Onetransportthatwillfrequentlybeusedtodistributesession
descriptionsistheSessionAnnouncementProtocol(SAP).SAP
providesbothencryptionandauthenticationmechanismsbutduetothe
natureofsessionannouncementsitislikelythattherearemany
occasionswheretheoriginatorofasessionannouncementcannotbe
authenticatedbecausetheyarepreviouslyunknowntothereceiverof
theannouncementandbecausenocommonpublickeyinfrastructureis
available.
Onreceivingasessiondescriptionoveranunauthenticatedtransport
mechanismorfromanuntrustedparty,softwareparsingthesession
shouldtakeafewprecautions.Sessiondescriptioncontain
informationrequiredtostartsoftwareonthereceiverssystem.
SoftwarethatparsesasessiondescriptionMUSTnotbeabletostart
othersoftwareexceptthatwhichisspecificallyconfiguredas
appropriatesoftwaretoparticipateinmultimediasessions.Itis
normallyconsideredINAPPROPRIATEforsoftwareparsingasession
descriptiontostart,onauser'ssystem,softwarethatis
appropriatetoparticipateinmultimediasessions,withouttheuser
firstbeinginformedthatsuchsoftwarewillbestartedandgiving
theirconsent.Thusasessiondescriptionarrivingbysession
announcement,email,sessioninvitation,orWWWpageSHOULDnot
delivertheuserintoan{itinteractive}multimediasessionwithout
theuserbeingawarethatthiswillhappen.Asitisnotalways
simpletotellwhetherasessionisinteractiveornot,applications
thatareunsureshouldassumesessionsareinteractive.
Inthisspecification,therearenoattributeswhichwouldallowthe
recipientofasessiondescriptiontobeinformedtostartmultimedia
toolsinamodewheretheydefaulttotransmitting.Undersome
circumstancesitmightbeappropriatetodefinesuchattributes.If
thisisdoneanapplicationparsingasessiondescriptioncontaining
suchattributesSHOULDeitherignorethem,orinformtheuserthat
joiningthissessionwillresultintheautomatictransmissionof
multimediadata.Thedefaultbehaviourforanunknownattributeis
toignoreit.
55/84
11/16/2015
56/84
11/16/2015
RFC2327SDPApril1998
Sessiondescriptionsmaybeparsedatintermediatesystemssuchas
firewallsforthepurposesofopeningaholeinthefirewalltoallow
theparticipationinmultimediasessions.Itisconsidered
INAPPROPRIATEforafirewalltoopensuchholesforunicastdata
streamsunlessthesessiondescriptioncomesinarequestfrominside
thefirewall.
Formulticastsessions,itislikelythatlocaladministratorswill
applytheirownpolicies,buttheexclusiveuseof"local"or"site
local"administrativescopewithinthefirewallandtherefusalof
thefirewalltoopenaholeforsuchscopeswillprovideseparation
ofglobalmulticastsessionsfromlocalones.
57/84
11/16/2015
58/84
11/16/2015
RFC2327SDPApril1998
AppendixA:SDPGrammar
ThisappendixprovidesanAugmentedBNFgrammarforSDP.ABNFis
definedinRFC2234.
announcement=protoversion
originfield
sessionnamefield
informationfield
urifield
emailfields
phonefields
connectionfield
bandwidthfields
timefields
keyfield
attributefields
mediadescriptions
protoversion="v="1*DIGITCRLF
;thismemodescribesversion0
originfield="o="usernamespace
sessidspacesessversionspace
nettypespaceaddrtypespace
addrCRLF
sessionnamefield="s="textCRLF
informationfield=["i="textCRLF]
urifield=["u="uriCRLF]
emailfields=*("e="emailaddressCRLF)
phonefields=*("p="phonenumberCRLF)
connectionfield=["c="nettypespaceaddrtypespace
connectionaddressCRLF]
;aconnectionfieldmustbepresent
;ineverymediadescriptionoratthe
;sessionlevel
bandwidthfields=*("b="bwtype":"bandwidthCRLF)
59/84
11/16/2015
60/84
11/16/2015
RFC2327SDPApril1998
timefields=1*("t="starttimespacestoptime
*(CRLFrepeatfields)CRLF)
[zoneadjustmentsCRLF]
repeatfields="r="repeatintervalspacetypedtime
1*(spacetypedtime)
zoneadjustments=timespace[""]typedtime
*(spacetimespace[""]typedtime)
keyfield=["k="keytypeCRLF]
keytype="prompt"|
"clear:"keydata|
"base64:"keydata|
"uri:"uri
keydata=emailsafe|"~"|"
attributefields=*("a="attributeCRLF)
mediadescriptions=*(mediafield
informationfield
*(connectionfield)
bandwidthfields
keyfield
attributefields)
mediafield="m="mediaspaceport["/"integer]
spaceproto1*(spacefmt)CRLF
media=1*(alphanumeric)
;typically"audio","video","application"
;or"data"
fmt=1*(alphanumeric)
;typicallyanRTPpayloadtypeforaudio
;andvideomedia
61/84
11/16/2015
62/84
11/16/2015
RFC2327SDPApril1998
proto=1*(alphanumeric)
;typically"RTP/AVP"or"udp"forIP4
port=1*(DIGIT)
;shouldintherange"1024"to"65535"inclusive
;forUDPbasedmedia
attribute=(attfield":"attvalue)|attfield
attfield=1*(alphanumeric)
attvalue=bytestring
sessid=1*(DIGIT)
;shouldbeuniqueforthisoriginatingusername/host
sessversion=1*(DIGIT)
;0isanewsession
connectionaddress=multicastaddress
|addr
multicastaddress=3*(decimaluchar".")decimaluchar"/"ttl
["/"integer]
;multicastaddressesmaybeintherange
;224.0.0.0to239.255.255.255
ttl=decimaluchar
starttime=time|"0"
stoptime=time|"0"
time=POSDIGIT9*(DIGIT)
;sufficientfor2morecenturies
repeatinterval=typedtime
63/84
11/16/2015
64/84
11/16/2015
RFC2327SDPApril1998
typedtime=1*(DIGIT)[fixedlentimeunit]
fixedlentimeunit="d"|"h"|"m"|"s"
bwtype=1*(alphanumeric)
bandwidth=1*(DIGIT)
username=safe
;prettywidedefinition,butdoesn'tincludespace
emailaddress=email|email"("emailsafe")"|
emailsafe"<"email">"
email=;definedinRFC822
uri=;definedinRFC1630
phonenumber=phone|phone"("emailsafe")"|
emailsafe"<"phone">"
phone="+"POSDIGIT1*(space|""|DIGIT)
;theremustbeaspaceorhyphenbetweenthe
;internationalcodeandtherestofthenumber.
nettype="IN"
;listtobeextended
addrtype="IP4"|"IP6"
;listtobeextended
addr=FQDN|unicastaddress
FQDN=4*(alphanumeric|""|".")
;fullyqualifieddomainnameasspecifiedinRFC1035
65/84
11/16/2015
66/84
11/16/2015
RFC2327SDPApril1998
unicastaddress=IP4address|IP6address
IP4address=b1"."decimaluchar"."decimaluchar"."b4
b1=decimaluchar
;lessthan"224";not"0"or"127"
b4=decimaluchar
;not"0"
IP6address=;tobedefined
text=bytestring
;defaultistointerpretthisasIS010646UTF8
;ISO88591requiresa"a=charset:ISO88591"
;sessionlevelattributetobeused
bytestring=1*(0x01..0x09|0x0b|0x0c|0x0e..0xff)
;anybyteexceptNUL,CRorLF
decimaluchar=DIGIT
|POSDIGITDIGIT
|("1"2*(DIGIT))
|("2"("0"|"1"|"2"|"3"|"4")DIGIT)
|("2""5"("0"|"1"|"2"|"3"|"4"|"5"))
integer=POSDIGIT*(DIGIT)
alphanumeric=ALPHA|DIGIT
DIGIT="0"|POSDIGIT
POSDIGIT="1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
ALPHA="a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|
"l"|"m"|"n"|"o"|"p"|"q"|"r"|"s"|"t"|"u"|"v"|
"w"|"x"|"y"|"z"|"A"|"B"|"C"|"D"|"E"|"F"|"G"|
"H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|"Q"|"R"|
"S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"
67/84
11/16/2015
68/84
11/16/2015
RFC2327SDPApril1998
emailsafe=safe|space|tab
safe=alphanumeric|
"'"|"'"|""|"."|"/"|":"|"?"|"""|
"#"|"$"|"&"|"*"|";"|"="|"@"|"["|
"]"|"^"|"_"|"`"|"{"|"|"|"}"|"+"|
"~"|"
space=%d32
tab=%d9
CRLF=%d13.10
69/84
11/16/2015
70/84
11/16/2015
RFC2327SDPApril1998
AppendixB:GuidelinesforregisteringSDPnameswithIANA
TherearesevenfieldnamesthatmayberegisteredwithIANA.Using
theterminologyintheSDPspecificationBNF,theyare"media",
"proto","fmt","attfield","bwtype","nettype"and"addrtype".
"media"(eg,audio,video,application,data).
Packetizedmediatypes,suchasthoseusedbyRTP,sharethe
namespaceusedbymediatypesregistry[RFC2048](i.e."MIME
types").Thelistofvalidmedianamesisthesetoftoplevel
MIMEcontenttypes.Thesetofmediaisintendedtobesmalland
nottobeextendedexceptunderrarecircumstances.(TheMIME
subtypecorrespondstothe"fmt"parameterbelow).
"proto"
IngeneralthisshouldbeanIETFstandardstracktransport
protocolidentifiersuchasRTP/AVP(rfc1889undertherfc1890
profile).
However,peoplewillwanttoinventtheirownproprietary
transportprotocols.Someoftheseshouldberegisteredasa
"fmt"using"udp"astheprotocolandsomeofwhichprobably
can'tbe.
Wheretheprotocolandtheapplicationareintimatelylinked,
suchaswiththeLBLwhiteboardwbwhichusedaproprietaryand
specialpurposeprotocoloverUDP,theprotocolnameshouldbe
"udp"andtheformatnamethatshouldberegisteredis"wb".The
rulesforformats(seebelow)applytosuchregistrations.
Wheretheproprietarytransportprotocolreallycarriesmany
differentdataformats,itispossibletoregisteranewprotocol
namewithIANA.Insuchacase,anRFCMUSTbeproduced
describingtheprotocolandreferencedintheregistration.Such
anRFCMAYbeinformational,althoughitispreferableifitis
standardstrack.
"fmt"
Theformatnamespaceisdependentonthecontextofthe"proto"
field,soaformatcannotberegisteredwithoutspecifyingoneor
moretransportprotocolsthatitappliesto.
Formatscoverallthepossibleencodingsthatmightwanttobe
transportedinamultimediasession.
71/84
11/16/2015
72/84
11/16/2015
RFC2327SDPApril1998
ForRTPformatsthathavebeenassignedstaticpayloadtypes,the
payloadtypenumberisused.ForRTPformatsusingadynamic
payloadtypenumber,thedynamicpayloadtypenumberisgivenas
theformatandanadditional"rtpmap"attributespecifiesthe
formatandparameters.
FornonRTPformats,anyunregisteredformatnamemaybe
registeredthroughtheMIMEtyperegistrationprocess[RFC2048].
ThetypegivenhereistheMIMEsubtypeonly(thetoplevelMIME
contenttypeisspecifiedbythemediaparameter).TheMIMEtype
registrationSHOULDreferenceastandardstrackRFCwhich
describesthetransportprotocolforthismediatype.Ifthere
isanexistingMIMEtypeforthisformat,theMIMEregistration
shouldbeaugmentedtoreferencethetransportspecificationfor
thismediatype.IfthereisnotanexistingMIMEtypeforthis
format,andthereexistsnoappropriatefileformat,thisshould
benotedintheencodingconsiderationsas"noappropriatefile
format".
"attfield"(Attributenames)
AttributefieldnamesMAYberegisteredwithIANA,althoughthis
isnotcompulsory,andunknownattributesaresimplyignored.
Whenanattributeisregistered,itmustbeaccompaniedbya
briefspecificationstatingthefollowing:
ocontactname,emailaddressandtelephonenumber
oattributename(asitwillappearinSDP)
olongformattributenameinEnglish
otypeofattribute(sessionlevel,medialevel,orboth)
owhethertheattributevalueissubjecttothecharset
attribute.
oaoneparagraphexplanationofthepurposeoftheattribute.
oaspecificationofappropriateattributevaluesforthis
attribute.
IANAwillnotsanitychecksuchattributeregistrationsexceptto
ensurethattheydonotclashwithexistingregistrations.
73/84
11/16/2015
74/84
11/16/2015
RFC2327SDPApril1998
AlthoughtheaboveistheminimumthatIANAwillaccept,ifthe
attributeisexpectedtoseewidespreaduseandinteroperability
isanissue,authorsareencouragedtoproduceastandardstrack
RFCthatspecifiestheattributemoreprecisely.
Submittersofregistrationsshouldensurethatthespecification
isinthespiritofSDPattributes,mostnotablythatthe
attributeisplatformindependentinthesensethatitmakesno
implicitassumptionsaboutoperatingsystemsanddoesnotname
specificpiecesofsoftwareinamannerthatmightinhibit
interoperability.
"bwtype"(bandwidthspecifiers)
Aproliferationofbandwidthspecifiersisstronglydiscouraged.
NewbandwidthspecifiersmayberegisteredwithIANA.The
submissionMUSTreferenceastandardstrackRFCspecifyingthe
semanticsofthebandwidthspecifierprecisely,andindicating
whenitshouldbeused,andwhytheexistingregisteredbandwidth
specifiersdonotsuffice.
"nettype"(NetworkType)
NewnetworktypesmayberegisteredwithIANAifSDPneedstobe
usedinthecontextofnoninternetenvironments.Whilstthese
arenotnormallythepreserveofIANA,theremaybecircumstances
whenanInternetapplicationneedstointeroperatewithanon
internetapplication,suchaswhengatewayinganinternet
telephonycallintothePSTN.Thenumberofnetworktypesshould
besmallandshouldberarelyextended.Anewnetworktype
cannotberegisteredwithoutregisteringatleastoneaddress
typetobeusedwiththatnetworktype.Anewnetworktype
registrationMUSTreferenceanRFCwhichgivesdetailsofthe
networktypeandaddresstypeandspecifieshowandwhenthey
wouldbeused.SuchanRFCMAYbeInformational.
"addrtype"(AddressType)
NewaddresstypesmayberegisteredwithIANA.Anaddresstype
isonlymeaningfulinthecontextofanetworktype,andany
registrationofanaddresstypeMUSTspecifyaregisterednetwork
type,orbesubmittedalongwithanetworktyperegistration.A
newaddresstyperegistrationMUSTreferenceanRFCgiving
detailsofthesyntaxoftheaddresstype.SuchanRFCMAYbe
Informational.Addresstypesarenotexpectedtoberegistered
frequently.
75/84
11/16/2015
76/84
11/16/2015
RFC2327SDPApril1998
RegistrationProcedure
Toregisteranametheaboveguidelinesshouldbefollowedregarding
therequiredlevelofdocumentationthatisrequired.The
registrationitselfshouldbesenttoIANA.Attributeregistrations
shouldincludetheinformationgivenabove.Otherregistrations
shouldincludethefollowingadditionalinformation:
ocontactname,emailaddressandtelephonenumber
onamebeingregistered(asitwillappearinSDP)
olongformnameinEnglish
otypeofname("media","proto","fmt","bwtype","nettype",or
"addrtype")
oaoneparagraphexplanationofthepurposeoftheregisteredname.
oareferencetothespecification(egRFCnumber)oftheregistered
name.
IANAmayreferanyregistrationtotheIESGortoanyappropriate
IETFworkinggroupforreview,andmayrequestrevisionstobemade
beforearegistrationwillbemade.
77/84
11/16/2015
78/84
11/16/2015
RFC2327SDPApril1998
AppendixC:Authors'Addresses
MarkHandley
InformationSciencesInstitute
c/oMITLaboratoryforComputerScience
545TechnologySquare
Cambridge,MA02139
UnitedStates
electronicmail:mjh@isi.edu
VanJacobson
MS46a1121
LawrenceBerkeleyLaboratory
Berkeley,CA94720
UnitedStates
electronicmail:van@ee.lbl.gov
Acknowledgments
ManypeopleintheIETFMMUSICworkinggrouphavemadecommentsand
suggestionscontributingtothisdocument.Inparticular,wewould
liketothankEveSchooler,SteveCasner,BillFenner,Allison
Mankin,RossFinlayson,PeterParnes,JoergOtt,CarstenBormann,Rob
LanphierandSteveHanna.
References
[1]Mills,D.,"NetworkTimeProtocol(version3)specificationand
implementation",RFC1305,March1992.
[2]Schulzrinne,H.,Casner,S.,Frederick,R.andV.Jacobson,"RTP:
ATransportProtocolforRealTimeApplications",RFC1889,January
1996.
[3]Schulzrinne,H.,"RTPProfileforAudioandVideoConferences
withMinimalControl",RFC1890,January1996
[4]Handley,M.,"SAPSessionAnnouncementProtocol",Workin
Progress.
[5]V.Jacobson,S.McCanne,"vatX11basedaudioteleconferencing
tool"vatmanualpage,LawrenceBerkeleyLaboratory,1994.
[6]TheUnicodeConsortium,"TheUnicodeStandardVersion2.0",
AddisonWesley,1996.
79/84
11/16/2015
80/84
11/16/2015
RFC2327SDPApril1998
[7]ISO/IEC106461:1993.InternationalStandardInformation
technologyUniversalMultipleOctetCodedCharacterSet(UCS)
Part1:ArchitectureandBasicMultilingualPlane.Fiveamendments
andatechnicalcorrigendumhavebeenpublisheduptonow.UTF8
isdescribedinAnnexR,publishedasAmendment2.
[8]Goldsmith,D.,andM.Davis,"UsingUnicodewithMIME",RFC1641,
July1994.
[9]Yergeau,F.,"UTF8,atransformationformatofUnicodeandISO
10646",RFC2044,October1996.
[10]ITUTRecommendationH.332(1998):"MultimediaTerminalfor
ReceivingInternetbasedH.323Conferences",ITU,Geneva.
[11]Handley,M.,Schooler,E.,andH.Schulzrinne,"Session
InitiationProtocol(SIP)",WorkinProgress.
[12]Schulzrinne,H.,Rao,A.,andR.Lanphier,"RealTimeStreaming
Protocol(RTSP)",RFC2326,April1998.
81/84
11/16/2015
82/84
11/16/2015
RFC2327SDPApril1998
FullCopyrightStatement
Copyright(C)TheInternetSociety(1998).AllRightsReserved.
Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.
Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
83/84
11/16/2015
84/84

RFC 2327 - SDP - Session Description Protocol

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

RFC 2327 - SDP - Session Description Protocol

Загружено:

Авторское право:

Доступные форматы

11/16/2015

Вам также может понравиться