SDP — τι είναι, μορφή περιγραφής συνεδριών και ρόλος στο WebRTC

Τι είναι το SDP (Session Description Protocol);

SDP — είναι ένα πρωτόκολλο επιπέδου εφαρμογής που προορίζεται για την περιγραφή παραμέτρων πολυμεσικών συνεδριών σε μορφή κειμένου. Αναπτύχθηκε στο πλαίσιο της ομάδας εργασίας MMUSIC (Multiparty Multimedia Session Control) του IETF και τυποποιήθηκε για πρώτη φορά στο RFC 2327 το 1998. Το 2021 δημοσιεύθηκε η τρέχουσα προδιαγραφή RFC 8866, η οποία αντικατέστησε την προηγούμενη έκδοση RFC 4566.

Η κύρια αποστολή του SDP είναι να παρέχει στους συμμετέχοντες της συνεδρίας όλες τις απαραίτητες πληροφορίες για τη δημιουργία σύνδεσης: ποιες ροές πολυμέσων θα μεταδοθούν, ποιοι κωδικοποιητές υποστηρίζονται, σε ποιες διευθύνσεις δικτύου και θύρες θα γίνει η μετάδοση. Το SDP δεν μεταδίδει τα ίδια τα δεδομένα πολυμέσων, αλλά περιγράφει μόνο πώς πρέπει να οργανωθεί η σύνδεση.

Σύμφωνα με το IETF RFC 8866, η μορφή SDP αποτελείται από ένα σύνολο γραμμών, κάθε μία από τις οποίες ξεκινά με έναν μονογράμματο τύπο, ακολουθούμενο από ίσον και μια τιμή. Για παράδειγμα, η γραμμή m=audio 5004 RTP/AVP 0 σημαίνει ότι η συνεδρία περιλαμβάνει μια ροή ήχου στη θύρα 5004 με πρωτόκολλο μεταφοράς RTP/AVP και κωδικοποιητή PCMU (τύπος 0).

Ιστορία και τυποποίηση του SDP

Η πρώτη έκδοση του SDP δημοσιεύθηκε στο RFC 2327 τον Απρίλιο του 1998 ως αποτέλεσμα της εργασίας της ομάδας MMUSIC. Το πρωτόκολλο δημιουργήθηκε αρχικά για την ανακοίνωση συνεδριών multicast στο πλαίσιο του Mbone (Multicast Backbone). Με την ανάπτυξη του VoIP και των βιντεοδιασκέψεων, το πεδίο εφαρμογής του SDP επεκτάθηκε και το 2006 δημοσιεύθηκε η ενημερωμένη προδιαγραφή RFC 4566.

Η πραγματική ανακάλυψη στη χρήση του SDP συνέβη με την εμφάνιση του WebRTC το 2011. Η Google ενσωμάτωσε το SDP ως τον κύριο μηχανισμό περιγραφής πολυμεσικών συνεδριών στο πλαίσιο επικοινωνίας πραγματικού χρόνου του προγράμματος περιήγησης. Από τότε, το SDP έγινε υποχρεωτικό συστατικό κάθε υλοποίησης WebRTC — από προγράμματα περιήγησης έως εφαρμογές κινητών σε iOS και Android.

Το 2021, η ομάδα εργασίας IETF δημοσίευσε το RFC 8866 — την τρέχουσα προδιαγραφή SDP που αντικατέστησε το RFC 4566. Η ενημερωμένη έκδοση αποσαφήνισε τον χειρισμό του ICE (Interactive Connectivity Establishment), την υποστήριξη για DTLS (Datagram Transport Layer Security) και επέκτεινε τις δυνατότητες περιγραφής ομαδικών συνεδριών.

Διαφορά του SDP από τα πρωτόκολλα μεταφοράς

