एसआईपी - त्वरित गाइड

सत्र पहल प्रोटोकॉल (एसआईपी) वीओआईपी प्रौद्योगिकी में उपयोग किए जाने वाले सबसे आम प्रोटोकॉल में से एक है। यह एक एप्लीकेशन लेयर प्रोटोकॉल है जो इंटरनेट पर मल्टीमीडिया संचार सत्रों को नियंत्रित करने के लिए अन्य एप्लिकेशन लेयर प्रोटोकॉल के साथ मिलकर काम करता है।

वीओआईपी प्रौद्योगिकी

आगे बढ़ने से पहले, चलिए पहले वीओआईपी के बारे में कुछ बिंदुओं को समझते हैं।

• वीओआइपी एक ऐसी तकनीक है जो आपको इंटरनेट पर आवाज और मल्टीमीडिया (वीडियो, चित्र) सामग्री देने की अनुमति देती है। यह इंटरनेट की उपलब्धता के साथ कहीं भी, कभी भी संवाद करने का सबसे सस्ता तरीका है।

• वीओआइपी के कुछ फायदों में शामिल हैं -

  • कम लागत

  • Portability

  • कोई अतिरिक्त केबल नहीं

  • Flexibility

  • वीडियो कॉन्फ्रेंसिंग

• वीओआइपी कॉल के लिए, आपको इंटरनेट कनेक्टिविटी के साथ कंप्यूटर / लैपटॉप / मोबाइल की आवश्यकता है। निम्न आकृति दर्शाती है कि एक वीओआईपी कॉल कैसे होता है।

इस बहुत मौलिक के साथ, हम SIP पर वापस आते हैं।

एसआईपी - अवलोकन

एसआईपी के बारे में ध्यान देने के लिए नीचे कुछ बिंदु दिए गए हैं -

• SIP एक सिग्नलिंग प्रोटोकॉल है जिसका उपयोग इंटरनेट प्रोटोकॉल पर एक मल्टीमीडिया सत्र को बनाने, संशोधित करने और समाप्त करने के लिए किया जाता है। एक सत्र दो एंडपॉइंट के बीच एक साधारण कॉल के अलावा कुछ भी नहीं है। एक समापन बिंदु एक स्मार्टफोन, एक लैपटॉप या कोई भी उपकरण हो सकता है जो इंटरनेट पर मल्टीमीडिया सामग्री प्राप्त और भेज सकता है।

• SIP IETF (इंटरनेट इंजीनियरिंग टास्क फोर्स) मानक द्वारा परिभाषित एक एप्लीकेशन लेयर प्रोटोकॉल है। में परिभाषित किया गया हैRFC 3261।

• SIP क्लाइंट-सर्वर आर्किटेक्चर और URL और URI के उपयोग का प्रतीक है HTTP और एक पाठ एन्कोडिंग योजना और एक हेडर शैली से SMTP।

• SIP SDP (सत्र विवरण प्रोटोकॉल) की मदद लेता है जो आईपी नेटवर्क पर आवाज और वीडियो पहुंचाने के लिए उपयोग किए जाने वाले सत्र और RTP (रियल टाइम ट्रांसपोर्ट प्रोटोकॉल) का वर्णन करता है।

• एसआईपी का उपयोग दो-पक्षीय (यूनिकस्ट) या मल्टीपार्टी (मल्टीकास्ट) सत्रों के लिए किया जा सकता है।

• अन्य एसआईपी अनुप्रयोगों में फ़ाइल स्थानांतरण, त्वरित संदेश, वीडियो कॉन्फ्रेंसिंग, ऑनलाइन गेम और स्टीमिंग मल्टीमीडिया वितरण शामिल हैं।

कहाँ सिप फिट में?

असल में SIP एक एप्लीकेशन लेयर प्रोटोकॉल है। यह एक या अधिक प्रतिभागियों के साथ सत्र बनाने और समाप्त करने के लिए एक सरल नेटवर्क सिग्नलिंग प्रोटोकॉल है। SIP प्रोटोकॉल को अंतर्निहित परिवहन प्रोटोकॉल से स्वतंत्र होने के लिए डिज़ाइन किया गया है, इसलिए SIP एप्लिकेशन टीसीपी, यूडीपी या अन्य निचले-स्तर के नेटवर्किंग प्रोटोकॉल पर चल सकते हैं।

निम्नलिखित चित्रण में दर्शाया गया है कि एसआईपी चीजों की सामान्य योजना में कहां फिट बैठता है -

आमतौर पर, SIP प्रोटोकॉल का उपयोग इंटरनेट टेलीफोनी और मल्टीमीडिया वितरण के लिए दो या दो से अधिक समापन बिंदुओं के बीच किया जाता है। उदाहरण के लिए, एक व्यक्ति एसआईपी का उपयोग करके किसी अन्य व्यक्ति को एक टेलीफोन कॉल शुरू कर सकता है, या कोई व्यक्ति कई प्रतिभागियों के साथ एक सम्मेलन कॉल कर सकता है।

SIP प्रोटोकॉल को बहुत ही सरल बनाया गया था, जिसमें कमांड का एक सीमित सेट था। यह टेक्स्ट-आधारित भी है, इसलिए कोई भी SIP सत्र में समापन बिंदुओं के बीच पारित एक SIP संदेश पढ़ सकता है।

कुछ संस्थाएँ हैं जो SIP को अपना नेटवर्क बनाने में मदद करती हैं। एसआईपी में, प्रत्येक नेटवर्क तत्व को ए द्वारा पहचाना जाता हैSIP URI(यूनिफ़ॉर्म रिसोर्स आइडेंटिफ़ायर) जो एक पते की तरह है। निम्नलिखित नेटवर्क तत्व हैं -

• उपभोक्ता अभिकर्ता
• प्रतिनिधि सर्वर
• रजिस्ट्रार सर्वर
• पुनर्निर्देशित सर्वर
• स्थान सर्वर

उपभोक्ता अभिकर्ता

यह समापन बिंदु और SIP नेटवर्क के सबसे महत्वपूर्ण नेटवर्क तत्वों में से एक है। एक समापन बिंदु एक सत्र को आरंभ, संशोधित या समाप्त कर सकता है। उपयोगकर्ता एजेंट SIP नेटवर्क के सबसे बुद्धिमान उपकरण या नेटवर्क तत्व हैं। यह सॉफ्टफोन, मोबाइल या लैपटॉप हो सकता है।

उपयोगकर्ता एजेंट तार्किक रूप से दो भागों में विभाजित हैं -

• User Agent Client (UAC) - वह इकाई जो अनुरोध भेजती है और प्रतिक्रिया प्राप्त करती है।

• User Agent Server (UAS) - वह इकाई जो अनुरोध प्राप्त करती है और प्रतिक्रिया भेजती है।

एसआईपी क्लाइंट-सर्वर आर्किटेक्चर पर आधारित है, जहां कॉलर का फोन एक क्लाइंट के रूप में कार्य करता है, जो कॉल शुरू करता है और कैली का फोन सर्वर के रूप में कार्य करता है, जो कॉल का जवाब देता है।

प्रतिनिधि सर्वर

यह नेटवर्क तत्व है जो एक उपयोगकर्ता एजेंट से एक अनुरोध लेता है और इसे दूसरे उपयोगकर्ता को अग्रेषित करता है।

• मूल रूप से प्रॉक्सी सर्वर की भूमिका एक राउटर की तरह होती है।

• इसमें SIP अनुरोध को समझने और URI की मदद से आगे भेजने के लिए कुछ बुद्धिमत्ता है।

• एक प्रॉक्सी सर्वर दो उपयोगकर्ता एजेंटों के बीच बैठता है।

• एक स्रोत और एक गंतव्य के बीच अधिकतम 70 प्रॉक्सी सर्वर हो सकते हैं।

प्रॉक्सी सर्वर दो प्रकार के होते हैं -

• Stateless Proxy Server- यह प्राप्त संदेश को बस आगे की ओर। इस प्रकार का सर्वर कॉल या लेनदेन की किसी भी जानकारी को संग्रहीत नहीं करता है।

• Stateful Proxy Server- इस प्रकार का प्रॉक्सी सर्वर प्राप्त किए गए हर अनुरोध और प्रतिक्रिया पर नज़र रखता है और आवश्यकता पड़ने पर भविष्य में इसका उपयोग कर सकता है। यह अनुरोध को फिर से स्वीकार कर सकता है, अगर समय में दूसरी तरफ से कोई प्रतिक्रिया नहीं होती है।

रजिस्ट्रार सर्वर

रजिस्ट्रार सर्वर उपयोगकर्ता एजेंटों से पंजीकरण अनुरोध स्वीकार करता है। यह उपयोगकर्ताओं को नेटवर्क के भीतर खुद को प्रमाणित करने में मदद करता है। यह एक ही डोमेन के भीतर अन्य एसआईपी सर्वरों की मदद करने के लिए एक डेटाबेस में यूआरआई और उपयोगकर्ताओं के स्थान को संग्रहीत करता है।

निम्नलिखित उदाहरण पर एक नज़र डालें जो SIP पंजीकरण की प्रक्रिया को दर्शाता है।

यहां कॉलर TMC डोमेन के साथ पंजीकरण करना चाहता है। तो यह टीएमसी के रजिस्ट्रार सर्वर को एक रेजिस्टर अनुरोध भेजता है और क्लाइंट को अधिकृत करते हुए सर्वर 200 ओके प्रतिक्रिया देता है।

पुनर्निर्देशित सर्वर

पुनर्निर्देशित सर्वर अनुरोध प्राप्त करता है और रजिस्ट्रार द्वारा बनाए गए स्थान डेटाबेस में अनुरोध के प्राप्तकर्ता को देखता है।

रीडायरेक्ट सर्वर स्थान की जानकारी प्राप्त करने के लिए डेटाबेस का उपयोग करता है और उपयोगकर्ता को 3xx (रीडायरेक्ट प्रतिक्रिया) के साथ प्रतिक्रिया करता है। हम इस ट्यूटोरियल में बाद में प्रतिक्रिया कोड पर चर्चा करेंगे।

स्थान सर्वर

लोकेशन सर्वर किसी कॉलर के संभावित स्थानों के बारे में रीडायरेक्ट और प्रॉक्सी सर्वर को जानकारी प्रदान करता है।

केवल एक प्रॉक्सी सर्वर या रीडायरेक्ट सर्वर किसी लोकेशन सर्वर से संपर्क कर सकता है।

निम्न आंकड़ा एक सत्र की स्थापना में नेटवर्क तत्वों में से प्रत्येक द्वारा निभाई गई भूमिकाओं को दर्शाता है।

एसआईपी - सिस्टम आर्किटेक्चर

एसआईपी एक स्तरित प्रोटोकॉल के रूप में संरचित है, जिसका अर्थ है कि इसका व्यवहार प्रत्येक चरण के बीच केवल ढीले युग्मन के साथ काफी स्वतंत्र प्रसंस्करण चरणों के एक सेट के रूप में वर्णित है।

• एसआईपी की सबसे निचली परत इसकी है syntax and encoding। इसका एन्कोडिंग एक संवर्धित का उपयोग करके निर्दिष्ट किया गया हैBackus-Naur Form grammar (BNF)।

