Ինչու 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 կապի տողը այնպես, ինչպես ուղարկվել է։
Համեմատեք այդ կապի տողի հասցեն այն հասցեի հետ, ուր հեռավոր կողմը իրականում կարող է երթուղավորել։ Այդ մեկ համեմատությունը լուծում է միակողմանի ձայնի հաշվետվությունների մեծ մասը ավելի արագ, քան ցանկացած կարգավորման վերանայում։
Գաղտնագրումը կանգ է առնում թունելի եզրին
SIP-ը TLS-ի վրա պաշտպանում է այն ազդանշանի թռիչքը, որի համար կարգավորվել է, SRTP-ը պաշտպանում է մեդիան, երբ երկու կողմերը պայմանավորվում են դրա շուրջ, իսկ թունելը պաշտպանում է երթևեկությունը իր իսկ վերջնակետերի միջև։ Դրանցից ոչ մեկը չի տալիս մյուսներին։ Թունելի ներսում գաղտնագրված զանգը կարող է դարպասից դուրս գալ բաց տեքստով դեպի PBX, և դա ձևավորման որոշում է, ոչ թե թերություն։
Նախքան տոմսը փակելը, հերթով հաստատեք երեք բան՝ գրանցումը թարմ է, SDP-ն կրում է հասցե, որին հեռավոր կողմը կարող է հասնել, և փաթեթները հոսում են երկու ուղղությամբ մեդիայի պորտերով։ Եթե դրանցից մեկը սուտ է, թունելը խնդրի տեղը չէ։ Ուղղեք ձախողված ուղին, ապա նորից գործարկեք նույն գրառումը՝ փոփոխությունը հաստատելու համար։ Նախկին և հետագա գրառումները պահելը հաջորդ միակողմանի հաշվետվությունը դարձնում է հինգ րոպեի ստուգում՝ ամբողջ կեսօրի փոխարեն։