Sessionsbeskrivningsprotokoll

Session Description Protocol ( SDP ) är ett format för att beskriva multimediakommunikationssessioner i syfte att tillkännage och inbjuda . Dess övervägande användning är till stöd för strömmande mediaapplikationer , såsom röst över IP (VoIP) och videokonferenser . SDP levererar inga mediaströmmar själv utan används mellan slutpunkter för förhandling av nätverksmått, mediatyper och andra associerade egenskaper. Uppsättningen egenskaper och parametrar kallas en sessionsprofil .

SDP är utbyggbart för stöd för nya mediatyper och format. SDP var ursprungligen en komponent i Session Announcement Protocol (SAP), men hittade andra användningsområden i samband med Real-time Transport Protocol (RTP), Real-time Streaming Protocol (RTSP), Session Initiation Protocol (SIP) och som ett fristående protokoll för att beskriva multicast- sessioner.

IETF publicerade den ursprungliga specifikationen som en föreslagen standard i april 1998 (RFC 2327) . Reviderade specifikationer släpptes 2006 (RFC 4566) och 2021 (RFC 8866).

Sessionsbeskrivning

Sessionsbeskrivningsprotokollet beskriver en session som en grupp av fält i ett textbaserat format, ett fält per rad. Formen för varje fält är följande.

<character>=<value><CR><LF>

Där <tecken> är ett enda skiftlägeskänsligt tecken och <värde> är strukturerad text i ett format som beror på tecknet. Värden är vanligtvis UTF-8- kodade. Blanksteg tillåts inte omedelbart på någon sida av likhetstecknet.

Sessionsbeskrivningar består av tre sektioner: session, timing och mediabeskrivningar. Varje beskrivning kan innehålla flera timing- och mediabeskrivningar. Namn är bara unika inom den associerade syntaktiska konstruktionen.

Fält måste visas i den ordning som visas; valfria fält är markerade med en asterisk:

• Sessionsbeskrivning

 v= (protokollversionsnummer, för närvarande endast 0) o= (upphovsman och sessionsidentifierare: användarnamn, id, versionsnummer, nätverksadress) s= (sessionsnamn: obligatoriskt med minst ett UTF-8-kodat tecken) i =* (sessionens titel eller kort information) u=* (URI för beskrivning) e=* (noll eller fler e-postadresser med valfritt namn på kontakter) p=* (noll eller fler telefonnummer med valfritt namn på kontakter) c=* (anslutningsinformation – krävs inte om den ingår i alla media) b=* (noll eller fler bandbreddsinformationsrader)  En eller flera  tidsbeskrivningar  ("t=" och "r=" linjer; se  nedan  )  z=* (tidszonsjusteringar) ) k=* (krypteringsnyckel) a=* (noll eller fler sessionsattributrader)  Noll eller fler  mediabeskrivningar  (var och en som börjar med en "m="-rad; se  nedan  ) 

• Tidsbeskrivning (obligatorisk)

 t= (tidpunkten för sessionen är aktiv) r=* (noll eller fler upprepningstider) 

• Mediebeskrivning (valfritt)

 m= (medianamn och transportadress) i=* (mediatitel eller informationsfält) c=* (anslutningsinformation — valfritt om det ingår på sessionsnivå ) b=* (noll eller fler bandbreddsinformationsrader) k=* (krypteringsnyckel) a=* (noll eller fler mediaattributrader — åsidosätter sessionsattributlinjerna) 

Nedan finns ett exempel på en sessionsbeskrivning från RFC 4566. Denna session är skapad av användaren "jdoe", på IPv4-adressen 10.47.16.5. Dess namn är "SDP Seminar" och utökad sessionsinformation ("Ett seminarium om sessionsbeskrivningsprotokollet") ingår tillsammans med en länk för ytterligare information och en e-postadress för att kontakta den ansvariga parten, Jane Doe. Denna session är specificerad att pågå i två timmar med hjälp av NTP-tidsstämplar, med en anslutningsadress (som indikerar adressen som klienterna måste ansluta till eller – när en multicast-adress tillhandahålls, som den är här – prenumerera på) specificerad som IPv4 224.2.17.12 med en TTL på 127. Mottagare av denna sessionsbeskrivning instrueras att endast ta emot media. Två mediebeskrivningar tillhandahålls, båda med RTP Audio Video Profile. Den första är en ljudström på port 49170 med RTP/AVP nyttolast typ 0 (definierad av RFC 3551 som PCMU ), och den andra är en videoström på port 51372 med RTP/AVP nyttolast typ 99 (definierad som "dynamisk"). Slutligen ingår ett attribut som mappar RTP/AVP nyttolast typ 99 till format h263-1998 med en 90 kHz klockfrekvens. RTCP- portar för ljud- och videoströmmarna för 49171 respektive 51373 är underförstådda.

SDP-specifikationen är enbart ett format för sessionsbeskrivning. Den är avsedd att distribueras över olika transportprotokoll vid behov, inklusive SAP , SIP och RTSP . SDP kan till och med överföras via e-post eller som en HTTP-nyttolast.

Attribut

SDP använder attribut för att utöka kärnprotokollet. Attribut kan visas inom sessions- eller mediasektionerna och omfångas därefter som sessionsnivå eller medianivå . Nya attribut läggs till standarden då och då genom registrering hos IANA.

Attribut är antingen egenskaper eller värden:

• Egenskap: a= ​​flagga förmedlar en boolesk egenskap hos media eller session.
• Värde: a= attribut : värde ger en namngiven parameter.

