Protokół opisu sesji - Session Description Protocol

Session Description Protocol ( SDP ) jest formatem opisywania multimedialnej komunikacji sesje dla celów zapowiedzi i zaproszenia. Jego głównym zastosowaniem jest obsługa aplikacji do strumieniowego przesyłania multimediów , takich jak Voice over IP (VoIP) i wideokonferencje . SDP sam nie dostarcza żadnych strumieni mediów, ale jest używany między punktami końcowymi do negocjowania metryk sieciowych, typów mediów i innych powiązanych właściwości. Zestaw właściwości i parametrów nazywany jest profilem sesji .

SDP jest rozszerzalny w celu obsługi nowych typów i formatów mediów. SDP był pierwotnie składnikiem Session Announcement Protocol (SAP), ale znalazł inne zastosowania w połączeniu z Real-time Transport Protocol (RTP), Real-time Streaming Protocol (RTSP), Session Initiation Protocol (SIP) oraz jako samodzielny protokół do opisywania sesji multiemisji .

IETF opublikowała oryginalnej specyfikacji jako proponowanej normy w kwietniu 1998. Zmienione specyfikacje zostały wydane w 2006 roku (RFC 4566), aw 2021 (RFC 8866) ..

Opis sesji

Protokół opisu sesji opisuje sesję jako grupę pól w formacie tekstowym, jedno pole w wierszu. Postać każdego pola jest następująca.

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

Gdzie <character>jest pojedynczym znakiem rozróżniającym<value> wielkość liter i jest tekstem strukturalnym w formacie zależnym od znaku. Wartości są zazwyczaj zakodowane w UTF-8 . Białe znaki nie mogą znajdować się natychmiast po obu stronach znaku równości.

Opisy sesji składają się z trzech sekcji: sesji, czasu i opisów mediów. Każdy opis może zawierać wiele opisów czasu i mediów. Nazwy są unikalne tylko w ramach skojarzonej konstrukcji składniowej.

Pola muszą pojawić się w pokazanej kolejności; pola opcjonalne są oznaczone gwiazdką:

• Opis sesji

    v=  (protocol version number, currently only 0)
    o=  (originator and session identifier : username, id, version number, network address)
    s=  (session name : mandatory with at least one UTF-8-encoded character)
    i=* (session title or short information)
    u=* (URI of description)
    e=* (zero or more email address with optional name of contacts)
    p=* (zero or more phone number with optional name of contacts)
    c=* (connection information—not required if included in all media)
    b=* (zero or more bandwidth information lines)
    One or more time descriptions ("t=" and "r=" lines; see below)
    z=* (time zone adjustments)
    k=* (encryption key)
    a=* (zero or more session attribute lines)
    Zero or more Media descriptions (each one starting by an "m=" line; see below)

• Opis czasu (obowiązkowe)

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

• Opis mediów (opcjonalnie)

    m=  (media name and transport address)
    i=* (media title or information field)
    c=* (connection information — optional if included at session level)
    b=* (zero or more bandwidth information lines)
    k=* (encryption key)
    a=* (zero or more media attribute lines — overriding the Session attribute lines)