SDP διαφέρει θεμελιωδώς από τα πρωτόκολλα μεταφοράς επειδή δεν συμμετέχει στη μετάδοση δεδομένων. Εκτελεί αποκλειστικά περιγραφική λειτουργία — παρόμοια με τα μεταδεδομένα ενός αρχείου πολυμέσων. Ενώ το RTP (Real-time Transport Protocol) μεταδίδει πακέτα ήχου και βίντεο, και το RTCP ελέγχει την ποιότητα μετάδοσης, το SDP απλώς υποδεικνύει ποιους κωδικοποιητές και θύρες να χρησιμοποιήσει.

Μια αναλογία από την ανάπτυξη ιστού: το SDP είναι η σήμανση HTML που περιγράφει τη δομή της σελίδας, και το RTP είναι οι ίδιες οι εικόνες και το κείμενο. Χωρίς SDP, οι συμμετέχοντες της συνεδρίας δεν γνωρίζουν πώς να συνδεθούν μεταξύ τους, ακόμη και αν η σύνδεση δικτύου έχει ήδη δημιουργηθεί. Ο μηχανισμός NAT-traversal (ICE) βασίζεται επίσης στο SDP για τη μετάδοση πληροφοριών σχετικά με υποψηφίους δικτύου.

Πώς είναι δομημένο το SDP

Η δομή του SDP είναι οργανωμένη ως μια ακολουθία γραμμών κειμένου, κάθε μία από τις οποίες ακολουθεί τη μορφή type=value. Ο μονογράμματος τύπος καθορίζει τον σκοπό της γραμμής και η τιμή περιέχει την αντίστοιχη τιμή. Όλες οι γραμμές διαχωρίζονται από τον χαρακτήρα νέας γραμμής CRLF.

Το πρότυπο RFC 8866 ορίζει αρκετά υποχρεωτικά και προαιρετικά πεδία. Τα υποχρεωτικά πεδία περιλαμβάνουν την έκδοση πρωτοκόλλου (v=), το όνομα συνεδρίας (s=), τον χρόνο έναρξης και λήξης της συνεδρίας (t=). Τα υπόλοιπα πεδία είναι προαιρετικά, αλλά για συνεδρίες WebRTC, απαιτούνται επίσης περιγραφές πολυμέσων (m=), χαρακτηριστικά (a=) και πληροφορίες δικτύου (c=).

v=0
o=- 46116397 2 IN IP4 192.168.1.100
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 5004 RTP/SAVPF 111 103 104
c=IN IP4 192.168.1.100
a=rtpmap:111 opus/48000/2
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
m=video 5006 RTP/SAVPF 96 97
a=rtpmap:96 VP8/90000
a=rtpmap:97 H264/90000

Στο παραπάνω παράδειγμα εμφανίζεται ένα τυπικό τμήμα SDP για μια συνεδρία WebRTC. Η γραμμή v=0 υποδεικνύει την έκδοση πρωτοκόλλου. Το πεδίο o= περιέχει το αναγνωριστικό του κατόχου συνεδρίας και την έκδοσή του. Η γραμμή s=- ορίζει το όνομα συνεδρίας (η παύλα σημαίνει κενό όνομα). Το πεδίο t=0 0 υποδεικνύει ότι η συνεδρία δεν είναι χρονικά περιορισμένη.

Το πεδίο a=group:BUNDLE audio video είναι ένα χαρακτηριστικό που ομαδοποιεί πολλαπλές ροές πολυμέσων σε ένα κανάλι μεταφοράς. Ο μηχανισμός BUNDLE επιτρέπει την εξοικονόμηση πόρων δικτύου μεταδίδοντας ήχο και βίντεο μέσω μιας σύνδεσης. Αυτό είναι ιδιαίτερα σημαντικό για κινητές συσκευές με περιορισμένο εύρος ζώνης.

Υποχρεωτικά πεδία SDP

Η προδιαγραφή RFC 8866 ορίζει ένα σύνολο υποχρεωτικών και προαιρετικών πεδίων. Τα υποχρεωτικά πεδία περιλαμβάνουν v= (έκδοση), s= (όνομα συνεδρίας) και t= (χρόνος). Το πεδίο o= (κάτοχος), αν και δεν είναι αυστηρά υποχρεωτικό σύμφωνα με το RFC, είναι πρακτικά πάντα παρόν σε πραγματικές υλοποιήσεις.

