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 એવું સરનામું ધરાવે છે જ્યાં દૂરનો પક્ષ પહોંચી શકે છે, અને મીડિયા પોર્ટ પર પેકેટ બંને દિશામાં વહે છે. તેમાંથી કોઈ પણ ખોટું હોય તો સમસ્યા ટનલમાં નથી. જે માર્ગ નિષ્ફળ ગયો તેને સુધારો, પછી ફેરફારની ખાતરી કરવા એ જ કૅપ્ચર ફરી ચલાવો. પહેલાં અને પછીના કૅપ્ચર રાખવાથી આગલો એકમાર્ગી રિપોર્ટ આખી બપોરને બદલે પાંચ મિનિટની ચકાસણી બની જાય છે.