Ого. Судя по настройке "Codec Order: (alaw|ulaw|g726|gsm|g729|g723) " порядок кодеков задавать все-таки можно. Проверил у себя - и правда, оно сохраняет тот порядок который в allow перечислен и в исходящих INVITE'ах сохраняет его. Век живи, век лечись...

однако же согласно "Codecs: 0x38090f (g723|gsm|ulaw|alaw|g726|g729|h263|h263p|h264) "

у вас не сделано
disallow=all
allow=ulaw,alaw

глобально, то есть в [general]. Я у себя делаю - и Астериск слушается - звонит на софтфон тольо тем что разрешено и не ругается что "No audio format found to offer"

проверьте что "sip show settings" + "sip show peer 252" перечисляют действительно то что сконфигурировано. И если в итоге для пира разрешен ulaw,alaw, то ошибки быть не должно - и INVITE улетит именно с этими двумя кодеками.

Set: SIP_CODEC лучше убрать чтобы не интерферировал...

сделано вот так

disallow=all
allow = alaw
allow = ulaw
allow = g726
allow = gsm
allow = g729
allow = g723
allow = h263
allow = h263p
allow = h264

dimas:

проверьте что "sip show settings" + "sip show peer 252" перечисляют действительно то что сконфигурировано. И если в итоге для пира разрешен ulaw,alaw, то ошибки быть не должно - и INVITE улетит именно с этими двумя кодеками.

Set: SIP_CODEC лучше убрать чтобы не интерферировал...

sip show peer 252
показывает то, что сконфигурировано глобально в sip.conf, т.к. отдельно для пира ничего по кодекам не скорфигурировано:

Codecs : 0x38090f (g723|gsm|ulaw|alaw|g726|g729|h263|h263p|h264)
Codec Order : (alaw|ulaw|g726|gsm|g729|g723)

[252]
host=dynamic
context=internal
type=friend
username=252
fromuser=252
fromdomain=<my domain>
nat=yes
canreinvite=no
secret=xxxxxxxxxxx
mailbox=252@default
language=ru

может и есть косяк в файлах настроек.... могу скинуть на почту, если гляните....

Ну подождите. За что мы боремся? Вам не нравится GSM кодек, вам предлагают его исключить. В пределе - вообще оставив только ULAW,ALAW. А у вас разрешены все включая gsm.

Давайте с проблемами по одной разбираться - при том конфиге что у вас есть у вас call файл никаких ошибок не генерит я полагаю?

Давайте сделаем для одного тестового пира (252)
disallow = all
allow = ulaw,alaw

После этого команда в консоле

originate SIP/252 extension EXT@CONTEXT

и посмотрите на INVITE который идет на софтфон 252. Он должен быть только с теми двумя кодеками что запрошены. Никаких ошибок типа "No audio format found to offer" быть не должно.

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

как я уже писал, если я исключаю gsm глобально - то мне тут же ругается "No audio format found to offer" даже не попытавшись позвонить...

провёл эксперимент, при выполнении команды originate SIP/252 extension <spb_number>@internal
звонок идёт нормально на 252 и через корбину в питер и соединяется по ulaw (при этом в глобальной секции кодеки перечислены как выше, у 252 про кодеки ни слова)

выполение такого call файла

Channel: Local/252@internal
Callerid: 252
MaxRetries: 0
Context: internal
Extension: <spb nubmer>
Priority: 1

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

при этом совершенно пофиг что там прописано в пире 252...
прописал у него
disallow = all
allow = ulaw,alaw
при этом при звонке из консоли, астериск шлёт инвайт с теми кодеками, что прописаны глобально, правда опять в нелепой последовательности

m=audio 10208 RTP/AVP 4 0 8 3 18 111 101
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:111 G726-32/8000
a=rtpmap:101 telephone-event/8000

но соединяет таки по ulaw

может всё таки в call файле что то не так?

я думаю, в файле...

потому как у меня тоже они работают странно, инструкции вида
exten => _X.,1,dial(sip/100)
exten => _X.,2,dial(sip/101)
exten => _X.,3,dial(sip/102)

выполняются "одновременно", т.е. даже если первый абонент свободен и может принять звонок, вызов все равно переходит на следующую инструкцию. при этом по первому каналу соединение может и пройти...

заменил обработку на использование AMI, все стало путем

Вы хотите сказать что на одних и тех же настройках originate и call-файл с одинаковыми экстеншенами работают по разному? Не очень склонен этому верить если честно потому то код который они в итоге вызывают - одинаковый:

Originate:

ast_pbx_outgoing_exten(chantech, AST_FORMAT_SLINEAR, chandata, TIMEOUT * 1000, context, exten, 1, &reason, 0, NULL, NULL, NULL, NULL, NULL);

call files:

res = ast_pbx_outgoing_exten(o->tech, AST_FORMAT_SLINEAR, o->dest, o->waittime * 1000, o->context, o->exten,o->priority, &reason, 2 /* wait to finish */, o->cid_num, o->cid_name, o->vars, o->account, NULL);

Там не откуда взяться разным способам выбора кодека - запрошенный формат в обоих случаях одинаковый.

Это код для 1.4.22. Сейчас посмотрел сорсы бранча 1.4 с репозитория - в кол файлах вообще появилась возможность кодек указывать через "Codecs: "

сейчас стоит последняя 1.4.22.1
формат значит такая:
Codecs: ulaw, alaw
?

в 1.4.22 писать в call-файлах Codecs еще нельзя.

Я в любом случае не вижу смысла с этим заморачиваться сейчас - у вас имхо проблема в другом. Я только что проверил на 1.4.21.2:

(echo Channel: Local/1011@default; echo Extension: 8003; echo Priority: 1; echo Context: default) > /var/spool/asterisk/outgoing/1.call

работает нормально - в SIP INVITE который улетает на 1011 - есть ровно те кодеки которые показывает "sip show peer 1011". И ровно в том порядке в котором они лежат в "Codec Order :".

Если же у вас SIP invite не улетает вообще если глобально disallow=gsm сказано - то надо разбираться почему.

Тоже бился на подобным на FreeBSD 7.2 + asterisk 1.4.24.1.

Как оказалось вся проблема в использовании вызова с "пустого места", т.е.
вместо "Channel: Local/252@internal" нужно вызывать реальный канал,
например "Channel: SIP/252@prov".

Похоже при использовании псевдоканала без единого лега звонка asterisk не может определится на каком кодеке ему канал открыть.

После перехода на линукс ниразу не было ничего подобного.