Två av dessa attribut är speciellt definierade:

• a=teckenuppsättning: kodning används i sessions- eller mediasektionerna för att ange en annan teckenkodning (som registrerats i IANA-registret) från det rekommenderade standardvärdet ( UTF-8 ) för standardprotokollnycklar. Dessa värden innehåller en text som är avsedd att visas för en användare.
• a=sdplang: kod används för att specificera textens språk. Alternativ text på flera språk kan bäras i sessionen och väljas automatiskt av användaragenten enligt användarens preferenser.

I båda fallen tolkas textfält som är avsedda att visas för en användare som ogenomskinliga strängar, men återges till användaren eller applikationen med de värden som angavs i den senaste förekomsten av fälten charset och sdplang i den aktuella mediesektionen, eller annars deras senaste värde i sessionssektionen.

Parametrarna v , s och o är obligatoriska, får inte vara tomma och bör vara UTF-8-kodade. De används som identifierare och är inte avsedda att visas för användare.

Några andra attribut finns också i exemplet, antingen som ett attribut på sessionsnivå (som attributet i egenskapsformen a=recvonly ), eller som ett attribut på medianivå (som attributet i värdeformen a=rtpmap: 99 h263-1998/90000 för videon i exemplet).

Tidsformat och upprepningar

Absoluta tider representeras i Network Time Protocol (NTP)-format (antal sekunder sedan 1900). Om stopptiden är 0 är sessionen obegränsad . Om starttiden också är noll anses sessionen vara permanent . Obegränsade och permanenta sessioner avråds men är inte förbjudna. Intervaller kan representeras med NTP-tider eller i inskriven tid: ett värde och tidsenheter (dagar: d , timmar: h , minuter: m och sekunder: s ) sekvens.

Således kan ett timmöte från kl. 10 UTC den 1 augusti 2010, med en enda upprepningstid en vecka senare vid samma tidpunkt representeras som:

t=1280656800 1281265200 r=604800 3600 0

Eller använd inskriven tid:

t=1280656800 1281265200 r=7d 1h 0

När repetitionstider är specificerade kan starttiden för varje repetition behöva justeras för att kompensera för ändringar i sommartid så att den inträffar vid samma lokala tid i en specifik tidszon under hela perioden mellan starttiden och stopptiden .

Istället för att specificera denna tidszon och behöva stödja en databas med tidszoner för att veta när och var dagsljusjusteringar kommer att behövas, antas repetitionstiderna alla definieras inom samma tidszon, och SDP stöder indikeringen av NTP absoluta tider när en dagsljusförskjutning (uttryckt i sekunder eller med en typtid) kommer att behöva tillämpas på den upprepade starttiden eller sluttid som faller vid eller efter varje dagsljusjustering. Alla dessa förskjutningar är relativa till starttiden, de är inte kumulativa. NTP stöder detta med fält z , som indikerar en serie par vars första post är NTP:s absoluta tid då en dagsljusjustering kommer att ske, och den andra posten indikerar offset som ska tillämpas i förhållande till de absoluta tiderna beräknade med fältet r .

Till exempel, om en dagsljusjustering kommer att subtrahera 1 timme den 31 oktober 2010 kl. 03.00 UTC (dvs. 60 dagar minus 7 timmar efter starttiden söndagen den 1 augusti 2010 kl. 10.00 UTC), och detta kommer att vara den enda dagsljusjusteringen som gäller under den schemalagda perioden som skulle inträffa mellan den 1 augusti 2010 och den 28 november 2010 kl. 10.00 UTC (stopptiden för den upprepade 1-timmes sessionen som upprepas varje vecka vid samma lokala tid, vilket inträffar 88 dagar senare), detta kan specificeras som:

t=1280656800 1290938400 r=7d 1h 0 z=1288494000 -1h

Om den veckovisa 1-timmessessionen upprepades varje söndag under ett helt år, dvs från söndagen den 1 augusti 2010 kl. 03.00 UTC till söndagen den 26 juni 2011 kl. 04.00 UTC (stopptid för den sista upprepningen, dvs. 360 dagar plus 1 timme senare, eller 31107600 sekunder senare), så att den skulle inkludera övergången tillbaka till sommartid söndagen den 27 mars 2011 kl. 02.00 (1 timme läggs igen till lokal tid så att den andra dagsljusövergången skulle inträffa 209 dagar efter den första starttiden):

t=1280656800 1290938400 r=7d 1h 0 z=1288494000 -1h 1269655200 0

Eftersom SDP-meddelanden för upprepade sessioner inte bör göras för att täcka mycket långa perioder som överstiger några år, bör antalet dagsljusjusteringar som ska inkluderas i z=-parametern förbli litet.

Sessioner kan upprepas oregelbundet under en vecka men schemaläggs på samma sätt för alla veckor i perioden, genom att lägga till fler tupler i parametern r . Till exempel, för att schemalägga samma evenemang även på lördag (vid samma tid på dagen) skulle du använda:

t=1280656800 1290938400 r=7d 1h 0 6d z=1288494000 -1h 1269655200 0

SDP-protokollet stöder inte upprepade sessioner månads- och årsscheman med så enkla upprepningstider, eftersom de är oregelbundet fördelade i tid; istället kan ytterligare t / r -tuplar tillhandahållas för varje månad eller år.

externa länkar

• Rosenberg, J.; Schulzrinne, H. (juni 2002). En erbjudande/svarsmodell med sessionsbeskrivningsprotokollet . IETF . doi : 10.17487/RFC3264 . RFC 3264 .