কেন একটি 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-কে তবুও একটি পৌঁছনোযোগ্য ঠিকানা ঘোষণা করতে হয়। একাধিক নেটওয়ার্কযুক্ত হোস্টে external_media_address আর external_signaling_address, pjsip.conf-এ ঠিক করে 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 এমন ঠিকানা বহন করছে যেখানে দূর প্রান্ত পৌঁছাতে পারে, এবং মিডিয়া পোর্টে প্যাকেট দুই দিকেই চলছে। এর কোনোটির সত্যতা না থাকলে সমস্যা টানেলে নেই। যে পথটি ব্যর্থ হয়েছে তা ঠিক করুন, তারপর পরিবর্তন নিশ্চিত করতে একই ক্যাপচার আবার চালান। আগের ও পরের ক্যাপচার রেখে দিলে পরবর্তী একমুখী রিপোর্ট পুরো এক বিকেলের বদলে পাঁচ মিনিটের পরীক্ষা হয়ে যায়।