• दूसरे स्तर पर है transport layer। यह परिभाषित करता है कि कैसे एक ग्राहक अनुरोध भेजता है और प्रतिक्रियाएं प्राप्त करता है और कैसे एक सर्वर अनुरोध प्राप्त करता है और नेटवर्क पर प्रतिक्रिया भेजता है। सभी एसआईपी तत्वों में एक परिवहन परत होती है।

• इसके बाद आता है transaction layer। लेन-देन एक क्लाइंट ट्रांजेक्शन (ट्रांसपोर्ट लेयर का उपयोग करके) सर्वर ट्रांजेक्शन के लिए भेजा गया एक रिक्वेस्ट है, साथ ही सर्वर से ट्रांजेक्शन से भेजे गए उस रिक्वेस्ट पर सभी रिस्पॉन्स के साथ। उपयोगकर्ता एजेंट क्लाइंट (UAC) को पूरा करने वाला कोई भी कार्य लेनदेन की एक श्रृंखला का उपयोग करके होता है।Stateless proxies लेन-देन परत नहीं है।

• के ऊपर की परत transaction layerलेन-देन उपयोगकर्ता कहा जाता है। एसआईपी संस्थाओं में से प्रत्येक को छोड़करStateless proxies, एक लेन-देन उपयोगकर्ता है।

निम्नलिखित छवि एक एसआईपी सत्र के मूल कॉल प्रवाह को दर्शाती है।

नीचे दिए गए कॉल प्रवाह का चरण-दर-चरण स्पष्टीकरण दिया गया है -

• किसी सत्र सर्वर को भेजने के लिए किसी प्रॉक्सी सर्वर को भेजा गया एक INVITE अनुरोध।

• प्रॉक्सी सर्वर सेंड करता है 100 Trying INVITE अनुरोध के पुन: प्रसारण को रोकने के लिए कॉलर (एलिस) को तुरंत प्रतिक्रिया दें।

• प्रॉक्सी सर्वर लोकेशन सर्वर में बॉब का पता खोजता है। पता मिलने के बाद, यह आगे अनुरोध को आगे बढ़ाता है।

• इसके बाद, 180 Ringing बॉब द्वारा उत्पन्न (अनंतिम प्रतिक्रियाएं) ऐलिस में वापस आ गया है।

• ए 200 OK बॉब फोन उठाते ही प्रतिक्रिया उत्पन्न होती है।

• बॉब एक ​​प्राप्त करता है ACK ऐलिस से, एक बार यह हो जाता है 200 OK।

• उसी समय, सत्र स्थापित हो जाता है और आरटीपी पैकेट (वार्तालाप) दोनों सिरों से बहने लगते हैं।

• बातचीत के बाद, कोई भी प्रतिभागी (एलिस या बॉब) ए भेज सकता है BYE सत्र समाप्त करने का अनुरोध।

• BYE प्रॉक्सी सर्वर को दरकिनार करके ऐलिस से बॉब तक सीधे पहुंचता है।

• अंत में, बॉब एक ​​भेजता है 200 OK BYE और सत्र की पुष्टि करने के लिए प्रतिक्रिया समाप्त हो गई है।

• उपरोक्त बुनियादी कॉल प्रवाह में, तीन transactions उपलब्ध हैं (1, 2, 3 के रूप में चिह्नित)।

पूर्ण कॉल (INVITE से 200 ओके तक) के रूप में जाना जाता है Dialog।

एसआईपी ट्रेपोजॉइड

एक उपयोगकर्ता को दूसरे के साथ जोड़ने के लिए प्रॉक्सी कैसे मदद करता है? आइए हम निम्नलिखित आरेख की सहायता से पता करते हैं।

आरेख में दिखाया गया टोपोलॉजी एक एसआईपी ट्रेपेज़ॉइड के रूप में जाना जाता है। प्रक्रिया निम्नानुसार होती है -

• जब एक कॉलर एक कॉल शुरू करता है, तो एक INVITE संदेश प्रॉक्सी सर्वर को भेजा जाता है। INVITE प्राप्त करने पर, प्रॉक्सी सर्वर DNS सर्वर की मदद से कैली के पते को हल करने का प्रयास करता है।

• अगला मार्ग प्राप्त करने के बाद, कॉलर के प्रॉक्सी सर्वर (प्रॉक्सी 1, जिसे आउटबाउंड प्रॉक्सी सर्वर के रूप में भी जाना जाता है) को कॉल्ली के प्रॉक्सी सर्वर के लिए इनवाईट अनुरोध के लिए भेजा जाता है, जो कि कॉल्ली के लिए इनबाउंड प्रॉक्सी सर्वर (प्रॉक्सी 2) के रूप में कार्य करता है।

• इनबाउंड प्रॉक्सी सर्वर उस स्थान सर्वर से संपर्क करता है जहां उपयोगकर्ता पंजीकृत होने के बारे में जानकारी प्राप्त करता है।

• लोकेशन सर्वर से जानकारी प्राप्त करने के बाद, वह कॉल को अपने गंतव्य पर भेज देता है।

• एक बार जब उपयोगकर्ता एजेंटों को अपना पता पता हो जाता है, तो वे कॉल को बायपास कर सकते हैं, अर्थात, वार्तालाप सीधे पास होते हैं।

SIP संदेश दो प्रकार के होते हैं - requests तथा responses।

• अनुरोध की प्रारंभिक पंक्ति में एक तरीका है जो अनुरोध को परिभाषित करता है, और एक अनुरोध-यूआरआई जो परिभाषित करता है कि अनुरोध कहां भेजा जाना है।

• इसी तरह, एक प्रतिक्रिया की प्रारंभिक पंक्ति में एक प्रतिक्रिया कोड होता है।

अनुरोध के तरीके

SIP requestsसंचार स्थापित करने के लिए उपयोग किए जाने वाले कोड हैं। उन्हें पूरक करने के लिए, वहाँ हैंSIP responses आमतौर पर संकेत मिलता है कि अनुरोध सफल हुआ या विफल।

ये SIP अनुरोध जिन्हें METHODS के रूप में जाना जाता है, SIP संदेश को काम करने योग्य बनाते हैं।

• METHODS को SIP अनुरोध माना जा सकता है, क्योंकि वे किसी अन्य उपयोगकर्ता एजेंट या सर्वर द्वारा की जाने वाली विशिष्ट कार्रवाई का अनुरोध करते हैं।

• METHODS को दो प्रकारों में विभक्त किया जाता है -

  • कोर तरीके

  • एक्सटेंशन के तरीके

कोर तरीके

नीचे चर्चा की गई छह मुख्य विधियाँ हैं।

आमंत्रित

उपयोगकर्ता एजेंट के साथ सत्र आरंभ करने के लिए INVITE का उपयोग किया जाता है। दूसरे शब्दों में, उपयोगकर्ता एजेंटों के बीच एक मीडिया सत्र स्थापित करने के लिए एक INVITE विधि का उपयोग किया जाता है।

• INVITE में मैसेज बॉडी में कॉलर की मीडिया जानकारी हो सकती है।

• एक सत्र स्थापित माना जाता है अगर किसी INVITE को सफलता की प्रतिक्रिया (2xx) मिली है या ACK भेजा गया है।



• एक सफल निवेश अनुरोध एक स्थापित करता है dialog सत्र समाप्त करने के लिए एक BYE भेजे जाने तक दो उपयोगकर्ता एजेंटों के बीच जारी रहता है।

• एक स्थापित संवाद के भीतर भेजे गए एक INVITE को a के रूप में जाना जाता है re-INVITE।

• Re-INVITE का उपयोग सत्र विशेषताओं को बदलने या संवाद की स्थिति को ताज़ा करने के लिए किया जाता है।

उदाहरण के लिए आमंत्रित करें

निम्न कोड दिखाता है कि कैसे INVITE का उपयोग किया जाता है।

INVITE sips:[email protected] SIP/2.0 
   Via: SIP/2.0/TLS client.ANC.com:5061;branch = z9hG4bK74bf9 
   Max-Forwards: 70 
   From: Alice<sips:[email protected]>;tag = 1234567 
   To: Bob<sips:[email protected]>
   Call-ID: [email protected]  
   CSeq: 1 INVITE 
   Contact: <sips:[email protected]> 
   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 
   Supported: replaces 
   Content-Type: application/sdp 
   Content-Length: ...  
   
   v = 0 
   o = Alice 2890844526 2890844526 IN IP4 client.ANC.com 
   s = Session SDP 
   c = IN IP4 client.ANC.com 
   t = 3034423619 0 
   m = audio 49170 RTP/AVP 0 
   a = rtpmap:0 PCMU/8000

अलविदा

BYE एक स्थापित सत्र को समाप्त करने के लिए उपयोग की जाने वाली विधि है। यह एक एसआईपी अनुरोध है जिसे किसी सत्र को समाप्त करने के लिए कॉलर या कैली द्वारा भेजा जा सकता है।

• इसे प्रॉक्सी सर्वर द्वारा नहीं भेजा जा सकता है।

• BYE अनुरोध सामान्य रूप से अंत तक समाप्त होता है, प्रॉक्सी सर्वर को दरकिनार करता है।

• BYE को लंबित किसी INVITE या अनइंस्टॉल किए गए सत्र में नहीं भेजा जा सकता है।

रजिस्टर करें

REGISTER अनुरोध उपयोगकर्ता एजेंट का पंजीकरण करता है। यह अनुरोध उपयोगकर्ता एजेंट द्वारा एक रजिस्ट्रार सर्वर को भेजा जाता है।

• जब तक यह निर्दिष्ट डोमेन के एक आधिकारिक रजिस्ट्रार तक नहीं पहुंचता, तब तक अनुरोध को अग्रेषित या अनुमानित किया जा सकता है।

• इसमें AOR (रिकॉर्ड का पता) होता है To उस उपयोगकर्ता का शीर्षक जो पंजीकृत किया जा रहा है।

• REGISTER अनुरोध में समयावधि (3600 वर्ग सेकंड) शामिल है।

• एक उपयोगकर्ता एजेंट दूसरे उपयोगकर्ता एजेंट की ओर से REGISTER अनुरोध भेज सकता है। इस रूप में जाना जाता हैthird-party registration। यहां हीFrom टैग में पार्टी का यूआरआई होता है जो उस पार्टी की ओर से पंजीकरण प्रस्तुत करता है जिसकी पहचान की जाती है To हैडर।

रद्द करना

CANCEL का उपयोग उस सत्र को समाप्त करने के लिए किया जाता है जो स्थापित नहीं है। उपयोगकर्ता एजेंट पहले से शुरू किए गए एक लंबित कॉल प्रयास को रद्द करने के लिए इस अनुरोध का उपयोग करते हैं।

• इसे यूजर एजेंट या प्रॉक्सी सर्वर द्वारा भेजा जा सकता है।

• CANCEL एक है hop by hop अनुरोध, यानी, यह उपयोगकर्ता एजेंट के बीच तत्वों के माध्यम से जाता है और अगले राज्य तत्व द्वारा उत्पन्न प्रतिक्रिया प्राप्त करता है।

एसीके

