Avaya & Asterisk
Avaya S8510 Asterisk 1.6.2.11 H323
|
Сообщений: 10
|
Avaya & Asterisk
Здравствуйте, нужна помощь в разрешении классической задачи "не проходит голос с одной стороны".
Архитектура: Avaya (10.10.0.1) <-> (10.10.1.254) Cisco 2811 (192.168.55.2) <~> vpntunnel <~> (192.168.55.1) Cisco 2811 (192.168.22.164) <-> (192.168.22.208) Asterisk
Avaya имеет выход в город, обслуживает офис, и настроен выход на Asterisk.
Asterisk имеет выход в город, соединение по IAX2 с другим Asterisk, обслуживает офис и настроен выход на Avaya.
При совершении звонка с Asterisk на Avaya, звонок проходит, голос поднявшего трубку проходит, мой голос отсутствует.
h323.conf
[general]
port = 1720
bindaddr = 192.168.22.208
disallow=all
allow=alaw
dtmfmode=inband
gatekeeper = DISABLE
context=local
progress_setup = 8
progress_alert = 8
[avaya]
type=friend
host=10.10.0.1
port=1720
context=local
incominglimit=15
disallow=all
allow=alaw
Вызов на Avaya
exten => _1XXX,1,Dial(H323/avaya/${EXTEN},60,Tt)
Лог одного звонка
<------------>
[Sep 8 14:39:14] -- Making call to 1037@10.10.0.1:1720 without gatekeeper.
[Sep 8 14:39:14] Using 192.168.22.208 for outbound call
[Sep 8 14:39:15] == New H.323 Connection created.
[Sep 8 14:39:15] -- root is calling host 1037@10.10.0.1:1720
[Sep 8 14:39:15] -- Call token is ip$localhost/7687
[Sep 8 14:39:15] -- Call reference is 7687
[Sep 8 14:39:15] -- DTMF Payload is 0x1cb2b18
[Sep 8 14:39:15]
<--- Transmitting (no NAT) to 192.168.22.127:5060 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.22.127:5060;branch=z9hG4bK-11843829;received=192.168.22.127
From: <sip:238@192.168.22.208>;tag=2c765652b522c225o0
To: <sip:1037@192.168.22.208>;tag=as30b72a4a
Call-ID: dbf68796-9d4ca1b1@192.168.22.127
CSeq: 102 INVITE
Server: Asterisk PBX 1.6.2.11
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: <sip:1037@192.168.22.208>
Content-Length: 0
<------------>
[Sep 8 14:39:15] Setting capabilities to 0x10a (gsm|alaw|g729)
[Sep 8 14:39:15] Capabilities in preference order is (alaw|g729|gsm)
[Sep 8 14:39:15] DTMF mode is 8
[Sep 8 14:39:15] Allowed Codecs for ip$localhost/7687 (ip$192.168.22.208:42857):
[Sep 8 14:39:15] Table:
[Sep 8 14:39:15] G.711-ALaw-64k <1>
[Sep 8 14:39:15] G.729A <2>
[Sep 8 14:39:15] G.729 <3>
[Sep 8 14:39:15] GSM-06.10 <4>
[Sep 8 14:39:15] UserInput/hookflash <5>
[Sep 8 14:39:15] UserInput/basicString <6>
[Sep 8 14:39:15] Set:
[Sep 8 14:39:15] 0:
[Sep 8 14:39:15] 0:
[Sep 8 14:39:15] G.711-ALaw-64k <1>
[Sep 8 14:39:15] G.729A <2>
[Sep 8 14:39:15] G.729 <3>
[Sep 8 14:39:15] GSM-06.10 <4>
[Sep 8 14:39:15] 1:
[Sep 8 14:39:15] UserInput/hookflash <5>
[Sep 8 14:39:15] 2:
[Sep 8 14:39:15] UserInput/basicString <6>
[Sep 8 14:39:15]
[Sep 8 14:39:15] -- Sending SETUP message
[Sep 8 14:39:15] -- Started logical channel: sending G.711-ALaw-64k
[Sep 8 14:39:15] -- channelsOpen = 1
[Sep 8 14:39:15] External RTP Session Starting
[Sep 8 14:39:15] RTP channel id 1 parameters:
[Sep 8 14:39:15] -- remoteIpAddress: 10.10.0.2
[Sep 8 14:39:15] -- remotePort: 2072
[Sep 8 14:39:15] -- ExternalIpAddress: 192.168.22.208
[Sep 8 14:39:15] -- ExternalPort: 15610
[Sep 8 14:39:15] -- Started logical channel: receiving G.711-ALaw-64k
[Sep 8 14:39:15] -- channelsOpen = 2
[Sep 8 14:39:15] External RTP Session Starting
[Sep 8 14:39:15] RTP channel id 1 parameters:
[Sep 8 14:39:15] -- remoteIpAddress: 10.10.0.2
[Sep 8 14:39:15] -- remotePort: 2072
[Sep 8 14:39:15] -- ExternalIpAddress: 192.168.22.208
[Sep 8 14:39:15] -- ExternalPort: 15610
[Sep 8 14:39:15] ExternalRTPChannel Destroyed
[Sep 8 14:39:15] ExternalRTPChannel Destroyed
[Sep 8 14:39:15] ExternalRTPChannel Destroyed
[Sep 8 14:39:15] ExternalRTPChannel Destroyed
[Sep 8 14:39:15] ExternalRTPChannel Destroyed
[Sep 8 14:39:15] ExternalRTPChannel Destroyed
[Sep 8 14:39:15] =-= In OnAlerting for call 7687: sessionId=0
[Sep 8 14:39:15] -- Ringing phone for "1037"
[Sep 8 14:39:15] - Progress Indicator: 8
[Sep 8 14:39:15]
<--- Transmitting (no NAT) to 192.168.22.127:5060 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.22.127:5060;branch=z9hG4bK-11843829;received=192.168.22.127
From: <sip:238@192.168.22.208>;tag=2c765652b522c225o0
To: <sip:1037@192.168.22.208>;tag=as30b72a4a
Call-ID: dbf68796-9d4ca1b1@192.168.22.127
CSeq: 102 INVITE
Server: Asterisk PBX 1.6.2.11
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: <sip:1037@192.168.22.208>
Content-Length: 0
<------------>
[Sep 8 14:39:21] 22:47:23.695 H225 Calle...er:1cb2ee0 h323ep.cxx(2723) H225 Received connect PDU.
[Sep 8 14:39:21] =-= In OnConnectionEstablished for call 7687
[Sep 8 14:39:21] -- Connection Established with "Esyunin-DV"
[Sep 8 14:39:21] Audio is at 192.168.22.208 port 16978
[Sep 8 14:39:21] Adding codec 0x4 (ulaw) to SDP
[Sep 8 14:39:21] Adding codec 0x8 (alaw) to SDP
[Sep 8 14:39:21] Adding non-codec 0x1 (telephone-event) to SDP
[Sep 8 14:39:21]
<--- Reliably Transmitting (no NAT) to 192.168.22.127:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.22.127:5060;branch=z9hG4bK-11843829;received=192.168.22.127
From: <sip:238@192.168.22.208>;tag=2c765652b522c225o0
To: <sip:1037@192.168.22.208>;tag=as30b72a4a
Call-ID: dbf68796-9d4ca1b1@192.168.22.127
CSeq: 102 INVITE
Server: Asterisk PBX 1.6.2.11
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Contact: <sip:1037@192.168.22.208>
Content-Type: application/sdp
Content-Length: 290
v=0
o=root 930855284 930855284 IN IP4 192.168.22.208
s=Asterisk PBX 1.6.2.11
c=IN IP4 192.168.22.208
t=0 0
m=audio 16978 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
<------------>
[Sep 8 14:39:21]
<--- SIP read from UDP:192.168.22.127:5060 --->
ACK sip:1037@192.168.22.208 SIP/2.0
Via: SIP/2.0/UDP 192.168.22.127:5060;branch=z9hG4bK-3122f4b3
From: <sip:238@192.168.22.208>;tag=2c765652b522c225o0
To: <sip:1037@192.168.22.208>;tag=as30b72a4a
Call-ID: dbf68796-9d4ca1b1@192.168.22.127
CSeq: 102 ACK
Max-Forwards: 70
Authorization: Digest username="238",realm="asterisk",nonce="3356148d",uri="sip:1037@192.168.22.208",algorithm=MD5,response="dc339b944e091dd805496f1dea8eb534"
Contact: <sip:238@192.168.22.127:5060>
User-Agent: Linksys/SPA922-6.1.5(a)
Content-Length: 0
<------------->
[Sep 8 14:39:21] --- (11 headers 0 lines) ---
[Sep 8 14:39:21] -- Received Facility message...
[Sep 8 14:39:21] Peer capability is G.711-ALaw-64k <1>
[Sep 8 14:39:21] Found peer capability G.711-ALaw-64k <1>, Asterisk code is 8, frame size (in ms) is 20
[Sep 8 14:39:21] Peer capability is UserInput/dtmf <4>
[Sep 8 14:39:21] Peer capabilities = 0x8 (alaw), ordered list is (alaw)
[Sep 8 14:39:21] -- Received Facility message...
[Sep 8 14:39:21] -- Received Facility message...
[Sep 8 14:39:21] -- Received Facility message...
[Sep 8 14:39:21] -- Received Facility message...
[Sep 8 14:39:24]
Я обратил внимание на
[Sep 8 14:39:14] -- Making call to 1037@10.10.0.1:1720 without gatekeeper.
...
To: <sip:1037@192.168.22.208>;tag=as30b72a4a
Видимо астер запутался куда слать пакеты, но как пофиксить, пока не соображу.
Может кто-то подскажет куда копать. Если нужны какие-то логи еще, могу дать, кроме AVAYA, к ней доступа у меня нет и фидбеки с нее я получаю через мастера от avaya... |
|
Сообщений: 147
|
Re: Avaya & Asterisk
RTP рэйнжи на астериске и аваевском регионе совпадают ? Сколько интерфейсов слушает h323 ? И если в конфиге прописано 0.0.0.0 вы его патчили чтобы он принимал ртп со всех интерфейсов ?
|
|
Сообщений: 10
|
Re: Avaya & Asterisk
RTP проверю, спасибо. h323 слушает один интерфейс, h323.conf целиком выложен в первом посте.
bindaddr = 192.168.22.208
h323 собран с последней версией asterisk 1.6.2.11 и libopenh323-1.19.1
Действительно не совпадали RTP, однако установка идентичных диапазонов не помогла, так же меня не слышат.
[2010-09-10 17:01:50] DEBUG[30379] chan_sip.c: Trying to put 'SIP/2.0 180' onto UDP socket destined for 192.168.22.127:5060
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Got RTCP report of 84 bytes
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2067
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Got RTCP report of 84 bytes
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2067
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Got RTCP report of 84 bytes
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2067
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Got RTCP report of 84 bytes
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2067
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Got RTCP report of 84 bytes
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2067
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Got RTCP report of 84 bytes
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2067
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Got RTCP report of 84 bytes
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2067
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Got RTCP report of 84 bytes
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2067
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Got RTCP report of 84 bytes
[2010-09-10 17:01:50] DEBUG[30379] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2067
[2010-09-10 17:01:52] VERBOSE[30380] ast_h323.cxx: [2010-09-10 17:01:52] 73:09:55.431 H225 Calle...er:1cee410 h323ep.cxx(2723) H225 Received
[2010-09-10 17:01:52] VERBOSE[30380] ast_h323.cxx: [2010-09-10 17:01:52] =-= In OnConnectionEstablished for call 7692
[2010-09-10 17:01:52] VERBOSE[30380] ast_h323.cxx: [2010-09-10 17:01:52] -- Connection Established with "Fedorov-SA"
[2010-09-10 17:01:52] DEBUG[30380] chan_h323.c: Call ip$localhost/7692 answered
[2010-09-10 17:01:52] DEBUG[20811] devicestate.c: No provider found, checking channel drivers for H323 - aemavaya
[2010-09-10 17:01:52] DEBUG[20811] channel.c: Avoiding initial deadlock for channel '0x1cba680'
[2010-09-10 17:01:52] DEBUG[20811] channel.c: Avoiding initial deadlock for channel '0x1cba680'
[2010-09-10 17:01:52] DEBUG[20811] channel.c: Avoiding initial deadlock for channel '0x1cba680'
[2010-09-10 17:01:52] DEBUG[20811] devicestate.c: Changing state for H323/aemavaya - state 2 (In use)
[2010-09-10 17:01:52] DEBUG[20811] devicestate.c: device 'H323/aemavaya' state '2'
[2010-09-10 17:01:52] DEBUG[20852] app_queue.c: Device 'H323/aemavaya' changed to state '2' (In use) but we don't care because they're not a member of an
[2010-09-10 17:01:52] VERBOSE[30379] app_dial.c: [2010-09-10 17:01:52] -- H323/aemavaya-13 answered SIP/238-00000bea
[2010-09-10 17:01:52] DEBUG[30379] channel.c: Set channel SIP/238-00000bea to read format alaw
[2010-09-10 17:01:52] DEBUG[30379] channel.c: Set channel H323/aemavaya-13 to read format ulaw
[2010-09-10 17:01:52] DEBUG[20811] devicestate.c: No provider found, checking channel drivers for SIP - 238
[2010-09-10 17:01:52] DEBUG[20811] chan_sip.c: Checking device state for peer 238
[2010-09-10 17:01:52] DEBUG[20811] devicestate.c: Changing state for SIP/238 - state 2 (In use)
[2010-09-10 17:01:52] DEBUG[20811] devicestate.c: device 'SIP/238' state '2'
[2010-09-10 17:01:52] DEBUG[20852] app_queue.c: Device 'SIP/238' changed to state '2' (In use)
[2010-09-10 17:01:52] DEBUG[30379] chan_sip.c: SIP answering channel: SIP/238-00000bea
[2010-09-10 17:01:52] DEBUG[30379] rtp.c: Setting the marker bit due to a source update
[2010-09-10 17:01:52] DEBUG[30379] chan_sip.c: Setting framing from config on incoming call
[2010-09-10 17:01:52] DEBUG[30379] chan_sip.c: ** Our capability: 0xc (ulaw|alaw) Video flag: True Text flag: True
[2010-09-10 17:01:52] DEBUG[30379] chan_sip.c: ** Our prefcodec: 0x0 (nothing)
[2010-09-10 17:01:52] VERBOSE[30379] chan_sip.c: [2010-09-10 17:01:52] Audio is at 192.168.22.208 port 3122
[2010-09-10 17:01:52] VERBOSE[30379] chan_sip.c: [2010-09-10 17:01:52] Adding codec 0x4 (ulaw) to SDP
[2010-09-10 17:01:52] VERBOSE[30379] chan_sip.c: [2010-09-10 17:01:52] Adding codec 0x8 (alaw) to SDP
[2010-09-10 17:01:52] VERBOSE[30379] chan_sip.c: [2010-09-10 17:01:52] Adding non-codec 0x1 (telephone-event) to SDP
[2010-09-10 17:01:52] DEBUG[30379] chan_sip.c: -- Done with adding codecs to SDP
[2010-09-10 17:01:52] DEBUG[30379] chan_sip.c: Done building SDP. Settling with this capability: 0xc (ulaw|alaw)
[2010-09-10 17:01:52] VERBOSE[30379] chan_sip.c: [2010-09-10 17:01:52]
[2010-09-10 17:01:52] DEBUG[30379] chan_sip.c: *** SIP TIMER: Initializing retransmit timer on packet: Id #91336
[2010-09-10 17:01:52] DEBUG[30379] chan_sip.c: Trying to put 'SIP/2.0 200' onto UDP socket destined for 192.168.22.127:5060
[2010-09-10 17:01:52] DEBUG[30379] features.c: bridge answer set, chan answer set
[2010-09-10 17:01:52] DEBUG[30379] rtp.c: Setting the marker bit due to a source update
[2010-09-10 17:01:52] DEBUG[30379] chan_h323.c: OH323: Indicating 20 on ip$localhost/7692 (H323/aemavaya-13)
[2010-09-10 17:01:52] DEBUG[30379] rtp.c: Setting the marker bit due to a source update
[2010-09-10 17:01:52] DEBUG[30379] chan_h323.c: OH323: Indicated 20 on ip$localhost/7692, res=0
[2010-09-10 17:01:52] DEBUG[30379] rtp.c: Cannot packet2packet bridge - raw formats are incompatible
[2010-09-10 17:01:52] VERBOSE[20850] chan_sip.c:
обратил внимание на OH323(откуда?, когда h323), на
[2010-09-10 17:01:52] DEBUG[30379] rtp.c: Cannot packet2packet bridge - raw formats are incompatible
Что-то тут не чисто... |
|
Сообщений: 147
|
Re: Avaya & Asterisk
Снимите дамп с интерфейса 192.168.22.208. Посмотрите ртп пакеты ходят в обе стороны ? И попробуйте оставить только 1 кодек на астериске и на авае. И попроуйте диал переписать вот таким образом:
exten => _1XXX,1,Dial(H323/${EXTEN}@10.10.0.1 ,60,Tt)
|
|
Сообщений: 10
|
Re: Avaya & Asterisk
у меня намеренно удалены все конфигурации, отличные от h323, отсюда и непонимание, откуда другие варианты. На Avaya попробую уже в будние дни.
предложенный вариант звонка был реализован, и эффект был тот же. В понедельник я решу вопрос с протоколом и дам логи.
|
|
Откуда: Санкт-Петербург
Сообщений: 541
|
Re: Avaya & Asterisk
уберите ulaw у SIP-устройства в sip.conf или поменяйте их (ulaw, alaw) порядок
[2010-09-10 17:01:52] DEBUG[30379] channel.c: Set channel SIP/238-00000bea to read format alaw
[2010-09-10 17:01:52] DEBUG[30379] channel.c: Set channel H323/aemavaya-13 to read format ulaw
вот этого ничего хорошего ждать не следует |
|
Сообщений: 147
|
Re: Avaya & Asterisk
На всякий случай мануал по настройке стыка: http://asterisk.ru/more/avaya
|
|
Сообщений: 10
|
Re: Avaya & Asterisk
Настройки на AVAYA практически идентичны мануалу.
Поменял порядок ulaw и alaw, теперь
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: Processing session-level SDP v=0... UNSUPPORTED.
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: Processing session-level SDP o=- 873667 873667 IN IP4 192.168.22.127... UNSUPPORTED.
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: Processing session-level SDP s=-... UNSUPPORTED.
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: Processing session-level SDP c=IN IP4 192.168.22.127... OK.
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: Processing session-level SDP t=0 0... UNSUPPORTED.
[2010-09-13 16:01:38] VERBOSE[20850] chan_sip.c: [2010-09-13 16:01:38] Found RTP audio format 0
[2010-09-13 16:01:38] VERBOSE[20850] chan_sip.c: [2010-09-13 16:01:38] Found RTP audio format 101
[2010-09-13 16:01:38] VERBOSE[20850] chan_sip.c: [2010-09-13 16:01:38] Found audio description format PCMU for ID 0
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:0 PCMU/8000... OK.
[2010-09-13 16:01:38] VERBOSE[20850] chan_sip.c: [2010-09-13 16:01:38] Found audio description format telephone-event for ID 101
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:101 telephone-event/8000... OK.
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: Processing media-level (audio) SDP a=fmtp:101 0-15... UNSUPPORTED.
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: Processing media-level (audio) SDP a=ptime:20... OK.
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: Processing media-level (audio) SDP a=sendrecv... OK.
[2010-09-13 16:01:38] VERBOSE[20850] chan_sip.c: [2010-09-13 16:01:38] Capabilities: us - 0x10c (ulaw|alaw|g729), peer - audio=0x4 (ulaw)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x4 (ulaw)
[2010-09-13 16:01:38] VERBOSE[20850] chan_sip.c: [2010-09-13 16:01:38] Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
[2010-09-13 16:01:38] VERBOSE[20850] chan_sip.c: [2010-09-13 16:01:38] Peer audio RTP is at port 192.168.22.127:16444
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: Peer doesn't provide T.38 UDPTL
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: We're settling with these formats: 0x4 (ulaw)
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: We have an owner, now see if we need to change this call
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: Oooh, we need to change our audio formats since our peer supports only 0x4 (ulaw) and not 0x8 (alaw)
вижу, что пир работает только по ulaw (в конце лог с ulaw)
[2010-09-13 16:01:38] DEBUG[20850] channel.c: Set channel SIP/238-0000101f to read format alaw
[2010-09-13 16:01:38] DEBUG[20850] channel.c: Set channel SIP/238-0000101f to write format alaw
[2010-09-13 16:01:38] DEBUG[20850] chan_sip.c: Updating call counter for outgoing call
Про H323 ни слова, зато вылезает
chan_h323.c: OH323: Indicating 3 on ip$10.10.0.1:11674/5145 (H323/ip$10.10.0.1:11674/5145)
module show like chan
Module Description Use Count
chan_mgcp.so Media Gateway Control Protocol (MGCP) 0
app_chanspy.so Listen to the audio of an active channel 0
chan_jingle.so Jingle Channel Driver 0
func_channel.so Channel information dialplan functions 0
chan_local.so Local Proxy Channel (Note: used internal 0
app_chanisavail.so Check channel availability 0
chan_bridge.so Bridge Interaction Channel 0
chan_iax2.so Inter Asterisk eXchange (Ver 2) 0
app_dumpchan.so Dump Info About The Calling Channel 0
chan_dahdi.so DAHDI Telephony Driver w/PRI 0
chan_agent.so Agent Proxy Channel 0
chan_h323.so The NuFone Network's OpenH323 Channel Dr 1
app_channelredirect.so Redirects a given channel to a dialplan 0
chan_unistim.so UNISTIM Protocol (USTM) 0
chan_phone.so Linux Telephony API Support 0
chan_skinny.so Skinny Client Control Protocol (Skinny) 0
chan_gtalk.so Gtalk Channel Driver 0
chan_oss.so OSS Console Channel Driver 0
chan_sip.so Session Initiation Protocol (SIP) 5
Ну нет у меня OH323!
Выставил ulaw, теперь после набора сразу "занято"
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] == New H.323 Connection created.
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] --Received SETUP message
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: Setting up incoming call for ip$10.10.0.1:11673/5040
[2010-09-13 16:38:51] VERBOSE[4593] chan_h323.c: [2010-09-13 16:38:51] -- Setting up Call
[2010-09-13 16:38:51] VERBOSE[4593] chan_h323.c: [2010-09-13 16:38:51] -- Call token: [ip$10.10.0.1:11673/5040]
[2010-09-13 16:38:51] VERBOSE[4593] chan_h323.c: [2010-09-13 16:38:51] -- Calling party name: []
[2010-09-13 16:38:51] VERBOSE[4593] chan_h323.c: [2010-09-13 16:38:51] -- Calling party number: [4959747979]
[2010-09-13 16:38:51] VERBOSE[4593] chan_h323.c: [2010-09-13 16:38:51] -- Called party name: [2238]
[2010-09-13 16:38:51] VERBOSE[4593] chan_h323.c: [2010-09-13 16:38:51] -- Called party number: [2238]
[2010-09-13 16:38:51] VERBOSE[4593] chan_h323.c: [2010-09-13 16:38:51] -- Calling party IP: [10.10.0.1]
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: Could not find user by name 10.10.0.1 or address 10.10.0.1
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: Sending 10.10.0.1@10.10.0.1 to context [from_aem] extension 2238
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: Setting capabilities for connection ip$10.10.0.1:11673/5040
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] Setting capabilities to 0x4 (ulaw)
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] Capabilities in preference order is (ulaw)
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] DTMF mode is 4
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] Allowed Codecs for ip$10.10.0.1:11673/5040 (ip$192.168.22.208:1720):
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] Table:
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] G.711-uLaw-64k <1>
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] UserInput/hookflash <2>
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] UserInput/dtmf <3>
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] Set:
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] 0:
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] 0:
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] G.711-uLaw-64k <1>
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] 1:
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] UserInput/hookflash <2>
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] 2:
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] UserInput/dtmf <3>
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51]
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: local prefs[0]=ulaw:20
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: Capabilities for connection ip$10.10.0.1:11673/5040 is set
[2010-09-13 16:38:51] DEBUG[4593] acl.c: Attached to given IP address
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: Created RTP channel
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: Setting NAT on RTP to 0
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: Sending RTP 'US' 192.168.22.208:3104
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: Sending RTP 'US' 192.168.22.208:3104
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] =-= In OnAnswerCall for call 5040
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] - Progress Indicator: 0
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] - Inserting PI of 0 into ALERTING message
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: Preparing Asterisk to answer for ip$10.10.0.1:11673/5040
[2010-09-13 16:38:51] DEBUG[4594] pbx.c: Launching 'Dial'
[2010-09-13 16:38:51] VERBOSE[4594] pbx.c: [2010-09-13 16:38:51] -- Executing [2238@from_aem:1] Dial("H323/ip$10.10.0.1:11673/5040", "SIP/238,60,Tt") in new stack
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: Asked to create a SIP channel with formats: 0x4 (ulaw)
[2010-09-13 16:38:51] VERBOSE[4594] netsock.c: [2010-09-13 16:38:51] == Using SIP RTP CoS mark 5
[2010-09-13 16:38:51] VERBOSE[4594] netsock.c: [2010-09-13 16:38:51] == Using SIP VRTP CoS mark 6
[2010-09-13 16:38:51] VERBOSE[4594] netsock.c: [2010-09-13 16:38:51] == Using UDPTL CoS mark 5
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: Allocating new SIP dialog for 0d30212330bb98b77ea3849033f07121@127.0.0.1 - INVITE (With RTP)
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: Setting NAT on RTP to Off
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: Setting NAT on UDPTL to Off
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: OBPROXY: Not applying OBproxy to this call
[2010-09-13 16:38:51] DEBUG[4594] acl.c: Found IP address for this socket
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: Setting SIP_TRANSPORT_UDP with address 192.168.22.208:5060
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: *** Our native formats are 0x4 (ulaw)
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: *** Joint capabilities are 0x4 (ulaw)
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: *** Our capabilities are 0x10c (ulaw|alaw|g729)
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: *** AST_CODEC_CHOOSE formats are 0x4 (ulaw)
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: *** Our preferred formats from the incoming channel are 0x4 (ulaw)
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: This channel will not be able to handle video.
[2010-09-13 16:38:51] DEBUG[4594] channel.c: Not copying variable DIALEDTIME.
[2010-09-13 16:38:51] DEBUG[4594] channel.c: Not copying variable ANSWEREDTIME.
[2010-09-13 16:38:51] DEBUG[4594] channel.c: Not copying variable DIALEDPEERNAME.
[2010-09-13 16:38:51] DEBUG[4594] channel.c: Not copying variable DIALEDPEERNUMBER.
[2010-09-13 16:38:51] DEBUG[4594] channel.c: Not copying variable DIALSTATUS.
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: Outgoing Call for 238
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: Updating call counter for outgoing call
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: Call to peer '238' is 1 out of 100
[2010-09-13 16:38:51] DEBUG[20811] devicestate.c: No provider found, checking channel drivers for SIP - 238
[2010-09-13 16:38:51] DEBUG[20811] chan_sip.c: Checking device state for peer 238
[2010-09-13 16:38:51] DEBUG[20811] devicestate.c: Changing state for SIP/238 - state 6 (Ringing)
[2010-09-13 16:38:51] DEBUG[20811] devicestate.c: device 'SIP/238' state '6'
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: ** Our capability: 0xc (ulaw|alaw) Video flag: False Text flag: False
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: ** Our prefcodec: 0x4 (ulaw)
[2010-09-13 16:38:51] VERBOSE[4594] chan_sip.c: [2010-09-13 16:38:51] Audio is at 192.168.22.208 port 2430
[2010-09-13 16:38:51] DEBUG[20852] app_queue.c: Device 'SIP/238' changed to state '6' (Ringing)
[2010-09-13 16:38:51] VERBOSE[4594] chan_sip.c: [2010-09-13 16:38:51] Adding codec 0x4 (ulaw) to SDP
[2010-09-13 16:38:51] VERBOSE[4594] chan_sip.c: [2010-09-13 16:38:51] Adding codec 0x8 (alaw) to SDP
[2010-09-13 16:38:51] VERBOSE[4594] chan_sip.c: [2010-09-13 16:38:51] Adding non-codec 0x1 (telephone-event) to SDP
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: -- Done with adding codecs to SDP
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: Done building SDP. Settling with this capability: 0xc (ulaw|alaw)
...
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: *** SIP TIMER: Initializing retransmit timer on packet: Id #124560
[2010-09-13 16:38:51] DEBUG[4594] chan_sip.c: Trying to put 'INVITE sip:' onto UDP socket destined for 192.168.22.127:5060
[2010-09-13 16:38:51] VERBOSE[4594] app_dial.c: [2010-09-13 16:38:51] -- Called 238
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] -- Started logical channel: sending G.711-uLaw-64k
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] -- channelsOpen = 1
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] External RTP Session Starting
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] RTP channel id 1 parameters:
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] -- remoteIpAddress: 10.10.0.2
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] -- remotePort: 2088
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] -- ExternalIpAddress: 192.168.22.208
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] -- ExternalPort: 3104
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: Setting up RTP connection for ip$10.10.0.1:11673/5040
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: Native format is set to 4 from 4 by RTP payload type 0
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: RTP connection prepared for ip$10.10.0.1:11673/5040
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] -- Started logical channel: receiving G.711-uLaw-64k
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] -- channelsOpen = 2
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] External RTP Session Starting
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] RTP channel id 1 parameters:
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] -- remoteIpAddress: 10.10.0.2
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] -- remotePort: 2088
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] -- ExternalIpAddress: 192.168.22.208
[2010-09-13 16:38:51] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:51] -- ExternalPort: 3104
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: Setting up RTP connection for ip$10.10.0.1:11673/5040
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: Native format is set to 4 from 4 by RTP payload type 0
[2010-09-13 16:38:51] DEBUG[4593] chan_h323.c: RTP connection prepared for ip$10.10.0.1:11673/5040
[2010-09-13 16:38:51] VERBOSE[20850] chan_sip.c: [2010-09-13 16:38:51]
[2010-09-13 16:38:51] VERBOSE[20850] chan_sip.c: [2010-09-13 16:38:51] --- (8 headers 0 lines) ---
[2010-09-13 16:38:51] DEBUG[20850] chan_sip.c: *** SIP TIMER: Cancelling retransmission #124560 - INVITE (got response)
[2010-09-13 16:38:51] DEBUG[20850] chan_sip.c: (Provisional) Stopping retransmission (but retaining packet) on '13ea0b293d2d38db1a2947d453347b1e@192.168.22.208' Request 102: Found
[2010-09-13 16:38:51] DEBUG[20850] chan_sip.c: SIP response 100 to standard invite
[2010-09-13 16:38:51] DEBUG[20850] chan_sip.c: SIP response 180 to standard invite
[2010-09-13 16:38:51] DEBUG[20811] devicestate.c: No provider found, checking channel drivers for SIP - 238
[2010-09-13 16:38:51] VERBOSE[4594] app_dial.c: [2010-09-13 16:38:51] -- SIP/238-0000105c is ringing
[2010-09-13 16:38:51] DEBUG[20811] chan_sip.c: Checking device state for peer 238
[2010-09-13 16:38:51] DEBUG[4594] chan_h323.c: OH323: Indicating 3 on ip$10.10.0.1:11673/5040 (H323/ip$10.10.0.1:11673/5040)
[2010-09-13 16:38:51] VERBOSE[4594] ast_h323.cxx: [2010-09-13 16:38:51] Sending alerting
[2010-09-13 16:38:51] DEBUG[4594] chan_h323.c: OH323: Indicated 3 on ip$10.10.0.1:11673/5040, res=-1
[2010-09-13 16:38:51] DEBUG[4594] channel.c: Driver for channel 'H323/ip$10.10.0.1:11673/5040' does not support indication 3, emulating it
[2010-09-13 16:38:51] DEBUG[20852] app_queue.c: Device 'SIP/238' changed to state '6' (Ringing)
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Ooh, format changed from unknown to ulaw
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Created smoother: format: 4 ms: 20 len: 160
[2010-09-13 16:38:51] DEBUG[4594] channel.c: Generator got voice, switching to phase locked mode
[2010-09-13 16:38:51] DEBUG[4594] channel.c: Scheduling timer at (0 requested / 0 actual) timer ticks per second
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Got RTCP report of 84 bytes
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2089
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Got RTCP report of 84 bytes
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2089
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Got RTCP report of 84 bytes
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2089
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Got RTCP report of 84 bytes
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2089
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Got RTCP report of 84 bytes
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2089
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Got RTCP report of 84 bytes
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2089
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Got RTCP report of 84 bytes
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2089
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Got RTCP report of 84 bytes
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2089
[2010-09-13 16:38:51] DEBUG[4291] rtp.c: Got RTCP report of 80 bytes
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Got RTCP report of 84 bytes
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2089
[2010-09-13 16:38:51] DEBUG[4403] rtp.c: Got RTCP report of 80 bytes
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Got RTCP report of 84 bytes
[2010-09-13 16:38:51] DEBUG[4594] rtp.c: Unknown RTCP packet (pt=250) received from 10.10.0.2:2089
[2010-09-13 16:38:52] DEBUG[4403] rtp.c: Got RTCP report of 80 bytes
[2010-09-13 16:38:52] DEBUG[4291] rtp.c: Got RTCP report of 80 bytes
[2010-09-13 16:38:53] DEBUG[20850] chan_sip.c: Processing session-level SDP v=0... UNSUPPORTED.
[2010-09-13 16:38:53] DEBUG[20850] chan_sip.c: Processing session-level SDP o=- 1097180 1097180 IN IP4 192.168.22.127... UNSUPPORTED.
[2010-09-13 16:38:53] DEBUG[20850] chan_sip.c: Processing session-level SDP s=-... UNSUPPORTED.
[2010-09-13 16:38:53] DEBUG[20850] chan_sip.c: Processing session-level SDP c=IN IP4 192.168.22.127... OK.
[2010-09-13 16:38:53] DEBUG[20850] chan_sip.c: Processing session-level SDP t=0 0... UNSUPPORTED.
[2010-09-13 16:38:53] VERBOSE[20850] chan_sip.c: [2010-09-13 16:38:53] Found RTP audio format 0
[2010-09-13 16:38:53] VERBOSE[20850] chan_sip.c: [2010-09-13 16:38:53] Found RTP audio format 101
[2010-09-13 16:38:53] VERBOSE[20850] chan_sip.c: [2010-09-13 16:38:53] Found audio description format PCMU for ID 0
[2010-09-13 16:38:53] DEBUG[20850] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:0 PCMU/8000... OK.
[2010-09-13 16:38:53] VERBOSE[20850] chan_sip.c: [2010-09-13 16:38:53] Found audio description format telephone-event for ID 101
[2010-09-13 16:38:53] DEBUG[20850] chan_sip.c: Processing media-level (audio) SDP a=rtpmap:101 telephone-event/8000... OK.
[2010-09-13 16:38:53] DEBUG[20850] chan_sip.c: Processing media-level (audio) SDP a=fmtp:101 0-15... UNSUPPORTED.
[2010-09-13 16:38:53] DEBUG[20850] chan_sip.c: Processing media-level (audio) SDP a=ptime:20... OK.
[2010-09-13 16:38:53] DEBUG[20850] chan_sip.c: Processing media-level (audio) SDP a=sendrecv... OK.
[2010-09-13 16:38:53] VERBOSE[20850] chan_sip.c: [2010-09-13 16:38:53] Capabilities: us - 0x10c (ulaw|alaw|g729), peer - audio=0x4 (ulaw)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x4 (ulaw)
[2010-09-13 16:38:53] VERBOSE[20850] chan_sip.c: [2010-09-13 16:38:53] Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
[2010-09-13 16:38:53] VERBOSE[20850] chan_sip.c: [2010-09-13 16:38:53] Peer audio RTP is at port 192.168.22.127:16458
[2010-09-13 16:38:53] DEBUG[20850] chan_sip.c: Peer doesn't provide T.38 UDPTL
[2010-09-13 16:38:53] DEBUG[20850] chan_sip.c: We're settling with these formats: 0x4 (ulaw)
[2010-09-13 16:38:53] DEBUG[20850] chan_sip.c: We have an owner, now see if we need to change this call
[2010-09-13 16:38:53] DEBUG[20850] chan_sip.c: Updating call counter for outgoing call
[2010-09-13 16:38:53] DEBUG[4594] chan_h323.c: OH323: Indicating -1 on ip$10.10.0.1:11673/5040 (H323/ip$10.10.0.1:11673/5040)
[2010-09-13 16:38:53] DEBUG[20811] devicestate.c: No provider found, checking channel drivers for H323 - ip$10.10.0.1:11673/5040
[2010-09-13 16:38:53] DEBUG[20811] devicestate.c: Changing state for H323/ip$10.10.0.1:11673/5040 - state 0 (Unknown)
[2010-09-13 16:38:53] DEBUG[20852] app_queue.c: Device 'SIP/238' changed to state '2' (In use)
[2010-09-13 16:38:53] DEBUG[20811] devicestate.c: device 'H323/ip$10.10.0.1:11673/5040' state '0'
[2010-09-13 16:38:53] DEBUG[4594] chan_h323.c: OH323: Indicated -1 on ip$10.10.0.1:11673/5040, res=-1
[2010-09-13 16:38:53] DEBUG[20852] app_queue.c: Device 'H323/ip$10.10.0.1:11673/5040' changed to state '0' (Unknown) but we don't care because they're not a member of any queue.
[2010-09-13 16:38:53] DEBUG[4594] features.c: bridge answer set, chan answer set
[2010-09-13 16:38:53] DEBUG[4594] chan_h323.c: OH323: Indicating 20 on ip$10.10.0.1:11673/5040 (H323/ip$10.10.0.1:11673/5040)
[2010-09-13 16:38:53] DEBUG[4594] rtp.c: Setting the marker bit due to a source update
[2010-09-13 16:38:53] DEBUG[4594] chan_h323.c: OH323: Indicated 20 on ip$10.10.0.1:11673/5040, res=0
[2010-09-13 16:38:53] DEBUG[4594] rtp.c: Setting the marker bit due to a source update
[2010-09-13 16:38:53] DEBUG[4594] channel.c: Set channel SIP/238-0000105c to write format ulaw
[2010-09-13 16:38:53] DEBUG[4594] channel.c: Scheduling timer at (0 requested / 0 actual) timer ticks per second
[2010-09-13 16:38:53] DEBUG[4594] rtp.c: Ooh, format changed from unknown to ulaw
[2010-09-13 16:38:53] DEBUG[4594] rtp.c: Created smoother: format: 4 ms: 20 len: 160
[2010-09-13 16:38:53] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:53] -- Received Facility message...
[2010-09-13 16:38:53] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:53] Peer capability is G.711-ALaw-64k <1>
[2010-09-13 16:38:53] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:53] Found peer capability G.711-ALaw-64k <1>, Asterisk code is 8, frame size (in ms) is 20
[2010-09-13 16:38:53] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:53] Peer capability is G.711-uLaw-64k <3>
[2010-09-13 16:38:53] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:53] Found peer capability G.711-uLaw-64k <3>, Asterisk code is 4, frame size (in ms) is 20
[2010-09-13 16:38:53] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:53] Peer capability is UserInput/dtmf <5>
[2010-09-13 16:38:53] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:53] Peer capabilities = 0xc (ulaw|alaw), ordered list is (alaw|ulaw)
[2010-09-13 16:38:53] DEBUG[4593] chan_h323.c: Got remote capabilities from connection ip$10.10.0.1:11673/5040
[2010-09-13 16:38:53] DEBUG[4593] chan_h323.c: prefs[0]=alaw:20
[2010-09-13 16:38:53] DEBUG[4593] chan_h323.c: prefs[1]=ulaw:20
[2010-09-13 16:38:53] DEBUG[4593] chan_h323.c: Autoframing option not set, ignoring peer's packetization settings
[2010-09-13 16:38:53] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:53] -- Received Facility message...
[2010-09-13 16:38:53] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:53] -- Received Facility message...
[2010-09-13 16:38:53] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:53] -- Received Facility message...
[2010-09-13 16:38:53] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:53] =-= In OnConnectionEstablished for call 5040
[2010-09-13 16:38:53] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:53] -- Connection Established with "10.10.0.1"
[2010-09-13 16:38:53] DEBUG[4593] chan_h323.c: Call ip$10.10.0.1:11673/5040 answered
[2010-09-13 16:38:53] VERBOSE[4593] ast_h323.cxx: [2010-09-13 16:38:53] -- Received Facility message...
[2010-09-13 16:38:53] DEBUG[4291] rtp.c: Got RTCP report of 80 bytes
[2010-09-13 16:38:53] DEBUG[4403] rtp.c: Got RTCP report of 80 bytes
вот такое полотенце, уж простите, не знаю куда смотреть. |
|
Сообщений: 147
|
Re: Avaya & Asterisk
Как был ставлен астериск ? Из сорцов, пакетом ? напишите oh323 и нажмите таб, если покажет варианты - значит у вас загружен кроме h323 модуля еще и oh323.
И насчет libopenh323-1.19.1 : не знаю как в 11 версии а в 9 яскно написано:
Tested with Open H.323 version v1.18.0, PWLib v1.10.0 and GCC v3.2.2. Usage of any
other (especially prior OpenH323 v1.17.3 and PWLib v1.9.2) versions is not
supported.
И вы снимали дамп с интерфейса ? Тупо tcpdump'ом. Пакеты ходят в обе стороны ? |
|
Откуда: Moscow
Сообщений: 227
|
Re: Avaya & Asterisk
knode, с libopenh323-1.19.1 - были проблемы. сейчас не помню что именно.
Вообщем как то не гладко пошло.
в результате работало и работает устойчиво либо с
openh323-v1_18_0-src-tar.gz
pwlib-v1_10_0-src-tar.gz
либо с H323Plus
H.323 version: 1.21.0
Только вот собирается с H323Plus не совсем так, как написано здесь http://asterisk.ru/knowledgebase/asterisk-h323.
И потом, на счет tcpdump -- дельный совет. Очень даже вероятно, что пакеты у вас ходят к avaya по одному пути, а возвращаются по другому.
ps
не стоит так писать
exten => _1XXX,1,Dial(H323/${EXTEN}@10.10.0.1 ,60,Tt)
- создайте custom trunk для H323 и рулите через FreePBX
Псмотрите что у вас на экране после
команды
CLI>core show channeltypes
|
|
