Нет голоса при исходящем по DAHDI (плата TDM410)

[leeyoo]

Прошу помощи.
Выход на внешнюю аналоговую АТС (Panasonic TDA100) через китайскую плату TDM410 с четырьмя FXO портами.
При исходящем звонке с * нет голоса в обе стороны.

Маршрут входящего звонка: TDA100 #200 --> TDM410(FXO-1) --> DAHDI/g1 --> SIP/100
Всё ОК, звонок проходит, голос есть и Zoiper ещё до ответа на вызов, сразу пишет a-law.

В обратном направлении (исходящие звонки) - звонок проходит, но нет голоса в обе стороны и Zoiper не пишет кодек не до ответа, не после.

Ткните плиз носом, каие логи и конфиги проверить.

[Zavr2008]

TDA100 вязать так изврат, ИМХО. Можно по цифре и вполне прилично.

[leeyoo]

TDA100 - это для тестового стенда.
Вместо TDA100 будут городске анальные линии. Других пока не дают.

[Zavr2008]

лучше переубедить конечника взять по SIP и на старье просто повесить переадресации, либо (и это часто - самому оператору выгоднее) перекинуть на SIP напрямую.

[ded]

DAHDI/g1 - не совсем правильно. Это группа каналов, а не сам канал. И, даже если допустить, что сконфигурировано правильно
(CLI> dahdi show channels ?), и все четыре порта обхъединены в группу g1, то при исходящем может кидать не на тот порт.
У вас же для теста подключен скорее всего один порт FXO в абонентский порт TDA.

Установите вербозность побольше
CLI> core set verbose 5
и звоните с Zoiper. Всё будет видно, хотя, может быть непонятно. Нужно стараться понять, переводить английские слова на русский язык. Звонок должен совершаться как Dial(DAHDI/1/23456)
где 1 - номер порта FXO, а 234567 - набранный номер.

[leeyoo]

Чтобы не искать чёрную мамбу в чёрной комнате, сначала, на всякий случай напишу версии софта.

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER: Версии софта

Дистрибутив: Elastix 2.5.
#uname -a: Linux localtel 2.6.18-348.6.1.el5 #1 SMP Tue May 21 15:34:22 EDT 2013 i686 i686 i386 GNU/Linux

# dahdi_cfg -vvv
DAHDI Tools Version - 2.10.0.1
DAHDI Version: 2.10.0.1
Echo Canceller(s): OSLEC

CLI> core show version
Asterisk 11.17.1 built by palosanto @ rpmbuild32-2.elastix.palosanto.com on a i686 running Linux on 2015-04-11 22:12:09 UTC

У вас же для теста подключен скорее всего один порт FXO в абонентский порт TDA.

Уже подключил 3 линии с TDA. )))

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER: # service dahdi status

### Span 1: WCTDM/0 "Wildcard TDM410P" (MASTER)
1 FXO FXSKS (In use) (EC: OSLEC - INACTIVE) <-----тут номер 351 от TDA100
2 FXO FXSKS (In use) (EC: OSLEC - INACTIVE) <-----тут номер 352 от TDA100
3 FXO FXSKS (In use) (EC: OSLEC - INACTIVE) <-----тут номер 353 от TDA100
4 FXO FXSKS (In use) (EC: OSLEC - INACTIVE) RED

DAHDI/g1 - не совсем правильно. Это группа каналов, а не сам канал.
и все четыре порта обхъединены в группу g1, то при исходящем может кидать не на тот порт.

Спасибо вам за замечание.
В dahdi_channels.conf кажому FXO порту прописал разные группы (это я у кого-то подсмотрел).
А в веб-инетрфейсе для кадого транка прописан отдельный "DAHDi Identifier" g1 (для FXO-1), g2 (для FXO-2)...
Вызовы начианющиеся на 7, 8, 9:
с 7 --> FXO-1
с 8 --> FXO-2
с 9 --> FXO-3
Набираю в сторону TDA100 --> 7210, 8210, 9210 и каждый раз вызов приходит с разных номеров 351, 352, 353 соответственно - это видно на системнике Panasonic.

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER: dahdi_channels.conf

; Span 1: WCTDM/0 "Wildcard TDM410P" (MASTER)
;;; line="1 WCTDM/0/0 FXSKS"
signalling=fxs_ks
callerid=asreceived
group=1 ;<-- Тут группа 1
;context=from-pstn
context = from-analog
channel => 1
;callerid=
;context=default

;;; line="2 WCTDM/0/1 FXSKS"
signalling=fxs_ks
callerid=asreceived
group=2 ;<-- Тут группа 2
;context=from-pstn
context = from-analog
channel => 2
;callerid=
;context=default

