Кодек PCMU выбирается окончанием FXO, хотя он не поддерживается другой стороной

[san]

В настройках медиа окончания FXS я убрал кодек PCMU, однако при вызове FXS->FXO, окончание FXO отображает в столбце кодек PCMU.

Я проводил эксперимент на нашей АТС - в ней ревизия прошивки VE-01 какая-то экспериментальная - 255, так что может быть причина странностей в этом.

[alx]

Уточни, пожалуйста, какие кодеки были выбраны в конфигурации обоих канальных окончаний.

Также прошу приложить подробный (с уровнем DEBUG) лог вызова.

[san]

Пробовал повторить эксперимент в своей плате, сделав похожие настройки - у меня не получилось.
Поэтому записал лог эксперимента в АТС АДС:
Абонент FXS 324@192.168.0.4 набрал номер 2297488 и попал в окончание FXO fxo1@192.168.0.4
После соединения у FXS отображался кодек PCMA, а у FXS - PCMU
Выбранные кодеки FXS: PCMA
Выбранные кодеки FXO: PCMA, PCMU, G723.1, G729a
Лог приложу ниже

[san]

Ещё я пробовал на своём сип-телефоне оставить только кодек PCMA и позвонить через FXO на АТС АДС - аналогично FXO отображает кодек PCMU

[alx]

Replying to san:

Поэтому записал лог эксперимента в АТС АДС:
Абонент FXS 324@192.168.0.4 набрал номер 2297488 и попал в окончание FXO fxo1@192.168.0.4

В прикрепленном логе нет прямых вызовов канальным окончанием FXS канального окончания FXO. В 07:10:01 канальное окончание FXS отправляет вызов в сеть. Этот вызов приходит на коммутатор FreeSwitch, который немедленно передает ответ с кодом 183 и активирует медиапоток, о чем свидетельствует сообщение в логе "ringing with status code 183" и следующие строки, в которых видно, что медиапоток идет на адреса 192.168.0.13/fc:aa:14:33:61:6b (адреса FreeSwitch), и что этот медиапоток использует кодек PCMA:

Nov 12 07:10:01 sip_ua[406]: user_agent.cpp:2472: ---> ringing with status code 183
Nov 12 07:10:01 sip_ua[368]: fxs.cpp:432: ---> ts=17, state=Calling: RTP parameters, ts=17, flags=0000, data=7008
Nov 12 07:10:01 sip_ua[368]: comcerto.cpp:6951: --> ts 17: 192.168.0.4[10034] --> 192.168.0.13[19168]
Nov 12 07:10:01 sip_ua[368]: comcerto.cpp:6952: --> ts 17: codec PCMA, VAD is off, red=0
Nov 12 07:10:01 sip_ua[368]: comcerto.cpp:6953: --> audio pt: 8/8, event pt: 101/101, VBD pt: -1/-1
Nov 12 07:10:01 sip_ua[368]: comcerto.cpp:7048: routing 192.168.0.13 to 192.168.0.13 (eth0)
Nov 12 07:10:01 sip_ua[368]: comcerto.cpp:7059: getMac(192.168.0.13): fc:aa:14:33:61:6b
Nov 12 07:10:01 sip_ua[368]: comcerto.cpp:7069: ts 17: RTP destination is fc:aa:14:33:61:6b
Nov 12 07:10:01 sip_ua[368]: comcerto.cpp:6776: ts 17: starting RTP stream

Далее по логу видно, что в шлюз поступает входящий вызов, который принимает канальное окончание FXO, которое занимает телефонную линию, набирает номер и автивирует медиапоток, используя кодек PCMU также на адреса FreeSwitch:

Nov 12 07:10:07 sip_ua[368]: comcerto.cpp:6180: channel 33: answer
Nov 12 07:10:07 sip_ua[368]: fxo.cpp:341: ---> ts=33, state=Connected: RTP parameters, ts=33, flags=0000, data=7010
Nov 12 07:10:07 sip_ua[368]: comcerto.cpp:6951: --> ts 33: 192.168.0.4[10066] --> 192.168.0.13[27072]
Nov 12 07:10:07 sip_ua[368]: comcerto.cpp:6952: --> ts 33: codec PCMU, VAD is off, red=0
Nov 12 07:10:07 sip_ua[368]: comcerto.cpp:6953: --> audio pt: 0/0, event pt: 101/101, VBD pt: -1/-1
Nov 12 07:10:07 sip_ua[368]: comcerto.cpp:7048: routing 192.168.0.13 to 192.168.0.13 (eth0)
Nov 12 07:10:07 sip_ua[368]: comcerto.cpp:7059: getMac(192.168.0.13): fc:aa:14:33:61:6b
Nov 12 07:10:07 sip_ua[368]: comcerto.cpp:7069: ts 33: RTP destination is fc:aa:14:33:61:6b
Nov 12 07:10:07 sip_ua[368]: comcerto.cpp:6776: ts 33: starting RTP stream

Но это уже другое, новое телефонное соединение, не то, которое было ранее установлено канальным окончанием FXS. Новое телефонное соединение было инициировано коммутатором FreeFwitch, который, очевидно, указал в своем запросе INVITE наиболее приоритетным кодеком PCMU, с использованием которого и согласилось канальное окончание FXO.

Таким образом, в проведенном эксперименте все работает правильно, медиакодеки выбираются и отображаются верно. Тикет создан по ошибке.

[san]

Действительно. Забыл что и в ту сторону тоже фрисвитч учавствует в вызове.