Чому 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 може запропонувати свою 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 несе адресу, досяжну для дальньої сторони, і пакети йдуть в обидва боки на портах медіа. Якщо щось із цього неправдиве, проблема не в тунелі. Виправте шлях, який відмовив, і потім повторіть той самий запис, щоб підтвердити зміну. Збереження записів до і після перетворює наступне повідомлення про однобічний звук на п'ятихвилинну перевірку замість цілого дня.