Как настроить freeSWITCH для контейнера Docker внутри boot2docker?

Я пытаюсь настроить контейнер Docker, на котором выполняется freeSWITCH, чтобы я мог развернуть его на сервере Debian.

Для разработки я использую Mac с контейнером freeSWITCH в boot2docker.

Мне нужен контейнер для работы в обеих этих средах.

Мне удается подключиться к серверу FS с помощью софтфона и сделать вызов, но через 32 секунды звонок сбрасывается.

freeswitch@internal> version
FreeSWITCH Version 1.4.15-1~64bit (-1 64bit)

Это пакет SIP 200 OK, который FS отправляет и ожидает ответа:

14  0.029449000 192.168.59.103  192.168.59.3    SIP/SDP 1312    Status: 200 OK | 

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.141:49822;rport=49822;branch=z9hG4bKPjFf3iaNQ0tDY1fySiz1zGSEXSVFpZeE2b;received=192.168.59.3
From: "1000" <sip:1000@192.168.59.103>;tag=tNpJHmkYg0ke5GYyvIhkdBSIMM.ujzXE
To: <sip:5000@192.168.59.103>;tag=6N3793jeayeUe
Call-ID: 4wWTcxr9Q4OqlgT2Fs-8SeOkLhVYXTLb
CSeq: 10007 INVITE
Contact: <sip:5000@172.17.0.6:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.4.15-1~64bit
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 333
Remote-Party-ID: "5000" <sip:5000@192.168.59.103>;party=calling;privacy=off;screen=no

v=0
o=FreeSWITCH 1422731206 1422731207 IN IP4 172.17.0.6
s=FreeSWITCH
c=IN IP4 172.17.0.6
t=0 0
m=audio 16386 RTP/SAVP 9 101
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp:16387 IN IP4 172.17.0.6
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:/NTeSA7Od0+1Uo1/3wIclZwEiKJ+R4Mh8gyTx+5O

Тогда это происходит:

1745    32.031059000    192.168.59.103  192.168.59.3    SIP 664 Request: BYE sip:29716085@192.168.59.3:49822 | 

BYE sip:29716085@192.168.59.3:49822 SIP/2.0
Via: SIP/2.0/UDP 172.17.0.6;rport;branch=z9hG4bK0m429X0ac150r
Max-Forwards: 70
From: <sip:5000@192.168.59.103>;tag=6N3793jeayeUe
To: "1000" <sip:1000@192.168.59.103>;tag=tNpJHmkYg0ke5GYyvIhkdBSIMM.ujzXE
Call-ID: 4wWTcxr9Q4OqlgT2Fs-8SeOkLhVYXTLb
CSeq: 71037748 BYE
Contact: <sip:5000@172.17.0.6:5060;transport=udp>
User-Agent: FreeSWITCH-mod_sofia/1.4.15-1~64bit
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Reason: SIP;cause=408;text="ACK Timeout"
Content-Length: 0

Я предполагаю, что FS никогда не получает ответ от софтфона из-за различных уровней NAT и сбрасывает вызов, предполагая, что он не подключился.

192.168.1.141 - это IP-адрес моего Mac в локальной сети (как показано в VIA для пакета 200 OK)

192.168.59.103 - виртуальная машина boot2docker

192.168.59.3 - мой Mac в виртуальной сети boot2docker

172.17.0.xxx - это IP-адрес сервера ФС в сети Docker (этот IP-адрес изменяется в зависимости от того, сколько контейнеров было / раньше работало)

Это то, что у меня есть в моем sip_profiles/internal.xml

<param name="rtp-ip" value="$${local_ip_v4}"/>
<!-- ip address to bind to, DO NOT USE HOSTNAMES ONLY IP ADDRESSES -->
<param name="sip-ip" value="$${local_ip_v4}"/>
<param name="hold-music" value="$${hold_music}"/>
<param name="apply-nat-acl" value="nat.auto"/>

<!-- Docker NAT magic -->
<param name="ext-rtp-ip" value="$${external_sip_ip}"/>
<param name="ext-rtp-ip" value="$${external_rtp_ip}"/>

И в моем vars.xml

  <X-PRE-PROCESS cmd="set" data="external_rtp_ip=192.168.59.103"/>
  <X-PRE-PROCESS cmd="set" data="external_sip_ip=192.168.59.103"/>

Из fs_cli:

freeswitch@internal> eval ${external_rtp_ip}
192.168.59.103
freeswitch@internal> eval ${external_sip_ip}
192.168.59.103
freeswitch@internal> eval ${ext-rtp-ip}
-ERR no reply

freeswitch@internal> eval ${ext-sip-ip}
-ERR no reply

Я установил порты 16384 в 16484 UDP для трафика RTP, 5060, 5070, 5080 UDP и TCP для SIP, как в FS, так и в контейнере.

Эхо-тест показывает, что аудио течет в обоих направлениях.

Есть идеи, что происходит и как это исправить?

Источник

2 ответа

У меня была похожая проблема с моей установкой FreeSwitch, и я решил ее, настроив коммутатор на постоянную проверку связи с зарегистрированными программными телефонами, чтобы каналы брандмауэра NAT оставались открытыми. Вот настройки, которые сделали это для меня:

            <param name="nat-options-ping" value="true"/>
            <param name="all-reg-options-ping" value="true"/>

            <!-- One successful options ping is enough to verify that a phone is reachable -->
            <param name="sip-user-ping-min" value="1"/>
            <!-- Three pings need to be lost to consider the phone disconnected -->
            <param name="sip-user-ping-max" value="4"/>

            <param name="unregister-on-options-fail" value="true"/>

            <!-- Freeswitch is coded to send
            pings at variable intervals with the mean value determined by the
            variable below and a normal distribution with a deviation of half the
            interval value. -->
            <param name="ping-mean-interval" value="15"/>

Они идут в sip_profiles/internal.xml.

Источник

Итак, вот обновление.

Оказывается, проблема была в том, что FS не смог правильно определить свой IP-адрес, а отправляемые пакеты содержали неправильный IP-адрес.

Я придумал этот скрипт как часть моей последовательности загрузки контейнера: https://github.com/Coaxial/mushimushi/blob/a29ae537314e89bc7f9808c2bd7fdb4917eafa04/lib/freeswitch_conf/start.sh#L7-L21

Затем я включаю полученный XML-файл в общую конфигурацию: https://github.com/Coaxial/mushimushi/blob/a29ae537314e89bc7f9808c2bd7fdb4917eafa04/lib/freeswitch_conf/freeswitch.xml#L3

Таким образом, я могу ссылаться на переменные для настройки соответствующих профилей Софии: https://github.com/Coaxial/mushimushi/blob/a29ae537314e89bc7f9808c2bd7fdb4917eafa04/lib/freeswitch_conf/autoload_configs/sofia.conf.xml#L29-L32

Это работает при запуске в boot2docker, но еще не проверено в бою в "ванильном" докере.

Источник
Другие вопросы по тегам