Το πεδίο m= (media) είναι ένα από τα σημαντικότερα. Περιγράφει μια συγκεκριμένη ροή πολυμέσων και περιέχει τον τύπο πολυμέσων (audio, video, text, application), θύρα, πρωτόκολλο μεταφοράς και λίστα υποστηριζόμενων κωδικοποιητών. Στο WebRTC, οι πιο συχνά χρησιμοποιούμενοι τύποι είναι audio και video με πρωτόκολλα μεταφοράς RTP/SAVPF (Secure Audio/Video Profile with Feedback) ή UDP/TLS/RTP/SAVPF.

Το πεδίο a= (attribute) είναι το πιο ευέλικτο και επεκτάσιμο. Μπορεί να περιέχει rtpmap (αντιστοίχιση αριθμού κωδικοποιητή σε όνομα), fmtp (παραμέτρους κωδικοποιητή), fingerprint (αποτύπωμα κλειδιού DTLS), ice-ufrag και ice-pwd (διαπιστευτήρια ICE) και πολλά άλλα χαρακτηριστικά. Μέσω των χαρακτηριστικών, το SDP υποστηρίζει σύγχρονους μηχανισμούς ασφαλείας και NAT-traversal.

Πώς λειτουργεί το SDP στο WebRTC

Στην αρχιτεκτονική WebRTC, το SDP παίζει τον ρόλο πρωτοκόλλου σηματοδοσίας για την περιγραφή και διαπραγμάτευση παραμέτρων πολυμεσικής συνεδρίας μεταξύ δύο συμμετεχόντων. Το ίδιο το SDP δεν ορίζει μηχανισμό μετάδοσης αυτών των περιγραφών — αυτή η εργασία επιλύεται από το κανάλι σηματοδοσίας που υλοποιεί ανεξάρτητα ο προγραμματιστής μέσω WebSocket, HTTP ή άλλου πρωτοκόλλου.

Η διαδικασία ξεκινά με τη δημιουργία μιας προσφοράς SDP — Offer από τον εκκινητή (καλούντα). Για αυτό, το πρόγραμμα περιήγησης καλεί τη μέθοδο createOffer() στο αντικείμενο RTCPeerConnection. Η παραγόμενη περιγραφή SDP περιέχει όλες τις παραμέτρους συνεδρίας από την πλευρά του εκκινητή: υποστηριζόμενους κωδικοποιητές, διευθύνσεις δικτύου, υποψηφίους ICE και απαιτήσεις ασφαλείας.

const configuration = { iceServers: [{ urls: 'stun:stun.l.google.com:19302' }] };
const pc = new RTCPeerConnection(configuration);

// Δημιουργία προσφοράς SDP σε Android
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// Αποστολή συμβολοσειράς SDP στον απομακρυσμένο ομότιμο
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// Send SDP to remote peer via signaling channel
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

Μετά τη δημιουργία Offer και τη ρύθμιση της τοπικής περιγραφής μέσω setLocalDescription(), ο εκκινητής στέλνει τη συμβολοσειρά SDP στον απομακρυσμένο συμμετέχοντα μέσω του καναλιού σηματοδοσίας. Ο απομακρυσμένος συμμετέχων, μετά τη λήψη του SDP Offer, δημιουργεί μια απάντηση SDP — Answer — και την στέλνει πίσω. Αυτή η ανταλλαγή ονομάζεται ανταλλαγή σηματοδοσίας (signaling exchange) και είναι υποχρεωτικό βήμα πριν από τη δημιουργία σύνδεσης peer-to-peer.