ACK का उपयोग INVITE विधि के लिए अंतिम प्रतिक्रियाओं को स्वीकार करने के लिए किया जाता है। एक ACK हमेशा INVITE.ACK की दिशा में जाता है, इसमें SDP बॉडी (मीडिया विशेषताएँ) हो सकती हैं, अगर यह INVITE में उपलब्ध नहीं है।

• ACK का उपयोग उन मीडिया विवरण को संशोधित करने के लिए नहीं किया जा सकता है जो पहले से ही प्रारंभिक INVITE में भेजे गए हैं।

• ACK को प्राप्त करने वाला एक स्टेटिक प्रॉक्सी यह निर्धारित करना चाहिए कि ACK को किसी अन्य प्रॉक्सी या उपयोगकर्ता एजेंट के लिए डाउनस्ट्रीम भेजा जाना चाहिए या नहीं।

• 2xx प्रतिक्रियाओं के लिए, ACK अंत से अंत तक है, लेकिन अन्य सभी अंतिम प्रतिक्रियाओं के लिए, यह आशा के आधार पर आशा के आधार पर काम करता है जब स्टेटफुल प्रॉक्सी शामिल होते हैं।

विकल्प

विकल्प विधि का उपयोग किसी उपयोगकर्ता एजेंट या प्रॉक्सी सर्वर को उसकी क्षमताओं के बारे में बताने और उसकी वर्तमान उपलब्धता की खोज करने के लिए किया जाता है। अनुरोध की प्रतिक्रिया उपयोगकर्ता एजेंट या सर्वर की क्षमताओं को सूचीबद्ध करती है। एक प्रॉक्सी कभी भी एक विकल्प अनुरोध उत्पन्न नहीं करता है।

एक्सटेंशन के तरीके

सदस्यता लेने के

SUBSCRIBE का उपयोग उपयोगकर्ता एजेंटों द्वारा किसी विशेष घटना के बारे में सूचना प्राप्त करने के उद्देश्य से सदस्यता स्थापित करने के लिए किया जाता है।

• इसमें ए Expires हेडर फ़ील्ड जो किसी सदस्यता की अवधि को इंगित करता है।

• समय अवधि बीतने के बाद, सदस्यता स्वतः समाप्त हो जाएगी।

• सदस्यता उपयोगकर्ता एजेंटों के बीच एक संवाद स्थापित करती है।

• आप समाप्ति समय से पहले संवाद के भीतर एक और SUBSCRIBE भेजकर फिर से सदस्यता ले सकते हैं।

• उपयोगकर्ता से सदस्यता के लिए 200 ओके प्राप्त किया जाएगा।

• उपयोगकर्ता एक्सपायर वैल्यू 0 (शून्य) के साथ एक और SUBSCRIBE विधि भेजकर सदस्यता समाप्त कर सकते हैं।

सूचित करें

NOTIFY का उपयोग उपयोगकर्ता एजेंटों द्वारा किसी विशेष घटना की घटना को प्राप्त करने के लिए किया जाता है। आमतौर पर एक NOTIFY एक डायलॉग के भीतर ट्रिगर हो जाता है जब सब्सक्राइबर और नोटिफ़ायर के बीच कोई सब्सक्रिप्शन मौजूद होता है।

• अगर नोटिफ़ायर मिलता है तो हर NOTIFY को 200 ओके रिस्पॉन्स मिलेगा।

• NOTIFY में a Event हेडर फ़ील्ड घटना और एक का संकेत है subscriptionstate हेडर फ़ील्ड सदस्यता की वर्तमान स्थिति को दर्शाता है।

• एक सदस्यता की शुरुआत और समाप्ति पर एक NOTIFY हमेशा भेजा जाता है।

प्रकाशित

PUBLISH का उपयोग उपयोगकर्ता एजेंट द्वारा ईवेंट स्थिति की जानकारी सर्वर पर भेजने के लिए किया जाता है।

• सार्वजनिक जानकारी के कई स्रोत होने पर सार्वजनिक रूप से उपयोगी होता है।

• एक सार्वजनिक अनुरोध एक सूचना के समान है, सिवाय इसके कि यह एक संवाद में नहीं भेजा गया है।

• एक सार्वजनिक अनुरोध में एक होना चाहिए Expires हेडर फील्ड और ए Min-Expires हेडर फ़ील्ड।

संदर्भ लें

REFER का उपयोग उपयोगकर्ता एजेंट द्वारा संवाद के लिए URI तक पहुँचने के लिए किसी अन्य उपयोगकर्ता एजेंट को संदर्भित करने के लिए किया जाता है।

• संदर्भ में एक होना चाहिए Refer-Toहैडर। यह REFER के लिए एक अनिवार्य हैडर है।

• REFER को एक संवाद के अंदर या बाहर भेजा जा सकता है।

• ए 202 Accepted एक REFER अनुरोध को ट्रिगर करेगा जो इंगित करता है कि अन्य उपयोगकर्ता एजेंट ने संदर्भ को स्वीकार किया है।

जानकारी

INFO का उपयोग उपयोगकर्ता एजेंट द्वारा कॉल सिग्नलिंग जानकारी को किसी अन्य उपयोगकर्ता एजेंट को भेजने के लिए किया जाता है जिसके साथ उसने एक मीडिया सत्र स्थापित किया है।

• यह एंड-टू-एंड अनुरोध है।

• एक प्रॉक्सी हमेशा एक INFO अनुरोध को आगे बढ़ाएगा।

अपडेट करें

यदि किसी सत्र की स्थापना नहीं होती है, तो UPDATE का उपयोग सत्र की स्थिति को संशोधित करने के लिए किया जाता है। उपयोगकर्ता कोडेक को अद्यतन कर सकता है।

यदि कोई सत्र स्थापित है, तो सत्र को बदलने / अद्यतन करने के लिए एक पुन: आमंत्रित किया जाता है।

PRACK

PRACK का उपयोग अनंतिम प्रतिक्रिया (1XX) के एक विश्वसनीय हस्तांतरण की प्राप्ति को स्वीकार करने के लिए किया जाता है।

• आम तौर पर PRACK एक क्लाइंट द्वारा जेनरेट किया जाता है जब उसे अनंतिम प्रतिक्रिया मिलती है RSeq विश्वसनीय अनुक्रम संख्या और ए supported:100rel हैडर।

• PRACK में (RSeq + CSeq) मान समाहित है rack हैडर।

• PRACK मेथड 100 Trying response को छोड़कर सभी अनंतिम प्रतिक्रियाओं पर लागू होता है, जिसे कभी भी विश्वसनीय तरीके से परिवहन नहीं किया जाता है।

• एक संदेश में एक संदेश शामिल हो सकता है; इसका उपयोग ऑफ़र / उत्तर एक्सचेंज के लिए किया जा सकता है।

संदेश

इसका उपयोग एसआईपी का उपयोग करके एक त्वरित संदेश भेजने के लिए किया जाता है। एक IM आम तौर पर पाठ वार्तालाप में लगे प्रतिभागियों द्वारा वास्तविक समय में आदान-प्रदान किए गए छोटे संदेश होते हैं।

• संदेश को संवाद के भीतर या संवाद के बाहर भेजा जा सकता है।

• संदेश में निकाय की सामग्री को संदेश के रूप में ले जाया जाता है MIME लगाव।

• ए 200 OK प्रतिक्रिया आम तौर पर यह इंगित करने के लिए प्राप्त होती है कि संदेश अपने गंतव्य पर वितरित किया गया है।

एसआईपी प्रतिक्रिया एक संदेश है जो एक उपयोगकर्ता एजेंट सर्वर (यूएएस) या एसआईपी सर्वर द्वारा क्लाइंट द्वारा उत्पन्न अनुरोध का जवाब देने के लिए उत्पन्न होता है। यह एक UAC द्वारा अनुरोधों के पुन: प्रसारण को रोकने के लिए एक औपचारिक स्वीकृति हो सकती है।

• प्रतिक्रिया में UAC द्वारा आवश्यक जानकारी के कुछ अतिरिक्त हेडर फ़ील्ड हो सकते हैं।

• एसआईपी में छह प्रतिक्रियाएं हैं।

• 1xx से 5xx को HTTP से उधार लिया गया है और 6xx को SIP में पेश किया गया है।

• 1xx एक माना जाता है provisional प्रतिक्रिया और बाकी हैं final प्रतिक्रियाओं।

क्र.सं.	समारोह विवरण
1	1xx: अनंतिम / सूचनात्मक प्रतिक्रियाएं संकेत करने के लिए सूचनात्मक प्रतिक्रियाओं का उपयोग किया जाता है call progress। आम तौर पर प्रतिक्रियाएं समाप्त होती हैं (100 कोशिश को छोड़कर)।
2	2xx: सफलता के जवाब प्रतिक्रियाओं का यह वर्ग संकेत देने के लिए है कि अनुरोध स्वीकार कर लिया गया है।
3	3xx: पुनर्निर्देशन प्रतिक्रियाएँ आम तौर पर इन वर्ग प्रतिक्रियाओं को INVITE के जवाब में पुनर्निर्देशित सर्वरों द्वारा भेजा जाता है। उन्हें पुनर्निर्देशित वर्ग प्रतिक्रियाओं के रूप में भी जाना जाता है।
4	4xx: क्लाइंट विफलता प्रतिक्रियाएँ क्लाइंट त्रुटि प्रतिक्रियाओं से संकेत मिलता है कि अनुरोध पूरा नहीं किया जा सकता है क्योंकि UAC की ओर से कुछ त्रुटियों की पहचान की गई है।
5	5xx: सर्वर विफलता प्रतिक्रिया इस वर्ग की प्रतिक्रिया का उपयोग यह इंगित करने के लिए किया जाता है कि सर्वर के साथ त्रुटि के कारण अनुरोध को संसाधित नहीं किया जा सकता है।
6	6xx: ग्लोबल फेल्योर रिस्पांस यह प्रतिक्रिया वर्ग इंगित करता है कि सर्वर जानता है कि अनुरोध को विफल कर दिया जाएगा जहाँ भी इसे आज़माया जाएगा। परिणामस्वरूप, अनुरोध को अन्य स्थानों पर नहीं भेजा जाना चाहिए।

हेडर एक एसआईपी संदेश का एक घटक है जो संदेश के बारे में जानकारी देता है। यह शीर्ष लेख फ़ील्ड के अनुक्रम के रूप में संरचित है।

ज्यादातर मामलों में SIP हेडर फ़ील्ड HTTP हेडर फ़ील्ड के समान नियमों का पालन करते हैं। हैडर फ़ील्ड के रूप में परिभाषित किया गया हैHeader: field, जहां हेडर का उपयोग हेडर फ़ील्ड नाम का प्रतिनिधित्व करने के लिए किया जाता है, और फ़ील्ड टोकन का सेट होता है जिसमें जानकारी होती है। प्रत्येक फ़ील्ड में एक बृहदान्त्र (":") और फ़ील्ड-मान (अर्थात) के बाद फ़ील्ड नाम शामिल होता हैfield-name: field-value)।

एसआईपी हेडर्स - कॉम्पैक्ट फॉर्म

कई सामान्य SIP हेडर फ़ील्ड में एक संक्षिप्त रूप होता है, जहाँ हेडर फ़ील्ड का नाम एक एकल लोअर केस वर्ण द्वारा दर्शाया जाता है। कुछ उदाहरण नीचे दिए गए हैं -

