Аппарат номер 549, 18 неделя 2007 года - один из древних.

Обычно, стараются уменьшить джиттер. У ОХО глубина буфера для подавления джиттера вполне определенная.
Что означает фраза: на asterisk включили джиттер ?

А, может быть, маршрут проверить ОХО - провайдер на наличие джиттера? Если алкатель ругается - скорее всего, он есть. Для эксперимента можете перевести ком порт ОХО в режим вывода сообщений и увидите как она ругается в реальном времени.

На цифровом проводном аппарате трубку снимать не надо, dialer сам это делает.

А проводных аппаратов нет? Попробуйте с проводным аппаратом. Мне кажется, функционирование dialer c DECT трубкой не заявлено.

Выдержка из доки:
Note:
some known inconveniences of the fax over G711 (pass-through method) are listed below:
• It is not standard based and hence implementation can be different depending on the vendor
• Bandwidth usage with G711 codec is high
• As with many vendors, the PCX implementation does not offer packet redundancy. Fax
transmission is then very dependent on end-to-end performance of the IP network and reliability
is very sensible to packet loss
• End-to-end G711 transparency must be guaranteed, that means no transcoding of the media
channel is allowed through the IP network
• Voice Activity Detection (VAD) must be disabled on both sides of the fax call

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

FoIP Service
No matter the OMC setting (T.38 or G711), a SIP fax call on PCX is always established first as
a normal voice call transmitting an RTP flow. After some seconds, upon detection of the fax
tone, the FoIP service is then triggered to operate the selected T.38 or G711 choice (see Fax
T.38 Annex D or Fax over G711 ).

Fax over G711
When Fax over G711 is selected, RTP voice channels are maintained but if current codec is
G729A or G723, it is renegotiated to G711.
Fax over G711 is not compatible with Voice Activity Detection (VAD) which is a mechanism
used to save bandwidth during VoIP calls. Therefore, the PCX supports the "silenceSupp"
attribute in the SDP part of the SIP message in order to dynamically disable VAD during the
Fax over G711 media session.
This attribute is used to request the other side to disable VAD. It works as follows:
- Case of an incoming fax call: the PCX detects the fax tone in the RTP stream and sends
Re-Invite to renegotiate the media session characteristics with "silenceSupp" attribute set
to "off" in order to ask the remote side to disable VAD
• If the PCX receives a response containing "silenceSupp" attribute set to "off", it means
that remote side has disabled VAD and then the PCX disables VAD also. This is the
normal mode of operation
• If the PCX receives a response which does not contain "silenceSupp" attribute set to
"off, then VAD remains active on the PCX side. In that case fax over G.711 is not
guaranteed when VAD on both ends is not disabled
- Case of an outgoing fax call: remote side (called side) should detect fax tone. The PCX
expects to receive a Re-Invite from the remote side with "silenceSupp" attribute set to "off"
• If the PCX receives a Re-Invite request containing "silenceSupp" attribute set to "off", it
means that remote side requests to disable VAD, then the PCX disables VAD and
sends a response containing "silenceSupp" attribute set to "off" to acknowledge the
request. This is the normal mode of operation
• If the PCX receives a request which does not contain "silenceSupp" attribute set to "off,
then VAD remains active on the PCX side. In that case, fax over G.711 is not
guaranteed when VAD on both ends is not disabled
Recommendation for deployment of Fax over G711:
- If remote side supports "silenceSupp" attribute => this is the expected mode of operation
- If remote side does not support "silenceSupp" attribute => disable VAD on both the remote
side and the PCX => Fax over G711 works but VoIP calls will not benefit from bandwidth
optimization
- If remote side does not support "silenceSupp" attribute and it is not possible to disable
VAD on remote side => fax over G.711 is not guaranteed as VAD on both ends is not
disabled

1) да
2) отсутствует D-канал, сообщения ходить не будут между станциями, позвонить не сможете.

Это точные цифры? Просто в PARI последняя цифра может быть только или 0 или 4, а у вас - 3.

А R8.1 или 8.2 не пробовали? Может там лучше будет?

Попробуйте прописать Alternative CLIP\COLP на портах речевой почты, которые и отвечают.

Если по ошибке в порт подключения консоли включали кабель Ethernet, то выгорает порт консоли в аппарате. На эту тему ТС от Алкателя было.

Делаете 6-ую тр.группу для VoIP. Абонентам соответственно разрешаете выходить (ставите +) у кого 1 - на 1 и 6, у кого 2 - на 2 и 6 и т.д.

В свойствах VoIP линии указывается шаринг, когда она выступает в роли абонента, т.е. при транзите, когда вошли через неё и ушли дальше на транк. Матрица шаринга задает соответствие разрешений между абонентом и транковой группой - не транком, линией, доступом. На мой взгляд, тут два вопроса: как сделать разный шаринг на одной линии и как сделать, чтобы через одну VoIP линию выходили с разными логинами. В OmniPCX Office это решается одним способом. Фишка (особенность) ОХО - что один транк, доступ, линия может быть в разных транковых группах. Т.е. делаем несколько транковых групп с разным шарингом, но с одним и тем же VoIP доступом. К примеру, тр. группа 500 - шаринг 2 - межофисная связь - всем разрешаем ходить. Тр. группа 501 - для отдела 1, шаринг 3. В таблице ARS используем таблицу Gateway parameters 3 со своими логинами. И т.д.

Посмотрите в следующей теме:
http://www.intersyst.ru/support/forum/messages/forum31/topic945/message7808/#message7808
там и другие интересные сообщения есть.

Что-то у вас неправильно. Отчего такие разные IP адреса? У клиента должен быть адрес 192.168.92.246. Вы bootpd не правили? Help (F1) у ЛоЛы читали? Переключатели на процессоре ставили в режим ЛоЛы?