Это снова Я ;)
Вот решил теперь железку помучить. Это voip шлюз. Хотелосьбы из SIP звонки на H323 в нее заворачивать через *. Астериск последней верисс и драйвер родной установлены и работают по h323 нормально. А вот на cisco звноки не идут. С нее можно дозаониться до SIP, тот снимает трубку и неичего не слышно, при этом на трубке от cisco еще идут длинные гудки до таймаута. Трафик проходит, и * и cisco в одной сети, все открыто. Настройки от cisco брал по аналогии с теми что были когда она была шлюзом от карбины.
Вот настройки цыски:
voice-port 1
input gain 9
output attenuation 9
echo-cancel coverage 16
cptone RU
timeouts interdigit 4
!
voice-port 2
input gain 9
output attenuation 9
echo-cancel coverage 16
cptone RU
timeouts interdigit 4
!
voice-port 3
echo-cancel coverage 16
cptone RU
timeouts interdigit 4
!
voice-port 4
echo-cancel coverage 16
cptone RU
timeouts interdigit 4
!
dial-peer voice 8 voip
destination-pattern 8T
session target ipv4:<Астериск>
req-qos guaranteed-delay
codec g729br8 bytes 40
!

dial-peer voice 1 voip
destination-pattern [1-79]......
session target ipv4:<Астериск>
req-qos guaranteed-delay
codec g729br8 bytes 80
no vad
!
dial-peer voice 10 voip
destination-pattern 0T
session target ipv4:<Астериск>
codec g729br8 bytes 40
!
dial-peer voice 14 pots
preference 1
destination-pattern 0021
port 1

dial-peer voice 12 pots
preference 1
destination-pattern 0022
port 2
!
dial-peer voice 13 pots
preference 1
destination-pattern 0023
port 3
!
dial-peer voice 11 pots
preference 1
destination-pattern 0024
port 4
!

А вот что выдает h.323 debug в астериске:
-- Making call to 0023@213.171.61.28:1720 without gatekeeper.
proxy*CL== New H.323 Connection created.
proxy*CL-- root is calling host 0023@213.171.61.28:1720
proxy*CL-- Call token is ip$localhost/27633
proxy*CL-- Call reference is 27633
proxy*CL-- DTMF Payload is [pt=101]
Allowed Codecs:
proxy*CL Table:
G.729A <1>
G.729 <2>
G.723.1 <3>
G.711-uLaw-64k <4>
G.711-ALaw-64k <5>
UserInput/hookflash <6>
UserInput/RFC2833 <7>
Set:*CLI>
0:*CLI>
0:LI>
G.729A <1>
G.729 <2>
G.723.1 <3>
G.711-uLaw-64k <4>
G.711-ALaw-64k <5>
1:LI>
UserInput/hookflash <6>
2:LI>
UserInput/RFC2833 <7>
proxy*CLI>
proxy*CL-- Sending SETUP message
proxy*CL-- Transmitting RFC2833 on payload 101
proxy*CL-- Received RELEASE COMPLETE message...
proxy*CL-- ClearCall: Request to clear call with token ip$localhost/27633, cause EndedByQ931Cause
proxy*CL-- Sending RELEASE COMPLETE
proxy*CLExternalRTPChannel Destroyed
ExternalRTPChannel Destroyed
ExternalRTPChannel Destroyed
ExternalRTPChannel Destroyed
ExternalRTPChannel Destroyed
ExternalRTPChannel Destroyed
ExternalRTPChannel Destroyed
ExternalRTPChannel Destroyed
ExternalRTPChannel Destroyed
ExternalRTPChannel Destroyed
proxy*CL-- ClearCall: Request to clear call with token ip$localhost/27633, cause EndedByTransportFail
-- Call with 0023 completed (EndedByQ931Cause)
== H.323 Connection deleted.

С чего начать копать ?

У нас такая работает.
С такими пирами -
dial-peer voice 1 voip
destination-pattern[1-79]......
session target ipv4:<Астериск>
req-qos guaranteed-delay
codec g729br8 bytes 80
no vad
!
dial-peer voice 10 voip
destination-pattern 0T
session target ipv4:<Астериск>
codec g729br8 bytes 40
!
Соединение устанавливается по Н.323, но ведь можно пи SIP!
добавь там session protocol sipv2 в пирах и выкинь codec g729br8 bytes 40 вместо него надо группу кодеков - voice-class codec 1
и его добавить -
!
voice class codec 1
codec preference 1 g729br8
codec preference 2 g729r8
codec preference 3 g711alaw
codec preference 4 g711ulaw
!
Кроме того оч рекомендую выбросить input gain и output attenuation на портах, тогда они сбросяться в дефолт. А то по опыту - чем больше задираешь или вообще как начнёшь крутить - тем хуже слышно.