हैडर	कॉम्पैक्ट फॉर्म
सेवा	टी
के जरिए	वी
कॉल-आईडी	मैं
संपर्क करें	म
से	एफ
विषय	रों
कंटेंट की लम्बाई	मैं

SIP हैडर प्रारूप

निम्न छवि एक विशिष्ट एसआईपी हेडर की संरचना को दिखाती है।

एसआईपी में उनके उपयोग के आधार पर हेडर्स को निम्नानुसार वर्गीकृत किया गया है -

• अनुरोध और प्रतिक्रिया
• केवल अनुरोध करें
• केवल प्रतिक्रिया
• संदेश का मुख्य हिस्सा

एसडीपी का अर्थ सत्र वर्णन प्रोटोकॉल है। इसका उपयोग किसी नेटवर्क पर प्रतिभागियों द्वारा समझे गए प्रारूप में मल्टीमीडिया सत्रों का वर्णन करने के लिए किया जाता है। इस विवरण के आधार पर, एक पार्टी यह तय करती है कि सम्मेलन में शामिल होना है या सम्मेलन में कब या कैसे शामिल होना है।

• एक सम्मेलन का मालिक मल्टीकास्ट संदेश भेजकर नेटवर्क पर इसका विज्ञापन करता है जिसमें सत्र का वर्णन होता है जैसे कि मालिक का नाम, सत्र का नाम, कोडिंग, समय आदि। इन सूचनाओं के आधार पर, विज्ञापन के प्राप्तकर्ता। सत्र में भागीदारी के बारे में निर्णय लें।

• एसडीपी को आम तौर पर सत्र पहल प्रोटोकॉल के शरीर के अंग में शामिल किया जाता है जिसे लोकप्रिय रूप से एसआईपी कहा जाता है।

• एसडीपी को RFC 2327 में परिभाषित किया गया है। एक एसडीपी संदेश लाइनों की एक श्रृंखला से बना है, जिसे फ़ील्ड्स कहा जाता है, जिनके नाम एकल लोअर केस लेटर द्वारा संक्षिप्त किए गए हैं, और पार्सिंग को सरल बनाने के लिए एक आवश्यक क्रम में हैं।

एसडीपी का उद्देश्य

SDP का उद्देश्य प्रतिभागियों को किसी विशेष सत्र की जानकारी में शामिल होने या इकट्ठा करने में मदद करने के लिए मल्टीमीडिया सत्रों में मीडिया धाराओं के बारे में जानकारी देना है।

• एसडीपी एक संक्षिप्त संरचित पाठ्य विवरण है।

• यह सत्र, मीडिया, प्रोटोकॉल, कोडेक प्रारूप, समय और परिवहन जानकारी के नाम और उद्देश्य को बताता है।

• एक अस्थायी प्रतिभागी इन सूचनाओं की जांच करता है और यह तय करता है कि क्या एक सत्र में शामिल होना है और एक सत्र में कैसे और कब शामिल होना है यदि वह ऐसा करने का निर्णय लेता है।

• प्रारूप में <टाइप> = <value> के रूप में प्रविष्टियां हैं, जहां <टाइप> एक अद्वितीय सत्र पैरामीटर को परिभाषित करता है और <value> उस पैरामीटर के लिए एक विशिष्ट मूल्य प्रदान करता है।

• एसडीपी संदेश का सामान्य रूप है -

  x = parameter1 parameter2 ... parameterN

• लाइन एक एकल लोअर-केस पत्र से शुरू होती है, उदाहरण के लिए, एक्स। अक्षर और = के बीच कोई रिक्त स्थान नहीं हैं, और प्रत्येक पैरामीटर के बीच बिल्कुल एक स्थान है। प्रत्येक क्षेत्र में मापदंडों की एक निर्धारित संख्या होती है।

सत्र विवरण पैरामीटर

सत्र विवरण (* वैकल्पिक को दर्शाता है)

• v = (प्रोटोकॉल संस्करण)
• ओ = (मालिक / निर्माता और सत्र पहचानकर्ता)
• s = (सत्र का नाम)
• मैं = * (सत्र जानकारी)
• यू = * (विवरण का यूआरआई)
• ई = * (ईमेल पता)
• p = * (फ़ोन नंबर)
• c = * (कनेक्शन की जानकारी - सभी मीडिया में शामिल होने की आवश्यकता नहीं है)
• b = * (बैंडविड्थ की जानकारी)
• z = * (समय क्षेत्र समायोजन)
• k = * (एन्क्रिप्शन कुंजी)
• a = * (शून्य या अधिक सत्र विशेषता लाइनें)

प्रोटोकॉल संस्करण

V = फ़ील्ड में SDP संस्करण संख्या होती है। क्योंकि SDP का वर्तमान संस्करण 0 है, एक मान्य SDP संदेश हमेशा v = 0 से शुरू होगा।

मूल

O = फ़ील्ड में सत्र और सत्र पहचानकर्ताओं के प्रवर्तक के बारे में जानकारी होती है। इस क्षेत्र का उपयोग सत्र को विशिष्ट रूप से पहचानने के लिए किया जाता है।

• फ़ील्ड में शामिल हैं -

  ओ = <उपयोगकर्ता नाम> <सत्र-आईडी> <version> <नेटवर्क प्रकार> <पते के प्रकार>

• username पैरामीटर में प्रवर्तक का लॉगिन या होस्ट होता है।

• session-id पैरामीटर एक नेटवर्क टाइम प्रोटोकॉल (NTP) टाइमस्टैम्प या एक यादृच्छिक संख्या है जिसका उपयोग विशिष्टता सुनिश्चित करने के लिए किया जाता है।

• version एक संख्यात्मक क्षेत्र है जिसे सत्र में प्रत्येक परिवर्तन के लिए बढ़ाया जाता है, जिसे NTP टाइमस्टैम्प होने की भी सिफारिश की जाती है।

• network-typeहमेशा इंटरनेट के लिए है। पता-प्रकार का पैरामीटर या तो IP4 या IPv4 के लिए IP6 या IPv6 पते के लिए या तो बिंदीदार दशमलव रूप में या पूरी तरह से होस्ट किया गया नाम है।

सत्र का नाम और सूचना

S = फ़ील्ड में सत्र के लिए एक नाम होता है। इसमें किसी भी गैर-वर्ण की संख्या हो सकती है। वैकल्पिक i = फ़ील्ड में सत्र के बारे में जानकारी होती है। इसमें कोई भी वर्ण हो सकते हैं।

यूआरआई

वैकल्पिक यू = फ़ील्ड में सत्र के बारे में अधिक जानकारी के साथ एक समान संसाधन संकेतक (URI) होता है

ई-मेल पता और फोन नंबर

वैकल्पिक ई = फ़ील्ड में सत्र के होस्ट का ई-मेल पता होता है। वैकल्पिक पी = फ़ील्ड में एक फ़ोन नंबर होता है।

कनेक्शन डेटा

सी = फ़ील्ड में मीडिया कनेक्शन के बारे में जानकारी शामिल है।

• फ़ील्ड में शामिल हैं -

  c = <नेटवर्क-प्रकार> <पता-प्रकार> <कनेक्शन-पता>

• network-type पैरामीटर को इंटरनेट के लिए IN के रूप में परिभाषित किया गया है।

• address-type IPv4 पतों और IP6 IPv6 पतों के लिए IP4 के रूप में परिभाषित किया गया है।

• connection-address आईपी ​​एड्रेस या होस्ट है जो मीडिया पैकेट भेज रहा होगा, जो मल्टीकास्ट या यूनिकस्ट हो सकता है।

• यदि मल्टीकास्ट, कनेक्शन-पता फ़ील्ड में शामिल है -

  कनेक्शन-पता = आधार-मल्टीकास्ट-पता / टीटीएल / संख्या के- पतों

कहाँ पे ttl समय-टू-लाइव मान है, और संख्या-के-पते यह इंगित करते हैं कि आधार-मल्टीकास्ट पते के साथ कितने प्रासंगिक मल्टीकास्ट पते शामिल हैं।

बैंडविड्थ

वैकल्पिक b = फ़ील्ड में आवश्यक बैंडविड्थ के बारे में जानकारी होती है। यह फार्म का है -

बी = संशोधक: बैंडविड्थ - मूल्य

टाइम, रिपीट टाइम्स और टाइम जोन

T = फ़ील्ड में सत्र का प्रारंभ समय और स्टॉप समय होता है।

t = स्टार्ट-टाइम स्टॉप-टाइम

वैकल्पिक आर = फ़ील्ड में बार-बार एनटीपी या दिनों ( डी ), घंटे ( एच ), या मिनट ( एम ) में निर्दिष्ट किया जा सकता है ।

वैकल्पिक z = फ़ील्ड में समय क्षेत्र ऑफसेट के बारे में जानकारी होती है। यदि यह सत्र हो रहा है तो इस क्षेत्र का उपयोग दिन के उजाले की बचत से लेकर मानक समय या इसके विपरीत तक के बदलाव के लिए किया जाता है।

मीडिया घोषणाएँ

वैकल्पिक m = फ़ील्ड में मीडिया सत्र के प्रकार के बारे में जानकारी होती है। फ़ील्ड में शामिल हैं -

m = मीडिया पोर्ट ट्रांसपोर्ट प्रारूप-सूची

• मीडिया पैरामीटर या तो ऑडियो, वीडियो, टेक्स्ट, एप्लिकेशन, संदेश, छवि या नियंत्रण है। पोर्ट पैरामीटर में पोर्ट नंबर होता है।

• ट्रांसपोर्ट पैरामीटर में ट्रांसपोर्ट प्रोटोकॉल या RTP प्रोफाइल का उपयोग किया जाता है।

• प्रारूप-सूची में मीडिया के बारे में अधिक जानकारी है। आमतौर पर, इसमें RTP ऑडियो वीडियो प्रोफाइल में परिभाषित मीडिया पेलोड प्रकार होते हैं।

Example:
m = audio 49430 RTP/AVP 0 6 8 99

इन तीन कोडेक्स में से एक का उपयोग ऑडियो मीडिया सत्र के लिए किया जा सकता है। यदि तीन ऑडियो चैनल स्थापित करने का इरादा है, तो तीन अलग-अलग मीडिया क्षेत्रों का उपयोग किया जाएगा।

गुण

वैकल्पिक a = फ़ील्ड में पूर्ववर्ती मीडिया सत्र की विशेषताएँ होती हैं। इस फ़ील्ड का उपयोग किया जा सकता हैextend SDP to provide more information about the media। यदि एसडीपी उपयोगकर्ता द्वारा पूरी तरह से समझा नहीं गया है, तो विशेषता क्षेत्र को अनदेखा किया जा सकता है। मीडिया क्षेत्र में सूचीबद्ध प्रत्येक मीडिया पेलोड प्रकार के लिए एक या अधिक विशेषता फ़ील्ड हो सकते हैं।

एसडीपी में विशेषताएँ या तो हो सकती हैं

• सत्र स्तर, या
• मीडिया स्तर।

सत्र स्तर का मतलब है कि विशेषता को एसडीपी में पहली मीडिया लाइन से पहले सूचीबद्ध किया गया है। यदि यह मामला है, तो विशेषता इसके नीचे सभी मीडिया लाइनों पर लागू होती है।

