SIP ग्राहक सहभागिता। भाग 1

एक महीने पहले, मैंने आईपी-टेलीफोनी के साथ अपना परिचित शुरू किया, अर्थात् Lync और Asterisk के साथ। और मैंने निम्नलिखित तस्वीर पर ध्यान दिया: मुद्दे के व्यावहारिक पक्ष पर बहुत सारे दिलचस्प लेख हैं (कैसे और क्या करना है) और सिद्धांत पर बहुत कम ध्यान दिया जाता है (लेख के अंत में लिंक हैं)। यदि आप एसआईपी से निपटना चाहते हैं, तो आप RFC 3261 या "इन मोटी किताबों" में से एक को पढ़ सकते हैं। यह, ज़ाहिर है, उपयोगी है, लेकिन कई शुरुआत में किसी प्रकार का निचोड़ सीखना चाहते हैं, और उसके बाद ही अपने सिर के साथ पूल में भागते हैं। यह लेख ऐसे लोगों के लिए ही है।

पाठक को अधिभार न देने के लिए, मैंने लेख को दो भागों में विभाजित करने का निर्णय लिया। पहले भाग में, हम दो ग्राहकों की बातचीत में एसआईपी प्रोटोकॉल के संचालन पर विचार करेंगे।

सरल ग्राहक बातचीत

एसआईपी के ढांचे के भीतर ग्राहकों की बातचीत को अक्सर बातचीत के रूप में अंजाम दिया जाता है।

एक संवाद दो उपयोगकर्ता एजेंट (यूए) के बीच एक समान बातचीत है, जो उनके बीच एसआईपी संदेशों के अनुक्रम के रूप में है। इसी समय, ऐसे प्रश्न हैं जो संवाद नहीं बनाते हैं। हालांकि, क्रम में सब कुछ।

निम्नलिखित दो एसआईपी-सक्षम उपकरणों के बीच एक साधारण बातचीत का एक उदाहरण है:



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



स्टार्ट लाइन में विधि, अनुरोध-यूआरआई और एसआईपी का संस्करण (वास्तविक - 2.0) शामिल है। अनुरोध-URI उस संसाधन का SIP पता है जिसके लिए अनुरोध भेजा गया है।



शीर्ष लेख फ़ील्ड में निम्न प्रारूप होता है: <शीर्षक>: <मान> <पंक्ति फ़ीड>

पहली पंक्ति हेडिंग वाया से शुरू होती है। किसी संदेश को बनाने या अग्रेषित करने वाला प्रत्येक SIP डिवाइस वाया फ़ील्ड में अपना पता जोड़ता है (मैं यह दिखाने की योजना बनाता हूं कि यह लेख के अगले भाग में कैसे होता है)। आमतौर पर, एक पता एक होस्ट नाम है जिसे DNS क्वेरी का उपयोग करके हल किया जा सकता है। Via फ़ील्ड में SIP संस्करण, "/" चिह्न, स्थान, परिवहन प्रोटोकॉल (UDP, TCP, TLS, SCTP), कोलन, पोर्ट नंबर और शाखा - लेनदेन पहचानकर्ता शामिल हैं। इस अनुरोध के जवाबों में एक ही लेनदेन संख्या शामिल होगी।



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

अगले क्षेत्र, मैक्स-फॉरवर्ड में अपेक्षाकृत बड़ा पूर्णांक शामिल है। प्रत्येक SIP सर्वर जो संदेश को अग्रेषित करता है वह इस संख्या को एक घटा देता है। यह क्षेत्र एक सरल लूप डिटेक्शन तंत्र प्रदान करता है।

इसके बाद From और To फ़ील्ड आते हैं, जो अनुरोध के प्रेषक और रिसीवर का वर्णन करते हैं। यह महत्वपूर्ण है कि SIP अनुरोध प्रारंभ लाइन में निर्दिष्ट अनुरोध (URI) के आधार पर रूट किए गए हैं (ऊपर देखें)। ऐसा इसलिए है क्योंकि फ़ॉरवर्डिंग के दौरान From और To फ़ील्ड को बदला जा सकता है। यदि एक प्रदर्शन नाम का उपयोग किया जाता है (उदाहरण के लिए, इवान इवानोव), तो एसआईपी यूआरआई को कोण कोष्ठक की एक जोड़ी के अंदर रखा जाता है। प्रेष फ़ील्ड में टैग पैरामीटर भेजने वाले पक्ष द्वारा उत्पन्न होता है। बदले में, प्राप्त करने वाली पार्टी अपना टैग To फ़ील्ड में रखेगी।

