Чаму 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 нясе дасяжны для далёкага боку адрас, і пакеты ідуць у абодвух напрамках на партах медыя. Калі хоць адно з гэтага няпраўда, праблема не ў тунэлі. Выпраўце шлях, які зваліўся, і паўтарыце той жа запіс, каб пацвердзіць змену. Захаванне запісаў да і пасля робіць наступную справаздачу пра аднабаковы гук пяціхвіліннай праверкай замест цэлага дня.