Схема такая LDK300<----h323---->CISCO<-----sip----->ASTERISK
C Asterisk звонок на LDK300 проходит, разговор идет - все замечательно. Проблема в звонке с LDK300 на Asterisk - звонок проходит, на телефоне Asterisk поднимаем трубку - у нас пошло время считать, а на телефоне LDK300 слышны гудки, как буд то никто на Asterisk трубку не снимал. Дабы исключить Asterisk он был заменён сиповским телефоном - таким образом в игре остались миниАТС LDK300 и cisco 2821 с sip-телефоном. Ради эксперимента в cisco была вставлена платка FXS - звонки ходят во все стороны нормально - следовательно косяк где то в преобразовании H323->SIP. Перепробовал уже все мысли которые были - помогите победить эту проблему?Какие дебаги нужны - скажите тогда выложу, а то если все выкладывать - будет много :-) Дебаги с LDK300 получить скорее не смогу... человек который её обслуживает говорит что уже не знает что может быть. с Другими H323 устройствами напрямую без cisco звонки с LDK300 проходят
LDK300:
Прошика АТС (стоит 600 проц) - 3.8
Плата voib (как выяснилость sip не поддердживает) с прошивкой 4.3Cisco 2821
IOS - c2800nm-advipservicesk9-mz.124-4.T2.bin
Конфиг касаемо того что описано (работает на ней ещё много чего)
!
voice-card 0
dspfarm
!
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
redirect ip2ip
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback none
h323
emptycapability
no call service stop
h245 caps mode restricted
modem passthrough nse codec g711ulaw redundancy
sip
no call service stop
!
voice class codec 1
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 g729r8
codec preference 4 g723r63
codec preference 5 g723r53
!
voice class h323 1
h225 connect-passthru
call start fast
!
voice register global
!
interface GigabitEthernet0/0
description LAN
ip address 192.168.0.1 255.255.252.0
no ip redirects
no ip unreachables
no ip proxy-arp
duplex auto
speed auto
no mop enabled
h323-gateway voip interface
h323-gateway voip bind srcaddr 192.168.0.1
!
dial-peer voice 3 voip
destination-pattern 5555
voice-class codec 1
session protocol sipv2
session target ipv4:192.168.1.83
!
dial-peer voice 21 voip
description Kolos H323 LDK300
destination-pattern 4[0,1,2,3][0-9][0-9]
voice-class codec 1
session target ipv4:192.168.16.17
dtmf-relay h245-alphanumeric
!
gateway
timer receive-rtp 1200
!
sip-ua
!
>[оверквотинг удален]
> destination-pattern 4[0,1,2,3][0-9][0-9]
> voice-class codec 1
> session target ipv4:192.168.16.17
> dtmf-relay h245-alphanumeric
>!
>gateway
> timer receive-rtp 1200
>!
>sip-ua
>!посмотрите н аwww.artcom.ru может что-то найдёте.
>посмотрите н аwww.artcom.ru может что-то найдёте.смотрел по инету - не помогает. Есть похожие проблемы - там говорится про обновлении прошивки и Fast Start - это действительно так - я говорил что звонок с LDK300 на другое h323 оборудование напрямую ходят нормально - а вот если на этом оборудование выключить Fast Start - будет наблюдаться такая же ситуация как и с сипом... то есть он влияет. Прошивку на LDK300 обновили, настройка Fast Start появилась, но только, кажется мне, она не работает, ибо эффекта добиться не удалось. Пробовал играться на cisco с Fast Start - не помогло - либо так же, либо еще хуже становится... более того с LDK300 больше я уже не выдавлю, мне кажется, потому я обращаюсь за советом по cisco. Что же касается LDK300 - выход то есть - надо купить другую голосовую плату, поддерживающую SIP и будут все хорошо... но только она 1) дорогая 2) не станет на мой проц - то есть + цена проца + работы по перестройки - дорогое решение получится... да и LDK300 у меня 5 штук... и вот только в одной проц поддерживающий есть....
Раньше это все работало - но вместо cisco стоял Infinet - сгорел он... и cisco пришлось принять на себя
телефонию
снифер можете показать?
>снифер можете показать?Проблемного звонка? или и проблемного и удавшегося?
Хотя сделать это трудно... может лучше дебаг какой показать? :-)
>Проблемного звонка? или и проблемного и удавшегося?прежде всего проблемного
>Хотя сделать это трудно... может лучше дебаг какой показать? :-)телепатически вижу у вас трудность из-за отсутствия коммутаторов с возможностью зеркалирования портов - тогда собирайте пакеты прямо на роутере - примерно так
monitor capture buffer buf1 size 256 max-size 256 circular
monitor capture point ip cef cappoint fa 0/0 both
monitor capture point associate cappoint buf1
monitor capture buffer buf1 filter access-list №
monitor capture point start all
monitor capture buffer buf1 export tftpболее подробно
http://techoover.blogspot.com/2008/10/capture-on-cisco-ios-t...
>Схема такая LDK300<----h323---->CISCO<-----sip----->ASTERISKу вас получается звонок из IP в IP, что на cisco реализуется функционалом CUBE, наличие которого в IOS, отражается присутствием букв _ivs, которые в вашем
>IOS - c2800nm-advipservicesk9-mz.124-4.T2.binотсутствуют
>>Схема такая LDK300<----h323---->CISCO<-----sip----->ASTERISK
>
>у вас получается звонок из IP в IP, что на cisco реализуется
>функционалом CUBE, наличие которого в IOS, отражается присутствием букв _ivs, которые
>в вашем
>>IOS - c2800nm-advipservicesk9-mz.124-4.T2.bin
>
>отсутствуютТо есть с имеющимся IOS даже смысла нет играться? надо ставить голосовой?
Просто этот работает... много чего на нем уже поднято и заменить его на голосовой будет проблематично...
>То есть с имеющимся IOS даже смысла нет играться? надо ставить голосовой?голосовой у вас и так стоит, а для использования функционала, который вы хотите, выше написано, какой ios нужен
>Просто этот работает... много чего на нем уже поднято и заменить его
>на голосовой будет проблематично...если менять на указанный, то весь остальной функционал остаётся
Поменял IOS на c2800nm-adventerprisek9_ivs-mz.124-24.T3.bin при том же конфиги теперь в обе стороны звонки не проходят. То есть. я набираю номер, у него звонит телефон, он поднимает трубку и говорит "але" - я же слышу гудки как будто бы никто не взял трубку. потом он ложит трубку и у меня идет отбой. Такой эффект в обе стороны теперь прослеживается - раньше с sip в h323 звонок проходил, обратно нет. Подскажите куда двигаться дальше с настройками этого нового иоса?
>Поменял IOS на c2800nm-adventerprisek9_ivs-mz.124-24.T3.bin при том же конфиги теперь в обе стороны
>звонки не проходят. То есть. я набираю номер, у него звонит
>телефон, он поднимает трубку и говорит "але" - я же слышу
>гудки как будто бы никто не взял трубку. потом он ложит
>трубку и у меня идет отбой. Такой эффект в обе стороны
>теперь прослеживается - раньше с sip в h323 звонок проходил, обратно
>нет. Подскажите куда двигаться дальше с настройками этого нового иоса?Может с кодаками поиграться?
>Может с кодаками поиграться?каким образом?
давайте снифер звонка LDK->Cisco
дополнительно можно
debug voice ccapi inout
debug h225 asn1
debug h245 asn1
debug ccsip all
>давайте снифер звонка LDK->CiscoВ виду большого кол-ва звонков не могу сделать это сейчас - мешаются. сниму дебаги вечером, когда народ уйдет и выложу
>debug voice ccapi inoutJun 23 08:25:04.686 PCTime: //-1/02B21E035634/CCAPI/cc_api_display_ie_subfields:
cc_api_call_setup_ind_common:
cisco-username=LDKVOIB
----- ccCallInfo IE subfields -----
cisco-ani=4169
cisco-anitype=0
cisco-aniplan=1
cisco-anipi=0
cisco-anisi=0
dest=5555
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-lastrdn=
cisco-rdntype=-1
cisco-rdnplan=-1
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0Jun 23 08:25:04.690 PCTime: //-1/02B21E035634/CCAPI/cc_api_call_setup_ind_common:
Interface=0x48A98E28, Call Info(
Calling Number=4169,(Calling Name=)(TON=Unknown, NPI=ISDN, Screening=Not Screened, Presentation=Allowed),
Called Number=5555(TON=Unknown, NPI=Unknown),
Calling Translated=FALSE, Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE,
Incoming Dial-peer=21, Progress Indication=NULL(0), Calling IE Present=TRUE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id=2844
Jun 23 08:25:04.690 PCTime: //-1/02B21E035634/CCAPI/ccCheckClipClir:
In: Calling Number=4169(TON=Unknown, NPI=ISDN, Screening=Not Screened, Presentation=Allowed)
Jun 23 08:25:04.690 PCTime: //-1/02B21E035634/CCAPI/ccCheckClipClir:
Out: Calling Number=4169(TON=Unknown, NPI=ISDN, Screening=Not Screened, Presentation=Allowed)
Jun 23 08:25:04.690 PCTime: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
Jun 23 08:25:04.690 PCTime: :cc_get_feature_vsa malloc success
Jun 23 08:25:04.690 PCTime: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
Jun 23 08:25:04.690 PCTime: cc_get_feature_vsa count is 7
Jun 23 08:25:04.690 PCTime: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
Jun 23 08:25:04.690 PCTime: :FEATURE_VSA attributes are: feature_name:0,feature_time:1250470232,feature_id:2466
Jun 23 08:25:04.690 PCTime: //2844/02B21E035634/CCAPI/cc_api_call_setup_ind_common:
Set Up Event Sent;
Call Info(Calling Number=4169(TON=Unknown, NPI=ISDN, Screening=Not Screened, Presentation=Allowed),
Called Number=5555(TON=Unknown, NPI=Unknown))
Jun 23 08:25:04.690 PCTime: //2844/02B21E035634/CCAPI/cc_process_call_setup_ind:
Event=0x498C3DF8
Jun 23 08:25:04.690 PCTime: //-1/xxxxxxxxxxxx/CCAPI/cc_setupind_match_search:
Try with the demoted called number 5555
Jun 23 08:25:04.690 PCTime: //2844/02B21E035634/CCAPI/ccCallSetContext:
Context=0x4A983FE4
Jun 23 08:25:04.690 PCTime: //2844/02B21E035634/CCAPI/cc_process_call_setup_ind:
>>>>CCAPI handed cid 2844 with tag 21 to app "_ManagedAppProcess_Default"Jun 23 08:25:04.690 PCTime: //2844/02B21E035634/CCAPI/ccCallProceeding:
Progress Indication=NULL(0)
Jun 23 08:25:04.694 PCTime: //2844/02B21E035634/CCAPI/ccCallSetupRequest:
Destination=, Calling IE Present=TRUE, Mode=0,
Outgoing Dial-peer=3, Params=0x4A9794EC, Progress Indication=NULL(0)
Jun 23 08:25:04.694 PCTime: //2844/02B21E035634/CCAPI/ccCheckClipClir:
In: Calling Number=4169(TON=Unknown, NPI=ISDN, Screening=Not Screened, Presentation=Allowed)
Jun 23 08:25:04.694 PCTime: //2844/02B21E035634/CCAPI/ccCheckClipClir:
Out: Calling Number=4169(TON=Unknown, NPI=ISDN, Screening=Not Screened, Presentation=Allowed)
Jun 23 08:25:04.694 PCTime: //2844/02B21E035634/CCAPI/ccCallSetupRequest:
Destination Pattern=5555, Called Number=5555, Digit Strip=FALSE
Jun 23 08:25:04.694 PCTime: //2844/02B21E035634/CCAPI/ccCallSetupRequest:
Calling Number=4169(TON=Unknown, NPI=ISDN, Screening=Not Screened, Presentation=Allowed),
Called Number=5555(TON=Unknown, NPI=Unknown),
Redirect Number=, Display Info=
Account Number=LDKVOIB, Final Destination Flag=TRUE,
Guid=02B21E03-619F-C9F9-5634-343434EF0000, Outgoing Dial-peer=3
Jun 23 08:25:04.694 PCTime: //2844/02B21E035634/CCAPI/cc_api_display_ie_subfields:
ccCallSetupRequest:
cisco-username=LDKVOIB
----- ccCallInfo IE subfields -----
cisco-ani=4169
cisco-anitype=0
cisco-aniplan=1
cisco-anipi=0
cisco-anisi=0
dest=5555
cisco-desttype=0
cisco-destplan=0
cisco-rdie=FFFFFFFF
cisco-rdn=
cisco-lastrdn=
cisco-rdntype=-1
cisco-rdnplan=-1
cisco-rdnpi=-1
cisco-rdnsi=-1
cisco-redirectreason=-1 fwd_final_type =0
final_redirectNumber =
hunt_group_timeout =0Jun 23 08:25:04.698 PCTime: //2844/02B21E035634/CCAPI/ccIFCallSetupRequestPrivate:
Interface=0x48E4DA1C, Interface Type=3, Destination=, Mode=0x0,
Call Params(Calling Number=4169,(Calling Name=)(TON=Unknown, NPI=ISDN, Screening=Not Screened, Presentation=Allowed),
Called Number=5555(TON=Unknown, NPI=Unknown), Calling Translated=FALSE,
Subscriber Type Str=Unknown, FinalDestinationFlag=TRUE, Outgoing Dial-peer=3, Call Count On=FALSE,
Source Trkgrp Route Label=, Target Trkgrp Route Label=, tg_label_flag=0, Application Call Id=)
Jun 23 08:25:04.698 PCTime: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
Jun 23 08:25:04.698 PCTime: :cc_get_feature_vsa malloc success
Jun 23 08:25:04.698 PCTime: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
Jun 23 08:25:04.698 PCTime: cc_get_feature_vsa count is 8
Jun 23 08:25:04.698 PCTime: //-1/xxxxxxxxxxxx/CCAPI/cc_get_feature_vsa:
Jun 23 08:25:04.698 PCTime: :FEATURE_VSA attributes are: feature_name:0,feature_time:1250470008,feature_id:2467
Jun 23 08:25:04.698 PCTime: //2845/02B21E035634/CCAPI/ccIFCallSetupRequestPrivate:
SPI Call Setup Request Is Success; Interface Type=3, FlowMode=1
Jun 23 08:25:04.698 PCTime: //2845/02B21E035634/CCAPI/ccCallSetContext:
Context=0x4A97949C
Jun 23 08:25:04.698 PCTime: //2844/02B21E035634/CCAPI/ccSaveDialpeerTag:
Outgoing Dial-peer=3
Jun 23 08:25:04.702 PCTime: //2845/02B21E035634/CCAPI/cc_api_call_proceeding:
Interface=0x48E4DA1C, Progress Indication=NULL(0)
Jun 23 08:25:07.350 PCTime: //2845/02B21E035634/CCAPI/cc_api_call_alert:
Interface=0x48E4DA1C, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
Jun 23 08:25:07.350 PCTime: //2845/02B21E035634/CCAPI/cc_api_call_alert:
Call Entry(Retry Count=0, Responsed=TRUE)
Jun 23 08:25:07.350 PCTime: //2844/02B21E035634/CCAPI/ccCallAlert:
Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
Jun 23 08:25:07.350 PCTime: //2844/02B21E035634/CCAPI/ccCallAlert:
Call Entry(Responsed=TRUE, Alert Sent=TRUE)
Jun 23 08:25:07.350 PCTime: //2845/02B21E035634/CCAPI/cc_api_get_called_ccm_detected:
CallInfo(ccm detected=0)
Jun 23 08:25:07.354 PCTime: //2844/02B21E035634/CCAPI/ccCallNotify:
Data Bitmask=0x7, Call Id=2844
Jun 23 08:25:07.354 PCTime: //2845/02B21E035634/CCAPI/cc_api_get_called_ccm_detected:
CallInfo(ccm detected=0)
Jun 23 08:25:07.354 PCTime: //2844/02B21E035634/CCAPI/cc_api_get_delay_xport:
CallInfo(delay xport=FALSE)
Jun 23 08:25:10.210 PCTime: //2845/02B21E035634/CCAPI/cc_api_event_indication:
Event=156, Call Id=2845
Jun 23 08:25:10.210 PCTime: //2845/02B21E035634/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
Jun 23 08:25:10.210 PCTime: //2845/02B21E035634/CCAPI/cc_api_event_indication:
Event=90, Call Id=2845
Jun 23 08:25:10.210 PCTime: //2845/02B21E035634/CCAPI/cc_api_event_indication:
Event Is Sent To Conferenced SPI(s) Directly
Jun 23 08:25:10.210 PCTime: //2845/02B21E035634/CCAPI/cc_api_caps_ind:
Destination Interface=0x0, Destination Call Id=-1, Source Call Id=2845,
Caps(Codec=0x0, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
Jun 23 08:25:10.210 PCTime: //2845/02B21E035634/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
Jun 23 08:25:10.210 PCTime: //2845/02B21E035634/CCAPI/cc_api_call_connected:
Interface=0x48E4DA1C, Data Bitmask=0x1, Progress Indication=NULL(0),
Connection Handle=0
Jun 23 08:25:10.210 PCTime: //2845/02B21E035634/CCAPI/cc_api_call_connected:
Call Entry(Connected=TRUE, Responsed=TRUE, Retry Count=0)
Jun 23 08:25:10.214 PCTime: //2844/xxxxxxxxxxxx/CCAPI/ccConferenceCreate:
(confID=0x4AB0F804, callID1=0xB1C, callID2=0xB1D, tag=0x0)
Jun 23 08:25:10.214 PCTime: //2844/xxxxxxxxxxxx/CCAPI/ccConferenceCreate:
(confID=0x4AB0F804, callID1=0xB1C, gcid=0-0-0-0, tag=0x0)
Jun 23 08:25:10.214 PCTime: //2845/xxxxxxxxxxxx/CCAPI/ccConferenceCreate:
(confID=0x4AB0F804, callID2=0xB1D, gcid=0-0-0-0, tag=0x0)
Jun 23 08:25:10.214 PCTime: //2844/02B21E035634/CCAPI/ccConferenceCreate:
Conference Id=0x4AB0F804, Call Id1=2844, Call Id2=2845, Tag=0x0
Jun 23 08:25:10.214 PCTime: //2844/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
Jun 23 08:25:10.214 PCTime: cc_api_get_xcode_stream : 4534
Jun 23 08:25:10.214 PCTime: //2844/xxxxxxxxxxxx/CCAPI/cc_api_bridge_done:
Conference Id=0x2E6, Source Interface=0x48A98E28, Source Call Id=2844,
Destination Call Id=2845, Disposition=0x0, Tag=0x0
Jun 23 08:25:10.214 PCTime: //2845/xxxxxxxxxxxx/CCAPI/cc_api_get_xcode_stream:
Jun 23 08:25:10.214 PCTime: cc_api_get_xcode_stream : 4534
Jun 23 08:25:10.214 PCTime: //2845/xxxxxxxxxxxx/CCAPI/cc_api_bridge_done:
Conference Id=0x2E6, Source Interface=0x48E4DA1C, Source Call Id=2845,
Destination Call Id=2844, Disposition=0x0, Tag=0x0
Jun 23 08:25:10.214 PCTime: //2844/02B21E035634/CCAPI/cc_generic_bridge_done:
Conference Id=0x2E6, Source Interface=0x48E4DA1C, Source Call Id=2845,
Destination Call Id=2844, Disposition=0x0, Tag=0x0
Jun 23 08:25:10.214 PCTime: //2844/02B21E035634/CCAPI/ccConferenceCreate:
Call Entry(Conference Id=0x2E6, Destination Call Id=2845)
Jun 23 08:25:10.214 PCTime: //2845/02B21E035634/CCAPI/ccConferenceCreate:
Call Entry(Conference Id=0x2E6, Destination Call Id=2844)
Jun 23 08:25:10.214 PCTime: //2844/02B21E035634/CCAPI/cc_process_notify_bridge_done:
Conference Id=0x2E6, Call Id1=2844, Call Id2=2845
Jun 23 08:25:10.218 PCTime: //2844/02B21E035634/CCAPI/ccCallConnect:
Progress Indication=NULL(0), Data Bitmask=0x1
Jun 23 08:25:10.218 PCTime: //2845/02B21E035634/CCAPI/cc_api_get_called_ccm_detected:
CallInfo(ccm detected=0)
Jun 23 08:25:10.218 PCTime: //2844/02B21E035634/CCAPI/ccCallConnect:
Call Entry(Connected=TRUE, Responsed=TRUE)
Jun 23 08:25:10.218 PCTime: //2844/02B21E035634/CCAPI/ccCallNotify:
Data Bitmask=0x7, Call Id=2844
Jun 23 08:25:10.218 PCTime: //2845/02B21E035634/CCAPI/cc_api_get_called_ccm_detected:
CallInfo(ccm detected=0)
Jun 23 08:25:10.970 PCTime: //2844/02B21E035634/CCAPI/cc_api_caps_ind:
Destination Interface=0x48E4DA1C, Destination Call Id=2845, Source Call Id=2844,
Caps(Codec=0x207, Fax Rate=0x2, Vad=0x2,
Modem=0x0, Codec Bytes=20, Signal Type=2)
Jun 23 08:25:10.970 PCTime: //2844/02B21E035634/CCAPI/cc_api_caps_ind:
Caps(Playout Mode=1, Playout Initial=60(ms), Playout Min=40(ms),
Playout Max=1000(ms), Fax Nom=300(ms))
Jun 23 08:25:10.970 PCTime: //2845/02B21E035634/CCAPI/cc_api_caps_ack:
Destination Interface=0x48A98E28, Destination Call Id=2844, Source Call Id=2845,
Caps(Codec=g711alaw(0x2), Fax Rate=FAX_RATE_VOICE(0x2), Vad=ON(0x2),
Modem=OFF(0x0), Codec Bytes=160, Signal Type=2, Seq Num Start=3655)
stniva#
Jun 23 08:25:15.894 PCTime: //2844/02B21E035634/CCAPI/ccGenerateToneInfo:
Stop Tone On Digit=FALSE, Tone=Null,
Tone Direction=Sum Network, Params=0x0, Call Id=2844
Jun 23 08:25:15.894 PCTime: //2845/02B21E035634/CCAPI/cc_api_call_disconnected:
Cause Value=16, Interface=0x48E4DA1C, Call Id=2845
Jun 23 08:25:15.894 PCTime: //2845/02B21E035634/CCAPI/cc_api_call_disconnected:
Call Entry(Responsed=TRUE, Cause Value=16, Retry Count=0)
Jun 23 08:25:15.894 PCTime: //2844/02B21E035634/CCAPI/ccConferenceDestroy:
Conference Id=0x2E6, Tag=0x0
Jun 23 08:25:15.894 PCTime: //2844/xxxxxxxxxxxx/CCAPI/cc_api_bridge_drop_done:
Conference Id=0x2E6, Source Interface=0x48A98E28, Source Call Id=2844,
Destination Call Id=2845, Disposition=0x0, Tag=0x0
Jun 23 08:25:15.894 PCTime: //2845/xxxxxxxxxxxx/CCAPI/cc_api_bridge_drop_done:
Conference Id=0x2E6, Source Interface=0x48E4DA1C, Source Call Id=2845,
Destination Call Id=2844, Disposition=0x0, Tag=0x0
Jun 23 08:25:15.894 PCTime: //2844/02B21E035634/CCAPI/cc_generic_bridge_done:
Conference Id=0x2E6, Source Interface=0x48E4DA1C, Source Call Id=2845,
Destination Call Id=2844, Disposition=0x0, Tag=0x0
Jun 23 08:25:15.898 PCTime: //2844/02B21E035634/CCAPI/ccCallDisconnect:
Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=0)
Jun 23 08:25:15.898 PCTime: //2844/02B21E035634/CCAPI/ccCallDisconnect:
Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
Jun 23 08:25:15.898 PCTime: //2844/02B21E035634/CCAPI/cc_api_get_transfer_info:
Transfer Number Is Null
Jun 23 08:25:15.898 PCTime: //2845/02B21E035634/CCAPI/ccCallDisconnect:
Cause Value=16, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Cause=16)
Jun 23 08:25:15.898 PCTime: //2845/02B21E035634/CCAPI/ccCallDisconnect:
Cause Value=16, Call Entry(Responsed=TRUE, Cause Value=16)
Jun 23 08:25:15.902 PCTime: //2844/02B21E035634/CCAPI/cc_api_call_disconnect_done:
Disposition=0, Interface=0x48A98E28, Tag=0x0, Call Id=2844,
Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
Jun 23 08:25:15.902 PCTime: //2844/02B21E035634/CCAPI/cc_api_call_disconnect_done:
Call Disconnect Event Sent
Jun 23 08:25:15.902 PCTime: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
Jun 23 08:25:15.902 PCTime: :cc_free_feature_vsa freeing 4A88A950
Jun 23 08:25:15.902 PCTime: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
Jun 23 08:25:15.902 PCTime: vsacount in free is 7
Jun 23 08:25:15.906 PCTime: //2845/02B21E035634/CCAPI/cc_api_call_disconnect_done:
Disposition=0, Interface=0x48E4DA1C, Tag=0x0, Call Id=2845,
Call Entry(Disconnect Cause=16, Voice Class Cause Code=0, Retry Count=0)
Jun 23 08:25:15.906 PCTime: //2845/02B21E035634/CCAPI/cc_api_call_disconnect_done:
Call Disconnect Event Sent
Jun 23 08:25:15.906 PCTime: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
Jun 23 08:25:15.906 PCTime: :cc_free_feature_vsa freeing 4A88A870
Jun 23 08:25:15.906 PCTime: //-1/xxxxxxxxxxxx/CCAPI/cc_free_feature_vsa:
Jun 23 08:25:15.906 PCTime: vsacount in free is 6
>[оверквотинг удален]
> destination-pattern 4[0,1,2,3][0-9][0-9]
> voice-class codec 1
> session target ipv4:192.168.16.17
> dtmf-relay h245-alphanumeric
>!
>gateway
> timer receive-rtp 1200
>!
>sip-ua
>!Пингуется ли АТС с Астериска (или сиповского телефоничка)?
Покажите show call history voice brief для удачного звонка с FXS платой и неудачного на сип телефончик или астериск.
В разделе
voice service voip
добавьте, если звонки по сип идут тоже через GigEth0/0:
sip
bind control source-interface GigabitEthernet0/0
bind media source-interface GigabitEthernet0/0
>Пингуется ли АТС с Астериска (или сиповского телефоничка)?да. сетка прозрачная везде
>Покажите show call history voice brief для удачного звонка с FXS платой
Неудачный звонок с h323 4169 на sip 5555
Telephony call-legs: 23
SIP call-legs: 4
H323 call-legs: 23
Call agent controlled call-legs: 0
Total call-legs: 50
13A8 : 3011 75987300ms.2604 +-1 +1930 pid:21 Originate 4159
dur 00:00:00 tx:0/0 rx:45/7200 11 (user busy (17))
IP 192.168.16.17:2522 SRTP: off rtt:0ms pl:0/0ms lost:0/0/0 delay:0/0/0ms g711alaw TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long dur callduration :n/a timestamp:n/a
Звонок с E1 1278 на h323 4169 - тут я чего то не разобрался куда смотреть
13D3 : 3156 77165700ms.2742 +2970 +15990 pid:21 Originate 4169
dur 00:00:13 tx:292/45367 rx:748/119680 29 (temporary failure (41))
IP 192.168.16.17:2594 SRTP: off rtt:767ms pl:11460/100ms lost:6/2/0 delay:65/65/75ms g711alaw TextRelay: off
media inactive detected:n media contrl rcvd:n/a timestamp:n/a
long duration call detected:n long dur callduration :n/a timestamp:n/a251B : 3143 77039850ms.2727 +5270 +6470 pid:40 Originate 1278
dur 00:00:01 tx:36/720 rx:52/1456 10 (normal call clearing (16))
Telephony 0/0/0:15 (3143) [0/0/0.4] tx:1200/760/0ms g729r8 noise:-66dBm acom:6dBm
long duration call detected:n long dur callduration :n/a timestamp:n/a
>В разделе voice service voip
>добавьте, если звонки по сип идут тоже через GigEth0/0:
> sip
> bind control source-interface GigabitEthernet0/0это не прокатило
> bind media source-interface GigabitEthernet0/0добавилось. Но звонки с другими h323 устройствами ходят нормально - проблема только с LDK300
>Схема такая LDK300<----h323---->CISCO<-----sip----->ASTERISKВ результате всех переделок у меня
1) связь перестала работать даже в одну сторону
2) примерно через 5 секунд рабочие звонки стали отбиваться - успеваешь разве что только поздороваться
Вот пункт 2 это что-то новенькое и не приятненькое...
IOS сейчас c2800nm-adventerprisek9_ivs-mz.124-24.T3.bin
Конфиг (включая строки с потоком, который в прошлом не приводил):card type e1 0 0
!
isdn switch-type primary-net5
!
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback none
h323
emptycapability
no call service stop
modem passthrough nse codec g711ulaw redundancy
sip
bind media source-interface GigabitEthernet0/0
no call service stop
!
voice class codec 1
codec preference 1 g711alaw
codec preference 2 g711ulaw
codec preference 3 g729r8
codec preference 4 g723r63
codec preference 5 g723r53
!
voice class codec 2
codec preference 1 g711alaw
!
voice class h323 1
h225 connect-passthru
call start fast
!
voice register global
!
voice-card 0
dspfarm
dsp services dspfarm
!
controller E1 0/0/0
framing NO-CRC4
pri-group timeslots 1-31!
interface Serial0/0/0:15
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn not-end-to-end 64
isdn incoming-voice voice
isdn map address .* plan unknown type unknown
isdn send-alerting
isdn bchan-number-order ascending
isdn sending-complete
no cdp enable
!
voice-port 0/0/0:15
bearer-cap Speech
!sccp local GigabitEthernet0/0
sccp ccm 192.168.0.1 identifier 1 version 4.1
sccp
!
sccp ccm group 1
bind interface GigabitEthernet0/0
associate ccm 1 priority 1
associate profile 1 register XCODE123456
keepalive retries 5
switchover method immediate
switchback method immediate
switchback interval 15
!
dspfarm profile 1 transcode
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g723r53
codec g723r63
maximum sessions 10
associate application SCCP
!
dial-peer voice 3 voip
destination-pattern 5555
voice-class codec 1
session protocol sipv2
session target ipv4:192.168.1.83
!
dial-peer voice 21 voip
description Kolos H323 LDK300
destination-pattern 4[0,1,2,3][0-9][0-9]
voice-class codec 1
session target ipv4:192.168.16.17
dtmf-relay h245-alphanumeric
!
dial-peer voice 40 pots
destination-pattern 1[1,2][0-9][0-9]
direct-inward-dial
port 0/0/0:15
forward-digits all
!gateway
timer receive-rtp 1200
!
sip-ua
!
!
!
gatekeeper
shutdown
!
забыл
telephony-service
sdspfarm units 1
sdspfarm transcode sessions 10
sdspfarm tag 1 XCODE123456
max-ephones 1
max-dn 1
ip source-address 192.168.0.1 port 2000
max-conferences 8 gain -6
transfer-system full-consult
>забылДа, проблема только с LDK300 - есть другое h323 оборудование, с которым все хорошо работает, и связь не рвется и вообще все чудесно. А с ldk300 проблема даже при такой схеме LDK300----h323----CISCO----h323----NSG800 и при такой LDK300----h323----CISCO----E1----LDK300
PS дебаг пока не удается снять - никак не соображу как составить акцеслисты что бы поймать только то что надо
>А с ldk300 проблема даже при такой схеме ...
>такой LDK300----h323----CISCO----E1----LDK300тогда как работает это
>Ради эксперимента в cisco была вставлена платка FXS - звонки ходят во все стороны нормальноили по потоку E1 ldk вам тоже не удаётся настроить?
>>А с ldk300 проблема даже при такой схеме ...
>>такой LDK300----h323----CISCO----E1----LDK300
>
>тогда как работает этоНа старом IOS это работало в обе стороны без нареканий
>>Ради эксперимента в cisco была вставлена платка FXS - звонки ходят во все стороны нормально
>
>или по потоку E1 ldk вам тоже не удаётся настроить?Нет, с потоком и FXS все нормально. просто плату FXS я временно ставил - чисто посмотреть, это было еще до потока. Сейчас связка LDK300---E1---CISCO---что_угодно_кроме_VoIPLDK300 работает хорошо. Все проблемы которые есть они есть только когда в звонке так или иначе участвует LDK300 та, которая подключена через VoIP плату (я говорил что LDK300 много и они подключены по разному как меж собой так и с Cisco).
Резюмируя - проблема только в VoIP плате LDK300, а точнее в её старой прошивки, как мне кажется- но там ничего не сделаешь, потому задача подстроить cisco под эту старую прошивку VoIP платы LDK300
Блин, LDK посылало завершение вызова зачем-то поставил no call service stop и связь рваться перестала. Вернул старый IOS - разговоры пошли в одну сторону... В общем проблема - нет разговора при звонке с LDK300 на asterisk - то есть вернулись к самому первому посту
>[оверквотинг удален]
>Нет, с потоком и FXS все нормально. просто плату FXS я временно
>ставил - чисто посмотреть, это было еще до потока. Сейчас связка
>LDK300---E1---CISCO---что_угодно_кроме_VoIPLDK300 работает хорошо. Все проблемы которые есть они есть только когда
>в звонке так или иначе участвует LDK300 та, которая подключена через
>VoIP плату (я говорил что LDK300 много и они подключены по
>разному как меж собой так и с Cisco).
>Резюмируя - проблема только в VoIP плате LDK300, а точнее в её
>старой прошивки, как мне кажется- но там ничего не сделаешь, потому
>задача подстроить cisco под эту старую прошивку VoIP платы LDK300
>>>Ради эксперимента в cisco была вставлена платка FXS - звонки ходят во все стороны нормальноэто работало с VOIB(ldk)?
>>>Ради эксперимента в cisco была вставлена платка FXS - звонки ходят во все стороны нормальноэто работало с VOIB(ldk)?
>>>>Ради эксперимента в cisco была вставлена платка FXS - звонки ходят во все стороны нормально
>
>это работало с VOIB(ldk)?Да. Так же как и звонки VOIB(ldk)---h323---CISCO---e1---PRI(ldk) сейчас работают нормально в обе стороны.
Не работают звонки voip to voip, звонки voip to pots работают
Повторюсь что звонки voip to voip без участия VOIB(ldk) - работают
debug voice ccapi inout
debug h225 asn1
debug h245 asn1
debug ccsip all
нужно всё вместе
>debug voice ccapi inout
>debug h225 asn1
>debug h245 asn1
>debug ccsip all
>нужно всё вместеhttp://83.221.166.33/
Тут примешалось еще несколько звонков, но кинул полностью все что происходило на cisco за время нужного нам звонка...
Звонок идет с номера 4169 находящегося на ldk(192.168.16.17) на сиповский аппарат с номером 5555(192.168.1.83) подключенный к cisco(192.168.0.1). телефон 5555 увидел выходящий вызов, 5 секунд поалёкал в тишину и положил трубку.
и всё таки нужен снифер
>и всё таки нужен сниферне подскажите как акцеслисты составить правильно что бы словить все что надо?
указать только ip адрес VOIB
>указать только ip адрес VOIBЧто-то ничего не получается с этой записью...
так ловлю:
access-list 100 permit ip host 192.168.16.17 any
так смотрю:
monitor capture buffer buf1 size 256 max-size 256 circular
monitor capture point ip cef cappoint tun0 both
monitor capture point associate cappoint buf1
monitor capture point start all
после чего звоню и хочу что нить увидеть:
show monitor capture buffer buf1 dump
что-то показывает...
делаю
monitor capture point stop all
monitor capture buffer buf1 export tftp:
и получаю
% Export of Capture Buffer failedИ как назло - новый IOS не звонит в обе стороны, а старый в одну сторону звонит, но не умеет capture
на 1841 на физическом интерфейсе сделайте снифер
>>>>>Ради эксперимента в cisco была вставлена платка FXS - звонки ходят во все стороны нормально
>>
>>это работало с VOIB(ldk)?
>
>Да. Так же как и звонки VOIB(ldk)---h323---CISCO---e1---PRI(ldk) сейчас работают нормально в
>обе стороны.
>
>Не работают звонки voip to voip, звонки voip to pots работают
>
>Повторюсь что звонки voip to voip без участия VOIB(ldk) - работаютВот интересная запись в вашем дебаге:
Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.0.1:5060;branch=z9hG4bK3C262B
From: <sip:4169@192.168.0.1>;tag=3596B0-188F
To: <sip:5555@192.168.1.83>;tag=1152124516
Call-ID: 7FF96397-7DDA11DF-8114BBC0-3E3EC6A0@192.168.0.1
CSeq: 101 INVITE
Contact: <sip:5555@192.168.1.83:5060;user=phone>
Supported: replaces, path, timer
User-Agent: Grandstream GXV3140 1.0.3.20
Allow-Events: talk, hold
Warning: 399 192.168.1.83 "Detected NAT type is UDP Blocked"
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
Content-Length: 0Особенно эта строка:
Warning: 399 192.168.1.83 "Detected NAT type is UDP Blocked"попробуйте в разделе sip-ua выполнить следующее:
nat symmetric check-media-src
nat symmetric role active
>попробуйте в разделе sip-ua выполнить следующее:
>nat symmetric check-media-src
>nat symmetric role activeНе помогло. выключил весь nat который был на cisco - не помогло.... эта cisco держит IPSec туннели - может влиять?
>>попробуйте в разделе sip-ua выполнить следующее:
>>nat symmetric check-media-src
>>nat symmetric role active
>
>Не помогло. выключил весь nat который был на cisco - не помогло....
>эта cisco держит IPSec туннели - может влиять?LDK через туннель подключается?
>LDK через туннель подключается?Да.
LDK300----CISCO(1841)===тунель_через_интернет===CICSO(2821)-----asterisk
хотя вот тут такая странность заметилась
[nb-admin:~] roman% traceroute 192.168.16.17
traceroute to 192.168.16.17 (192.168.16.17), 64 hops max, 52 byte packets
1 s.cisco.s.ru (192.168.0.1) 1.783 ms 0.750 ms 1.038 ms
2 b.gw.s.ru (10.200.255.4) 6.392 ms 5.619 ms 5.876 ms
3 * * *
^C
И в то же время
[nb-admin:~] roman% ping -s 1300 192.168.16.17
PING 192.168.16.17 (192.168.16.17): 1300 data bytes
1308 bytes from 192.168.16.17: icmp_seq=0 ttl=28 time=13.771 ms
1308 bytes from 192.168.16.17: icmp_seq=1 ttl=28 time=13.216 ms
^C
>[оверквотинг удален]
> 2 b.gw.s.ru (10.200.255.4) 6.392 ms 5.619 ms
>5.876 ms
> 3 * * *
>^C
>И в то же время
>[nb-admin:~] roman% ping -s 1300 192.168.16.17
>PING 192.168.16.17 (192.168.16.17): 1300 data bytes
>1308 bytes from 192.168.16.17: icmp_seq=0 ttl=28 time=13.771 ms
>1308 bytes from 192.168.16.17: icmp_seq=1 ttl=28 time=13.216 ms
>^Cдобавьте
на 2821
ip tcp path-mtu-discoveryи проверьте acl на 1841, udp разрешен?
>[оверквотинг удален]
>>PING 192.168.16.17 (192.168.16.17): 1300 data bytes
>>1308 bytes from 192.168.16.17: icmp_seq=0 ttl=28 time=13.771 ms
>>1308 bytes from 192.168.16.17: icmp_seq=1 ttl=28 time=13.216 ms
>>^C
>
>добавьте
>на 2821
>ip tcp path-mtu-discovery
>
>и проверьте acl на 1841, udp разрешен?P.S. Ввели в заблуждение многих товарищей по "цеху", сразу надо описывать всю схему.
>ip tcp path-mtu-discoveryДобавил. видимых изменений не последовало
>и проверьте acl на 1841, udp разрешен?
Разрешен. там вообще нет никаких acl кроме прикрытого ssh
>P.S. Ввели в заблуждение многих товарищей по "цеху", сразу надо описывать всю
>схему.Извиняюсь. так как сетки полностью прозрачны без натов и так далее не считал это важным. Больше, вроде, никаких сюрпризов нет
вот дамп - файл 27 мегабайт... http://83.221.166.33/zvonki.pcap.zip
1) Первый звонок - каким то чудом прошел... и мы поговорили... офигели, ибо звонок был контрольный... но не смотря на состоявшийся разговор в дампе оказался записан только одн голос...
2) потом последовала полоса неудачных звонков - фокус повторить не удалось
3) пятым звонком я звонил туда - все нормально, мы поговорили, но это и работало...Чего делать дальше так и не придумали...
>1) Первый звонок - каким то чудом прошел... и мы поговорили... офигели,
>ибо звонок был контрольный... но не смотря на состоявшийся разговор в
>дампе оказался записан только один голос...Где и как снимался дамп?
>>1) Первый звонок - каким то чудом прошел... и мы поговорили... офигели,
>>ибо звонок был контрольный... но не смотря на состоявшийся разговор в
>>дампе оказался записан только один голос...
>
>Где и как снимался дамп?Все дампы в одном месте снимались вайресшарком
ldk300----(damp)----cisco-----cisco-----ipphone
взяли свитч алайттелесин, сделали 2 порта в зеркало и с этого зеркала и снимали
Какой фильтр был в варешарке?
Если вы слышали друг друга, значит RTP поток от станции был, осталось его найти.
>Какой фильтр был в варешарке?
>Если вы слышали друг друга, значит RTP поток от станции был, осталось
>его найти.никакого - это же полный дамп... фильтр потом применяли...
>>Какой фильтр был в варешарке?
>>Если вы слышали друг друга, значит RTP поток от станции был, осталось
>>его найти.
>
>никакого - это же полный дамп... фильтр потом применяли...Какой фильтр потом применили?
Интересуют все пакеты от-на ip адрес VOIB.
>>Какой фильтр был в варешарке?
>>Если вы слышали друг друга, значит RTP поток от станции был, осталось
>>его найти.
>
>никакого - это же полный дамп... фильтр потом применяли..В самой программе wireshark есть меню telephony, там есть фильтр по VoIP Calls. И он показывает с какого куда звонил и подробную инфу. Удачный звонок и не удачный я щас выложу
Этот звонок прошел нормально:
|Time | 192.168.16.17 |
| | | 192.168.0.1 |
|58.148 | setup OLC ( g711A g7231 g729 g711U g711A g7231... |H225 From: 4000 To:5555 TunnH245:off FS:on
| |(14425) ------------------> (1720) |
|58.163 | callProceeding |H225 TunnH245:off FS:off
| |(14425) <------------------ (1720) |
|58.238 | alerting | |H225 TunnH245:off FS:off
| |(14425) <------------------ (1720) |
|58.859 | information |H225 TunnH245:off FS:off
| |(14425) ------------------> (1720) |
|63.295 | connect OLC ( g711A g711A) |H225 TunnH245:off FS:on
| |(14425) <------------------ (1720) |
|63.296 | facility | |H225 TunnH245:off FS:off
| |(14425) <------------------ (1720) |
|63.296 | | |H225 TunnH245:off FS:off
| |(14425) <------------------ (1720) |
|63.332 | RTP (g711A) |RTP Num packets:1948 Duration:38.959s SSRC:0x3E45ADEA
| |(2098) <------------------ (18434) |
|63.633 | TCS ( t38fax g729A g729 g7231 g711U g711A) |H245 terminalCapabilitySet
| |(32671) <------------------ (22893) |
|63.634 | MSD | |H245 masterSlaveDetermination
| |(32671) <------------------ (22893) |
|63.989 | TCS ( g7231 g729 g711A g711U) |H245 terminalCapabilitySet
| |(32671) ------------------> (22893) |
|63.996 | TCSAck | |H245 terminalCapabilitySetAck
| |(32671) <------------------ (22893) |
|63.999 | MSD | |H245 masterSlaveDetermination
| |(32671) ------------------> (22893) |
|64.006 | MSDAck | |H245 masterSlaveDeterminationAck
| |(32671) <------------------ (22893) |
|64.105 | TCSAck | |H245 terminalCapabilitySetAck
| |(32671) ------------------> (22893) |
|64.291 | MSDAck | |H245 masterSlaveDeterminationAck
| |(32671) ------------------> (22893) |
|102.193 | CLC | |H245 closeLogicalChannel
| |(32671) ------------------> (22893) |
|102.199 | CLCAck | |H245 closeLogicalChannelAck
| |(32671) <------------------ (22893) |
|102.242 | ESC | |H245 endSessionCommand
| |(32671) ------------------> (22893) |
|102.249 | ESC | |H245 endSessionCommand
| |(32671) <------------------ (22893) |
|102.287 | releaseComplete |H225 Q931 Rel Cause (16):Normal call clearing
| |(14425) ------------------> (1720) |
|102.294 | releaseComplete |H225 Q931 Rel Cause (16):Normal call clearing
| |(14425) <------------------ (1720) |
-------------------------------------------------------------------
А этот вызов не прошел
|Time | 192.168.16.17 |
| | | 192.168.0.1 |
|145.581 | setup OLC ( g711A g7231 g729 g711U g711A g7231... |H225 From: 4000 To:5555 TunnH245:off FS:on
| |(15541) ------------------> (1720) |
|145.598 | callProceeding |H225 TunnH245:off FS:off
| |(15541) <------------------ (1720) |
|145.666 | alerting | |H225 TunnH245:off FS:off
| |(15541) <------------------ (1720) |
|147.759 | connect OLC ( g711A g711A) |H225 TunnH245:off FS:on
| |(15541) <------------------ (1720) |
|147.760 | facility | |H225 TunnH245:off FS:off
| |(15541) <------------------ (1720) |
|147.760 | | |H225 TunnH245:off FS:off
| |(15541) <------------------ (1720) |
|147.851 | RTP (g711A) |RTP Num packets:516 Duration:10.302s SSRC:0x18E4B6D6
| |(2106) <------------------ (16724) |
|148.113 | TCS ( t38fax g729A g729 g7231 g711U g711A) |H245 terminalCapabilitySet
| |(30415) <------------------ (58867) |
|148.113 | MSD | |H245 masterSlaveDetermination
| |(30415) <------------------ (58867) |
|148.462 | TCS ( g7231 g729 g711A g711U) |H245 terminalCapabilitySet
| |(30415) ------------------> (58867) |
|148.469 | TCSAck | |H245 terminalCapabilitySetAck
| |(30415) <------------------ (58867) |
|148.471 | MSD | |H245 masterSlaveDetermination
| |(30415) ------------------> (58867) |
|148.477 | MSDAck | |H245 masterSlaveDeterminationAck
| |(30415) <------------------ (58867) |
|148.587 | TCSAck | |H245 terminalCapabilitySetAck
| |(30415) ------------------> (58867) |
|148.772 | MSDAck | |H245 masterSlaveDeterminationAck
| |(30415) ------------------> (58867) |
|158.172 | releaseComplete |H225 Q931 Rel Cause (16):Normal call clearing
| |(15541) <------------------ (1720) |
|158.236 | CLC | |H245 closeLogicalChannel
| |(30415) ------------------> (58867) |
|158.243 | CLCAck | |H245 closeLogicalChannelAck
| |(30415) <------------------ (58867) |
|158.287 | ESC | |H245 endSessionCommand
| |(30415) ------------------> (58867) |
|158.293 | ESC | |H245 endSessionCommand
| |(30415) <------------------ (58867) |
---------------------------------------------------------------------разница в одной строчке
|58.859 | information |H225 TunnH245:off FS:off
| |(14425) ------------------> (1720) |
Дело не в этом.
пакеты UDP c голосом от VOIB в снифере есть, только в этих пакетах варешарк не распознал RTP.
>вот дамп - файл 27 мегабайт... http://83.221.166.33/zvonki.pcap.zip
>1) Первый звонок - каким то чудом прошел... и мы поговорили... офигели,
>ибо звонок был контрольный... но не смотря на состоявшийся разговор в
>дампе оказался записан только одн голос...
>2) потом последовала полоса неудачных звонков - фокус повторить не удалось
>3) пятым звонком я звонил туда - все нормально, мы поговорили, но
>это и работало...во всех звонках пакеты с голосом(RTP) VOIB отправляет с номера UDP порта на две единицы отличающихся, от того что ей заявила cisco в connect`е, в полях FastStart.
Так ведёт стек h323 от cisco всегда, стеки от других производителей, обычно не заполняют это поле.
Вы можете убедится в этом на примере обратного звонка, в callProceding от ldk это поле не заполнено.
Странно что звонки ldk-cisco-pots у вас проходят нормально, не моглибы выложить снифер такого звонка для сравнения.information появилось из-за того что вы набрали на одну 5 больше.
Попробуйте набрать так ещё раз, какой будет результат?
>[оверквотинг удален]
>>3) пятым звонком я звонил туда - все нормально, мы поговорили, но
>>это и работало...
>
>во всех звонках пакеты с голосом(RTP) VOIB отправляет с номера UDP порта
>на две единицы отличающихся, от того что ей заявила cisco в
>connect`е, в полях FastStart.
>Так ведёт стек h323 от cisco всегда, стеки от других производителей, обычно
>не заполняют это поле.
>Вы можете убедится в этом на примере обратного звонка, в callProceding от
>ldk это поле не заполнено.И как с этим бороться?..
>Странно что звонки ldk-cisco-pots у вас проходят нормально, не моглибы выложить снифер
>такого звонка для сравнения.звонок с 4000(двл300)----h323----CISCO----E1----1278(ldk300)
http://83.221.166.33/1278.pcap.zip>
>information появилось из-за того что вы набрали на одну 5 больше.
>Попробуйте набрать так ещё раз, какой будет результат?попробовали. друг друга не услышали... фокус не повторился :-(
>звонок с 4000(двл300)----h323----CISCO----E1----1278(ldk300)
>http://83.221.166.33/1278.pcap.zipварешарк также не увидел RTP от ldk, и ситуация с портами точно такая же.
При этом вы слышали друг друга нормально?
>варешарк также не увидел RTP от ldk, и ситуация с портами точно
>такая же.
>При этом вы слышали друг друга нормально?Да, слышим нормально и все вообще нормально при звонке в Е1 - ну внешне нормально и гудки, и связь и голос и все замечательно - как самый обычный звонок