Poniżej znajduje się przykładowy opis sesji z RFC 4566. Ta sesja została zainicjowana przez użytkownika „jdoe” pod adresem IPv4 10.47.16.5. Nazywa się „Seminarium SDP” i zawiera rozszerzone informacje o sesji („Seminarium dotyczące protokołu opisu sesji”) wraz z linkiem do dodatkowych informacji i adresem e-mail do kontaktu ze stroną odpowiedzialną, Jane Doe. Ta sesja jest określona jako trwająca dwie godziny przy użyciu znaczników czasu NTP, z adresem połączenia (który wskazuje adres, z którym klienci muszą się połączyć lub — gdy podany jest adres multiemisji, tak jak tutaj — subskrybować) określonym jako IPv4 224.2.17.12 z TTL z 127. Odbiorcy tego opisu sesji są instruowani, aby tylko otrzymać media. Dostępne są dwa opisy multimediów, oba przy użyciu profilu audio-wideo RTP. Pierwszym z nich jest strumień audio na porcie 49170 przy użyciu typu ładunku RTP/AVP 0 (zdefiniowany przez RFC 3551 jako PCMU ), a drugi to strumień wideo na porcie 51372 przy użyciu typu ładunku RTP/AVP 99 (zdefiniowany jako „dynamiczny”). Na koniec dołączany jest atrybut, który mapuje typ ładunku RTP/AVP 99 na format h263-1998 z częstotliwością zegara 90 kHz. Domyślne są porty RTCP dla strumieni audio i wideo odpowiednio 49171 i 51373.

    v=0
    o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
    s=SDP Seminar
    i=A Seminar on the session description protocol
    u=http://www.example.com/seminars/sdp.pdf
    e=j.doe@example.com (Jane Doe)
    c=IN IP4 224.2.17.12/127
    t=2873397496 2873404696
    a=recvonly
    m=audio 49170 RTP/AVP 0
    m=video 51372 RTP/AVP 99
    a=rtpmap:99 h263-1998/90000

Specyfikacja SDP jest wyłącznie formatem opisu sesji. W razie potrzeby jest przeznaczony do dystrybucji przez różne protokoły transportowe, w tym SAP , SIP i RTSP . SDP może być nawet przesyłany pocztą elektroniczną lub jako ładunek HTTP.

Atrybuty

SDP używa atrybutów do rozszerzenia protokołu podstawowego. Atrybuty mogą pojawiać się w sekcjach Sesja lub Media i mają odpowiedni zakres na poziomie sesji lub na poziomie mediów . Nowe atrybuty są od czasu do czasu dodawane do standardu poprzez rejestrację w IANA.

Atrybuty to właściwości lub wartości:

• Właściwość: flaga a= przekazuje wartość logiczną nośnika lub sesji.
• Wartość: a= atrybut : wartość dostarcza nazwany parametr.

Dwa z tych atrybutów są specjalnie zdefiniowane:

• a=charset: kodowanie jest używane w sekcjach sesji lub multimediów w celu określenia innego kodowania znaków (zarejestrowanego w rejestrze IANA) niż zalecana wartość domyślna ( UTF-8 ) dla kluczy protokołu standardowego. Te wartości zawierają tekst, który ma być wyświetlany użytkownikowi.
• a=sdplang: kod służy do określenia języka tekstu. Alternatywny tekst w wielu językach może być przenoszony w sesji i wybierany automatycznie przez agenta użytkownika zgodnie z preferencjami użytkownika.

W obu przypadkach pola tekstowe, które mają być wyświetlane użytkownikowi, są interpretowane jako nieprzezroczyste ciągi, ale renderowane dla użytkownika lub aplikacji z wartościami wskazanymi w ostatnim wystąpieniu pól charset i sdplang w bieżącej sekcji multimediów lub w przeciwnym razie ich ostatnim wartość w sekcji sesji.

Parametry v , s i o są obowiązkowe, nie mogą być puste i powinny być zakodowane w UTF-8. Są używane jako identyfikatory i nie są przeznaczone do wyświetlania użytkownikom.

W przykładzie występuje również kilka innych atrybutów, albo jako atrybut na poziomie sesji (na przykład atrybut w postaci właściwości a=recvonly ), albo jako atrybut na poziomie mediów (na przykład atrybut w postaci wartości a=rtpmap: 99 h263-1998/90000 dla wideo w przykładzie).

Formaty czasu i powtórzenia

Czasy bezwzględne są reprezentowane w formacie Network Time Protocol (NTP) (liczba sekund od 1900). Jeśli czas zatrzymania wynosi 0, sesja jest nieograniczona . Jeśli czas rozpoczęcia wynosi również zero, sesja jest uważana za stałą . Sesje nieograniczone i stałe są odradzane, ale nie zabronione. Odstępy mogą być reprezentowane przez czas NTP lub w postaci czasu wpisanego: wartość i jednostki czasu (dni: d , godziny: h , minuty: mi sekundy: s ).

