Господа, кто понимает как оное согласование происходит - поделитесь опытом - что же, черт возьми, надо писать в настройках ? :) Устал я действовать методом научного тыка, тем более что не все возможные направления вызова я могу проверить... На данный момент установил что работают все варианты, если оставлено везже только ulaw/alaw , но хотелось бы для внешнего траффика использовать gsm, вот тут-то и начинаются звонки с отсутствием слышимости... В общем, есть ли алгоритм для тормозов - где чего запрещать/разрешать ?

Ну и, рядом с этим вопросом стоит вопрос про canreinvite. Ситуация немножко сложная (по крайней мере для меня), так что опишу подробней:
Планируется 2 астериска, назовем их условно A & B - для питерского и московского оффисов лавки.
A установлен в оффисе, на шлюзовой машинке с натом - т.е., имеет доступ и к внутреннему интерфейсу и к внешнему. Во внутренней сетке имеется несколько хард-телефонов. Но есть еще несколько софтфонов на ноутбуках, которые могут коннектиться как из внутренней сетки, так и снаружи. Входящие от сип-провайдера X.
B будет установлен в датацентре. К нему будут цепляться несколько клиентов из непредсказуемых мест (некоторые - из-под ната), а еще он будет принимать звонки на number@company.com , которые надо будет направить одному из "своих" юзеров, либо юзеру сервера A. Входящие от сип-провайдера Y.
Оба сервера обслуживают общее пространство номеров, с беспрепятственным соединением межу юзерами A и B и переадресацией между ними.
canreinvite=no везде - гарантирует меня от проблем с натами, и гарантирует мне слишком длинные пути соединения, с паузами и заиканиями. Могут ли гуру посоветовать - допустимо ли где-то указывать yes при такой конфигурации ?

Порядок выбора кодека будет таким, как вы укажете в настройках пира:

[servA]
...
disallow=all
allow=gsm
allow=alaw
allow=ulaw

[servВ]
...
disallow=all
allow=gsm
allow=alaw
allow=ulaw

первым будет пробоваться кодек - gsm и по порядку.
При nat=yes параметр canreinvite не действует ...

stanislav.l, тема сложная, и чтобы не действовать методом научного тыка, надо для себя понять теорию, а потом уже применять её к вашему случаю.

Теория вкратце: Астериск умеет делать транскодинг из одного кодека в другой, если этот кодек у него есть:
CLI>show translations
Ясно, что с gsm всё нормально, он бесплатный.
Далее, устройство А1 соединится с устройством А2 (через Астериск А) кодеком gsm только в случае, если кодек gsm есть на обоих устройствах. Причём если у А1 стоит параметр canreinvite=yes, то медиа поток замкнётся между А1 и А2 напрямую, а если =no, проксируется через Астериск А. То есть - без транскодинга. И будет пытаться транскодировать, если, допустим, вызов от А1 идёт alaw, но А2 готов общаться только по gsm. И тут тоже слишком много возможностей для выбора кодека: если canreinvite=yes, а при выборе в момент установления соединения не согласовались по кодекам, то RTP не пойдет напрямую, а будет проксирование медиа через Астериск с транскодингом.
Смотреть что происходит при звонке лучше в командной строке, если видим native bridged, то устройства замкнулись по одному кодеку, и это видно
CLI>sip show channels.
В Вашем случае мне видится замкнуть А и В по IAX2, он более прозрачен к выбору кодеков, но указывать устройствам canreinvite=yes создаст проблемы. Если к В

будут цепляться несколько клиентов из непредсказуемых мест (некоторые - из-под ната), а еще он будет принимать звонки на number@company.com,

то позаботьтесь о наличии у этих клиентов кодека gsm, а если нет - g726, g729, g723, но тогда обеспеьте транскодинг на Астериске В.

Вообще, проблема с односторонней слышимостью/отсутствием слышимости - это ИСКЛЮЧИТЕЛЬНО нат[ы], или это все-таки может быть несогласование кодеков ?...

(Меня старшие товарищи слегка запутали :) ) По логике, при невозможности согласовать кодеки - соединение просто не должно состояться, ведь так ?

У меня наблюдается такая странность. Мы взяли на пробу питерский номер от телфин для входящих. (Исходящие через воипчип) Так вот, у меня спокойно соединяются все мои юзеры, делаю входящие через телфин - и на тот номер что мы у них взяли, и на "внутренний" номер через их "номер доступа". Все прекрасно и удивительно, КРОМЕ : когда мне звонит девушка из абонентского отдела телфин - в трубке тишина! Я не могу понять в чем дело, у меня мозги вскипают...
(Конечно, можно плюнуть, не так уж мне жизненно важно получать звонки изнутри телфина, но сам факт что я чего-то недокрутил сильно действует на нервы...)

включай rtp debug ip х.х.х.х и смотри откуда и куда у тебя голосовые пакеты ходят.

http://www.b2bua.org/wiki/AsteriskCodecNegotiationPatch

а кто может что-нибудь про это сказать?

Добрый день, господа гуру.
У меня возник следующий вопрос:
Есть в нашей организации абоненты, которые подключаются к сети предприятия посредвтвом GPRS интернета предоставляемого нам мобильным оператором. При установки SIP клиента у абонента есть возможность производить звонки через *, и даже при использовании самых сжатых кодеков (g729, g723, gsm) качество речи на грани фола, а иногда вообще просто обрывки слов или даже звуков. Скажите пожалуйста, может ли это быть из-за транскодинга производимого *, или все-таки дело в слишком малом канале upload?
Если все-таки дело в транскодинге, подскажите в каком направлении копать.
SIP телефоны Cisco используют кодек ulaw - при звонках на них речь вообще не членораздельная, набор каких-то шумов.
Пытались производить звонки по скайпу (для сравнения) посредством этого же GPRS интернета, качество речи отличное.
Заранее спасибо за ответ.

GPRS?!

В Скайпе наверное хотели сказать - немного лучше?
Поинтересуйтесь, как работает GPRS.

Через соединение 3G и кодек gsm (клиент fring в телефоне с 3G, и через 3G модем с X-Lite) - сам пользуюсь. Все нормально.
На GPRS - ни skype ни sip нормально не работали ...

Согласен, GPRS не лучшее решение, но пока по другому нельзя...
Проблема на самом деле только с голосом на стороне клиента с мобильным интернетом, т.к. аплоад не очень, но, по идее, 8 килобитные кодеки должен тянуть.
А скайп именно хорошо работал, не чуть лучше, а хорошо...
Подскажите, может где-то можно уменьшить величину пакетов, просто подскажите пожалуйста в чем может быть причина, и в каком направлении "копать" :)

alow=g729:20
alow=g723:20
alow=alaw:20