വിജയകരമായ രജിസ്ട്രേഷൻ ഓഡിയോയെക്കുറിച്ച് ഏതാണ്ട് ഒന്നും പറയുന്നില്ല. ഒരു സോഫ്റ്റ്ഫോൺ മണിക്കൂറുകളോളം ഓഫീസിലെ 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-ന് പിന്നിൽ മാത്രം നിലനിൽക്കുന്ന വിലാസത്തിലേക്ക് അയയ്ക്കാൻ പറഞ്ഞതിനാൽ ഓഡിയോ പരാജയപ്പെടുന്നു.

PathWho picks the addressTypical failure
REGISTERSoftphone, rewritten by the registrar if configuredBinding expires or points at a private address
INVITE and SDPEach endpoint in its own offer or answerOffer names a media address nobody can route to
RTPPBX relay policy or the two endpointsPort 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 അപ്രസ്ഥലത്തിന് എത്തിച്ചേരാവുന്ന വിലാസം വഹിക്കുന്നു, മീഡിയ പോർട്ടുകളിൽ പാക്കറ്റുകൾ ഇരു ദിശകളിലും ഒഴുകുന്നു. ഇവയിലൊന്ന് തെറ്റാണെങ്കിൽ പ്രശ്നം ടണലിലല്ല. പരാജയപ്പെട്ട വഴി ശരിയാക്കുക, തുടർന്ന് മാറ്റം ഉറപ്പാക്കാൻ അതേ ക്യാപ്ചർ വീണ്ടും പ്രവർത്തിപ്പിക്കുക. മുമ്പും ശേഷവുമുള്ള ക്യാപ്ചറുകൾ സൂക്ഷിച്ചാൽ അടുത്ത ഏകദിശാ റിപ്പോർട്ട് ഒരു ഉച്ചയ്ക്ക് പകരം അഞ്ച് മിനിറ്റ് പരിശോധനയാകും.

അനുബന്ധ ലേഖനങ്ങൾ