Translated ['src/network-services-pentesting/pentesting-voip/basic-voip-

2025-10-10 18:36:50 +00:00 · 2025-09-30 03:40:11 +00:00 · 2025-09-30 03:40:11 +00:00 · abc48ec611
commit abc48ec611
parent a371d53748
1 changed files with 172 additions and 87 deletions
--- a/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md
+++ b/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md
@ -2,78 +2,78 @@

 {{#include ../../../banners/hacktricks-training.md}}

-## Basic Information
+## बुनियादी जानकारी

-SIP (Session Initiation Protocol) एक **सिग्नलिंग और कॉल नियंत्रण प्रोटोकॉल** है जो IP नेटवर्क पर आवाज, वीडियो और तात्कालिक संदेश भेजने सहित मल्टीमीडिया सत्रों की स्थापना, संशोधन और समाप्ति के लिए व्यापक रूप से उपयोग किया जाता है। इसे **इंटरनेट इंजीनियरिंग टास्क फोर्स (IETF)** द्वारा विकसित किया गया था, SIP को **RFC 3261** में परिभाषित किया गया है और यह VoIP और एकीकृत संचार के लिए de facto मानक बन गया है।
+SIP (Session Initiation Protocol) एक **signaling and call control protocol** है जो IP नेटवर्क पर वॉइस, वीडियो और इंस्टेंट मैसेजिंग सहित मल्टीमीडिया सेशनों की स्थापना, संशोधन और समाप्ति के लिए व्यापक रूप से उपयोग होता है। **Internet Engineering Task Force (IETF)** द्वारा विकसित, SIP **RFC 3261** में परिभाषित है और VoIP और यूनिफाइड कम्युनिकेशन के लिए de facto मानक बन गया है।

-SIP की कुछ प्रमुख विशेषताएँ हैं:
+SIP की कुछ प्रमुख विशेषताएँ:

-1. **पाठ-आधारित प्रोटोकॉल**: SIP एक पाठ-आधारित प्रोटोकॉल है, जो इसे मानव-पठनीय और डिबग करने में आसान बनाता है। यह HTTP के समान एक अनुरोध-प्रतिक्रिया मॉडल पर आधारित है, और कॉल सत्रों को नियंत्रित करने के लिए INVITE, ACK, BYE, और CANCEL जैसे तरीकों का उपयोग करता है।
-2. **स्केलेबिलिटी और लचीलापन**: SIP अत्यधिक स्केलेबल है और इसे छोटे पैमाने पर तैनाती के साथ-साथ बड़े उद्यम और कैरियर-ग्रेड वातावरण में भी उपयोग किया जा सकता है। इसे नए फीचर्स के साथ आसानी से विस्तारित किया जा सकता है, जिससे यह विभिन्न उपयोग के मामलों और आवश्यकताओं के लिए अनुकूलनीय बनता है।
-3. **इंटरऑपरेबिलिटी**: SIP की व्यापक स्वीकृति और मानकीकरण विभिन्न उपकरणों, अनुप्रयोगों और सेवा प्रदाताओं के बीच बेहतर इंटरऑपरेबिलिटी सुनिश्चित करता है, जिससे विभिन्न प्लेटफार्मों के बीच निर्बाध संचार को बढ़ावा मिलता है।
-4. **मॉड्यूलर डिज़ाइन**: SIP अन्य प्रोटोकॉल जैसे **RTP (रीयल-टाइम ट्रांसपोर्ट प्रोटोकॉल)** के साथ मीडिया ट्रांसमिशन के लिए और **SDP (सत्र विवरण प्रोटोकॉल)** के साथ मल्टीमीडिया सत्रों का वर्णन करने के लिए काम करता है। यह मॉड्यूलर डिज़ाइन विभिन्न मीडिया प्रकारों और कोडेक्स के साथ अधिक लचीलापन और संगतता की अनुमति देता है।
-5. **प्रॉक्सी और रीडायरेक्ट सर्वर**: SIP कॉल रूटिंग को सुविधाजनक बनाने और कॉल फॉरवर्डिंग, कॉल ट्रांसफर, और वॉयसमेल सेवाओं जैसी उन्नत सुविधाएँ प्रदान करने के लिए प्रॉक्सी और रीडायरेक्ट सर्वरों का उपयोग कर सकता है।
-6. **उपस्थिति और तात्कालिक संदेश**: SIP केवल आवाज और वीडियो संचार तक सीमित नहीं है। यह उपस्थिति और तात्कालिक संदेश का भी समर्थन करता है, जिससे एक विस्तृत श्रृंखला के एकीकृत संचार अनुप्रयोगों को सक्षम बनाता है।
+1. **Text-based Protocol**: SIP एक टेक्स्ट-आधारित प्रोटोकॉल है, जो इसे मानव-पठनीय और डिबग करने में आसान बनाता है। यह HTTP जैसे request-response मॉडल पर आधारित है, और कॉल सेशंस को नियंत्रित करने के लिए INVITE, ACK, BYE, और CANCEL जैसे methods का उपयोग करता है।
+2. **Scalability and Flexibility**: SIP अत्यधिक स्केलेबल है और छोटे-स्केल परिनियोजनों से लेकर बड़े एंटरप्राइज़ और कैरियर-ग्रेड वातावरण तक उपयोग किया जा सकता है। इसे नए फीचर्स के साथ आसानी से एक्सटेंड किया जा सकता है, जिससे यह विभिन्न उपयोग-मामलों और आवश्यकताओं के अनुकूल बनता है।
+3. **Interoperability**: SIP की व्यापक अपनाने और मानकीकरण के कारण विभिन्न डिवाइस, एप्लिकेशन और सेवा प्रदाताओं के बीच बेहतर इंटरऑपरेबिलिटी सुनिश्चित होती है, जिससे विभिन्न प्लेटफ़ॉर्म पर सहज संचार संभव होता है।
+4. **Modular Design**: SIP अन्य प्रोटोकॉल के साथ काम करता है जैसे मीडिया ट्रांसमिशन के लिए **RTP (Real-time Transport Protocol)** और मल्टीमीडिया सत्रों का वर्णन करने के लिए **SDP (Session Description Protocol)**। यह मॉड्यूलर डिज़ाइन विभिन्न मीडिया प्रकारों और codecs के साथ अधिक लचीलापन और संगतता प्रदान करता है।
+5. **Proxy and Redirect Servers**: SIP कॉल रूटिंग को सुविधाजनक बनाने और कॉल फॉरवर्डिंग, कॉल ट्रांसफर और वॉइसमेल जैसी उन्नत सेवाएँ प्रदान करने के लिए proxy और redirect servers का उपयोग कर सकता है।
+6. **Presence and Instant Messaging**: SIP केवल वॉइस और वीडियो संचार तक सीमित नहीं है। यह presence और instant messaging का भी समर्थन करता है, जिससे यूनिफाइड कम्युनिकेशन एप्लिकेशन की एक विस्तृत रेंज संभव होती है।

-इसके कई लाभों के बावजूद, SIP को कॉन्फ़िगर और प्रबंधित करना जटिल हो सकता है, विशेष रूप से NAT ट्रैवर्सल और फ़ायरवॉल मुद्दों से निपटने के दौरान। हालाँकि, इसकी बहुपरकारीता, स्केलेबिलिटी, और उद्योग में व्यापक समर्थन इसे VoIP और मल्टीमीडिया संचार के लिए एक लोकप्रिय विकल्प बनाते हैं।
+कई फायदे होने के बावजूद, NAT traversal और फ़ायरवॉल मुद्दों से निपटते समय SIP को कॉन्फ़िगर और मैनेज करना जटिल हो सकता है। फिर भी, इसकी बहुमुखी प्रतिभा, स्केलेबिलिटी और उद्योग भर में व्यापक समर्थन इसे VoIP और मल्टीमीडिया संचार के लिए लोकप्रिय विकल्प बनाते हैं।

 ### SIP Methods

-**RFC 3261** में परिभाषित मुख्य SIP विधियाँ हैं:
+RFC 3261 में परिभाषित कोर SIP मेथड्स में शामिल हैं:

-1. **INVITE**: एक नए सत्र (कॉल) की **शुरुआत करने** या एक मौजूदा को संशोधित करने के लिए उपयोग किया जाता है। INVITE विधि सत्र विवरण (आमतौर पर SDP का उपयोग करके) ले जाती है ताकि प्राप्तकर्ता को प्रस्तावित सत्र के विवरण के बारे में सूचित किया जा सके, जैसे मीडिया प्रकार, कोडेक्स, और परिवहन प्रोटोकॉल।
-2. **ACK**: एक INVITE अनुरोध के अंतिम प्रतिक्रिया की **प्राप्ति की पुष्टि करने** के लिए भेजा जाता है। ACK विधि INVITE लेनदेन की विश्वसनीयता सुनिश्चित करती है।
-3. **BYE**: एक स्थापित सत्र (कॉल) को **समाप्त करने** के लिए उपयोग किया जाता है। BYE विधि सत्र में किसी भी पक्ष द्वारा भेजी जाती है ताकि यह संकेत दिया जा सके कि वे संचार समाप्त करना चाहते हैं।
-4. **CANCEL**: सत्र स्थापित होने से पहले एक लंबित INVITE अनुरोध को **रद्द करने** के लिए भेजा जाता है। CANCEL विधि भेजने वाले को INVITE लेनदेन को रद्द करने की अनुमति देती है यदि वे अपना मन बदलते हैं या यदि प्राप्तकर्ता से कोई प्रतिक्रिया नहीं होती है।
-5. **OPTIONS**: एक SIP सर्वर या उपयोगकर्ता एजेंट की **क्षमताओं का प्रश्न करने** के लिए उपयोग किया जाता है। OPTIONS विधि को सत्र स्थापित किए बिना समर्थित विधियों, मीडिया प्रकारों, या अन्य एक्सटेंशन के बारे में जानकारी मांगने के लिए भेजा जा सकता है।
-6. **REGISTER**: एक उपयोगकर्ता एजेंट द्वारा **SIP रजिस्ट्रार सर्वर के साथ अपनी वर्तमान स्थिति को पंजीकृत करने** के लिए उपयोग किया जाता है। REGISTER विधि उपयोगकर्ता के SIP URI और उनके वर्तमान IP पते के बीच अद्यतन मानचित्रण बनाए रखने में मदद करती है, जिससे कॉल रूटिंग और डिलीवरी सक्षम होती है।
+1. **INVITE**: एक नया सेशन (कॉल) शुरू करने या मौजूदा सेशन को संशोधित करने के लिए उपयोग किया जाता है। INVITE method session description (आमतौर पर SDP का उपयोग करते हुए) के साथ प्राप्तकर्ता को प्रस्तावित सेशन के विवरण, जैसे मीडिया प्रकार, codecs, और ट्रांसपोर्ट प्रोटोकॉल, के बारे में सूचित करती है।
+2. **ACK**: INVITE अनुरोध के अंतिम उत्तर की प्राप्ति की पुष्टि करने के लिए भेजा जाता है। ACK method INVITE लेन-देन की विश्वसनीयता सुनिश्चित करने के लिए end-to-end acknowledgement प्रदान करता है।
+3. **BYE**: एक स्थापित सेशन (कॉल) को समाप्त करने के लिए उपयोग किया जाता है। BYE method सेशन में किसी भी पक्ष द्वारा भेजा जा सकता है जो संचार समाप्त करना चाहता है।
+4. **CANCEL**: सेशन स्थापित होने से पहले लंबित INVITE अनुरोध को रद्द करने के लिए भेजा जाता है। CANCEL method भेजने वाले को INVITE लेन-देन को रद्द करने की अनुमति देता है यदि उसने मन बदल लिया हो या प्राप्तकर्ता से कोई प्रतिक्रिया न मिली हो।
+5. **OPTIONS**: SIP सर्वर या user agent की क्षमताओं का परीक्षण करने के लिए उपयोग किया जाता है। OPTIONS method बिना सेशन स्थापित किए समर्थित मेथड्स, मीडिया प्रकारों, या अन्य एक्सटेंशनों के बारे में जानकारी मांगने के लिए भेजी जा सकती है।
+6. **REGISTER**: एक user agent द्वारा अपने वर्तमान स्थान को SIP registrar server के साथ रजिस्टर करने के लिए उपयोग किया जाता है। REGISTER method उपयोगकर्ता के SIP URI और उनके वर्तमान IP पते के बीच अपडेटेड मैपिंग बनाए रखने में मदद करता है, जिससे कॉल रूटिंग और डिलीवरी सक्षम होती है।

 > [!WARNING]
-> ध्यान दें कि किसी को कॉल करने के लिए **REGISTER** का उपयोग करना आवश्यक नहीं है।\
-> हालाँकि, यह संभव है कि **INVITE** करने के लिए कॉल करने वाले को पहले **प्रमाणित** होना पड़े या उसे **`401 Unauthorized`** प्रतिक्रिया प्राप्त होगी।
+> ध्यान दें कि किसी को कॉल करने के लिए किसी भी चीज़ के लिए **REGISTER का उपयोग करना आवश्यक नहीं है**।\\
+> हालांकि, यह संभव है कि **INVITE** करने के लिए कॉलर को पहले प्रमाणीकृत होना पड़े अन्यथा उसे **`401 Unauthorized`** प्रतिक्रिया मिल सकती है।

-इन मुख्य विधियों के अलावा, अन्य RFCs में परिभाषित **कई SIP एक्सटेंशन विधियाँ** हैं, जैसे:
+इन कोर मेथड्स के अलावा, अन्य RFCs में परिभाषित कई SIP एक्सटेंशन मेथड्स भी हैं, जैसे:

-1. **SUBSCRIBE**: RFC 6665 में परिभाषित, SUBSCRIBE विधि का उपयोग एक विशिष्ट संसाधन की स्थिति के बारे में **सूचनाएँ मांगने** के लिए किया जाता है, जैसे उपयोगकर्ता की उपस्थिति या कॉल स्थिति।
-2. **NOTIFY**: RFC 6665 में भी परिभाषित, NOTIFY विधि एक सर्वर द्वारा एक **सदस्यता प्राप्त उपयोगकर्ता एजेंट** को निगरानी किए गए संसाधन की स्थिति में परिवर्तनों के बारे में सूचित करने के लिए भेजी जाती है।
-3. **REFER**: RFC 3515 में परिभाषित, REFER विधि का उपयोग **प्राप्तकर्ता से एक ट्रांसफर करने या तीसरे पक्ष को संदर्भित करने** के लिए किया जाता है। इसका उपयोग आमतौर पर **कॉल ट्रांसफर** परिदृश्यों के लिए किया जाता है।
-4. **MESSAGE**: RFC 3428 में परिभाषित, MESSAGE विधि का उपयोग SIP उपयोगकर्ता एजेंटों के बीच **तात्कालिक संदेश भेजने** के लिए किया जाता है, जिससे SIP ढांचे के भीतर पाठ-आधारित संचार सक्षम होता है।
-5. **UPDATE**: RFC 3311 में परिभाषित, UPDATE विधि **मौजूदा संवाद की स्थिति को प्रभावित किए बिना एक सत्र को संशोधित करने** की अनुमति देती है। यह एक चल रही कॉल के दौरान कोडेक्स या मीडिया प्रकारों जैसे सत्र पैरामीटर को अपडेट करने के लिए उपयोगी है।
-6. **PUBLISH**: RFC 3903 में परिभाषित, PUBLISH विधि का उपयोग एक उपयोगकर्ता एजेंट द्वारा **एक सर्वर पर घटना स्थिति जानकारी प्रकाशित करने** के लिए किया जाता है, जिससे इसे अन्य इच्छुक पक्षों के लिए उपलब्ध कराया जा सके।
+1. **SUBSCRIBE**: RFC 6665 में परिभाषित, SUBSCRIBE method किसी विशिष्ट संसाधन की स्थिति, जैसे उपयोगकर्ता की presence या कॉल स्थिति, के बारे में सूचनाएँ अनुरोध करने के लिए उपयोग की जाती है।
+2. **NOTIFY**: RFC 6665 में परिभाषित, NOTIFY method सर्वर द्वारा एक सब्स्क्राइब्ड user agent को मॉनिटर किए गए संसाधन की स्थिति में परिवर्तनों के बारे में सूचित करने के लिए भेजी जाती है।
+3. **REFER**: RFC 3515 में परिभाषित, REFER method उस प्राप्तकर्ता से अनुरोध करने के लिए उपयोग की जाती है कि वह किसी ट्रांसफर को निष्पादित करे या किसी तीसरे पक्ष को रेफ़र करे। यह आम तौर पर कॉल ट्रांसफर परिदृश्यों के लिए उपयोग होता है।
+4. **MESSAGE**: RFC 3428 में परिभाषित, MESSAGE method SIP user agents के बीच instant messages भेजने के लिए उपयोग की जाती है, जिससे SIP फ्रेमवर्क के भीतर टेक्स्ट-आधारित संचार संभव होता है।
+5. **UPDATE**: RFC 3311 में परिभाषित, UPDATE method मौजूदा dialog की स्थिति को प्रभावित किए बिना सेशन को संशोधित करने की अनुमति देती है। यह चल रही कॉल के दौरान codecs या मीडिया प्रकार जैसे सेशन पैरामीटर अपडेट करने के लिए उपयोगी है।
+6. **PUBLISH**: RFC 3903 में परिभाषित, PUBLISH method एक user agent द्वारा event state जानकारी को सर्वर पर प्रकाशित करने के लिए उपयोग की जाती है, जिससे यह अन्य इच्छुक पार्टियों के लिए उपलब्ध हो जाती है।

-### SIP Response Codes
+### SIP प्रतिक्रिया कोड

- **1xx (प्रारंभिक प्रतिक्रियाएँ)**: ये प्रतिक्रियाएँ इंगित करती हैं कि अनुरोध प्राप्त हुआ था, और सर्वर इसे संसाधित करना जारी रख रहा है।
- 100 Trying: अनुरोध प्राप्त हुआ, और सर्वर इस पर काम कर रहा है।
- 180 Ringing: कॉल करने वाले को सूचित किया जा रहा है और वह कॉल लेगा।
+- **1xx (Provisional Responses)**: ये प्रतिक्रियाएँ सूचित करती हैं कि अनुरोध प्राप्त कर लिया गया है और सर्वर इसे प्रोसेस करना जारी रख रहा है।
+- 100 Trying: अनुरोध प्राप्त कर लिया गया है, और सर्वर उस पर काम कर रहा है।
+- 180 Ringing: कॉल किए जा रहे व्यक्ति को अलर्ट किया जा रहा है और वह कॉल उठाएगा।
 - 183 Session Progress: कॉल की प्रगति के बारे में जानकारी प्रदान करता है।
- **2xx (सफल प्रतिक्रियाएँ)**: ये प्रतिक्रियाएँ इंगित करती हैं कि अनुरोध सफलतापूर्वक प्राप्त, समझा और स्वीकार किया गया।
- 200 OK: अनुरोध सफल रहा, और सर्वर ने इसे पूरा कर लिया।
- 202 Accepted: अनुरोध को संसाधित करने के लिए स्वीकार किया गया, लेकिन यह अभी पूरा नहीं हुआ है।
- **3xx (रीडायरेक्शन प्रतिक्रियाएँ)**: ये प्रतिक्रियाएँ इंगित करती हैं कि अनुरोध को पूरा करने के लिए आगे की कार्रवाई की आवश्यकता है, आमतौर पर एक वैकल्पिक संसाधन से संपर्क करके।
+- **2xx (Successful Responses)**: ये प्रतिक्रियाएँ सूचित करती हैं कि अनुरोध सफलतापूर्वक प्राप्त, समझा और स्वीकार कर लिया गया है।
+- 200 OK: अनुरोध सफल रहा और सर्वर ने उसे पूरा कर दिया है।
+- 202 Accepted: अनुरोध प्रोसेसिंग के लिए स्वीकार कर लिया गया है, लेकिन यह अभी पूरा नहीं हुआ है।
+- **3xx (Redirection Responses)**: ये प्रतिक्रियाएँ सूचित करती हैं कि अनुरोध को पूरा करने के लिए आगे की कार्रवाई की आवश्यकता है, सामान्यतः किसी वैकल्पिक संसाधन से संपर्क करके।
 - 300 Multiple Choices: कई विकल्प उपलब्ध हैं, और उपयोगकर्ता या क्लाइंट को एक चुनना होगा।
- 301 Moved Permanently: अनुरोधित संसाधन को एक नया स्थायी URI सौंपा गया है।
- 302 Moved Temporarily: अनुरोधित संसाधन अस्थायी रूप से एक अलग URI पर उपलब्ध है।
- 305 Use Proxy: अनुरोध को एक निर्दिष्ट प्रॉक्सी पर भेजा जाना चाहिए।
- **4xx (क्लाइंट त्रुटि प्रतिक्रियाएँ)**: ये प्रतिक्रियाएँ इंगित करती हैं कि अनुरोध में खराब वाक्यविन्यास है या इसे सर्वर द्वारा पूरा नहीं किया जा सकता।
- 400 Bad Request: अनुरोध गलत या अमान्य था।
- 401 Unauthorized: अनुरोध के लिए उपयोगकर्ता प्रमाणीकरण की आवश्यकता है।
- 403 Forbidden: सर्वर ने अनुरोध को समझा लेकिन इसे पूरा करने से इनकार कर दिया।
+- 301 Moved Permanently: अनुरोधित संसाधन का स्थायी रूप से नया URI असाइन कर दिया गया है।
+- 302 Moved Temporarily: अनुरोधित संसाधन अस्थायी रूप से किसी अलग URI पर उपलब्ध है।
+- 305 Use Proxy: अनुरोध को निर्दिष्ट proxy को भेजना होगा।
+- **4xx (Client Error Responses)**: ये प्रतिक्रियाएँ सूचित करती हैं कि अनुरोध में खराब सिन्टैक्स है या सर्वर द्वारा इसे पूरा नहीं किया जा सकता।
+- 400 Bad Request: अनुरोध malformed या अमान्य था।
+- 401 Unauthorized: अनुरोध को उपयोगकर्ता प्रमाणीकरण की आवश्यकता है।
+- 403 Forbidden: सर्वर ने अनुरोध को समझा लेकिन उसे पूरा करने से इनकार कर दिया।
 - 404 Not Found: अनुरोधित संसाधन सर्वर पर नहीं मिला।
- 408 Request Timeout: सर्वर ने उस समय के भीतर एक पूर्ण अनुरोध प्राप्त नहीं किया जब वह प्रतीक्षा करने के लिए तैयार था।
- 486 Busy Here: कॉल करने वाला वर्तमान में व्यस्त है और कॉल नहीं ले सकता।
- **5xx (सर्वर त्रुटि प्रतिक्रियाएँ)**: ये प्रतिक्रियाएँ इंगित करती हैं कि सर्वर ने एक मान्य अनुरोध को पूरा करने में विफलता दिखाई।
- 500 Internal Server Error: सर्वर ने अनुरोध को संसाधित करते समय एक त्रुटि का सामना किया।
- 501 Not Implemented: सर्वर उस कार्यक्षमता का समर्थन नहीं करता है जो अनुरोध को पूरा करने के लिए आवश्यक है।
+- 408 Request Timeout: सर्वर को एक पूरा अनुरोध उस समय सीमा के भीतर प्राप्त नहीं हुआ जिसे वह इंतज़ार करने के लिए तैयार था।
+- 486 Busy Here: कॉल किए जा रहे व्यक्ति वर्तमान में व्यस्त है और कॉल नहीं ले सकता।
+- **5xx (Server Error Responses)**: ये प्रतिक्रियाएँ सूचित करती हैं कि सर्वर एक वैध अनुरोध को पूरा करने में विफल रहा।
+- 500 Internal Server Error: अनुरोध को प्रोसेस करते समय सर्वर ने एक त्रुटि का सामना किया।
+- 501 Not Implemented: सर्वर के पास अनुरोध को पूरा करने के लिए आवश्यक कार्यक्षमता का समर्थन नहीं है।
 - 503 Service Unavailable: सर्वर वर्तमान में रखरखाव या ओवरलोड के कारण अनुरोध को संभालने में असमर्थ है।
- **6xx (वैश्विक विफलता प्रतिक्रियाएँ)**: ये प्रतिक्रियाएँ इंगित करती हैं कि अनुरोध को किसी भी सर्वर द्वारा पूरा नहीं किया जा सकता।
- 600 Busy Everywhere: कॉल के लिए सभी संभावित गंतव्य व्यस्त हैं।
- 603 Decline: कॉल करने वाला कॉल में भाग लेना नहीं चाहता।
+- **6xx (Global Failure Responses)**: ये प्रतिक्रियाएँ सूचित करती हैं कि कोई भी सर्वर अनुरोध को पूरा नहीं कर सकता।
+- 600 Busy Everywhere: कॉल के सभी संभावित गंतव्य व्यस्त हैं।
+- 603 Decline: कॉल किए जा रहे व्यक्ति कॉल में भाग लेना नहीं चाहता।
 - 604 Does Not Exist Anywhere: अनुरोधित संसाधन नेटवर्क में कहीं भी उपलब्ध नहीं है।

-## Examples
+## उदाहरण

-### SIP INVITE Example
+### SIP INVITE उदाहरण
 ```
 INVITE sip:jdoe@example.com SIP/2.0
 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
@ -94,43 +94,43 @@ s=-
 c=IN IP4 pc33.example.com
 t=0 0
 m=audio 49170 RTP/AVP 0
-a=rtpmap:0 PCMU/8000te
+a=rtpmap:0 PCMU/8000
 ```
 <details>

-<summary>प्रत्येक पैरामीटर की व्याख्या</summary>
+<summary>प्रत्येक पैरामीटर का विवरण</summary>

-1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - यह पंक्ति विधि (INVITE), अनुरोध URI (sip:[jdoe@example.com](mailto:jdoe@example.com)), और SIP संस्करण (SIP/2.0) को दर्शाती है।
-2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - Via हेडर परिवहन प्रोटोकॉल (UDP) और क्लाइंट का पता (pc33.example.com) निर्दिष्ट करता है। "branch" पैरामीटर लूप पहचान और लेनदेन मिलान के लिए उपयोग किया जाता है।
-3. **Max-Forwards**: `Max-Forwards: 70` - यह हेडर फ़ील्ड प्रॉक्सी द्वारा अनुरोध को आगे बढ़ाने की अधिकतम संख्या को सीमित करता है ताकि अनंत लूप से बचा जा सके।
-4. **To**: `To: John Doe <sip:jdoe@example.com>` - To हेडर कॉल के प्राप्तकर्ता को निर्दिष्ट करता है, जिसमें उनका प्रदर्शन नाम (John Doe) और SIP URI (sip:[jdoe@example.com](mailto:jdoe@example.com)) शामिल है।
-5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - From हेडर कॉल के प्रेषक को निर्दिष्ट करता है, जिसमें उनका प्रदर्शन नाम (Jane Smith) और SIP URI (sip:[jsmith@example.org](mailto:jsmith@example.org)) शामिल है। "tag" पैरामीटर संवाद में प्रेषक की भूमिका को अद्वितीय रूप से पहचानने के लिए उपयोग किया जाता है।
-6. **Call-ID**: `Call-ID: a84b4c76e66710` - Call-ID हेडर दो उपयोगकर्ता एजेंटों के बीच कॉल सत्र को अद्वितीय रूप से पहचानता है।
-7. **CSeq**: `CSeq: 314159 INVITE` - CSeq हेडर में एक अनुक्रम संख्या और अनुरोध में उपयोग की गई विधि होती है। इसका उपयोग प्रतिक्रियाओं को अनुरोधों से मिलाने और क्रमबद्ध संदेशों का पता लगाने के लिए किया जाता है।
-8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - Contact हेडर प्रेषक के लिए एक सीधा मार्ग प्रदान करता है, जिसका उपयोग बाद के अनुरोधों और प्रतिक्रियाओं के लिए किया जा सकता है।
-9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - User-Agent हेडर प्रेषक के सॉफ़्टवेयर या हार्डवेयर के बारे में जानकारी प्रदान करता है, जिसमें इसका नाम और संस्करण शामिल है।
-10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Allow हेडर प्रेषक द्वारा समर्थित SIP विधियों की सूची देता है। यह प्राप्तकर्ता को समझने में मदद करता है कि संचार के दौरान कौन सी विधियाँ उपयोग की जा सकती हैं।
-11. **Content-Type**: `Content-Type: application/sdp` - Content-Type हेडर संदेश शरीर के मीडिया प्रकार को निर्दिष्ट करता है, इस मामले में, SDP (सत्र विवरण प्रोटोकॉल)।
-12. **Content-Length**: `Content-Length: 142` - Content-Length हेडर संदेश शरीर के आकार को बाइट्स में दर्शाता है।
-13. **Message Body**: संदेश शरीर में SDP सत्र विवरण होता है, जिसमें प्रस्तावित सत्र के लिए मीडिया प्रकार, कोडेक और परिवहन प्रोटोकॉल के बारे में जानकारी शामिल होती है।
+1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - यह पंक्ति मेथड (INVITE), अनुरोध URI (sip:[jdoe@example.com](mailto:jdoe@example.com)), और SIP संस्करण (SIP/2.0) को दर्शाती है।
+2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - Via हेडर ट्रांसपोर्ट प्रोटोकॉल (UDP) और क्लाइंट का पता (pc33.example.com) बताता है। "branch" पैरामीटर लूप डिटेक्शन और ट्रांज़ैक्शन मैचिंग के लिए उपयोग होता है।
+3. **Max-Forwards**: `Max-Forwards: 70` - यह हेडर फ़ील्ड प्रॉक्सी द्वारा अनुरोध को कितनी बार फ़ॉरवर्ड किया जा सकता है, इसकी सीमा निर्धारित करता है ताकि अनंत लूप से बचा जा सके।
+4. **To**: `To: John Doe <sip:jdoe@example.com>` - To हेडर कॉल का प्राप्तकर्ता निर्दिष्ट करता है, जिसमें उनका डिस्प्ले नाम (John Doe) और SIP URI (sip:[jdoe@example.com](mailto:jdoe@example.com)) शामिल है।
+5. **From**: `From: Jane Smith <sip:jsmith@example.org>;tag=1928301774` - From हेडर कॉल का प्रेषक बताता है, जिसमें उनका डिस्प्ले नाम (Jane Smith) और SIP URI (sip:[jsmith@example.org](mailto:jsmith@example.org)) शामिल है। "tag" पैरामीटर संवाद में प्रेषक की भूमिका को अद्वितीय रूप से पहचानने के लिए उपयोग होता है।
+6. **Call-ID**: `Call-ID: a84b4c76e66710` - Call-ID हेडर दो user agents के बीच एक कॉल सेशन की अनन्य पहचान करता है।
+7. **CSeq**: `CSeq: 314159 INVITE` - CSeq हेडर में एक सीक्वेंस नंबर और अनुरोध में उपयोग किया गया मेथड होता है। इसे responses को requests से मिलाने और आउट-ऑफ-ऑर्डर संदेशों का पता लगाने के लिए उपयोग किया जाता है।
+8. **Contact**: `Contact: <sip:jsmith@pc33.example.com>` - Contact हेडर प्रेषक तक सीधा मार्ग प्रदान करता है, जिसे बाद के requests और responses के लिए उपयोग किया जा सकता है।
+9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - User-Agent हेडर प्रेषक के सॉफ़्टवेयर या हार्डवेयर के बारे में जानकारी देता है, जिसमें उसका नाम और संस्करण शामिल होता है।
+10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Allow हेडर प्रेषक द्वारा समर्थित SIP methods की सूची देता है। इससे प्राप्तकर्ता को समझने में मदद मिलती है कि संचार के दौरान किन methods का उपयोग किया जा सकता है।
+11. **Content-Type**: `Content-Type: application/sdp` - Content-Type हेडर संदेश बॉडी के मीडिया प्रकार को निर्दिष्ट करता है; इस मामले में, SDP (Session Description Protocol)।
+12. **Content-Length**: `Content-Length: 142` - Content-Length हेडर संदेश बॉडी के आकार को बाइट्स में दर्शाता है।
+13. **Message Body**: The message body contains the SDP session description, which includes information about the media types, codecs, and transport protocols for the proposed session.

 - `v=0` - प्रोटोकॉल संस्करण (SDP के लिए 0)
- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - उत्पत्ति और सत्र पहचानकर्ता
- `s=-` - सत्र का नाम (एकल हाइफ़न का अर्थ है कोई सत्र नाम नहीं)
+- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - उत्पन्नकर्ता और सेशन पहचानकर्ता
+- `s=-` - सेशन नाम (एक अकेला हाइफन दर्शाता है कि कोई सेशन नाम नहीं है)
 - `c=IN IP4 pc33.example.com` - कनेक्शन जानकारी (नेटवर्क प्रकार, पता प्रकार, और पता)
- `t=0 0` - समय की जानकारी (शुरुआत और समाप्ति समय, 0 0 का अर्थ है कि सत्र सीमित नहीं है)
- `m=audio 49170 RTP/AVP 0` - मीडिया विवरण (मीडिया प्रकार, पोर्ट संख्या, परिवहन प्रोटोकॉल, और प्रारूप सूची)। इस मामले में, यह RTP/AVP (रीयल-टाइम ट्रांसपोर्ट प्रोटोकॉल / ऑडियो वीडियो प्रोफ़ाइल) का उपयोग करते हुए एक ऑडियो स्ट्रीम को निर्दिष्ट करता है और प्रारूप 0 (PCMU/8000)।
- `a=rtpmap:0 PCMU/8000` - प्रारूप (0) को कोडेक (PCMU) और इसकी घड़ी दर (8000 Hz) से मैप करने वाला विशेषता।
+- `t=0 0` - टाइमिंग जानकारी (शुरू और समाप्ति समय — 0 0 का अर्थ है कि सेशन सीमाबद्ध नहीं है)
+- `m=audio 49170 RTP/AVP 0` - मीडिया विवरण (मीडिया प्रकार, पोर्ट नंबर, ट्रांसपोर्ट प्रोटोकॉल, और फ़ॉर्मेट सूची)। इस मामले में यह RTP/AVP (Real-time Transport Protocol / Audio Video Profile) का उपयोग करते हुए एक ऑडियो स्ट्रीम और फ़ॉर्मेट 0 (PCMU/8000) निर्दिष्ट करता है।
+- `a=rtpmap:0 PCMU/8000` - फॉर्मेट (0) को codec (PCMU) और इसकी क्लॉक दर (8000 Hz) से मैप करने वाला एट्रिब्यूट।

 </details>

-### SIP REGISTER उदाहरण
+### SIP REGISTER Example

-REGISTER विधि का उपयोग सत्र आरंभ प्रोटोकॉल (SIP) में एक उपयोगकर्ता एजेंट (UA), जैसे VoIP फोन या सॉफ़्टफोन, को **SIP रजिस्ट्रार सर्वर के साथ अपनी स्थिति पंजीकृत करने** की अनुमति देने के लिए किया जाता है। यह प्रक्रिया सर्वर को यह जानने देती है **कि पंजीकृत उपयोगकर्ता के लिए आने वाले SIP अनुरोधों को कहाँ रूट करना है**। रजिस्ट्रार सर्वर आमतौर पर एक SIP प्रॉक्सी सर्वर या एक समर्पित पंजीकरण सर्वर का हिस्सा होता है।
+The REGISTER method is used in Session Initiation Protocol (SIP) to allow a user agent (UA), such as a VoIP phone or a softphone, to **SIP registrar server के साथ अपना स्थान रजिस्टर कर सके**. यह प्रक्रिया सर्वर को बताती है **कि registered user के लिए आने वाले SIP अनुरोधों को कहाँ रूट करना है**. registrar server आमतौर पर किसी SIP proxy server का हिस्सा होता है या एक समर्पित registration server होता है।

-यहाँ REGISTER प्रमाणीकरण प्रक्रिया में शामिल SIP संदेशों का एक विस्तृत उदाहरण है:
+Here's a detailed example of the SIP messages involved in a REGISTER authentication process:

-1. UA से रजिस्ट्रार सर्वर के लिए प्रारंभिक **REGISTER** अनुरोध:
+1. प्रारंभिक **REGISTER** अनुरोध UA से registrar server को:
 ```yaml
 REGISTER sip:example.com SIP/2.0
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@ -143,11 +143,11 @@ Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
-यह प्रारंभिक REGISTER संदेश UA (Alice) द्वारा रजिस्ट्रार सर्वर को भेजा जाता है। इसमें महत्वपूर्ण जानकारी शामिल होती है जैसे कि इच्छित पंजीकरण अवधि (Expires), उपयोगकर्ता का SIP URI (sip:[alice@example.com](mailto:alice@example.com)), और उपयोगकर्ता का संपर्क पता (sip:alice@192.168.1.100:5060)।
+यह आरंभिक REGISTER संदेश UA (Alice) द्वारा रजिस्ट्रार सर्वर को भेजा जाता है। इसमें महत्वपूर्ण जानकारी शामिल होती है, जैसे कि इच्छित पंजीकरण अवधि (Expires), उपयोगकर्ता का SIP URI (sip:[alice@example.com](mailto:alice@example.com)), और उपयोगकर्ता का संपर्क पता (sip:alice@192.168.1.100:5060)।

-2. **401 Unauthorized** रजिस्ट्रार सर्वर से प्रतिक्रिया:
-```css
-cssCopy codeSIP/2.0 401 Unauthorized
+2. **401 Unauthorized** प्रतिक्रिया रजिस्ट्रार सर्वर से:
+```
+SIP/2.0 401 Unauthorized
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
 From: Alice <sip:alice@example.com>;tag=565656
 To: Alice <sip:alice@example.com>;tag=7878744
@ -156,9 +156,9 @@ CSeq: 1 REGISTER
 WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
 Content-Length: 0
 ```
-पंजीकरण सर्वर "401 Unauthorized" संदेश के साथ प्रतिक्रिया करता है, जिसमें "WWW-Authenticate" हेडर शामिल होता है। इस हेडर में UA को स्वयं को प्रमाणित करने के लिए आवश्यक जानकारी होती है, जैसे कि **प्रमाणन क्षेत्र, नॉनस, और एल्गोरिदम**।
+Registrar सर्वर "401 Unauthorized" संदेश के साथ प्रतिक्रिया करता है, जिसमें "WWW-Authenticate" हेडर शामिल होता है। यह हेडर UA को स्वयं प्रमाणित करने के लिए आवश्यक जानकारी शामिल करता है, जैसे कि **authentication realm, nonce, and algorithm**।

-3. पंजीकरण अनुरोध **प्रमाणन क्रेडेंशियल्स के साथ**:
+3. REGISTER अनुरोध **प्रमाणीकरण क्रेडेंशियल्स के साथ**:
 ```vbnet
 REGISTER sip:example.com SIP/2.0
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@ -172,9 +172,9 @@ Expires: 3600
 Authorization: Digest username="alice", realm="example.com", nonce="abcdefghijk", uri="sip:example.com", response="65a8e2285879283831b664bd8b7f14d4", algorithm=MD5, cnonce="lmnopqrst", qop=auth, nc=00000001
 Content-Length: 0
 ```
-UA एक और REGISTER अनुरोध भेजता है, इस बार आवश्यक क्रेडेंशियल्स जैसे कि उपयोगकर्ता नाम, क्षेत्र, nonce, और एक प्रतिक्रिया मान शामिल करते हुए **"Authorization" हेडर** के साथ, जो प्रदान की गई जानकारी और उपयोगकर्ता के पासवर्ड का उपयोग करके गणना की जाती है।
+UA एक और REGISTER अनुरोध भेजता है, इस बार **"Authorization" header with the necessary credentials, such as the username, realm, nonce, and a response value** शामिल करते हुए, जो प्रदान की गई जानकारी और उपयोगकर्ता के password का उपयोग करके गणना की जाती है।

-इस तरह **Authorization प्रतिक्रिया** की गणना की जाती है:
+यहाँ **Authorization response** की गणना इस प्रकार की जाती है:
 ```python
 import hashlib

@ -207,7 +207,7 @@ qop = "auth"
 response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
 print(f"MD5 response value: {response}")
 ```
-4. **सफल पंजीकरण** प्रतिक्रिया रजिस्ट्रार सर्वर से:
+4. **सफल पंजीकरण** रजिस्ट्रार सर्वर से प्रतिक्रिया:
 ```yaml
 SIP/2.0 200 OK
 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
@ -219,13 +219,98 @@ Contact: <sip:alice@192.168.1.100:5060>;expires=3600
 Expires: 3600
 Content-Length: 0
 ```
-रजिस्ट्रार सर्वर द्वारा प्रदान की गई क्रेडेंशियल्स की पुष्टि करने के बाद, **यह "200 OK" प्रतिक्रिया भेजता है यह संकेत करने के लिए कि पंजीकरण सफल रहा**। प्रतिक्रिया में पंजीकृत संपर्क जानकारी और पंजीकरण के लिए समाप्ति समय शामिल होता है। इस बिंदु पर, उपयोगकर्ता एजेंट (एलीस) सफलतापूर्वक SIP रजिस्ट्रार सर्वर के साथ पंजीकृत है, और एलीस के लिए आने वाले SIP अनुरोधों को उचित संपर्क पते पर रूट किया जा सकता है।
+प्रदत्त क्रेडेंशियल्स की पुष्टि करने के बाद रजिस्ट्रार सर्वर **"200 OK" प्रतिक्रिया भेजता है ताकि यह संकेत मिले कि रजिस्ट्रेशन सफल रहा**। प्रतिक्रिया में रजिस्टर किया गया contact जानकारी और रजिस्ट्रेशन की समाप्ति समय शामिल होता है। इस बिंदु पर, user agent (Alice) सफलतापूर्वक SIP रजिस्ट्रार सर्वर के साथ रजिस्टर्ड हो चुकी है, और Alice के लिए आने वाले SIP अनुरोध उपयुक्त contact पते पर रूट किए जा सकते हैं।

 ### कॉल उदाहरण

 <figure><img src="../../../images/image (1101).png" alt=""><figcaption></figcaption></figure>

-> [!NOTE]
-> यह उल्लेख नहीं किया गया है, लेकिन उपयोगकर्ता B को कॉल प्राप्त करने से पहले **Proxy 2 को एक REGISTER संदेश भेजना होगा**।
+> [!TIP]
+> यह उल्लेख नहीं किया गया है, लेकिन User B को कॉल प्राप्त करने में सक्षम होने से पहले **REGISTER message to Proxy 2** भेजा होना चाहिए।

+
+
+---
+
+## SIP Security और Pentesting Notes
+
+यह अनुभाग व्यापक VoIP मार्गदर्शन को दोहराए बिना प्रायोगिक, प्रोटोकॉल-विशिष्ट टिप्स जोड़ता है। end-to-end VoIP attacking methodology, tools और scenarios के लिए देखिए:
+
+{{#ref}}
+../README.md
+{{#endref}}
+
+### फिंगरप्रिंटिंग और डिस्कवरी
+
+- OPTIONS request भेजें और डिवाइस और स्टैक्स का फिंगरप्रिंट करने के लिए `Allow`, `Supported`, `Server` और `User-Agent` हेडर्स की समीक्षा करें:
+
+```bash
+# nmap NSE (UDP 5060 by default)
+sudo nmap -sU -p 5060 --script sip-methods <target>
+
+# Minimal raw OPTIONS over UDP
+printf "OPTIONS sip:<target> SIP/2.0\r\nVia: SIP/2.0/UDP attacker;branch=z9\r\nFrom: <sip:probe@attacker>;tag=1\r\nTo: <sip:probe@<target>>\r\nCall-ID: 1@attacker\r\nCSeq: 1 OPTIONS\r\nMax-Forwards: 70\r\nContact: <sip:probe@attacker>\r\nContent-Length: 0\r\n\r\n" | nc -u -w 2 <target> 5060
+```
+
+### Username/Extension Enumeration व्यवहार
+
+- एनेमरेशन आमतौर पर `401/407` बनाम `404/403` के बीच के अंतर का दुरुपयोग करता है जब `REGISTER`/`INVITE` पर। सर्वरों को समान प्रतिक्रिया देने के लिए कड़ा करें।
+- Asterisk chan_sip: valid users का खुलासा टालने के लिए सामान्य रूप से `alwaysauthreject=yes` सेट करें। नए Asterisk (PJSIP) में, जब तक कोई `anonymous` endpoint परिभाषित न हो, guest calling निष्क्रिय रहता है और समान "always auth reject" व्यवहार डिफ़ॉल्ट होता है; फिर भी perimeter पर network ACLs और fail2ban लागू करें।
+
+### SIP Digest Authentication: एल्गोरिदम और क्रैकिंग
+
+- SIP आमतौर पर HTTP-Digest स्टाइल auth का उपयोग करता है। ऐतिहासिक रूप से MD5 (और MD5-sess) प्रचलित हैं; नए स्टैक RFC 8760 के अनुसार SHA-256 और SHA-512/256 का समर्थन करते हैं। आधुनिक डिप्लॉयमेंट में इन मजबूत एल्गोरिदम को प्राथमिकता दें और जहाँ संभव हो MD5 अक्षम करें।
+- pcap से offline cracking MD5 digests के लिए सरल है। challenge/response निकालने के बाद, आप hashcat mode 11400 (SIP digest, MD5) का उपयोग कर सकते हैं:
+
+```bash
+# Example hash format (single line)
+# username:realm:method:uri:nonce:cnonce:nc:qop:response
+echo 'alice:example.com:REGISTER:sip:example.com:abcdef:11223344:00000001:auth:65a8e2285879283831b664bd8b7f14d4' > sip.hash
+
+# Crack with a wordlist
+hashcat -a 0 -m 11400 sip.hash /path/to/wordlist.txt
+```
+
+> [!NOTE]
+> RFC 8760 HTTP Digest के लिए SHA-256 और SHA-512/256 को परिभाषित करता है (जो SIP द्वारा भी उपयोग होता है)। अपनाना असमान है; सुनिश्चित करें कि आपके टूल आधुनिक PBX को लक्षित करते समय इन्हें संभालते हैं।
+
+### SIP over TLS (SIPS) और WebSockets पर
+
+- सिग्नलिंग एन्क्रिप्शन:
+- `sips:` URIs और TCP/TLS सामान्यतः 5061 पर। endpoints पर प्रमाणपत्र मान्यता सत्यापित करें; कई self-signed या wildcard certs स्वीकार करते हैं, जो कमजोर डिप्लॉयमेंट में MitM को सक्षम कर सकते हैं।
+- WebRTC softphones अक्सर RFC 7118 के अनुसार SIP over WebSocket (`ws://` या `wss://`) का उपयोग करते हैं। यदि PBX WSS एक्सपोज़ करता है, तो authentication और CORS का परीक्षण करें, और HTTP front end पर भी rate limits लागू होने सुनिश्चित करें।
+
+### DoS त्वरित जाँचें (प्रोटोकॉल स्तर)
+
+- INVITE, REGISTER या malformed संदेशों की बाढ़ transaction processing को समाप्त कर सकती है।
+- UDP/5060 के लिए सरल rate-limiting उदाहरण (Linux iptables hashlimit):
+
+```bash
+# Limit new SIP packets from a single IP to 20/s with burst 40
+iptables -A INPUT -p udp --dport 5060 -m hashlimit \
+--hashlimit-name SIP --hashlimit 20/second --hashlimit-burst 40 \
+--hashlimit-mode srcip -j ACCEPT
+iptables -A INPUT -p udp --dport 5060 -j DROP
+```
+
+### हाल की, प्रासंगिक SIP-stack CVE जिन पर नजर रखें (Asterisk PJSIP)
+
+- CVE-2024-35190 (प्रकाशित May 17, 2024): विशिष्ट Asterisk रिलीज़ में, `res_pjsip_endpoint_identifier_ip` अनधिकृत SIP अनुरोधों को स्थानीय endpoint के रूप में गलत पहचान सकता था, जिससे अनधिकृत क्रियाओं या जानकारी के खुलासे की संभावना हो सकती है। 18.23.1, 20.8.1 और 21.3.1 में फिक्स किया गया। परीक्षण करते समय अपने PBX वर्शन को सत्यापित करें और जिम्मेदारी से रिपोर्ट करें।
+
+### हार्डनिंग चेकलिस्ट (SIP-विशिष्ट)
+
+- सिग्नलिंग के लिए TLS और मीडिया के लिए SRTP/DTLS-SRTP को प्राथमिकता दें; जहाँ संभव हो cleartext अक्षम करें।
+- मजबूत पासवर्ड और digest एल्गोरिदम लागू करें (जहाँ समर्थित हो SHA-256/512-256; MD5 से बचें)।
+- Asterisk के लिए:
+- chan_sip: `alwaysauthreject=yes`, `allowguest=no`, प्रति-एंडपॉइंट `permit`/`deny` CIDR ACLs।
+- PJSIP: जब तक आवश्यक न हो `anonymous` endpoint न बनाएं; endpoint `acl`/`media_acl` लागू करें; fail2ban या समकक्ष सक्षम करें।
+- SIP proxies पर topology hiding (उदा., outbound proxy/edge SBC) ताकि information leakage कम हो।
+- `OPTIONS` का कड़ाई से हैंडलिंग और rate limits; अनावश्यक methods (उदा., `MESSAGE`, `PUBLISH`) को अक्षम करें यदि आवश्यक न हों।
+
+
+
+## References
+
+- RFC 8760 – Using SHA-256 and SHA-512/256 for HTTP Digest (applies to SIP Digest too): https://www.rfc-editor.org/rfc/rfc8760
+- Asterisk GHSA advisory for CVE-2024-35190: https://github.com/asterisk/asterisk/security/advisories/GHSA-qqxj-v78h-hrf9
 {{#include ../../../banners/hacktricks-training.md}}