मीडिया स्तर का मतलब है कि यह मीडिया लाइन के बाद सूचीबद्ध है। इस स्थिति में, विशेषता केवल इस विशेष मीडिया स्ट्रीम पर लागू होती है।

SDP में सत्र स्तर और मीडिया स्तर विशेषताएँ दोनों शामिल हो सकते हैं। यदि समान विशेषता दोनों के रूप में प्रकट होती है, तो मीडिया स्तर विशेषता उस विशेष मीडिया स्ट्रीम के लिए सत्र स्तर विशेषता को ओवरराइड करती है। ध्यान दें कि कनेक्शन डेटा फ़ील्ड या तो सत्र स्तर या मीडिया स्तर भी हो सकता है।

एक एसडीपी उदाहरण

नीचे एक उदाहरण सत्र विवरण दिया गया है, जिसे RFC 2327 से लिया गया है -

v = 0
o = mhandley2890844526 2890842807 IN IP4 126.16.64.4
s = SDP Seminar
i = A Seminar on the session description protocol
u = http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e = [email protected](Mark Handley)
c = IN IP4 224.2.17.12/127
t = 2873397496 2873404696
a = recvonly
m = audio 49170 RTP/AVP 0
m = video 51372 RTP/AVP 31
m = application 32416udp wb
a = orient:portrait

SIP के साथ SDP का उपयोग SDP प्रस्ताव उत्तर RFC 3264 में दिया गया है। SIP में डिफ़ॉल्ट संदेश निकाय प्रकार है application/sdp।

• कॉलिंग पार्टी उन मीडिया क्षमताओं को सूचीबद्ध करती है जिन्हें वे एसडीपी में प्राप्त करने के लिए तैयार हैं, आमतौर पर या तो इन्विट में या एसीके में।

• आमंत्रित पार्टी 200 ठीक प्रतिक्रिया के लिए अपनी मीडिया क्षमताओं को सूचीबद्ध करती है।

एसडीपी के एक विशिष्ट एसआईपी उपयोग में निम्नलिखित क्षेत्र शामिल हैं: संस्करण, मूल, विषय, समय, कनेक्शन, और एक या अधिक मीडिया और विशेषता।

• विषय और समय क्षेत्र SIP द्वारा उपयोग नहीं किए जाते हैं, लेकिन संगतता के लिए शामिल हैं।

• एसडीपी मानक में, विषय क्षेत्र एक आवश्यक क्षेत्र है और इसमें कम से कम एक वर्ण होना चाहिए, जिसमें कोई विषय नहीं होने पर s = - का सुझाव दिया गया हो।

• समय क्षेत्र आमतौर पर t = 00 पर सेट किया जाता है। SIP कनेक्शन, मीडिया और विशेषता फ़ील्ड का उपयोग करता है जो यूएएस के बीच सत्र सेट करता है।

• मूल क्षेत्र का एसआईपी के साथ सीमित उपयोग है।

• सत्र-आईडी को आमतौर पर SIP सत्र के दौरान स्थिर रखा जाता है।

• एसडीपी बदले जाने पर हर बार संस्करण में वृद्धि की जाती है। यदि भेजा जा रहा SDP पहले भेजे गए से अपरिवर्तित है, तो संस्करण समान रखा जाता है।

• जैसा कि मीडिया सत्र के प्रकार और उपयोग किए जाने वाले कोडेक कनेक्शन बातचीत का हिस्सा हैं, एसआईपी कई वैकल्पिक मीडिया प्रकारों को निर्दिष्ट करने और उन मीडिया प्रकारों को चुनिंदा रूप से स्वीकार करने या अस्वीकार करने के लिए एसडीपी का उपयोग कर सकता है।

ऑफ़र / उत्तर विनिर्देश, RFC 3264, यह अनुशंसा करता है कि एक विशेषता = rtpmap: प्रत्येक मीडिया फ़ील्ड के लिए उपयोग किया जाए। एसडीपी प्रतिक्रिया में संबंधित मीडिया क्षेत्र के लिए पोर्ट संख्या को शून्य पर सेट करके एक मीडिया स्ट्रीम को अस्वीकार कर दिया जाता है।

उदाहरण

निम्न उदाहरण में, कॉल करने वाला टेस्ला दो संभावित ऑडियो कोडेक्स के साथ एक ऑडियो और वीडियो कॉल स्थापित करना चाहता है और शुरुआती इनवॉइस में किए गए एसडीपी में एक वीडियो कोडेक -

v = 0 
o = John 0844526 2890844526 IN IP4 172.22.1.102  
s = - 
c = IN IP4 172.22.1.102 
t = 0 0 
m = audio 6000 RTP/AVP 97 98 
a = rtpmap:97 AMR/16000/1 
a = rtpmap:98 AMR-WB/8000/1 
m = video 49172 RTP/AVP 32 
a = rtpmap:32 MPV/90000

कोडेक्स को RTP / AVP प्रोफ़ाइल संख्या 97, 98 द्वारा संदर्भित किया जाता है।

कॉल पार्टी मैरी कॉल का जवाब देती है, पहले मीडिया क्षेत्र के लिए दूसरा कोडेक चुनती है, और दूसरे मीडिया क्षेत्र को केवल एमएमआई सत्र के लिए इच्छुक है।

v = 0 
o = Marry 2890844526 2890844526 IN IP4 172.22.1.110 
s = - 
c = IN IP4 200.201.202.203 
t = 0 0 
m = audio 60000 RTP/AVP 8 
a = rtpmap:97 AMR/16000 
m = video 0 RTP/AVP 32

यदि यह ऑडियो-केवल कॉल स्वीकार्य नहीं है, तो टॉम कॉल को रद्द करने के लिए एक एसीके फिर एक एसीई भेजेगा। अन्यथा, ऑडियो सत्र की स्थापना की जाएगी और आरटीपी पैकेट का आदान-प्रदान किया जाएगा।

जैसा कि इस उदाहरण से पता चलता है कि जब तक मीडिया क्षेत्रों की संख्या और क्रम बनाए नहीं रखा जाता है, तब तक कॉलिंग पार्टी को यह नहीं पता होगा कि किन मीडिया सत्रों को स्वीकार किया जा रहा है और उन्हें बुलाया पार्टी द्वारा अस्वीकार कर दिया गया है।

प्रस्ताव / उत्तर नियमों को निम्नलिखित वर्गों में संक्षेपित किया गया है।

ऑफर जनरेट करने के नियम

एक SDP ऑफ़र में सभी आवश्यक SDP फ़ील्ड शामिल होने चाहिए (इसमें v =, o =, s =, c =, और t =) शामिल हैं। ये एसडीपी में अनिवार्य क्षेत्र हैं।

इसमें आमतौर पर एक मीडिया क्षेत्र ( m = ) शामिल होता है, लेकिन यह नहीं होता है। मीडिया लाइनों में वरीयता क्रम में सूचीबद्ध सभी कोडेक्स होते हैं। इसका एकमात्र अपवाद यह है कि यदि समापन बिंदु भारी संख्या में कोडेक्स का समर्थन करता है, तो स्वीकार किए जाने की संभावना या सबसे पसंदीदा को सूचीबद्ध किया जाना चाहिए। विभिन्न मीडिया प्रकारों में ऑडियो, वीडियो, टेक्स्ट, MSRP, BFCP और इसके बाद के संस्करण शामिल हैं।

एक उत्तर उत्पन्न करने के नियम

एक प्रस्ताव के एसडीपी उत्तर का निर्माण निम्नलिखित नियमों के अनुसार किया जाना चाहिए -

• उत्तर में उत्तर के समान क्रम में m = पंक्तियों की समान संख्या होनी चाहिए ।

• पोर्ट नंबर को 0 पर सेट करके व्यक्तिगत मीडिया स्ट्रीम को अस्वीकार किया जा सकता है।

• नॉनज़ेरो पोर्ट नंबर भेजकर धाराओं को स्वीकार किया जाता है।

• प्रत्येक मीडिया प्रकार के लिए सूचीबद्ध पेलोड प्रस्ताव में सूचीबद्ध पेलोड का सबसेट होना चाहिए।

• डायनामिक पेलोड के लिए, एक ही डायनेमिक पेलोड संख्या को प्रत्येक दिशा में उपयोग करने की आवश्यकता नहीं है। आमतौर पर, केवल एक ही पेलोड का चयन किया जाता है।

एक सत्र को संशोधित करने के लिए नियम

किसी भी पार्टी को एक सत्र को संशोधित करने के लिए अन्य प्रस्ताव / उत्तर विनिमय शुरू कर सकते हैं। जब कोई सत्र संशोधित किया जाता है, तो निम्नलिखित नियमों का पालन किया जाना चाहिए -

• मूल ( ओ = ) लाइन संस्करण संख्या या तो पिछले एक भेजे गए के समान होनी चाहिए, जो इंगित करता है कि यह एसडीपी पिछले एक्सचेंज के समान है, या इसे एक द्वारा बढ़ाया जा सकता है, जो नए एसडीपी को इंगित करता है जिसे पार्स किया जाना चाहिए।

• प्रस्ताव में सभी मौजूदा मीडिया लाइनें शामिल होनी चाहिए और उन्हें उसी क्रम में भेजा जाना चाहिए।

• अतिरिक्त मीडिया स्ट्रीम को m = लाइन सूची के अंत में जोड़ा जा सकता है ।

• पोर्ट नंबर को 0. पर सेट करके एक मौजूदा मीडिया स्ट्रीम को हटाया जा सकता है। यह मीडिया लाइन एसडीपी और इस सत्र के लिए सभी भविष्य की पेशकश / उत्तर एक्सचेंजों में रहना चाहिए।

कॉल होल्ड

कॉल में एक पक्ष अस्थायी रूप से दूसरे को होल्ड पर रख सकता है। यह एक समान SDP के साथ एक INVITE भेजकर किया जाता है जो कि मूल INVITE के साथ होता है लेकिन साथ मेंa = sendonly विशेषता मौजूद है।

के साथ एक और INVITE भेजकर कॉल को फिर से सक्रिय कर दिया गया है a = sendrecvविशेषता मौजूद है। निम्नलिखित चित्रण कॉल होल्ड के कॉल प्रवाह को दर्शाता है।

Personal mobilityकई उपकरणों में एक निरंतर पहचानकर्ता होने की क्षमता है। एसआईपी रेजिस्टर विधि का उपयोग करके बुनियादी व्यक्तिगत गतिशीलता का समर्थन करता है, जो एक मोबाइल डिवाइस को अपने आईपी पते और इंटरनेट से कनेक्शन के बिंदु को बदलने की अनुमति देता है और अभी भी इनकमिंग कॉल प्राप्त करने में सक्षम है।

एसआईपी भी सपोर्ट कर सकता है service mobility - जब मोबाइल हो तो उसी सेवा को रखने के लिए उपयोगकर्ता की क्षमता

हैंडओवर (प्री-कॉल) के दौरान एसआईपी गतिशीलता