Σύμφωνα με την Προδιαγραφή W3C WebRTC, η ανταλλαγή SDP πρέπει να γίνει πριν από την έναρξη της ανταλλαγής υποψηφίων ICE. Στην πράξη, πολλές υλοποιήσεις στέλνουν υποψηφίους ICE παράλληλα με το SDP, χρησιμοποιώντας τον μηχανισμό ICE trickle. Αυτό μειώνει τον χρόνο δημιουργίας σύνδεσης, ιδιαίτερα για κινητά δίκτυα με υψηλή καθυστέρηση.

Ο ρόλος του ICE στο SDP

ICE (Interactive Connectivity Establishment) — είναι ένας μηχανισμός που χρησιμοποιεί χαρακτηριστικά SDP για τη μετάδοση πληροφοριών σχετικά με υποψηφίους δικτύου. Οι υποψήφιοι ICE περιγράφουν πιθανές διαδρομές σύνδεσης: host (τοπική διεύθυνση), srflx (διεύθυνση μετά από NAT, που λαμβάνεται μέσω STUN) και relay (διεύθυνση διακομιστή TURN).

Στο SDP, οι υποψήφιοι ICE μεταδίδονται μέσω χαρακτηριστικών a=candidate:, καθώς και μέσω πεδίων ice-ufrag και ice-pwd για αυθεντικοποίηση της κίνησης ICE. Κάθε υποψήφιος περιλαμβάνει πρωτόκολλο μεταφοράς (UDP, TCP), διεύθυνση IP, θύρα και προτεραιότητα. Η επιτυχής σύνδεση δημιουργείται μέσω του πρώτου υποψηφίου που περνά τη δοκιμή συνδεσιμότητας. Ο μηχανισμός ICE restart επιτρέπει την ενημέρωση της σύνδεσης κατά την αλλαγή δικτύου.

Για εφαρμογές κινητών, οι υποψήφιοι ICE είναι ιδιαίτερα σημαντικοί επειδή οι συσκευές βρίσκονται συχνά πίσω από NAT ή εταιρικά τείχη προστασίας. Ο μηχανισμός ICE επιτρέπει την εύρεση μιας λειτουργικής διαδρομής ακόμη και σε περίπλοκες συνθήκες δικτύου, και το SDP χρησιμεύει ως δοχείο μεταφοράς για αυτές τις πληροφορίες.

Ασφάλεια SDP στο WebRTC

SDP στο WebRTC περιλαμβάνει υποχρεωτικά χαρακτηριστικά ασφαλείας, συγκεκριμένα το αποτύπωμα DTLS (fingerprint) και παραμέτρους SRTP. Το πεδίο a=fingerprint:sha-256 περιέχει το αποτύπωμα του πιστοποιητικού DTLS που χρησιμοποιείται για αυθεντικοποίηση και κρυπτογράφηση της ροής πολυμέσων. Χωρίς αυτό το χαρακτηριστικό, η σύνδεση WebRTC δεν θα δημιουργηθεί.

Πρόσθετοι μηχανισμοί ασφαλείας περιλαμβάνουν το χαρακτηριστικό a=setup:, που καθορίζει τον ρόλο της χειραψίας DTLS (active, passive, actpass), και a=ice-lite: για απλοποιημένη υλοποίηση ICE στην πλευρά του διακομιστή. Όλες αυτές οι παράμετροι μεταδίδονται εντός του SDP και ελέγχονται και από τα δύο μέρη πριν από την έναρξη μετάδοσης δεδομένων πολυμέσων.

Τύποι SDP: Offer και Answer

Στο μοντέλο WebRTC, υπάρχουν δύο τύποι μηνυμάτων SDP: Offer (προσφορά) και Answer (απάντηση). Το Offer δημιουργείται από τον εκκινητή της σύνδεσης και περιέχει πλήρη περιγραφή της επιθυμητής πολυμεσικής συνεδρίας. Το Answer δημιουργείται από τον απομακρυσμένο συμμετέχοντα ως απάντηση στο Offer και περιέχει τις δυνατότητές του λαμβάνοντας υπόψη τους περιορισμούς που επιβάλλονται από την προσφορά.

