SIP کال VPN کے ذریعے رجسٹر ہوتی ہے مگر آواز کیوں نہیں بھیجتی
رجسٹریشن اور آواز الگ راستے لیتے ہیں۔ ایک کال کو سرنگ سے گزاریں تاکہ دیکھ سکیں کہ PBX کون سے پتے استعمال کر سکتا ہے اور RTP واقعی کہاں رکتا ہے۔
کامیاب رجسٹریشن آواز کے بارے میں تقریباً کچھ نہیں بتاتی۔ سافٹ فون گھنٹوں دفتر کے PBX کے ساتھ درست بندھن رکھ سکتا ہے اور پھر بھی خاموشی ہی بھیجتا ہے۔ سرنگ صرف وہی پیکٹ لے کر جاتی ہے جو کوئی جان بوجھ کر اس میں بھیجتا ہے، اور ایک کال تین الگ راستے استعمال کرتی ہے: بندھن، مکالمے کی تشکیل اور RTP کا بہاؤ۔ انہیں الگ کرتے ہی ناکامی VPN کے لفظ پر نہیں بلکہ ایک راستے پر آتی ہے۔
گھر کے Wi-Fi پر ایک لیپ ٹاپ منظور شدہ سرنگ کے ذریعے دفتر کی اندرونی لائن ملاتا ہے۔ PBX صارف کی تصدیق کرتا ہے، REGISTER قبول کرتا ہے، اور اندرونی لائن دستیاب دکھتی ہے، پھر بھی کال ایک سمت میں مکمل خاموشی کے ساتھ جڑ جاتی ہے۔
رجسٹریشن رابطہ باندھتی ہے، میڈیا کا راستہ نہیں
REGISTER درخواست رجسٹرار سے کہتی ہے کہ ریکارڈ کے پتے اور ایک یا زیادہ رابطہ URI کے درمیان نقشہ محفوظ رکھے۔ وہ نقشہ ایک تنگ سوال کا جواب دیتا ہے کہ نیا مکالمہ ابھی کہاں بھیجا جائے۔ یہ میڈیا کی جگہ کے بارے میں کچھ نہیں کہتا، اور قبول شدہ رجسٹریشن یہ ثابت نہیں کرتی کہ بعد کی INVITE قابل رسائی میڈیا پتہ رکھتی ہے۔ رجسٹریشن وقت پر ختم بھی ہوتی ہیں، اس لیے جو فون تجدید کرنا بند کر دے وہ آنے والی کالیں کھو دیتا ہے جبکہ اس کی سرنگ اب بھی صحت مند دکھتی ہے۔ سرنگ کی حالت کے بجائے رابطے کی میعاد دیکھیں۔
جب سافٹ فون سرنگ کے پیچھے ہو تو رابطہ ہیڈر نجی پتہ رکھ سکتا ہے۔ جو PBX اسے کسی دوسرے اینڈ پوائنٹ پر بھیجتا ہے وہ ایسے نیٹ ورک کی طرف مکالمہ بناتا ہے جہاں کال کی گئی فریق نہیں پہنچ سکتی۔ PJSIP اینڈ پوائنٹ پر rewrite_contact=yes مقرر کرنے سے PBX اپنا دیکھا ہوا ماخذ پتہ بدل دیتا ہے، اور اکثر گھنٹی اور ٹائم آؤٹ کے درمیان فرق یہی ہوتا ہے۔
INVITE کیا پیش کرتی ہے اور کون استعمال کر سکتا ہے
SDP باڈی والی INVITE تجویز کرتی ہے کہ کال کرنے والا میڈیا کہاں وصول کرنا چاہتا ہے: ایک پتہ، ایک پورٹ اور کوڈیک کی فہرست۔ کال کی گئی فریق اپنے پتے اور پورٹ کے ساتھ جواب دیتی ہے، پھر ہر فریق دوسرے کی تجویز کردہ جگہ RTP بھیجتا ہے۔ اگر کال کرنے والے نے 192.168.x.x جیسا پتہ تجویز کیا جو صرف اس کے گھر کے نیٹ ورک میں موجود ہے، تو سگنلنگ کتنی ہی صاف ہو، کال کی گئی فریق کے پاس آواز بھیجنے کی جگہ نہیں۔ ماسکنگ راوٹر چھوڑتے وقت پیکٹوں کے IP ہیڈر دوبارہ لکھتی ہے، مگر SDP باڈی کے اندر متن کبھی دوبارہ نہیں لکھتی۔
یہی خلا روایتی یک طرفہ کال کی وضاحت کرتا ہے: سگنلنگ کام کرتی ہے کیونکہ دونوں اینڈ پوائنٹ PBX تک پہنچتے ہیں، اور آواز ناکام ہوتی ہے کیونکہ ایک اینڈ پوائنٹ کو ایسے پتے پر بھیجنے کا کہا گیا تھا جو صرف کسی دوسرے NAT کے پیچھے موجود ہے۔
| Path | Who picks the address | Typical failure |
|---|---|---|
| REGISTER | Softphone, rewritten by the registrar if configured | Binding expires or points at a private address |
| INVITE and SDP | Each endpoint in its own offer or answer | Offer names a media address nobody can route to |
| RTP | PBX relay policy or the two endpoints | Port range blocked, or no return path |
آواز کون لے کر جاتا ہے یہ ترتیب کا انتخاب ہے
سگنلنگ اور میڈیا الگ کردار ہیں۔ پراکسی پوری کال کے دوران سگنلنگ راستے پر رہ سکتی ہے اور ایک بھی RTP پیکٹ کو نہیں چھوتی۔ PBX میڈیا ریلے بنتا ہے یا نہیں، یہ سرنگ کی موجودگی پر نہیں بلکہ ترتیب پر منحصر ہے۔
براہ راست میڈیا کے ساتھ اینڈ پوائنٹ خود RTP کا تبادلہ کرتے ہیں، جو ایک LAN پر اچھا چلتا ہے اور جب ایک فریق تنگ پورٹ رینج کے پیچھے ہو تو خراب چلتا ہے۔
direct_media=no مقرر کرنے سے PBX میڈیا راستے میں دھکیل دیا جاتا ہے تاکہ دونوں ٹانگیں اس کے کنٹرول والے پتے پر ختم ہوں، اور یہ قابل اندازہ ایڈریسنگ کے لیے بینڈوڈتھ اور پروسیسر کا تبادلہ کرتا ہے۔ ریلے کرتے وقت PBX کو پھر بھی قابل رسائی پتہ اعلان کرنا ہوتا ہے۔ کثیر نیٹ ورک ہوسٹ پر pjsip.conf میں external_media_address اور external_signaling_address طے کرتے ہیں کہ SDP میں اور Via ہیڈر میں کیا ظاہر ہوگا۔ انہیں غیر مقرر چھوڑ دیں تو PBX اپنا LAN پتہ ایسے کال کرنے والے کو پیش کر سکتا ہے جس کا واحد راستہ سرنگ کا دور والا سرا ہے۔
ترتیبات کو چھونے سے پہلے ہر سمت کا سراغ لگائیں
کال کے دوران PBX کے ساکٹ جدول سے شروع کریں: ss -uanp | grep -E '5060|10000' دکھاتا ہے کہ RTP پورٹ بندھے ہیں یا نہیں اور کون سا مقامی پتہ استعمال کرتے ہیں۔ اگر میڈیا رینج میں کچھ بندھا نہ ہو تو ریلے فعال نہیں اور اینڈ پوائنٹ خود براہ راست بات کر رہے ہیں۔ پھر سافٹ فون کی طرف tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap سے کیپچر کریں۔ آنے والے پیکٹوں کے بغیر جانے والے پیکٹ مسئلے کو واپسی کے راستے یا اس پتے تک محدود کرتے ہیں جو دور والی فریق کو استعمال کرنے کو کہا گیا، اور خالی کیپچر کا مطلب ہے کہ میڈیا سرنگ کے انٹرفیس تک کبھی نہیں پہنچا۔ sngrep کے ساتھ سگنلنگ کیپچر بقیہ نصف کا جواب دیتا ہے اور SDP کنکشن لائن بھیجے گئے روپ میں دکھاتا ہے۔
اس کنکشن لائن کے پتے کا موازنہ اس پتے سے کریں جہاں دور والی فریق واقعی راستہ بنا سکتی ہے۔ یہی ایک موازنہ زیادہ تر یک طرفہ آواز کی رپورٹوں کو کسی بھی ترتیب کے جائزے سے زیادہ تیزی سے حل کرتا ہے۔
انکرپشن سرنگ کے کنارے پر رک جاتی ہے
TLS پر SIP اس سگنلنگ چھلانگ کی حفاظت کرتی ہے جس کے لیے ترتیب دی گئی، SRTP آواز کی حفاظت کرتا ہے جب دونوں سرے اس پر متفق ہوں، اور سرنگ اپنے اینڈ پوائنٹس کے درمیان ٹریفک کی حفاظت کرتی ہے۔ ان میں سے کوئی بھی باقی کی حفاظت نہیں دیتا۔ سرنگ کے اندر انکرپٹ شدہ کال گیٹ وے چھوڑ کر PBX کی طرف سادہ متن میں جا سکتی ہے، اور یہ خرابی نہیں بلکہ ڈیزائن کا فیصلہ ہے۔
ٹکٹ بند کرنے سے پہلے تین چیزیں ترتیب سے یقینی بنائیں: رجسٹریشن تازہ ہے، SDP ایسا پتہ رکھتی ہے جہاں دور والی فریق پہنچ سکے، اور میڈیا پورٹس پر پیکٹ دونوں سمتوں میں بہہ رہے ہیں۔ ان میں سے کوئی بھی غلط ہو تو مسئلہ سرنگ میں نہیں۔ جو راستہ ناکام ہوا اسے درست کریں، پھر تبدیلی کی تصدیق کے لیے وہی کیپچر دوبارہ چلائیں۔ پہلے اور بعد کے کیپچر رکھنے سے اگلی یک طرفہ رپورٹ پوری دوپہر کے بجائے پانچ منٹ کی جانچ بن جاتی ہے۔