एक डिवाइस एक साधारण घूंट पंजीकरण द्वारा रिकॉर्ड के पते के साथ अपने संपर्क यूआरआई को बांधता है। डिवाइस आईपी पते के अनुसार, पंजीकरण इस जानकारी को स्वचालित रूप से सिप नेटवर्क में अपडेट करता है।

हैंडओवर के दौरान, अलग-अलग ऑपरेटरों के बीच उपयोगकर्ता एजेंट मार्ग, जहां इसे एक अन्य सेवा प्रदाता के साथ AOR के रूप में संपर्क के साथ फिर से पंजीकरण करना पड़ता है।

उदाहरण के लिए, चलो निम्नलिखित कॉल प्रवाह का उदाहरण लेते हैं। UA जिसे अस्थायी रूप से एक नया SIP URI मिला है एक नए सेवा प्रदाता के साथ। UA तब दोहरा पंजीकरण करता है -

• पहला पंजीकरण नए सेवा ऑपरेटर के साथ है, जो नए सेवा प्रदाता के एओआर यूआरआई के साथ डिवाइस के संपर्क यूआरआई को बांधता है।

• दूसरा REGISTER अनुरोध मूल सेवा प्रदाता को वापस भेज दिया जाता है और नए सेवा प्रदाता के AOR को संपर्क URI के रूप में प्रदान करता है।

जैसा कि बाद में कॉल प्रवाह में दिखाया गया है, जब मूल सेवा प्रदाता के नेटवर्क के लिए एक अनुरोध आता है, तो INVITE को नए सेवा प्रदाता के लिए पुनर्निर्देशित किया जाता है जो तब उपयोगकर्ता को कॉल को रूट करता है।

पहले पंजीकरण के लिए, उपकरण URI युक्त संदेश होगा -

REGISTER sip:visited.registrar1.com SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 72d65a24 
Call-ID: [email protected] 
CSeq: 1 REGISTER 
Contact: <sip:[email protected]:5060> 
Expires: 600000 
Content-Length: 0

रोमिंग यूआरआई के साथ दूसरा पंजीकरण संदेश होगा -

REGISTER sip:home.registrar2.in SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 45375 
Call-ID:[email protected] 
CSeq: 6421 REGISTER 
Contact: <sip:[email protected]> 
Content-Length: 0

उपरोक्त आकृति में प्रतिनिधित्व करने वाला पहला INVITE सिप को भेजा जाएगा: registrar2.in; दूसरा INVITE sip: sip: [email protected] पर भेजा जाएगा, जिसे आगे भेज दिया जाएगाsip:[email protected]। यह टॉम तक पहुंचता है और सत्र को स्थापित करने की अनुमति देता है। समय-समय पर दोनों पंजीकरणों को ताज़ा करना होगा।

कॉल के दौरान गतिशीलता (पुनः आमंत्रित करें)

उपयोगकर्ता एजेंट सत्र के दौरान अपना आईपी पता बदल सकता है क्योंकि यह एक नेटवर्क से दूसरे में स्वैप होता है। बेसिक एसआईपी इस परिदृश्य का समर्थन करता है, एक संवाद में फिर से आमंत्रित के रूप में संपर्क यूआरआई को अपडेट करने और एसडीपी में मीडिया की जानकारी को बदलने के लिए इस्तेमाल किया जा सकता है।

नीचे दिए गए आंकड़े में उल्लिखित कॉल प्रवाह पर एक नज़र डालें।

• यहाँ, टॉम एक नए नेटवर्क का पता लगाता है,

• एक नया आईपी पता प्राप्त करने के लिए डीएचसीपी का उपयोग करता है, और

• नए IP पते पर सिग्नलिंग और मीडिया प्रवाह की अनुमति देने के लिए एक पुन: आमंत्रित करता है।

यदि यूए दोनों नेटवर्क से मीडिया प्राप्त कर सकता है, तो रुकावट नगण्य है। यदि ऐसा नहीं है, तो कुछ मीडिया पैकेट खो सकते हैं, जिसके परिणामस्वरूप कॉल में थोड़ी रुकावट आ सकती है।

पुन: आमंत्रित इस प्रकार दिखाई देगा -

INVITE sip:[email protected] SIP/2.0  
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a 
Max-Forwards: 70 

To: <sip:[email protected]> 

From: sip:[email protected];tag = 70133df4 
Call-ID: 76d4861c19c 
CSeq: 1 INVITE 
Accept: application/sdp 
Accept-Language: en 

Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE 
Contact: <sip:172.22.1.102:5060>; 
Content-Type: application/sdp 
Content-Length: 168 

v = 0
o = PPT 40467 40468 IN IP4 192.168.2.1 
s = - 
c = IN IP4 192.168.2.1 
b = AS:49 
t = 0 0 
b = RR:0 
b = RS:0 
a = rtpmap:97 AMR/8000/1 
m = audio 6000 RTP/AVP 96 
a = fmtp:102 0-15 
a = ptime:20 
a = maxptime:240

पुन: INVITE में वाया और संपर्क हेडर फ़ील्ड और SDP मीडिया जानकारी में बॉउडिच का नया आईपी पता शामिल है।

मिडकॉल में गतिशीलता (हेडर की जगह)

मिडकॉल गतिशीलता में, वास्तविक रूट सेट (SIP प्रॉक्सी का सेट जो SIP संदेशों को पीछे ले जाना चाहिए) को बदलना होगा। हम मिडकॉल की गतिशीलता में फिर से निवेश नहीं कर सकते

उदाहरण के लिए, यदि NAT ट्रावेल के लिए एक प्रॉक्सी आवश्यक है, तो कॉन्टैक्ट यूआरआई को बदलना होगा - एक नया डायलॉग बनाना होगा। इसलिए, इसे एक रिप्लेसमेंट हेडर के साथ एक नया इनवाइट भेजना होगा, जो मौजूदा सत्र की पहचान करता है।

Note - मान लीजिए कि A & B दोनों एक कॉल में हैं और यदि A को एक अन्य हेडर (C का कहना है) को एक रिप्लेस्ड हेडर (मौजूदा डायलॉग से मेल खाना चाहिए) के साथ मिलता है, तो ए को इनवाइट को स्वीकार करना चाहिए और B के साथ सत्र समाप्त करना चाहिए और सभी संसाधन को इसमें ट्रांसफर करना चाहिए नवगठित संवाद

कॉल फ़्लो को निम्न चित्र में दिखाया गया है। यह पिछले कॉल फ़्लो के समान है जिसमें री-इनवाइट का उपयोग किया जाता है, सिवाय इसके कि एक BYE स्वचालित रूप से मौजूदा डायलॉग को समाप्त करने के लिए जनरेट किया जाता है जब INVITE विथ द रिप्लेस को स्वीकार किया जाता है।

इस परिदृश्य में ध्यान देने योग्य बिंदु नीचे दिए गए हैं -

• टॉम और जेरी के बीच मौजूदा संवाद में पुराने विज़िट किए गए प्रॉक्सी सर्वर शामिल हैं।

• नए वायरलेस नेटवर्क का उपयोग करने वाले नए संवाद में नए विज़िट किए गए प्रॉक्सी सर्वर को शामिल करने की आवश्यकता होती है।

• नतीजतन, टॉम द्वारा रिप्लाई के साथ एक INVITE भेजा जाता है, जो एक नया संवाद बनाता है जिसमें नया विज़िट किया गया प्रॉक्सी सर्वर शामिल होता है लेकिन पुराने विज़िट किए गए प्रॉक्सी सर्वर में नहीं।

• जब जेरी इन्विट को स्वीकार करता है, तो एक बीईई स्वचालित रूप से पुराने डायलॉग को समाप्त करने के लिए भेजा जाता है जो पुराने विज़िट किए गए प्रॉक्सी सर्वर के माध्यम से रूट करता है जो अब सत्र में शामिल नहीं होता है।

• परिणामी मीडिया सत्र टॉम के नए IP पते का उपयोग SDP से INVITE में किया गया है।

सेवा गतिशीलता

SIP में सेवाएँ प्रॉक्सिस या यूएएस में प्रदान की जा सकती हैं। व्यक्तिगत गतिशीलता के साथ सेवा गतिशीलता प्रदान करना तब तक चुनौतीपूर्ण हो सकता है जब तक कि उपयोगकर्ता के उपकरण समान सेवाओं के साथ समान रूप से कॉन्फ़िगर नहीं किए जाते हैं।

एसआईपी आसानी से इंटरनेट पर सेवा की गतिशीलता का समर्थन कर सकता है। जब इंटरनेट से जुड़ा है, तो भारत में एक प्रॉक्सी का उपयोग करने के लिए कॉन्फ़िगर किया गया UA अभी भी यूरोप में घूमने पर उन प्रॉक्सी का उपयोग कर सकता है। मीडिया सत्र की गुणवत्ता पर इसका कोई प्रभाव नहीं पड़ता है क्योंकि मीडिया हमेशा दो यूएएस के बीच सीधे प्रवाहित होता है और एसआईपी प्रॉक्सी सर्वरों को पार नहीं करता है।

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

शायद ही कभी एक प्रॉक्सी सर्वर एक ही एसआईपी कॉल को कई एसआईपी एंडपॉइंट्स के लिए आगे करता है। इस प्रक्रिया को फोर्किंग के रूप में जाना जाता है। यहां एक ही कॉल एक ही समय में कई एंडपॉइंट्स को रिंग कर सकता है।

एसआईपी फोर्किंग के साथ, आप अपने डेस्क फोन की रिंग को अपने सॉफ्टफोन या अपने मोबाइल पर एसआईपी फोन के समान रख सकते हैं, जिससे आप आसानी से किसी भी डिवाइस से कॉल ले सकते हैं।

आम तौर पर, एक कार्यालय में, मान लीजिए कि बॉस कॉल या दूर जाने में असमर्थ है, एसआईपी फोर्किंग सचिव को कॉल का जवाब देने की अनुमति देता है।

फोर्किंग तब संभव होगा जब कोई स्टेटफुल प्रॉक्सी उपलब्ध हो क्योंकि उसे प्राप्त होने वाले कई कार्यों को करने और प्रतिक्रिया देने की आवश्यकता होती है।

हमारे पास दो प्रकार के फोर्किंग हैं -

• समानांतर फोर्किंग
• अनुक्रमिक फोर्किंग

समानांतर फोर्किंग

इस परिदृश्य में, प्रॉक्सी सर्वर एक बार में दो डिवाइस (UA2, UA3), INVITE को फोर्क करेगा। दोनों डिवाइस 180 रिंगिंग उत्पन्न करेंगे और जो भी कॉल प्राप्त करेगा वह 200 ओके उत्पन्न करेगा। प्रतिक्रिया (मान लीजिए UA2) जो पहले ओरिजिनेटर तक पहुंचती है, UA2 के साथ एक सत्र स्थापित करेगी। अन्य प्रतिक्रिया के लिए, CANCEL को ट्रिगर किया जाएगा।

यदि प्रवर्तक दोनों प्रतिक्रियाओं को एक साथ प्राप्त करता है, तो q- मूल्य के आधार पर, यह प्रतिक्रिया को आगे बढ़ाएगा।

अनुक्रमिक फोर्किंग