;;; line="3 WCTDM/0/2 FXSKS"
signalling=fxs_ks
callerid=asreceived
group=3 ;<-- Тут группа 3
;context=from-pstn
context = from-analog
channel => 3
;callerid=
;context=default

;;; line="4 WCTDM/0/3 FXSKS"
signalling=fxs_ks
callerid=asreceived
group=4 ;<-- Тут группа 4
;context=from-pstn
context = from-analog
channel => 4
;callerid=
;context=default

Другого мануала или примера, как разбить FXO мне не попалось.
Везде создают транк и пишут g0, чтобы каналы перебирались по порядку по мере занятости - мне такое не подходит.

(CLI> dahdi show channels ?)

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER: CLI> dahdi show channels

Chan Extension Context Language MOH Interpret Blocked State Description
pseudo default default In Service
1 from-analog default In Service
2 from-analog default In Service
3 from-analog default In Service
4 from-analog default In Service

Установите вербозность побольше
CLI> core set verbose 5
и звоните с Zoiper. Всё будет видно, хотя, может быть непонятно. Нужно стараться понять, переводить английские слова на русский язык. Звонок должен совершаться как Dial(DAHDI/1/23456)
где 1 - номер порта FXO, а 234567 - набранный номер.

Вот рабочие цепочки, когда на FXO входящий вызов - всё ОК.
TDA100 (набор #351) --> TDM410(FXO-1) --> DAHDI/g1/101 --> звонит софтфон 101.
TDA100 (набор #352) --> TDM410(FXO-2) --> DAHDI/g1/102 --> звонит софтфон 102.
TDA100 (набор #353) --> TDM410(FXO-3) --> DAHDI/g1/103 --> звонит софтфон 103.
Во время звонка Zoiper сразу пишет. Codec: u-law, State:Ringing.
При ответе на вызов Codec: u-law, State:Up.
И сразу же при ответе софтфоном на вызов, лог останавливается таким событием:
> 0x9357028 -- Probation passed - setting RTP source address to 172.17.16.30:8000

В обратную сторону, когда набираешь с софтфона, то не слышно КПВ.
Zoiper, даже после ответа на звонок всегда пишет Codec: Unknown, State:Dialing.
Но стоит закричать несколько раз в трубку как голос начинает идти и меняется статус Codec: a-law, State:Up.
Только после крика в трубку в Zoiper меняется статус и в логе появляется событие:
> 0x9357028 -- Probation passed - setting RTP source address to 172.17.16.30:8000

Если молчать или просто делать "продувку" (дуть в микрофон ))) ), то ничего не будет.

Через web-интерфейс в настройках экстеншенов включена запись MixMonitor и в записи слышно всё как надо и КПВ и после ответа сразу слышно обе стороны. Но через софтфон слышно только после того как закричишь.

Нашёл сообщения от ded про Early media, но при изменении параметра progressinband = never|no|yes в sip.conf ничего не менялось.
https://forum.asterisk.ru/viewtopic.php ... 522#p97522
https://forum.asterisk.ru/viewtopic.php ... 522#p97555

Наверно, в платник отфутболите...ну хоть не на гарЭм

[ded]

1. Для контроля КПВ использовать параметры callprogress=yes и busydetect => yes, изучить файл indications.conf
2. Early media - не ваша область, это только в цифровых тел. сетях.
Читать:
http://asterisk.ru/knowledgebase/analogue
https://forum.asterisk.ru/viewtopic.php?f=5&t=1634

[leeyoo]

Описанная в этой теме проблема с КПВ при исходящих на аналоговые линии решается так:
chan_dahdi.conf --> callprogress=no (или вообще удалить).

1. Для контроля КПВ использовать параметры callprogress=yes и busydetect => yes, изучить файл indications.conf

Спасибо большое!
busydetect => yes - это сразу включил и функция корректно работает в паре с busycount.

По callprogress=yes - не понял.
По-умолчанию, в chan_dahdi.conf параметра callprogress не создаётся и он равен callprogress=no
В справке написано:

This feature can also easily detect false hangups. The symptoms of this is being disconnected in the middle of a call for no reason.
Эта функция также может легко обнаружить ложные зависания. Симптомы этого - отключение во время разговора без причины.

В моём случае она также влияет и на КПВ при звонках в направлении SIP(ext) --> DAHDI/X.

Возможно, кто-нибудь сталкивался и знает почему её включение ломает передачу КПВ и между чашечками кофе сможет провести краткий ликбез на странице форума, моей благодарности не будет предела.