Η κύρια διαφορά μεταξύ Offer και Answer έγκειται στη σημασιολογία των χαρακτηριστικών. Το Offer απαριθμεί όλους τους υποστηριζόμενους κωδικοποιητές, πρωτόκολλα μεταφοράς και διευθύνσεις δικτύου που μπορεί να προσφέρει ο εκκινητής. Το Answer επιλέγει ένα υποσύνολο αυτών των δυνατοτήτων που υποστηρίζονται από το απομακρυσμένο μέρος. Για παράδειγμα, εάν το Offer προσφέρει opus, ISAC και PCMU, το Answer μπορεί να επιλέξει μόνο το opus ως τον πλέον προτιμώμενο κωδικοποιητή.

Η διαδικασία ανταλλαγής ρυθμίζεται από την προδιαγραφή W3C WebRTC και περιλαμβάνει πολλές καταστάσεις του RTCPeerConnection. Μετά τη δημιουργία Offer μέσω createOffer() και τη ρύθμισή του ως τοπικής περιγραφής, η σύνδεση μεταβαίνει στην κατάσταση have-local-offer. Μετά τη λήψη Answer και τη ρύθμισή του ως απομακρυσμένης περιγραφής μέσω setRemoteDescription(), η σύνδεση μεταβαίνει στην κατάσταση stable — την τελική κατάσταση έτοιμη για μετάδοση πολυμέσων.

Χρήση SDP σε κινητά SDK

Τα κινητά SDK για WebRTC — Google WebRTC για Android και WebRTC.framework για iOS — υποστηρίζουν πλήρως την ανταλλαγή SDP μέσω Offer και Answer. Στο Android, για τη δημιουργία Offer χρησιμοποιείται η κλάση PeerConnection με τη μέθοδο createOffer(), παρόμοια με το API του προγράμματος περιήγησης. Η ληφθείσα περιγραφή SDP μεταδίδεται ως συμβολοσειρά μέσω του καναλιού σηματοδοσίας.

Στο iOS, η εργασία με SDP γίνεται μέσω της κλάσης RTCSessionDescription από το πλαίσιο WebRTC. Κατά την αρχικοποίηση, καθορίζονται ο τύπος (RTCSdpTypeOffer ή RTCSdpTypeAnswer) και η συμβολοσειρά SDP. Η πλατφόρμα αναλύει αυτόματα το SDP και διαμορφώνει τη σύνδεση σύμφωνα με τις μεταδιδόμενες παραμέτρους.

val configuration = PeerConnection.RTCConfiguration(List())
val peerConnection = factory.createPeerConnection(configuration, object : PeerConnection.Observer {
    override fun onIceCandidate(candidate: IceCandidate) { }
})

// Create SDP Offer on Android
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // Send SDP string to remote peer
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

Η δυνατότητα άμεσης εργασίας με τη συμβολοσειρά SDP παρέχει ευελιξία στους προγραμματιστές: μπορούν να τροποποιήσουν το SDP πριν από την αποστολή, προσθέτοντας ή αφαιρώντας συγκεκριμένους κωδικοποιητές, διαμορφώνοντας παραμέτρους ICE ή προσθέτοντας προσαρμοσμένα χαρακτηριστικά. Για εφαρμογές Android, συχνά απαιτείται η απενεργοποίηση βίντεο στο SDP όταν το εύρος ζώνης δικτύου είναι χαμηλό — αυτό γίνεται με την αφαίρεση των αντίστοιχων γραμμών m= από την περιγραφή SDP.

SDP στην ανάπτυξη κινητών

Στην ανάπτυξη κινητών, το SDP χρησιμοποιείται κυρίως στο πλαίσιο του WebRTC — για τη δημιουργία εφαρμογών με βιντεοκλήσεις, φωνητικές συνομιλίες και ροή πολυμέσων. Οι εφαρμογές κινητών σε Android και iOS μπορούν να λειτουργήσουν τόσο ως εκκινητές όσο και ως δέκτες μηνυμάτων SDP, επιτρέποντας την κατασκευή συμμετρικών συνδέσεων peer-to-peer.

