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 โปรโตคอลถูกสร้างขึ้นเดิมเพื่อประกาศเซสชันมัลติคาสต์ภายใน 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 หรือโปรโตคอลอื่น

กระบวนการเริ่มต้นเมื่อผู้เริ่มต้น (caller) สร้าง SDP Offer โดยเรียกใช้เมธอด createOffer() บนออบเจ็กต์ RTCPeerConnection คำอธิบาย SDP ที่สร้างขึ้นประกอบด้วยพารามิเตอร์เซสชันทั้งหมดจากฝั่งผู้เริ่มต้น: ตัวแปลงสัญญาณที่รองรับ ที่อยู่เครือข่าย ผู้สมัคร ICE และข้อกำหนดด้านความปลอดภัย

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

// เพิ่มแทร็กสื่อก่อน createOffer
const stream = await navigator.mediaDevices.getUserMedia({ audio: true, video: true });
stream.getTracks().forEach(track => pc.addTrack(track, stream));

// สร้าง SDP Offer
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// ส่ง SDP ไปยังเพียร์ระยะไกลผ่านช่องสัญญาณ
sendViaSignaling({ type: 'offer', sdp: offer.sdp });

หลังจากสร้าง Offer และตั้งค่าคำอธิบายท้องถิ่นผ่าน setLocalDescription() ผู้เริ่มต้นส่งสตริง SDP ไปยังผู้เข้าร่วมระยะไกลผ่านช่องสัญญาณ ผู้เข้าร่วมระยะไกลเมื่อได้รับ SDP Offer จะสร้าง SDP Answer และส่งกลับ การแลกเปลี่ยนนี้เรียกว่าการแลกเปลี่ยนสัญญาณและเป็นขั้นตอนบังคับก่อนสร้างการเชื่อมต่อแบบเพียร์ทูเพียร์

ตามข้อมูลจำเพาะ 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 และพารามิเตอร์ 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 คลาส PeerConnection พร้อมเมธอด createOffer() ใช้สร้าง Offer คล้ายกับ API ของเบราว์เซอร์ คำอธิบาย SDP ที่ได้จะถูกส่งเป็นสตริงผ่านช่องสัญญาณ

บน iOS การทำงานกับ SDP ทำผ่านคลาส RTCSessionDescription จากเฟรมเวิร์ก WebRPC เมื่อเริ่มต้น ประเภท (RTCSdpTypeOffer หรือ RTCSdpTypeAnswer) และสตริง SDP จะถูกระบุ แพลตฟอร์มจะแยกวิเคราะห์ SDP โดยอัตโนมัติและกำหนดค่าการเชื่อมต่อตามพารามิเตอร์ที่ส่ง

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

// สร้าง SDP Offer บน Android
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // ส่งสตริง SDP ไปยังเพียร์ระยะไกล
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

ความสามารถในการทำงานโดยตรงกับสตริง SDP ช่วยให้นักพัฒนามีความยืดหยุ่น: พวกเขาสามารถแก้ไข SDP ก่อนส่ง เพิ่มหรือลบตัวแปลงสัญญาณเฉพาะ กำหนดค่าพารามิเตอร์ ICE หรือเพิ่มคุณลักษณะที่กำหนดเอง สำหรับแอปพลิเคชัน Android มักจำเป็นต้องปิดวิดีโอใน SDP เมื่อแบนด์วิดท์เครือข่ายต่ำ — ทำได้โดยลบบรรทัด m= ที่เกี่ยวข้องออกจากคำอธิบาย SDP

SDP ในการพัฒนามือถือ

ในการพัฒนามือถือ SDP ถูกใช้เป็นหลักในบริบทของ WebRTC — สำหรับสร้างแอปพลิเคชันที่มีการโทรวิดีโอ แชทเสียง และสตรีมมิ่ง แอปพลิเคชันมือถือบน Android และ iOS สามารถทำหน้าที่เป็นทั้งผู้เริ่มต้นและผู้รับข้อความ SDP ทำให้สามารถเชื่อมต่อแบบเพียร์ทูเพียร์แบบสมมาตร

ลักษณะพิเศษของแอปพลิเคชันมือถือคือความจำเป็นในการทำงานกับ SDP ในสภาพคุณภาพเครือข่ายที่แปรปรวน เมื่อสลับระหว่าง Wi-Fi และอินเทอร์เน็ตมือถือ รวมถึงเมื่อแบนด์วิดท์เปลี่ยนแปลง อาจจำเป็นต้องสร้างคำอธิบาย SDP ใหม่ ซึ่งทำได้โดยใช้กลไก การเจรจาใหม่ — การแลกเปลี่ยน 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