SDP — यह क्या है, सत्र विवरण प्रारूप और WebRTC में भूमिका

SDP (Session Description Protocol) क्या है?

SDP एक एप्लिकेशन लेयर प्रोटोकॉल है जो टेक्स्ट प्रारूप में मल्टीमीडिया सत्र मापदंडों का वर्णन करने के लिए डिज़ाइन किया गया है। इसे IETF के MMUSIC (Multiparty Multimedia Session Control) कार्य समूह के तहत विकसित किया गया था और पहली बार 1998 में RFC 2327 में मानकीकृत किया गया था। 2021 में, वर्तमान विनिर्देश RFC 8866 जारी किया गया, जिसने पिछले संस्करण RFC 4566 को बदल दिया।

SDP का मुख्य कार्य सत्र प्रतिभागियों को कनेक्शन स्थापित करने के लिए सभी आवश्यक जानकारी प्रदान करना है: कौन सी मीडिया स्ट्रीम प्रेषित की जाएंगी, कौन से कोडेक समर्थित हैं, और किस नेटवर्क पते और पोर्ट पर प्रेषण होगा। SDP स्वयं मीडिया डेटा प्रेषित नहीं करता, बल्कि केवल यह वर्णन करता है कि कनेक्शन कैसे व्यवस्थित किया जाना चाहिए।

IETF RFC 8866 के अनुसार, SDP प्रारूप में पंक्तियों का एक सेट होता है, जिनमें से प्रत्येक एक अक्षर के प्रकार से शुरू होती है, उसके बाद एक समान चिह्न और मान होता है। उदाहरण के लिए, पंक्ति m=audio 5004 RTP/AVP 0 का अर्थ है कि सत्र में पोर्ट 5004 पर RTP/AVP ट्रांसपोर्ट प्रोटोकॉल और PCMU कोडेक (प्रकार 0) के साथ एक ऑडियो स्ट्रीम शामिल है।

SDP का इतिहास और मानकीकरण

SDP का पहला संस्करण अप्रैल 1998 में RFC 2327 में MMUSIC समूह के काम के परिणामस्वरूप प्रकाशित किया गया था। प्रोटोकॉल मूल रूप से Mbone (Multicast Backbone) के तहत मल्टीकास्ट सत्रों की घोषणा के लिए बनाया गया था। VoIP और वीडियो कॉन्फ्रेंसिंग के विकास के साथ, SDP के अनुप्रयोग क्षेत्र का विस्तार हुआ, और 2006 में अद्यतन विनिर्देश RFC 4566 जारी किया गया।