इस परिदृश्य में, प्रॉक्सी सर्वर INVITE को एक डिवाइस (UA2) में कांटा जाएगा। यदि उस समय UA2 अनुपलब्ध या व्यस्त है, तो प्रॉक्सी इसे किसी अन्य डिवाइस (UA3) पर फोर्क करेगा।

शाखा - आईडी और टैग

शाखा ID, परदे के पीछे के अनुरोधों के लिए प्रतिक्रियाओं का मिलान करने में मदद करता है। ब्रांच आईडी के बिना, एक प्रॉक्सी सर्वर फोर्क्ड प्रतिक्रिया को समझने में सक्षम नहीं होगा। शाखा-आईडी वाया हेडर में उपलब्ध होगी।

यूएसी द्वारा टैग का उपयोग विभिन्न यूएएस से कई अंतिम प्रतिक्रियाओं को अलग करने के लिए किया जाता है। एक UAS हल नहीं कर सकता है कि क्या अनुरोध को कांटा गया है या नहीं। इसलिए, इसे एक टैग जोड़ने की आवश्यकता है।

प्रॉक्सी भी टैग जोड़ सकते हैं यदि यह एक अंतिम प्रतिक्रिया उत्पन्न करता है, तो वे कभी भी अनुरोधों या प्रतिक्रियाओं में टैग नहीं डालते हैं।

यह संभव हो सकता है कि एक एकल अनुरोध को कई प्रॉक्सी सर्वरों द्वारा भी कांटा जा सकता है। तो जो प्रॉक्सी कांटा करेगा, वह अपनी विशिष्ट आईडी को अपनी बनाई शाखाओं में जोड़ देगा।

कॉल लेग और कॉल आईडी

एक कॉल लेग दो उपयोगकर्ता एजेंटों के बीच एक से एक सिग्नलिंग संबंध को संदर्भित करता है। कॉल आईडी SIP संदेश में किया गया एक विशिष्ट पहचानकर्ता है जो कॉल को संदर्भित करता है। कॉल कॉल पैरों का एक संग्रह है।

एक UAC एक INVITE भेजकर शुरू होता है। फोर्किंग के कारण, यह अलग-अलग यूएएस से कई 200 ओके प्राप्त कर सकता है। प्रत्येक एक ही कॉल के भीतर एक अलग कॉल लेग से मेल खाती है।

एक कॉल इस प्रकार कॉल पैरों का एक समूह है। एक कॉल लेग का तात्पर्य यूएएस के बीच एंड-टू-एंड कनेक्शन से है।

कॉल लेग की दो दिशाओं में CSeq रिक्त स्थान स्वतंत्र हैं। एक दिशा के भीतर, प्रत्येक लेनदेन के लिए अनुक्रम संख्या बढ़ाई गई है।

स्वर का मेल

एंटरप्राइज़ उपयोगकर्ताओं के लिए वॉइसमेल अब बहुत आम है। यह एक टेलीफोन एप्लिकेशन है। यह तब आता है जब कॉल की गई पार्टी अनुपलब्ध है या कॉल प्राप्त करने में असमर्थ है, पीबीएक्स एक वॉयस मैसेज छोड़ने के लिए कॉलिंग पार्टी की घोषणा करेगा।

उपयोगकर्ता एजेंट या तो 3xx प्रतिक्रिया प्राप्त करेगा या वॉइसमेल सर्वर पर पुनर्निर्देशित करेगा यदि कॉल की गई पार्टी की संख्या अनुपलब्ध है। हालाँकि, वॉइसमेल सिस्टम को इंगित करने के लिए किसी प्रकार के SIP एक्सटेंशन की आवश्यकता होती है, जिसका उपयोग मेलबॉक्स करने के लिए किया जाता है - जो कि अभिवादन करने के लिए और रिकॉर्ड किए गए संदेश को संग्रहीत करने के लिए कहाँ है। इसे प्राप्त करने के दो तरीके हैं -

• SIP शीर्ष लेख फ़ील्ड एक्सटेंशन का उपयोग करके

• इस जानकारी का संकेत देने के लिए अनुरोध-यूआरआई का उपयोग करके

उपयोगकर्ता के लिए मान लीजिए sip:[email protected] sip पर एक ध्वनि मेल सिस्टम है: voicemail.tutorialspoint.com जो ध्वनि मेल प्रदान कर रहा है, अनुरोध का URI जब ध्वनि मेल सर्वर के लिए अग्रेषित किया जाता है तो वह ऐसा देख सकता है -

sip:voicemail.tutorialspoint.com;target = sip:[email protected];cause = 486

निम्नलिखित चित्रण से पता चलता है कि अनुरोध-यूआरआई मेलबॉक्स पहचानकर्ता और कारण (यहां 486) को कैसे ले जाता है।

जैसा कि हम जानते हैं, एक प्रॉक्सी सर्वर स्टेटलेस या स्टेटफुल हो सकता है। यहां, इस अध्याय में, हम प्रॉक्सी सर्वर और एसआईपी रूटिंग पर अधिक चर्चा करेंगे।

स्टेटलेस प्रॉक्सी सर्वर

एक स्टेटलेस प्रॉक्सी सर्वर केवल उस संदेश को प्राप्त करता है जो उसे प्राप्त होता है। इस तरह का सर्वर कॉल या लेनदेन की किसी भी जानकारी को संग्रहीत नहीं करता है।

• स्टेटलेस प्रोक्सीज एसआईपी अनुरोध के बारे में भूल जाते हैं एक बार इसे आगे भेज दिया गया है।
• सांविधिक परदे के पीछे से लेन-देन तेज होगा।

स्टेटफुल प्रॉक्सी सर्वर

एक स्टेटफुल प्रॉक्सी सर्वर हर रिक्वेस्ट और रिस्पॉन्स का ट्रैक रखता है जो उसे मिलता है। यदि आवश्यक हो, तो यह भविष्य में संग्रहीत जानकारी का उपयोग कर सकता है। यह अनुरोध को फिर से स्वीकार कर सकता है यदि उसे दूसरी तरफ से प्रतिक्रिया नहीं मिलती है।

• स्टेटफुल प्रॉक्सिस को आगे भेजे जाने के बाद अनुरोध याद है, इसलिए वे इसे अग्रिम मार्ग के लिए उपयोग कर सकते हैं। स्टेटफुल प्रॉक्सिस ट्रांजेक्शन स्टेट को बनाए रखता है। लेनदेन से तात्पर्य लेनदेन की स्थिति से है,notकॉल स्टेट ।

• स्टेटलेस प्रॉक्सिअस के साथ स्टेटलेस के रूप में लेन-देन में तेजी नहीं है।

• यदि आवश्यक हो तो स्टेटफुल परदे के पीछे कांटा और फिर से पकड़ सकता है। (जैसे: उदाहरण के लिए, व्यस्त व्यस्त कॉल करें)।

वाया और रिकॉर्ड-मार्ग

रिकॉर्ड-मार्ग

रिकॉर्ड-रूट हेडर को प्रॉक्सी द्वारा अनुरोधों में डाला जाता है जो उसी कॉल-आईडी के लिए बाद के अनुरोधों के मार्ग में होना चाहते थे। इसके बाद इसका उपयोग उपयोगकर्ता एजेंट द्वारा बाद के अनुरोधों को रूट करने के लिए किया जाता है।

के जरिए

लूप का पता लगाने और क्लाइंट को अपना रास्ता खोजने के लिए प्रतिक्रियाओं की सहायता के लिए वाया हेडर सर्वर द्वारा अनुरोधों में डाले जाते हैं। यह उनके गंतव्य तक पहुंचने के लिए केवल प्रतिक्रियाओं के लिए सहायक है।

• अनुरोध भेजते समय एक UA खुद वाया हैडर फ़ील्ड में अपना स्वयं का पता उत्पन्न करता है और अपना पता जोड़ता है।

• अनुरोध को अग्रेषित करने वाला प्रॉक्सी वाया हेडर फ़ील्ड की सूची के शीर्ष पर अपना पता वाला वाया हेडर फ़ील्ड जोड़ता है।

• एक प्रॉक्सी या UA अनुरोध के जवाब में प्रतिक्रिया के क्रम में सभी Via हेडर फ़ील्ड्स को अनुरोध से कॉपी करता है, फिर शीर्ष Via हेडर फ़ील्ड में निर्दिष्ट पते पर प्रतिक्रिया भेजता है।

• एक प्रतिक्रिया प्राप्त करने वाला प्रॉक्सी शीर्ष Via शीर्ष लेख फ़ील्ड की जाँच करता है और अपने स्वयं के पते से मेल खाता है। यदि यह मेल नहीं खाता है, तो प्रतिक्रिया को छोड़ दिया गया है।

• शीर्ष वाया हेडर फ़ील्ड को तब हटा दिया जाता है, और प्रतिक्रिया अगले Via हेडर फ़ील्ड में निर्दिष्ट पते पर भेज दी जाती है।

वाया हेडर फ़ील्ड्स में प्रोटोकॉलनाम, वर्जनबेर और ट्रांसपोर्ट (एसआईपी / 2.0 / यूडीपी, एसआईपी / 2.0 / टीसीपी, आदि) होते हैं और इसमें पोर्टन्यूज़ और पैरामीटर जैसे प्राप्त, आरपोर्ट, ब्रांच होते हैं।

• यदि UA या प्रॉक्सी शीर्ष Via शीर्ष लेख फ़ील्ड में निर्दिष्ट किसी भिन्न पते से अनुरोध प्राप्त करता है, तो एक वाया शीर्षक फ़ील्ड में एक प्राप्त टैग जोड़ा जाता है।

• यूएएस और प्रॉक्सी द्वारा वाया हेडर फ़ील्ड में एक शाखा पैरामीटर जोड़ा जाता है, जिसे अनुरोध-यूआरआई के हैश फ़ंक्शन के रूप में गणना की जाती है, और टीओ, से, कॉल-आईडी और सीएसईके नंबर।

एसआईपी (सॉफ्टफोन) और पीएसटीएन (पुराना टेलीफोन) दोनों अलग-अलग नेटवर्क हैं और विभिन्न भाषाएं बोलते हैं। इसलिए हमें इन दोनों नेटवर्क के बीच संचार करने के लिए एक अनुवादक (गेटवे यहाँ) की आवश्यकता है।

आइए एक उदाहरण लेते हैं कि एक SIP फोन PSTN गेटवे के माध्यम से एक PSTN को टेलीफोन कॉल कैसे दिखाता है।

इस उदाहरण में, टॉम (sip:[email protected]) एक घूंट फोन है और जेरी एक वैश्विक टेलीफोन नंबर +91401234567 का उपयोग करता है।

गेटवे के माध्यम से पीएसटीएन को एसआईपी

निम्न दृष्टांत गेटवे के माध्यम से एसआईपी से पीएसटीएन के लिए एक कॉल फ्लो दिखाता है।

नीचे दिए गए SIP फोन से PSTN पर कॉल करते समय होने वाली सभी प्रक्रिया का चरण-दर-चरण स्पष्टीकरण दिया गया है।

• सबसे पहले, (टॉम) एसआईपी फोन जैरी तक पहुंचने के लिए वैश्विक नंबर +91401234567 डायल करता है। SIP उपयोगकर्ता एजेंट इसे एक वैश्विक संख्या के रूप में समझता है और इसे DNS का उपयोग करके अनुरोध-uri में परिवर्तित करता है और अनुरोध को ट्रिगर करता है।