Tak więc godzinne spotkanie od 10 rano UTC w dniu 1 sierpnia 2010 r., z pojedynczym powtórzeniem tydzień później w tym samym czasie, może być reprezentowane jako:

        t=1280656800 1281265200
        r=604800 3600 0

Lub używając wpisanej godziny:

        t=1280656800 1281265200
        r=7d 1h 0

Po określeniu czasów powtórzeń może być konieczne dostosowanie czasu rozpoczęcia każdego powtórzenia w celu skompensowania zmian czasu letniego, tak aby nastąpiło to w tym samym czasie lokalnym w określonej strefie czasowej w okresie między czasem rozpoczęcia a czasem zakończenia .

Zamiast określania tej strefy czasowej i konieczności obsługi bazy danych stref czasowych, aby wiedzieć, kiedy i gdzie będą potrzebne korekty światła dziennego, zakłada się, że czasy powtórzeń są zdefiniowane w tej samej strefie czasowej, a SDP obsługuje wskazanie czasów bezwzględnych NTP gdy przesunięcie światła dziennego (wyrażone w sekundach lub przy użyciu czasu typu) będzie musiało zostać zastosowane do powtarzającego się czasu rozpoczęcia lub zakończenia, przypadającego na lub po każdej zmianie światła dziennego. Wszystkie te przesunięcia odnoszą się do czasu rozpoczęcia, nie kumulują się. NTP obsługuje to za pomocą pola z , które wskazuje serię par, których pierwszą pozycją jest czas bezwzględny NTP, kiedy nastąpi korekta światła dziennego, a druga pozycja wskazuje przesunięcie do zastosowania względem czasów bezwzględnych obliczonych za pomocą pola r .

Na przykład, jeśli korekta czasu odejmie 1 godzinę 31 października 2010 o 3 rano UTC (tj. 60 dni minus 7 godzin po rozpoczęciu w niedzielę 1 sierpnia 2010 o 10:00 UTC), i będzie to jedyna korekta czasu w zaplanowanym okresie, który miałby nastąpić od 1 sierpnia 2010 r. do 28 listopada 2010 r. o godz. 10.00 UTC (czas zakończenia powtarzanej jednogodzinnej sesji, która powtarzana jest co tydzień o tej samej godzinie lokalnej, co następuje 88 dni później), można to określić jako:

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

Jeżeli cotygodniowa 1-godzinna sesja była powtarzana w każdą niedzielę przez cały rok, tj. od niedzieli 1 sierpnia 2010 r. o 3 nad ranem UTC do niedzieli 26 czerwca 2011 r. o 4 nad ranem (czas zakończenia ostatniego powtórzenia, tj. 360 dni plus 1 godzina później, lub 31107600 sekund później), tak aby obejmowało przejście z powrotem do czasu letniego w niedzielę 27 marca 2011 r. o godzinie 2 w nocy (1 godzina jest ponownie dodawana do czasu lokalnego, aby drugie przejście na czas letni nastąpiło 209 dni po pierwszym czasie rozpoczęcia):

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

Ponieważ ogłoszenia SDP dla powtarzających się sesji nie powinny obejmować bardzo długich okresów przekraczających kilka lat, liczba korekt światła dziennego, które należy uwzględnić w parametrze z=, powinna pozostać niewielka.

Sesje mogą być powtarzane nieregularnie w ciągu tygodnia, ale zaplanowane w ten sam sposób dla wszystkich tygodni w okresie, dodając więcej krotek w parametrze r . Na przykład, aby zaplanować to samo wydarzenie również w sobotę (o tej samej porze dnia), użyjesz:

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

Protokół SDP nie obsługuje powtarzających się sesji miesięcznych i rocznych harmonogramów z tak prostymi czasami powtórzeń, ponieważ są one rozmieszczone nieregularnie w czasie; zamiast tego można dostarczać dodatkowe krotki t / r dla każdego miesiąca lub roku.

Uwagi

Bibliografia

Linki zewnętrzne

• Rosenberg, J.; Schulzrinne, H. (czerwiec 2002). Model oferty/odpowiedzi z protokołem opisu sesji . IETF . doi : 10.17487/RFC3264 . RFC 3264 .