Я и не знал, что на ней SIP есть. С цысками до этого дела не имел. Все получилось спасибо!
Осталось заставить работать такой атавизм и пережиток прошлого как факс . Пока, в тупую, через voip gateway Cisco факс не прошел. астериск выдал вот такое в консоли:
-- Attempting native bridge of SIP/027-0560 and SIP/213.171.61.28-604b
Nov 11 15:08:12 WARNING[4068]: chan_sip.c:3451 process_sdp: Unknown SDP media type in offer: image 16886 udptl t38
Nov 11 15:08:12 NOTICE[5345]: rtp.c:564 ast_rtp_read: Unknown RTP codec 96 received
-- Started music on hold, class 'default', on channel 'SIP/213.171.61.28-604b'
-- Stopped music on hold on H323/ip$<КОРБИНА>6948/9143
-- Stopped music on hold on SIP/<CISCO-827>-604b
== Spawn extension (menu1-time-out, s, 1) exited non-zero on 'SIP/027-0560<ZOMBIE>'
Nov 11 15:08:14 NOTICE[5345]: rtp.c:564 ast_rtp_read: Unknown RTP codec 96 received
...
...
Nov 11 15:08:34 NOTICE[5345]: rtp.c:564 ast_rtp_read: Unknown RTP codec 96 received
== Spawn extension (cisco-gw, 0021, 1) exited non-zero on 'H323/ip$<КОРБИНА>:56948/9143'

Что-то тут про факс есть Не подскажете ?

Кто куда посылает? SIP/027 это где?
Unknown RTP codec 96 это тебе факс по протоколу Т38 передаётся. Asterisk поддерживает только прозрачный режим Т38, то есть если передающий шлюз и приеёмный терминал оба его понимают, то * склеит их.
И то, Т38 надо инсталлировать в * (смотри на форуме).
Альтернатива - pass-throw G711. В обсчем, я написал ответы на все твои вопросы и положил в Гугле.

Посылали из города через корбину h323 далее в * далее секретарь SIP/027 переводит на SIP/0021 - это железный факс подключеный cisco-827.

ded
Unknown RTP codec 96 это тебе факс по протоколу Т38 передаётся. Asterisk поддерживает только прозрачный режим Т38, то есть если передающий шлюз и приеёмный терминал оба его понимают, то * склеит их.
И то, Т38 надо инсталлировать в * (смотри на форуме).
Альтернатива - pass-throw G711. В обсчем, я написал ответы на все твои вопросы и положил в Гугле.

Ясно, спасибо тебе, уважаемый ded, огромное за все ответы. Попробую сам разобраться. Эта цыска ранее работала у нас как войсшлюз от карбины и факсы через нее проходили. Там наврно что-то настроено было. вот такие строчики:
voice service voip
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback cisco
h323

Вот ваша старая схема: Из города факс поступает на большой Цискоаппарат(5350) Корбины, там настроено так - если факс, то шпулять по Т38. Это принимается на вашей циске827, и там тоже было настроено

fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback cisco

. C T38 в Н.323 более-менее всё отработано, но в SIPe - это сырая тема (тема Т38 не раскрыта). Но настраиваемая.
КГ/АМ.

Таким образом, мне надо поросить их отключить T38 на цыскоаппарате, и получать факс напрямую, через H.323+g729, ибо t38 астериск не держит ? Я подкомпилил к астериску модули rxfax txfax. Удалось с локального факса по SIP g711 через cisco827 передавать на астериск бумажный факс в tiff файл. Сканер получился ;) Получится ли получать их из города через корбину?

Через G.729 не получится, pass-trough fax работает только на G.711

Получится, если Корбина изменит на вашем пире настройку на

fax protocol  fax protocol pass-through g711alaw 

врядли они будут так заморачиваться да и пользы будет мало. Я что-то не пойму - а что мешает мне принимать по H323 из корбины факс используя протокол T38 на тойже цыске827, которая и была изначально? Может быть такая схема?:
1. клиентский факс поступает из МГТС в корбину на 5350.
2. там его сигналы конвертятся в t38 и передаются мне на Asterisk по h323 (SIP не включат ).
3. Asterisk командой Dial(SIP/Faxnumber@Cisco827_IP,,R) переводит этот звонок на Cisco827 в которой T38 раскрывается и гудит в один из FXO портов вкоторый включена факс-машина.
То есть астериск в тупую склеивает корбину и мою cisco. вот только протокол меняется с h323 на SIP.
какие могут быть тут проблемы ? Может настройки какие на cisco поправить ?