Зошто SIP повик се регистрира преку VPN, но не испраќа звук
Регистрацијата и звукот одат по различни патишта. Следете еден повик низ тунелот за да видите кои адреси може да ги користи PBX и каде RTP навистина запира.
Успешната регистрација речиси ништо не ви кажува за звукот. Софтверски телефон може со часови да одржува валидна врска со канцеларискиот PBX и сепак да доставува тишина. Тунелот ги пренесува само оние пакети што некој намерно ги испраќа во него, а повикот користи три одделни патишта: врска, поставување дијалог и RTP тек. Кога ќе ги разделите, дефектот паѓа на едно патиште наместо на зборот VPN.
Замислете преносен компјутер на домашниот Wi-Fi што врти канцелариска внатрешна линија преку одобрен тунел. PBX го автентификува корисникот, го прифаќа REGISTER, и линијата се прикажува како достапна, но повикот се поврзува со целосна тишина во една насока.
Регистрацијата врзува контакт, не медиумско патиште
Барањето REGISTER го замолува регистраторот да зачува совпаѓање помеѓу адреса на запис и еден или повеќе контактни URI. Тоа совпаѓање одговара на тесно прашање: каде новиот дијалог треба да се испрати токму сега. Не кажува ништо за тоа каде припаѓаат медиумите, а прифатената регистрација не докажува дека подоцнежниот INVITE носи достапна медиумска адреса. Регистрациите исто така истекуваат по тајмер, па телефонот што престанува да освежува ги губи дојдовните повици додека неговиот тунел сѐ уште изгледа здрав. Гледајте го истекот на контактот, а не состојбата на тунелот.
Кога софтверскиот телефон е зад тунелот, заглавието на контактот може да носи приватна адреса. PBX што го препраќа до друг краен пункт создава дијалог насочен кон мрежа до која повиканиот не може да стигне. Поставувањето rewrite_contact=yes на PJSIP крајниот пункт го тера PBX да ја замени забележаната изворна адреса, и тоа често е разликата помеѓу ѕвонење и истек на време.
Што нуди INVITE и кој може да го користи
INVITE со SDP тело предлага каде повикувачот сака да прима медиуми: адреса, порта и список кодекси. Повиканиот одговара со сопствена адреса и порта, а потоа секоја страна испраќа 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 носи адреса до која далечната страна може да стигне, и пакетите течат во двете насоки на медиумските порти. Ако некое од нив е неточно, тунелот не е местото на проблемот. Поправете го патот што паднал, па повторно пуштете го истото снимање за да ја потврдите промената. Чувањето на снимањата пред и потоа го прави следниот извештај за еднонасочен звук петминутна проверка наместо цело попладне.