Защо 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, което работи добре в една локална мрежа и зле, когато едната страна е зад тесен диапазон от портове.
Задаването на direct_media=no принуждава PBX да влезе в пътя на медията, така че двата крака да завършват на адрес, който той контролира, в замяна на предвидима адресация срещу честотна лента и процесор. Когато ретранслира, PBX все още трябва да обявява достижим адрес. На хост с няколко мрежови интерфейса external_media_address и external_signaling_address в pjsip.conf решават какво се появява в SDP и в заглавките Via. Ако ги оставите незададени, PBX може да предложи локалния си адрес на извикващ, чийто единствен път е далечната страна на тунела.
Проследете всяка посока, преди да пипате настройки
Започнете с таблицата на сокетите на 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 носи адрес, достижим за далечната страна, и пакетите текат в двете посоки по портовете за медия. Ако някое от тях е невярно, тунелът не е мястото на проблема. Поправете пътя, който се е провалил, и след това повторете същия запис, за да потвърдите промяната. Запазването на записите преди и след прави следващия сигнал за еднопосочен звук петминутна проверка вместо цял следобед.