SIP क्या है?

अलग-अलग विक्रेताओं के फ़ोन सिस्टम को किसी कॉल पर सहमत होने के लिए एक साझा तरीके की ज़रूरत होती है।

SIP मीडिया नहीं ले जाता, और यही सीमा बताती है कि कनेक्ट हुई कॉल में ऑडियो क्यों नहीं हो सकता।

SIP असल में क्या करता है?

यह दो पक्षों को इस बात पर सहमत कराता है कि सत्र होना चाहिए, और किन शर्तों पर।

RFC 3261, जून 2002 का वह स्पेसिफिकेशन जो इसे परिभाषित करता है, SIP को "an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants" के रूप में बताता है। पाँच काम हैं: दूसरे छोर को ढूँढना, यह तय करना कि वह कॉल लेगा या नहीं, मीडिया पर सहमति बनाना, रिंग करना, और बाद में कॉल काटना या ट्रांसफ़र करना। स्पेसिफिकेशन इन्हें इस तरह सूचीबद्ध करता है:

User location: determination of the end system to be used for
     communication;

User availability: determination of the willingness of the called
     party to engage in communications;

User capabilities: determination of the media and media parameters
     to be used;

Session setup: "ringing", establishment of session parameters at
     both called and calling party;

Session management: including transfer and termination of
     sessions, modifying session parameters, and invoking
     services.

इन पाँचों में से कोई भी काम ऑडियो ले जाना नहीं है। इसका पूरा दायरा यही है।

मेरी कॉल कनेक्ट है, फिर भी ऑडियो क्यों नहीं है?

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

स्पेसिफिकेशन अपने दायरे के बारे में स्पष्ट है:

SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture.

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

इसी कारण एकतरफ़ा ऑडियो और ऑडियो न होना कॉल विफलता का कोई प्रकार नहीं, बल्कि अपनी अलग डायग्नोस्टिक श्रेणी हैं। कॉल लॉग में कॉल कनेक्ट दिखेगी, क्योंकि सिग्नलिंग ने ठीक यही हासिल किया था। वॉइस ट्रबलशूटिंग इन लक्षणों को एक-एक करके देखता है। Bird का अपना टेस्ट-कॉल टूल हर दिशा के लिए पीक-ऑडियो सारांश दिखाता है। उसमें किसी एक तरफ़ शून्य आना एकतरफ़ा ऑडियो के लक्षण को संख्या में दिखाता है।

यही अलगाव दूसरी सुविधाओं को आसानी से जुड़ने देता है। RFC 3261 इसे "SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services." के रूप में कहता है। वॉइसमेल, हंट ग्रुप, कॉल रिकॉर्डिंग और AI एजेंट, सभी इन बुनियादी तत्वों पर बने हैं, प्रोटोकॉल इन्हें परिभाषित नहीं करता।

क्या कॉल करने से पहले मुझे क्लाइंट रजिस्टर करना होगा?

नहीं। Bird ट्रंक क्लाइंट के रजिस्ट्रेशन के बिना कॉल को प्रमाणित करते हैं।

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

SIP INVITE वह मेथड है जो कॉल का अनुरोध करता है। Bird हर अनुरोध को ट्रंक की IP अनुमति सूची से या पासवर्ड चुनौती के ज़रिए प्रमाणित करता है। क्लाइंट ट्रंक के साथ रजिस्टर नहीं होते। Bird को रजिस्टर किए गए अकाउंट के बजाय ट्रंक के रूप में कॉन्फ़िगर करें: Asterisk में कोई type=registration सेक्शन नहीं, FreeSWITCH गेटवे पर register=false, और FreePBX या 3CX में रजिस्ट्रेशन को none पर सेट करें। अगर किसी सॉफ़्टफ़ोन में रजिस्ट्रेशन बंद करने का विकल्प नहीं है, तो रजिस्ट्रेशन का विफल प्रयास केवल दिखावटी है और डायल करना फिर भी काम करता है, क्योंकि प्लेटफ़ॉर्म रजिस्ट्रेशन पर नहीं, बल्कि आमंत्रण पर कार्रवाई करता है। SIP क्लाइंट सेटअप में तैयार कॉन्फ़िगरेशन दिए गए हैं।

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

प्रतिक्रियाएँ HTTP जैसी क्यों दिखती हैं?

क्योंकि प्रोटोकॉल को जानबूझकर ऐसा ही बनाया गया था, नंबरों की रेंज तक।

SIP मेथड और हेडर वाला टेक्स्ट-आधारित अनुरोध-प्रतिक्रिया प्रोटोकॉल है। इसकी प्रतिक्रियाएँ उन्हीं छह क्लास और उन्हीं जाने-पहचाने नंबरों में आती हैं: मौजूद न होने वाले गंतव्य के लिए 404 और व्यस्त एंड सिस्टम के लिए 486। इसी साझा संरचना के कारण आप SIP ट्रेस को लगभग वैसे ही पढ़ सकते हैं जैसे HTTP ट्रेस को।

इसके दो अपवाद हैं। छठी क्लास 6xx का कोई HTTP समकक्ष नहीं है। इसका मतलब है कि केवल यह सर्वर ही नहीं, बल्कि कहीं का भी कोई सर्वर अनुरोध पूरा नहीं कर सकता। एक आम कोड का Bird पर ऐसा अर्थ भी होता है जिसका वर्णन मानक में नहीं है। SIP प्रतिक्रिया कोड का क्या मतलब है में दोनों बातें बताई गई हैं। वहाँ यह भी समझाया गया है कि Bird से आया 503 आमतौर पर ओवरलोड नहीं होता, बल्कि ऐसा इनकार होता है जिसका कारण वह वायर पर नहीं बताता।

Bird पर मेरा सामना SIP से कहाँ होता है?

ट्रंक पर, यानी उस पते पर जहाँ आपके उपकरण अनुरोध भेजते हैं।

हर ट्रंक का एक निश्चित SIP डोमेन होता है। वह 5060 पर UDP या TCP स्वीकार करता है। अगर आप चाहते हैं कि सिग्नलिंग ट्रांज़िट के दौरान एन्क्रिप्ट रहे, तो वह 5061 पर TLS स्वीकार करता है। उसे कौन भेज सकता है, यह आप तय करते हैं। जब तक आप अनुमति नहीं देते, नया ट्रंक कुछ भी स्वीकार नहीं करता। SIP ट्रंक क्या है में यह निर्णय और इसके पीछे के तीन तरीके बताए गए हैं। वॉइस API क्या है में बताया गया है कि SIP हिस्सा और HTTP हिस्सा काम कैसे बाँटते हैं।