कॉल-आईडी फ़ील्ड - कॉल पहचानकर्ता। From और To और Call-ID फ़ील्ड से टैग का सेट विशिष्ट रूप से इस डायलॉग को पहचानता है। यह आवश्यक है, क्योंकि कई संवाद एक ही बार में ग्राहकों के बीच जा सकते हैं।

अगले क्षेत्र, Cseq, अनुरोध की अनुक्रम संख्या और विधि का नाम शामिल है। इस मामले में, INVTITE प्रत्येक नए अनुरोध के साथ संख्या बढ़ती जाती है।

Via, Max-Forwards, To, From, Call-ID और CSeq फ़ील्ड SIP शीर्ष लेख फ़ील्ड का न्यूनतम आवश्यक सेट बनाते हैं।



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



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

संदेश बॉडी के विवरण के लिए सामग्री-प्रकार और सामग्री-लंबाई फ़ील्ड जिम्मेदार हैं। इस स्थिति में, सत्र विवरण प्रोटोकॉल (SDP) का उपयोग किया जाएगा। संदेश आकार की गणना लाइन फ़ीड वर्णों को ध्यान में रखकर की जाती है:



एसडीपी प्रोटोकॉल के संचालन का एक विस्तृत विवरण एक अलग लेख के योग्य है, इसलिए, केवल एक संक्षिप्त विवरण नीचे दिया गया है:



INVITE के जवाब में, इवान के एसआईपी क्लाइंट दो संदेश भेजता है: 180 रिंगिंग और 200 ओके। पहली रिपोर्ट कि इवान की तरफ, एसआईपी क्लाइंट एक रिंगटोन देता है, दूसरा एक संवाद की स्थापना की पुष्टि करता है। हम उनमें से प्रत्येक से निपटेंगे।

यह 180 रिंगिंग संदेश की तरह दिखेगा:



वह पाठ जो INVITE संदेश की तुलना में नहीं बदला है, उसे बेहोश कर दिया गया है।

शीर्ष लेख फ़ील्ड से टू और नोटिस करें। इस तथ्य के बावजूद कि यह संदेश इवान से आ रहा है, क्षेत्र के मूल्य वैसे ही बने हुए हैं जैसे वे प्रारंभिक अनुरोध में थे (पीटर से इवान तक)। ऐसा इसलिए है क्योंकि ये फ़ील्ड अनुरोध की दिशा निर्धारित करते हैं, संदेश नहीं।

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

जैसा कि मैंने वादा किया था, डायलॉग को पहचानने वाला एक टैग To फ़ील्ड में जोड़ा गया है। संवाद के बाद के सभी संदेशों में अपरिवर्तित टैग मान शामिल होंगे।

अंत में, संपर्क क्षेत्र में इवान का वर्तमान पता है।

यह 200 ओके संदेश जैसा दिखता है, जिसे इवान के एसआईपी क्लाइंट द्वारा भेजा गया था:



मुझे लगता है कि SIP प्रोटोकॉल से संबंधित सभी क्षेत्रों का अर्थ अब स्पष्ट है।

200 ओके के जवाब में, पीटर के ग्राहक एक पुष्टि भेजता है:



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

ध्यान दें कि CSeq अनुक्रम संख्या अभी भी एक है, लेकिन ACK पहले से ही विधि के रूप में उपयोग किया जाता है। वाया क्षेत्र में शाखा पैरामीटर में नया लेनदेन पहचानकर्ता होता है, क्योंकि 200 OK के जवाब में भेजे गए ACK को एक नया लेनदेन माना जाता है।

अब देखते हैं कि मीडिया सत्र कैसे समाप्त होता है। पीटर के ग्राहक सत्र को समाप्त करने के लिए एक BYE अनुरोध भेजता है:



सत्र समाप्त करने के लिए एक अनुरोध प्राप्त करने के बाद, इवान के ग्राहक एक पुष्टि भेजता है:



सत्र समाप्त हो चुका है।

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

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

विषय पर क्या पढ़ें

1. RFC 3261. tools.ietf.org/html/rfc3261
2. सब कुछ आप एसआईपी (तीन भागों) के बारे में जानना चाहते थे। एंड्रे पोगरेबेनिक। samag.ru/archive/article/1831
3. एसआईपी: सेशन इनीशियशन प्रोटोकॉल को समझना। एलन बी। जॉनसन। www.amazon.com/SIP-Understanding-Initiation-Protocol-Telecommunications/dp/1607839954/ref=sr_1_1?ie=UTF8&qid=1375104428&sr=8-1&keywords=sip#
4. सिप प्रोटोकॉल। गोल्डस्टीन बी.एस., जरुबिन ए.ए., समोर्ज़ोव वी.वी. www.vef-kvant.ru/sip.htm