SIP (Session Initiation Protocol)

Reading time: 19 minutes

बुनियादी जानकारी

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

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 का भी समर्थन करता है, जिससे यूनिफाइड कम्युनिकेशन एप्लिकेशन की एक विस्तृत रेंज संभव होती है।

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

SIP Methods

RFC 3261 में परिभाषित कोर SIP मेथड्स में शामिल हैं:

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 पते के बीच अपडेटेड मैपिंग बनाए रखने में मदद करता है, जिससे कॉल रूटिंग और डिलीवरी सक्षम होती है।

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

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 प्रतिक्रिया कोड

• 1xx (Provisional Responses): ये प्रतिक्रियाएँ सूचित करती हैं कि अनुरोध प्राप्त कर लिया गया है और सर्वर इसे प्रोसेस करना जारी रख रहा है।
• 100 Trying: अनुरोध प्राप्त कर लिया गया है, और सर्वर उस पर काम कर रहा है।
• 180 Ringing: कॉल किए जा रहे व्यक्ति को अलर्ट किया जा रहा है और वह कॉल उठाएगा।
• 183 Session Progress: कॉल की प्रगति के बारे में जानकारी प्रदान करता है।
• 2xx (Successful Responses): ये प्रतिक्रियाएँ सूचित करती हैं कि अनुरोध सफलतापूर्वक प्राप्त, समझा और स्वीकार कर लिया गया है।
• 200 OK: अनुरोध सफल रहा और सर्वर ने उसे पूरा कर दिया है।
• 202 Accepted: अनुरोध प्रोसेसिंग के लिए स्वीकार कर लिया गया है, लेकिन यह अभी पूरा नहीं हुआ है।
• 3xx (Redirection Responses): ये प्रतिक्रियाएँ सूचित करती हैं कि अनुरोध को पूरा करने के लिए आगे की कार्रवाई की आवश्यकता है, सामान्यतः किसी वैकल्पिक संसाधन से संपर्क करके।
• 300 Multiple Choices: कई विकल्प उपलब्ध हैं, और उपयोगकर्ता या क्लाइंट को एक चुनना होगा।
• 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 (Server Error Responses): ये प्रतिक्रियाएँ सूचित करती हैं कि सर्वर एक वैध अनुरोध को पूरा करने में विफल रहा।
• 500 Internal Server Error: अनुरोध को प्रोसेस करते समय सर्वर ने एक त्रुटि का सामना किया।
• 501 Not Implemented: सर्वर के पास अनुरोध को पूरा करने के लिए आवश्यक कार्यक्षमता का समर्थन नहीं है।
• 503 Service Unavailable: सर्वर वर्तमान में रखरखाव या ओवरलोड के कारण अनुरोध को संभालने में असमर्थ है।
• 6xx (Global Failure Responses): ये प्रतिक्रियाएँ सूचित करती हैं कि कोई भी सर्वर अनुरोध को पूरा नहीं कर सकता।
• 600 Busy Everywhere: कॉल के सभी संभावित गंतव्य व्यस्त हैं।
• 603 Decline: कॉल किए जा रहे व्यक्ति कॉल में भाग लेना नहीं चाहता।
• 604 Does Not Exist Anywhere: अनुरोधित संसाधन नेटवर्क में कहीं भी उपलब्ध नहीं है।

उदाहरण

SIP INVITE उदाहरण

INVITE sip:jdoe@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: John Doe <sip:jdoe@example.com>
From: Jane Smith <sip:jsmith@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:jsmith@pc33.example.com>
User-Agent: ExampleSIPClient/1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Content-Length: 142

v=0
o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com
s=-
c=IN IP4 pc33.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000

SIP REGISTER Example

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 होता है।

Here's a detailed example of the SIP messages involved in a REGISTER authentication process:

1. प्रारंभिक REGISTER अनुरोध UA से registrar server को:

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
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), और उपयोगकर्ता का संपर्क पता (sip:alice@192.168.1.100:5060)।

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
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
Content-Length: 0

Registrar सर्वर "401 Unauthorized" संदेश के साथ प्रतिक्रिया करता है, जिसमें "WWW-Authenticate" हेडर शामिल होता है। यह हेडर UA को स्वयं प्रमाणित करने के लिए आवश्यक जानकारी शामिल करता है, जैसे कि authentication realm, nonce, and algorithm।

3. REGISTER अनुरोध प्रमाणीकरण क्रेडेंशियल्स के साथ:

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
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 अनुरोध भेजता है, इस बार "Authorization" header with the necessary credentials, such as the username, realm, nonce, and a response value शामिल करते हुए, जो प्रदान की गई जानकारी और उपयोगकर्ता के password का उपयोग करके गणना की जाती है।

यहाँ Authorization response की गणना इस प्रकार की जाती है:

import hashlib

def calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop):
# 1. Calculate HA1 (concatenation of username, realm, and password)
ha1_input = f"{username}:{realm}:{password}"
ha1 = hashlib.md5(ha1_input.encode()).hexdigest()

# 2. Calculate HA2 (concatenation of method and uri)
ha2_input = f"{method}:{uri}"
ha2 = hashlib.md5(ha2_input.encode()).hexdigest()

# 3. Calculate the final response value (concatenation of h1, stuff and h2)
response_input = f"{ha1}:{nonce}:{nc}:{cnonce}:{qop}:{ha2}"
response = hashlib.md5(response_input.encode()).hexdigest()

return response

# Example usage
username = "alice"
password = "mysecretpassword"
realm = "example.com"
method = "REGISTER"
uri = "sip:example.com"
nonce = "abcdefghijk"
nc = "00000001"
cnonce = "lmnopqrst"
qop = "auth"

response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
print(f"MD5 response value: {response}")

4. सफल पंजीकरण रजिस्ट्रार सर्वर से प्रतिक्रिया:

SIP/2.0 200 OK
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
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0

प्रदत्त क्रेडेंशियल्स की पुष्टि करने के बाद रजिस्ट्रार सर्वर "200 OK" प्रतिक्रिया भेजता है ताकि यह संकेत मिले कि रजिस्ट्रेशन सफल रहा। प्रतिक्रिया में रजिस्टर किया गया contact जानकारी और रजिस्ट्रेशन की समाप्ति समय शामिल होता है। इस बिंदु पर, user agent (Alice) सफलतापूर्वक SIP रजिस्ट्रार सर्वर के साथ रजिस्टर्ड हो चुकी है, और Alice के लिए आने वाले SIP अनुरोध उपयुक्त contact पते पर रूट किए जा सकते हैं।

कॉल उदाहरण

SIP Security और Pentesting Notes

यह अनुभाग व्यापक VoIP मार्गदर्शन को दोहराए बिना प्रायोगिक, प्रोटोकॉल-विशिष्ट टिप्स जोड़ता है। end-to-end VoIP attacking methodology, tools और scenarios के लिए देखिए:

Pentesting VoIP

फिंगरप्रिंटिंग और डिस्कवरी

• OPTIONS request भेजें और डिवाइस और स्टैक्स का फिंगरप्रिंट करने के लिए Allow, Supported, Server और User-Agent हेडर्स की समीक्षा करें:

# 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) का उपयोग कर सकते हैं:

# 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

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):

# 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