Здравствуйте.

Есть такая проблема нужно заставить работать связку
Addpac AP1100F <-> Asterisk 1.6.0.6 (Linux) <-> AudioCodes MP-114 FXO
по SIP с кодеком g726

В принципе достаточно будет только
Asterisk 1.6.0.6 (Linux) <-> AudioCodes MP-114 FXO
т.к. между addpac'ом и астериксом локалка, а между астериксом и audiocodes'ом интернет. Хотелось бы съэкономить трафик.

Проблема в том, что AudioCodes напрочь отказывается работать с астериксом по g726. Пишет Unsupported Media type, но только когда вызов идет от астерикса. Когда вызов идет от audiocodes'а то проблем нет.

С адпаком такая же ситуация.

Сейчас все работает на кодеке G.711 u-law и проблем нет.
Но хотелось бы все таки завести g726.

Кто-нибудь сталкивался с подобной проблемой?
В какую сторону нужно смотреть?

Пока не столкнулся :-( Но думаю на днях будет задачка аналогичная...
А в Codecs set имеется данный кодек?

конечно,
по поводу задачки, отпишите по результатам пожалуйста если вдруг задется g726,
очень интересно.

Нда! С наскока G726 не поднимается...
Надо смотреть дебаг что сам шлюз думает на эту тему..
Payload 23 мне как то не нравится...

Кстати, а что значит:

core show settings
.................
Transcode via SLIN: Enabled
.................

Может кто знает?

Нужно глядеть на SDP в INVITE'е который посылается от AudioCodes и Астериска. Дело в том что G.726 имеет несколько вариантов: G726-40, G726-32, G726-24, и G726-16 что означает соответственно 40, 32, 24, и 16 kbit/s. Астериск умеет только G726-32. Увидеть это можно в атрибуте rtpmap в SDP.
Согласно RFC 3551, G726 описывается динамическими palyload типами - то есть должен иметь payload type в диапазоне [96..127] и rtpmap этого payload типа на соответствующее именное описание (G726-40, G726-32, G726-24, или G726-16). Но это согласно RFC 3551 который появился в 2003 году. До этого был RFC 1890 который не описывал G726 кодека совсем но описывал G721 что полностью соответствует G726-32 но пользует статический payload type = 2. Подозреваю что одна из сторон пользует RFC 3551 а другая RFC 1890.
Также есть вероятность что кто-то из сторон не умеет работать с динамическими payload типами. Такое к сожалению очень часто встречается в последнее время - например многие SIP UA статически считают что payload type = 101 это всегда DTMF telephone-events (RFC 2833) хотя в реальности нужно всегда смотреть на rtpmap.

Разве * не поддерживает g726 с статическим payload?

P. S. core show codec 16 <- Что значит? Т. е. что за параметр 16 или 32 или 64 выводит и почему?

Поддерживает, но если только объявить USE_DEPRECATED_G726 перед компиляцией.
(добавить

#define USE_DEPRECATED_G726 1

в начало main/rtp.c файла и перекомпилировать астериск).
Кстати это означает что после этого астериск сможет принимать статический payload type = 2 но он все еще будет использовать динамический тип в собственных INVITE'ах (исходящих звонках).

baho_76:

P. S. core show codec 16 <- Что значит? Т. е. что за параметр 16 или 32 или 64 выводит и почему?

Число - это просто внутренний идентификатор формата в астериске - битовое представление каждого формата (см. AST_FORMAT_* в include/asterisk/frame.h).

baho_76:

Кстати, а что значит:
core show settings
.................
Transcode via SLIN: Enabled
.................
Может кто знает?

Означает что астериск при трансляции кодеков будет всегда сначала траслировать исходный фрейм в signed linear (16 bit PCM) а потом из signed linear уже будет транслировать в конечный. Тоесть например если нужно перевести ulaw в alaw то астериск будет делать так ulaw->slin->alaw даже если будет дешевле перевести напрямую ulaw->alaw

Сорри наверное за явно глупый вопрос, но я так и не нашёл как переключить в Disable...

asterisk.conf секция [options]:
transcode_via_sln = yes ; Build transcode paths via SLINEAR, instead of directly