Η ιδιαιτερότητα των εφαρμογών κινητών είναι η ανάγκη εργασίας με SDP σε συνθήκες μεταβαλλόμενης ποιότητας δικτύου. Κατά τη μεταγωγή μεταξύ Wi-Fi και κινητού διαδικτύου, καθώς και κατά την αλλαγή εύρους ζώνης, μπορεί να απαιτηθεί η δημιουργία νέας περιγραφής SDP. Για αυτό χρησιμοποιείται ο μηχανισμός renegotiation — επαναλαμβανόμενη ανταλλαγή SDP μέσω createOffer() και setLocalDescription().

Σύμφωνα με την ομάδα Google WebRTC (2023), η βελτιστοποίηση της ανταλλαγής SDP για κινητές συσκευές περιλαμβάνει τη χρήση ICE restart κατά την αλλαγή δικτύου, προτεραιοποίηση κωδικοποιητών με χαμηλό ρυθμό μετάδοσης (opus για ήχο, VP8 για βίντεο) και ελάχιστο μέγεθος συμβολοσειράς SDP με αποκλεισμό περιττών ροών πολυμέσων. Το βασικό πλεονέκτημα είναι η μειωμένη καθυστέρηση στη δημιουργία σύνδεσης σε κινητά δίκτυα.

Βελτιστοποίηση SDP για κινητά δίκτυα

Ένα από τα βασικά καθήκοντα κατά την εργασία με SDP σε κινητές συσκευές είναι η ελαχιστοποίηση του μεγέθους της περιγραφής SDP. Το πλήρες SDP για μια τυπική συνεδρία WebRTC με ήχο και βίντεο μπορεί να καταλαμβάνει 2–5 KB, που είναι σημαντικό για αργά δίκτυα. Η βελτιστοποίηση περιλαμβάνει τη χρήση BUNDLE (συγχώνευση ροών), αφαίρεση μη υποστηριζόμενων κωδικοποιητών και συμπίεση υποψηφίων ICE.

Ένα πρόσθετο πρόβλημα των κινητών συσκευών είναι η περιορισμένη διάρκεια ζωής του SDP. Σε συνθήκες ασταθούς σύνδεσης, το SDP μπορεί να λήξει πριν ο απομακρυσμένος συμμετέχων προλάβει να το επεξεργαστεί. Η λύση είναι η χρήση σύντομων χρονικών ορίων για τη λήψη Answer και η εκ νέου αποστολή SDP εάν χρειαστεί. Ο μηχανισμός ICE restart επιτρέπει την ενημέρωση της σύνδεσης χωρίς πλήρη αναδημιουργία του RTCPeerConnection. Το χαρακτηριστικό a=ice-lite απλοποιεί την υλοποίηση ICE στην πλευρά του διακομιστή.

Δημοφιλείς βιβλιοθήκες για εργασία με SDP

Οι προγραμματιστές εφαρμογών κινητών έχουν πρόσβαση σε έτοιμες βιβλιοθήκες που απλοποιούν την εργασία με SDP. Η libjingle_peerconnection (Google WebRTC) — η κύρια βιβλιοθήκη για Android, που παρέχει πλήρες API για διαχείριση SDP. Για iOS, χρησιμοποιείται το WebRTC.framework με παρόμοια λειτουργικότητα. Και οι δύο βιβλιοθήκες δημιουργούν και αναλύουν αυτόματα SDP, αλλά παρέχουν πρόσβαση στην ακατέργαστη συμβολοσειρά SDP εάν χρειαστεί.

Για λεπτότερο έλεγχο του SDP, υπάρχουν λύσεις τρίτων: sdp-transform (JavaScript ή Node.js) για ανάλυση και τροποποίηση SDP, NICENICE (Java) για εργασία με υποψηφίους ICE και έτοιμα SDK από παρόχους υποδομής WebRTC που αναλαμβάνουν ολόκληρη την ανταλλαγή σηματοδοσίας, συμπεριλαμβανομένου του SDP.