SDP उपयोग में एक वास्तविक सफलता 2011 में WebRTC के आगमन के साथ हुई। 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 ट्रैवर्सल तंत्र (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

उपरोक्त उदाहरण WebRTC सत्र के लिए एक विशिष्ट SDP खंड दिखाता है। 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 ट्रैवर्सल का समर्थन करता है।

WebRTC में SDP कैसे काम करता है

WebRTC आर्किटेक्चर में, SDP दो प्रतिभागियों के बीच मीडिया सत्र मापदंडों का वर्णन और बातचीत करने के लिए एक सिग्नलिंग प्रोटोकॉल के रूप में कार्य करता है। SDP स्वयं इन विवरणों को प्रेषित करने के तंत्र को परिभाषित नहीं करता — यह कार्य सिग्नलिंग चैनल द्वारा संभाला जाता है, जिसे डेवलपर स्वतंत्र रूप से WebSocket, HTTP या किसी अन्य प्रोटोकॉल के माध्यम से कार्यान्वित करता है।

प्रक्रिया तब शुरू होती है जब आरंभकर्ता (caller) एक SDP Offer बनाता है। ऐसा करने के लिए, ब्राउज़र RTCPeerConnection ऑब्जेक्ट पर createOffer() विधि को कॉल करता है। उत्पन्न 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 trickle तंत्र का उपयोग करके SDP के समानांतर ICE उम्मीदवार भेजते हैं। यह कनेक्शन स्थापना समय को कम करता है, विशेष रूप से उच्च विलंबता वाले मोबाइल नेटवर्क के लिए।

SDP में ICE की भूमिका

ICE (Interactive Connectivity Establishment) एक तंत्र है जो नेटवर्क उम्मीदवारों के बारे में जानकारी प्रेषित करने के लिए SDP विशेषताओं का उपयोग करता है। ICE उम्मीदवार संभावित कनेक्शन पथों का वर्णन करते हैं: host (स्थानीय पता), srflx (NAT के बाद का पता, STUN के माध्यम से प्राप्त) और relay (TURN सर्वर का पता)।

SDP में, ICE उम्मीदवार a=candidate: विशेषताओं के माध्यम से, साथ ही ICE ट्रैफ़िक प्रमाणीकरण के लिए ice-ufrag और ice-pwd फ़ील्ड के माध्यम से प्रेषित किए जाते हैं। प्रत्येक उम्मीदवार में ट्रांसपोर्ट प्रोटोकॉल (UDP, TCP), IP पता, पोर्ट और प्राथमिकता शामिल होती है। एक सफल कनेक्शन पहले उम्मीदवार के माध्यम से स्थापित होता है जो कनेक्टिविटी जाँच पास करता है। ICE restart तंत्र नेटवर्क बदलने पर कनेक्शन को अद्यतन करने की अनुमति देता है।

मोबाइल अनुप्रयोगों के लिए, ICE उम्मीदवार विशेष रूप से महत्वपूर्ण हैं क्योंकि उपकरण अक्सर NAT या कॉर्पोरेट फ़ायरवॉल के पीछे होते हैं। ICE तंत्र जटिल नेटवर्क स्थितियों में भी एक कार्यशील पथ खोजने की अनुमति देता है, और SDP इस जानकारी के लिए ट्रांसपोर्ट कंटेनर के रूप में कार्य करता है।

WebRTC में SDP सुरक्षा

WebRTC में SDP में आवश्यक रूप से सुरक्षा विशेषताएँ शामिल होती हैं, विशेष रूप से 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 की कई स्थितियाँ शामिल हैं। createOffer() के माध्यम से Offer बनाने और इसे स्थानीय विवरण के रूप में सेट करने के बाद, कनेक्शन have-local-offer स्थिति में प्रवेश करता है। Answer प्राप्त करने और इसे setRemoteDescription() के माध्यम से दूरस्थ विवरण के रूप में सेट करने के बाद, कनेक्शन stable स्थिति में प्रवेश करता है — मीडिया प्रेषण के लिए तैयार अंतिम स्थिति।

मोबाइल SDK में SDP का उपयोग

WebRTC के लिए मोबाइल SDK — Android के लिए Google WebRTC और iOS के लिए WebRTC.framework — Offer और Answer के माध्यम से SDP आदान-प्रदान का पूरी तरह से समर्थन करते हैं। Android पर, Offer बनाने के लिए PeerConnection क्लास का उपयोग createOffer() विधि के साथ किया जाता है, जो ब्राउज़र API के समान है। परिणामी SDP विवरण सिग्नलिंग चैनल के माध्यम से एक स्ट्रिंग के रूप में प्रेषित किया जाता है।

iOS पर, SDP के साथ काम WebRTC फ्रेमवर्क से RTCSessionDescription क्लास के माध्यम से किया जाता है। आरंभ करते समय, प्रकार (RTCSdpTypeOffer या RTCSdpTypeAnswer) और SDP स्ट्रिंग निर्दिष्ट की जाती है। प्लेटफ़ॉर्म स्वचालित रूप से SDP को पार्स करता है और प्रेषित मापदंडों के अनुसार कनेक्शन कॉन्फ़िगर करता है।

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

// Android पर SDP Offer बनाएँ
peerConnection.createOffer(object : SdpObserver {
    override fun onCreateSuccess(sdp: SessionDescription) {
        peerConnection.setLocalDescription(this, sdp)
        // दूरस्थ पीयर को SDP स्ट्रिंग भेजें
        sendSdpToRemotePeer(sdp.description)
    }
}, new MediaConstraints())

SDP स्ट्रिंग के साथ सीधे काम करने की क्षमता डेवलपर्स को लचीलापन देती है: वे भेजने से पहले SDP को संशोधित कर सकते हैं, विशिष्ट कोडेक जोड़ या हटा सकते हैं, ICE पैरामीटर कॉन्फ़िगर कर सकते हैं या कस्टम विशेषताएँ जोड़ सकते हैं। Android अनुप्रयोगों के लिए, नेटवर्क बैंडविड्थ कम होने पर SDP में वीडियो को अक्षम करना अक्सर आवश्यक होता है — यह SDP विवरण से संबंधित m= पंक्तियों को हटाकर किया जाता है।

मोबाइल डेवलपमेंट में SDP

मोबाइल डेवलपमेंट में, SDP का उपयोग मुख्य रूप से WebRTC के संदर्भ में किया जाता है — वीडियो कॉल, वॉयस चैट और स्ट्रीमिंग वाले अनुप्रयोग बनाने के लिए। Android और iOS पर मोबाइल एप्लिकेशन SDP संदेशों के आरंभकर्ता और प्राप्तकर्ता दोनों के रूप में कार्य कर सकते हैं, जो सममित पीयर-टू-पीयर कनेक्शन सक्षम करता है।

मोबाइल अनुप्रयोगों की एक विशेषता परिवर्तनशील नेटवर्क गुणवत्ता स्थितियों के तहत SDP के साथ काम करने की आवश्यकता है। Wi-Fi और मोबाइल इंटरनेट के बीच स्विच करते समय, साथ ही बैंडविड्थ बदलने पर, एक नया SDP विवरण उत्पन्न करने की आवश्यकता हो सकती है। यह पुनर्वार्ता तंत्र का उपयोग करके किया जाता है — createOffer() और setLocalDescription() के माध्यम से बार-बार SDP आदान-प्रदान।

Google WebRTC टीम (2023) के अनुसार, मोबाइल उपकरणों के लिए SDP आदान-प्रदान को अनुकूलित करने में नेटवर्क परिवर्तनों के दौरान ICE restart का उपयोग, कम बिटरेट कोडेक (ऑडियो के लिए opus, वीडियो के लिए VP8) को प्राथमिकता देना और अनावश्यक मीडिया स्ट्रीम को हटाकर SDP स्ट्रिंग आकार को कम करना शामिल है। मुख्य लाभ मोबाइल नेटवर्क स्थितियों में कनेक्शन स्थापित करते समय विलंबता को कम करना है।

मोबाइल नेटवर्क के लिए SDP अनुकूलन

मोबाइल उपकरणों पर SDP के साथ काम करते समय प्रमुख कार्यों में से एक SDP विवरण आकार को कम करना है। ऑडियो और वीडियो के साथ एक विशिष्ट WebRTC सत्र के लिए पूर्ण SDP 2–5 KB का हो सकता है, जो धीमी नेटवर्क के लिए महत्वपूर्ण है। अनुकूलन में BUNDLE (स्ट्रीम मल्टीप्लेक्सिंग) का उपयोग, असमर्थित कोडेक को हटाना और ICE उम्मीदवारों को संपीड़ित करना शामिल है।

मोबाइल उपकरणों के लिए एक अतिरिक्त समस्या सीमित SDP जीवनकाल है। अस्थिर कनेक्शन स्थितियों के तहत, SDP दूरस्थ प्रतिभागी द्वारा इसे संसाधित करने से पहले ही पुराना हो सकता है। समाधान Answer प्राप्त करने के लिए छोटी टाइमआउट अवधि का उपयोग करना और आवश्यकता पड़ने पर SDP को पुनः भेजना है। ICE restart तंत्र RTCPeerConnection को पूरी तरह से पुनः बनाए बिना कनेक्शन को अद्यतन करने की अनुमति देता है। a=ice-lite विशेषता सर्वर पक्ष पर ICE कार्यान्वयन को सरल बनाती है।

SDP के साथ काम करने के लिए लोकप्रिय लाइब्रेरी

मोबाइल एप्लिकेशन डेवलपर्स के पास SDP के साथ काम को सरल बनाने वाली तैयार लाइब्रेरी तक पहुँच है। libjingle_peerconnection (Google WebRTC) Android के लिए मुख्य लाइब्रेरी है, जो SDP प्रबंधन के लिए पूर्ण API प्रदान करती है। iOS के लिए, समान कार्यक्षमता वाले WebRTC.framework का उपयोग किया जाता है। दोनों लाइब्रेरी स्वचालित रूप से SDP उत्पन्न और पार्स करती हैं, लेकिन आवश्यकता पड़ने पर कच्ची SDP स्ट्रिंग तक पहुँच प्रदान करती हैं।

SDP पर अधिक सूक्ष्म नियंत्रण के लिए, तृतीय-पक्ष समाधान मौजूद हैं: SDP को पार्स और संशोधित करने के लिए sdp-transform (JavaScript या Node.js), ICE उम्मीदवारों के साथ काम करने के लिए NICENICE (Java), और WebRTC बुनियादी ढाँचा प्रदाताओं से तैयार SDK जो SDP सहित सभी सिग्नलिंग आदान-प्रदान को संभालते हैं।