• SIP फोन सीधे गेटवे के लिए INVITE भेजता है।

• गेटवे PSTN में अगले टेलीफोन स्विच के लिए SS7 ISUP ट्रंक का चयन करके PSTN में कॉल शुरू करता है।

• INVITE से प्राप्त अंकों को ISUP IAM में मैप किया जाता है। ISUP पता पूरा संदेश (ACM) PSTN द्वारा वापस भेजा जाता है ताकि यह इंगित किया जा सके कि ट्रंक बनाया गया है।

• टेलीफोन रिंगटोन उत्पन्न करता है और यह टेलीफोन स्विच पर जाता है। गेटवे एसीएम को 183 सत्र की प्रगति की प्रतिक्रिया में मैप करता है जिसमें एसडीपी होता है जो आरटीपी पोर्ट को दर्शाता है कि गेटवे पीएसटीएन से ऑडियो को पुल करने के लिए उपयोग करेगा।

• 183 के रिसेप्शन पर, कॉलर का यूएसी गेटवे से भेजे गए आरटीपी पैकेट प्राप्त करना शुरू कर देता है और कॉल करने वाले को ऑडियो प्रस्तुत करता है, ताकि उन्हें पता चल जाए कि पीएसटीएन में प्रगति कर रहे कैली।

• कॉल तब पूरा होता है जब कॉल करने वाला पक्ष टेलीफ़ोन का जवाब देता है, जिससे टेलिफ़ोन स्विच गेटवे पर एक उत्तर संदेश (ANM) भेजता है।

• गेटवे फिर दोनों दिशाओं में पीएसटीएन ऑडियो कनेक्शन को काटता है और कॉल करने वाले को 200 ओके प्रतिक्रिया भेजता है। जैसा कि RTP मीडिया पथ पहले से ही स्थापित है, गेटवे 183 में SDP का जवाब देता है, लेकिन RTP कनेक्शन में कोई बदलाव नहीं करता है।

• यूएसी एसआईपी सिग्नलिंग एक्सचेंज को पूरा करने के लिए एक एसीके भेजता है। जैसे कि ISUP में कोई समान संदेश नहीं है, गेटवे ACK को अवशोषित करता है।

• कॉल करने वाला BYE को गेटवे से टर्मिनेट करने के लिए भेजता है। गेटवे BYE को ISUP रिलीज़ संदेश (REL) में मैप करता है।

• गेटवे BYE को 200OK भेजता है और PSTN से एक RLC प्राप्त करता है।

कोडर-डिकोडर के लिए एक कोडेक, दो बुनियादी ऑपरेशन करता है -

• सबसे पहले, यह एक एनालॉग वॉइस सिग्नल को इसके समकक्ष डिजिटल रूप में परिवर्तित करता है ताकि इसे आसानी से प्रसारित किया जा सके।

• इसके बाद, यह संपीड़ित डिजिटल सिग्नल को उसके मूल एनालॉग रूप में वापस परिवर्तित करता है ताकि इसे दोबारा चलाया जा सके।

बाजार में कई कोडेक्स उपलब्ध हैं - कुछ मुफ्त हैं जबकि अन्य के लिए लाइसेंस की आवश्यकता होती है। Codecs ध्वनि की गुणवत्ता में भिन्नता रखते हैं और तदनुसार बैंडविड्थ में भिन्न होते हैं।

फोन और गेटवे जैसे हार्डवेयर डिवाइस कई अलग-अलग कोडेक्स का समर्थन करते हैं। एक दूसरे से बात करते समय, वे बातचीत करते हैं कि वे किस कोडेक का उपयोग करेंगे।

यहाँ, इस अध्याय में, हम कुछ लोकप्रिय SIP ऑडियो कोडेक्स पर चर्चा करेंगे जिनका व्यापक रूप से उपयोग किया जाता है।

G.711

G.711 एक कोडेक है जिसे 1972 में ITU द्वारा डिजिटल टेलीफोनी में उपयोग के लिए पेश किया गया था। कोडेक के दो संस्करण हैं:A-Law यूरोप और अंतरराष्ट्रीय टेलीफोन लिंक में इस्तेमाल किया जा रहा है, uLaw संयुक्त राज्य अमेरिका और जापान में प्रयोग किया जाता है।

• G.711 एक लघुगणक संपीड़न का उपयोग करता है। यह प्रत्येक 16-बिट नमूने को 8 बिट्स पर निचोड़ता है, इस प्रकार यह 1: 2 का संपीड़न अनुपात प्राप्त करता है।

• एक दिशा के लिए बिटरेट 64 kbit / s है, इसलिए एक कॉल में 128 kbit / s खपत होती है।

• G.711 PSTN नेटवर्क द्वारा उपयोग किया जाने वाला एक ही कोडेक है, इसलिए यह सबसे अच्छी आवाज की गुणवत्ता प्रदान करता है। हालाँकि यह अन्य कोडेक्स की तुलना में अधिक बैंडविड्थ की खपत करता है।

• यह स्थानीय क्षेत्र नेटवर्क में सबसे अच्छा काम करता है जहां हमारे पास बहुत सारे बैंडविड्थ उपलब्ध हैं।

G.729

G.729 कम बैंडविड्थ आवश्यकताओं के साथ एक कोडेक है; यह अच्छी ऑडियो गुणवत्ता प्रदान करता है।

• कोडेक ऑडियो को 10 एमएस लंबे फ्रेम में एनकोड करता है। 8 kHz की एक नमूना आवृत्ति को देखते हुए, एक 10 एमएस फ्रेम में 80 ऑडियो नमूने होते हैं।

• कोडेक एल्गोरिथ्म प्रत्येक फ्रेम को 10 बाइट्स में एन्कोड करता है, इसलिए परिणामस्वरूप बिटरेट एक दिशा में 8 kbit / s है।

• G.729 एक लाइसेंस प्राप्त कोडेक है। एंड-यूजर्स जो इस कोडेक का उपयोग करना चाहते हैं, उन्हें एक हार्डवेयर खरीदना चाहिए जो इसे लागू करता है (यह एक वीओआईपी फोन या गेटवे हो)।

• G.729 का अक्सर उपयोग किया जाने वाला संस्करण G.729a है। यह मूल कोडेक के साथ तार-संगत है लेकिन इसमें सीपीयू आवश्यकताएं कम हैं।

G.723.1

G.723.1 एक प्रतियोगिता का परिणाम है जिसे ITU ने एक कोडेक डिज़ाइन करने के उद्देश्य से घोषित किया है जो 28.8 और 33 kbit / s मॉडेम लिंक पर कॉल की अनुमति देगा।

• हमारे पास G.723.1 के दो संस्करण हैं। वे दोनों 30 एमएस (यानी 240 नमूने) के ऑडियो फ्रेम पर काम करते हैं, लेकिन एल्गोरिदम अलग हैं।

• पहले वेरिएंट की बिटरेट 6.4 kbit / s है, जबकि दूसरे वेरिएंट के लिए यह 5.3 kbit / s है।

• दो वेरिएंट के लिए एन्कोडेड फ्रेम क्रमशः 24 और 20 बाइट्स लंबे होते हैं।

जीएसएम 06.10

जीएसएम 06.10 जीएसएम मोबाइल नेटवर्क के लिए डिज़ाइन किया गया एक कोडेक है। इसे GSM फुल रेट के रूप में भी जाना जाता है।

• जीएसएम कोडेक के इस प्रकार का स्वतंत्र रूप से उपयोग किया जा सकता है, इसलिए आपको अक्सर यह खुले स्रोत वीओआईपी अनुप्रयोगों में मिलेगा।

• कोडेक ऑडियो फ्रेम 20 एमएस लंबे (यानी 160 नमूने) पर संचालित होता है और यह प्रत्येक फ्रेम को 33 बाइट्स तक संपीड़ित करता है, इसलिए परिणामस्वरूप बिटरेट 13 kbit / है।

बैक-टू-बैक उपयोगकर्ता एजेंट (B2BUA) SIP अनुप्रयोगों में एक तार्किक नेटवर्क तत्व है। यह एक प्रकार का SIP UA है जो SIP अनुरोध प्राप्त करता है, फिर अनुरोध को सुधारता है, और इसे नए अनुरोध के रूप में भेजता है।

प्रॉक्सी सर्वर के विपरीत, यह संवाद स्थिति बनाए रखता है और इसे स्थापित किए गए संवादों पर भेजे गए सभी अनुरोधों में भाग लेना चाहिए। एक B2BUA SIP की एंड-टू-एंड प्रकृति को तोड़ता है।

B2BUA - यह कैसे काम करता है?

एक B2BUA एजेंट एक फोन कॉल के दो समापन बिंदुओं के बीच काम करता है और संचार चैनल को दो में विभाजित करता है call legs। बी 2 बी यूएएसी और यूएएस का एक संयोजन है। यह कॉल के दोनों सिरों के बीच सभी एसआईपी सिग्नलिंग में भाग लेता है, इसे स्थापित किया है। जैसा कि एक संवाद सेवा प्रदाता में उपलब्ध B2BUA कुछ मूल्य वर्धित सुविधाओं को लागू कर सकता है।

कॉलिंग लेग में, B2BUA एक उपयोगकर्ता एजेंट सर्वर (UAS) के रूप में कार्य करता है और गंतव्य छोर तक एक उपयोगकर्ता एजेंट क्लाइंट (UAC) के रूप में अनुरोध को संसाधित करता है , अंतिम बिंदुओं के बीच सिग्नल को संभालता है।

एक B2BUA अपने द्वारा हैंडल की जाने वाली कॉल के लिए पूर्ण स्थिति बनाए रखता है। B2BU का प्रत्येक पक्ष RFC 3261 में निर्दिष्ट मानक SIP नेटवर्क तत्व के रूप में कार्य करता है।

B2BUA के कार्य

एक B2BUA निम्नलिखित कार्य प्रदान करता है -

• कॉल प्रबंधन (बिलिंग, स्वचालित कॉल वियोग, कॉल ट्रांसफर, आदि)

• नेटवर्क इंटरएक्टिव (शायद प्रोटोकॉल अनुकूलन के साथ)

• नेटवर्क इंटर्नल्स (निजी पते, नेटवर्क टोपोलॉजी, आदि) को छिपाना

सत्र पर पूर्ण नियंत्रण के लिए मीडिया स्ट्रीम को पाटने के लिए अक्सर, बी 2 बीयू को मीडिया गेटवे में भी लागू किया जाता है।

B2BUA का उदाहरण

कई निजी शाखा एक्सचेंज (PBX) एंटरप्राइज़ टेलीफोन सिस्टम B2BUA लॉजिक को शामिल करते हैं।

कुछ फायरवॉल ने ALG (एप्लीकेशन लेयर गेटवे) कार्यक्षमता के साथ बनाया है, जो उच्च स्तर की सुरक्षा को बनाए रखते हुए एक फ़ायरवॉल को SIP और मीडिया ट्रैफ़िक को अधिकृत करने की अनुमति देता है।

B2BUA का एक अन्य सामान्य प्रकार एक सत्र सीमा नियंत्रक (SBC) के रूप में जाना जाता है।