Итак, имеем Sangoma A108 и, соответственно, 8 линий Е1. Два сигнальных линка - 16 и 48. Инструкций много, я делал, в принципе, по http://www.barryodonovan.com/index.php/2 ... am-support - только Dahdi брал 2.5, так как 2.4 собирается с ошибками сам по себе на моём ядре, а с 2.6 не собирается драйвер wanpipe (Sangoma об этом знает и "работает над этим", но когда доработает - хз).
Не буду приводить все конфигурации, достаточно первых двух линий, проблемы видны во всей красе.
wanpipe1.conf
| Код: |
| [devices] wanpipe1 = WAN_AFT_TE1, Comment [interfaces] w1g1 = wanpipe1, , TDM_VOICE, Comment [wanpipe1] CARD_TYPE = AFT S514CPU = A CommPort = PRI AUTO_PCISLOT = NO PCISLOT = 4 PCIBUS = 5 FE_MEDIA = E1 FE_LCODE = HDB3 FE_FRAME = NCRC4 FE_LINE = 1 TE_CLOCK = NORMAL TE_REF_CLOCK = 0 TE_SIG_MODE = CCS TE_HIGHIMPEDANCE = NO TE_RX_SLEVEL = 430 LBO = 120OH FE_TXTRISTATE = NO MTU = 1500 UDPPORT = 9000 TTL = 255 IGNORE_FRONT_END = NO TDMV_SPAN = 1 TDMV_DCHAN = 0 TE_AIS_MAINTENANCE = NO TDMV_HW_DTMF = NO # YES: receive dtmf events from hardware TDMV_HW_FAX_DETECT = NO # YES: receive fax 1100hz events from hardware HWEC_OPERATION_MODE = OCT_NORMAL # OCT_NORMAL: echo cancelation enabled with nlp (default) # OCT_SPEECH: improves software tone detection by disabling NLP (echo possible) # OCT_NO_ECHO:disables echo cancelation but allows VQE/tone functions. HWEC_DTMF_REMOVAL = NO # NO: default YES: remove dtmf out of incoming media (must have hwdtmf enabled) HWEC_NOISE_REDUCTION = NO # NO: default YES: reduces noise on the line - could break fax HWEC_ACUSTIC_ECHO = NO # NO: default YES: enables acustic echo cancelation HWEC_NLP_DISABLE = NO # NO: default YES: guarantees software tone detection (possible echo) HWEC_TX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio level to be maintained (-20 default) HWEC_RX_AUTO_GAIN = 0 # 0: disable -40-0: default tx audio level to be maintained (-20 default) HWEC_TX_GAIN = 0 # 0: disable -24-24: db values to be applied to tx signal HWEC_RX_GAIN = 0 # 0: disable -24-24: db values to be applied to tx signal [w1g1] ACTIVE_CH = ALL TDMV_HWEC = NO MTU = 8 |
Для других идентично, только линии указаны соответствующие.
system.conf:
| Код: |
| loadzone=us defaultzone=us #Sangoma A108 port 1 [slot:4 bus:5 span:1] span=1,1,0,ccs,hdb3 bchan=1-15,17-31 mtp2=16 echocanceller=mg2,1-15,17-31 #Sangoma A108 port 2 [slot:4 bus:5 span:2] span=2,2,0,ccs,hdb3 bchan=32-47,49-62 mtp2=48 echocanceller=mg2,32-47,49-62 #Sangoma A108 port 3 [slot:4 bus:5 span:3] span=3,2,0,ccs,hdb3 bchan=63-93 echocanceller=mg2,63-93 |
Итак, * 1.6 и libss7
Вот конфиг (chan_dahdi.conf):
| Код: |
| [trunkgroups] [channels] usecallerid=yes hidecallerid=no callwaiting=yes usecallingpres=yes callwaitingcallerid=yes threewaycalling=yes transfer=yes canpark=yes cancallforward=yes callreturn=yes relaxdtmf=yes ;rxgain=0.0 ;txgain=0.0 switchtype=national context=ss7 echocancel=no signaling=ss7 ss7type=itu ss7_called_nai=unknown ss7_calling_nai=unknown ss7_internationalprefix=00 ss7_nationalprefix=0 ss7_subscriberprefix= ss7_unknownprefix= linkset=1 pointcode=5486 adjpointcode=10001 defaultdpc=10001 networkindicator=national group=0 callgroup=1 pickupgroup=1 immediate=no cicbeginswith=1 channel=1-15 cicbeginswith=17 channel=17-31 sigchan=16 cicbeginswith=33 channel=33-47 cicbeginswith=49 channel=49-63 sigchan=48 |
По непонятной причине устанавливается только первый сигнальный линк, а по второму только отправляется постоянно, но никакого ответа (забегая вперёд замечу, что с chan_ss7 работают оба линка!)
Link state change: NOTALIGNED -> IDLE
Link state change: IDLE -> NOTALIGNED
Len = 4 [ ff ff 01 00 ]
FSN: 127 FIB 1
BSN: 127 BIB 1
>[1] LSSU SIO
При этом CIC 33 (а также 49) - в состоянии unequipped:
| Код: |
| ......... 30 10001 30 Idle 31 10001 31 Idle 33 10001 33 NotInServ R:M 34 10001 34 NotInServ ........ |
Когда приходит звонок, экстеншн почему-то не находится:
| Код: |
| [Jan 24 07:34:55] VERBOSE[10731] logger.c: SS7 exten: 5512 complete: 1 [Jan 24 07:34:55] DEBUG[10731] chan_dahdi.c: Call on CIC for unconfigured extension 5512 |
Причём ошибку-то выдаёт chan_dahdi, то есть даже до dialplan-а не доходит дело (если я правильно понимаю).
Выше можно увидеть, кто контекст задан. В чём тут дело?
* 1.4 и chan_ss7
Конфиг следующий:
| Код: |
| [linkset-siuc] enabled => yes enable_st => no use_connect => no hunting_policy => even_mru context => ss7 language => en t35 => 15000,timeout subservice => auto variant => ITU [link-l1] linkset => siuc channels => 1-15,17-31 schannel => 16 firstcic => 1 enabled => yes echocancel => no sltm => no [link-l2] linkset => siuc channels => 1-15,17-31 schannel => 16 firstcic => 33 enabled => yes echocancel => no sltm => no [link-l3] linkset => siuc channels => 1-15,17-31 schannel => firstcic => 65 enabled => yes echocancel => no sltm => no [host-linux] enabled => yes opc => 5486 dpc => siuc:10001 links => l1:1,l2:2,l3:3 |
Удивительно, но, если отключить хардварное эхоподавление и DTMF-ы в настройках wanpipeX.conf - поднимается и второй сигнальный линк! Однако, работают только первые 30 линий. Во второму линку вот такое:
| Код: |
| [Jan 24 06:50:07] WARNING[30273]: l4isup.c:1582 t23_timeout: T23 timeout (No "circuit group reset acknowledge" from peer) CIC=33. [Jan 24 06:50:07] WARNING[30273]: l4isup.c:1582 t23_timeout: T23 timeout (No "circuit group reset acknowledge" from peer) CIC=48. [Jan 24 06:50:07] WARNING[30273]: l4isup.c:1582 t23_timeout: T23 timeout (No "circuit group reset acknowledge" from peer) CIC=65. [Jan 24 06:50:07] WARNING[30273]: l4isup.c:1582 t23_timeout: T23 timeout (No "circuit group reset acknowledge" from peer) CIC=81. [Jan 24 06:50:07] WARNING[30273]: l4isup.c:5057 l4isup_event: Received UEC (CIC 48), link 'l1'. [Jan 24 06:50:07] WARNING[30273]: l4isup.c:3026 process_circuit_message: Reset still in progress for CIC=48, typ=UEC, state=0 message discarded. [Jan 24 06:50:07] WARNING[30273]: l4isup.c:5057 l4isup_event: Received UEC (CIC 33), link 'l2'. [Jan 24 06:50:07] WARNING[30273]: l4isup.c:3026 process_circuit_message: Reset still in progress for CIC=33, typ=UEC, state=0 message discarded. [Jan 24 06:50:07] WARNING[30273]: l4isup.c:5057 l4isup_event: Received UEC (CIC 65), link 'l2'. [Jan 24 06:50:07] WARNING[30273]: l4isup.c:3026 process_circuit_message: Reset still in progress for CIC=65, typ=UEC, state=0 message discarded. [Jan 24 06:50:07] WARNING[30273]: l4isup.c:5057 l4isup_event: Received UEC (CIC 81), link 'l2'. [Jan 24 06:50:07] WARNING[30273]: l4isup.c:3026 process_circuit_message: Reset still in progress for CIC=81, typ=UEC, state=0 message discarded. |
Не понятно тут следующее:
1. С какого перепуга CIC 48 относится к линку l1? С какого перепуга CIC 65 и 81 относятся к линку l2? (хотя есть подозрение, что тут пишется сигнальный линк...)
2. Если во втором линке поставить channels 2-15,17-31 - то UEC приходит на CIC 34 - то есть в любом случае первый из списка.
3. Почему если unequipped только 33-й - не помечены как рабочие остальные?
| Код: |
| CIC 29 Idle CIC 30 Idle CIC 31 Idle CIC 33 Idle Reset pending CIC 34 Idle Reset pending CIC 35 Idle Reset pending |
В отличие от libss7 - тут звонки попадают в нужный контекст и, соответственно, они есть в dialplan-е.
Однако, когда я поставил проигрывание тестового файла из дистрибутива (/var/lib/asterisk/sounds), оказалось что ещё проблема с кодеками, и вот это уже совсем не понятно:
| Код: |
| [Jan 23 19:15:07] DEBUG[30254] devicestate.c: Changing state for SS7/siuc/1 - state 0 (Unknown) [Jan 23 19:15:07] DEBUG[32053] channel.c: Set channel SS7/siuc/1 to write format gsm [Jan 23 19:15:07] DEBUG[30282] app_queue.c: Device 'SS7/siuc/1' changed to state '0' (Unknown) but we don't care because they're not a member of any queue. [Jan 23 19:15:07] DEBUG[30273] mtp.c: Queue MSU, lsi=0, last_send_ix=0, linkset=siuc, m->link=l2 [Jan 23 19:15:07] DEBUG[30273] mtp.c: Queue MSU, lsi=0, last_send_ix=0, linkset=siuc, m->link=l2 [Jan 23 19:15:07] DEBUG[32053] channel.c: Scheduling timer at 160 sample intervals [Jan 23 19:15:07] VERBOSE[32053] logger.c: -- Playing 'queue-periodic-announce' (language 'en') [Jan 23 19:15:07] DEBUG[30273] mtp.c: Sending buffer to dahdi len=14, on link 'l2' bsn=45, fsn=67. [Jan 23 19:15:07] DEBUG[30273] mtp.c: Sending buffer to dahdi len=17, on link 'l2' bsn=45, fsn=68. [Jan 23 19:15:07] NOTICE[32053] channel.c: Dropping incompatible voice frame on SS7/siuc/1 of format ulaw since our native format has changed to 0x8 (alaw) |
А где для ss7 задать кодеки и как они вообще выбираются? Для SIP-то понятно...
Ну и в заключение - непонятность общего характера. В Е1 32 канала, первый канал используется для синхронизации (Максим в первом комментарии к странице привёл как раз: http://asteriskpbx.ru/pages/viewpage.action?pageId=1737125). Dahdi же выдаёт по 31 канал на каждый порт, при этом нумеруя их сквозной нумерацией. Получается, что, например, на второй линии должны быть CIC 33-63. А lsdahdi выдаёт, что 63 получается на 3-й линии уже:
| Код: |
| 31 PRI Clear (In use) (EC: MG2 - INACTIVE) ### Span 2: WPE1/1 "wanpipe2 card 1" HDB3/CCS 32 PRI Clear (EC: MG2 - INACTIVE) 33 PRI Clear (In use) (EC: MG2 - INACTIVE) 34 PRI Clear (In use) (EC: MG2 - INACTIVE) 35 PRI Clear (In use) (EC: MG2 - INACTIVE) 36 PRI Clear (In use) (EC: MG2 - INACTIVE) 37 PRI Clear (In use) (EC: MG2 - INACTIVE) 38 PRI Clear (In use) (EC: MG2 - INACTIVE) 39 PRI Clear (In use) (EC: MG2 - INACTIVE) 40 PRI Clear (In use) (EC: MG2 - INACTIVE) 41 PRI Clear (In use) (EC: MG2 - INACTIVE) 42 PRI Clear (In use) (EC: MG2 - INACTIVE) 43 PRI Clear (In use) (EC: MG2 - INACTIVE) 44 PRI Clear (In use) (EC: MG2 - INACTIVE) 45 PRI Clear (In use) (EC: MG2 - INACTIVE) 46 PRI Clear (In use) (EC: MG2 - INACTIVE) 47 PRI Clear (In use) (EC: MG2 - INACTIVE) 48 PRI MTP2 (In use) 49 PRI Clear (In use) (EC: MG2 - INACTIVE) 50 PRI Clear (In use) (EC: MG2 - INACTIVE) 51 PRI Clear (In use) (EC: MG2 - INACTIVE) 52 PRI Clear (In use) (EC: MG2 - INACTIVE) 53 PRI Clear (In use) (EC: MG2 - INACTIVE) 54 PRI Clear (In use) (EC: MG2 - INACTIVE) 55 PRI Clear (In use) (EC: MG2 - INACTIVE) 56 PRI Clear (In use) (EC: MG2 - INACTIVE) 57 PRI Clear (In use) (EC: MG2 - INACTIVE) 58 PRI Clear (In use) (EC: MG2 - INACTIVE) 59 PRI Clear (In use) (EC: MG2 - INACTIVE) 60 PRI Clear (In use) (EC: MG2 - INACTIVE) 61 PRI Clear (In use) (EC: MG2 - INACTIVE) 62 PRI Clear (In use) (EC: MG2 - INACTIVE) ### Span 3: WPE1/2 "wanpipe3 card 2" HDB3/CCS 63 PRI Clear (In use) (EC: MG2 - INACTIVE) |
Получается, dahdi не показывает каналы для синхронизации которые? И надо нумеровать по-дургому? Но почему тогда все примеры, что есть в интернете - именно с такой нумерацией, как у меня?
у меня как раз 2 сигнальных линка на А108 и chan_ss7
| adt2k писал(а): |
| поищите мои посты у меня как раз 2 сигнальных линка на А108 и chan_ss7 |
Да, они мне попадались.
у Вас другие проблемы были...
у Вас не правильно описаны конфиги, посравнивайте их.
Added after 3 minutes:
у вас в конфиге cic на один сдвинут, начиная с 32 должно быть во втором span
| adt2k писал(а): |
| у вас в конфиге cic на один сдвинут, начиная с 32 должно быть во втором span |
Ну вот я в конце об этом и пишу.
Однако в этом случае вопрос: а почему, собственно, с текущими настройками chan_ss7 для второго линка
schannel => 16
firstcic => 33
второй сигнальный линк поднимается?
И то есть получается, что всё-таки нумерация каналов в dahdi действительно не соответствует CIC-ам? Я в первом посте приводил ссылку на asteriskpbx, там комментарий был следующий (для chan_ss7 как раз):
| Цитата: |
| The first column are the timeslot where a sync. signal is present. The 'firstcic' directive should be the number in the second column (right after the '|') 1, 33, 65 and 97. Signalling timeslots are the column where the first '16' is in (16, 48, 80 and 112). Usually you will only use 16 for signalling and then 48, 80 and 112 for audio. Now comes the tricky part.. The "channels" and "schannels" directive refers to cic's at the particular E1 so they should be less than or equal to 31 and more than or equal to 1. In contrary, the 'firstcic' directive refers to all the E1's so it should typically be 1, 33, 65 or 97. |
Added after 2 minutes:
| adt2k писал(а): |
| я кому-то написал полное решение. у вас в конфиге cic на один сдвинут, начиная с 32 должно быть во втором span |
У Вас тоже: http://asteriskforum.ru/viewtopic.php?p=38516#38516
Тоже 1 - 33 - 65 -97 в ss7.conf (и один сигнальный в той ссылке, кстати)
И тоже 1-31, 32-62 и т.д. в system.conf
обратите внимание, при использовании chan_ss7 нужно в /etc/dahdi/system.conf нужно описывать все таймслоты
а сигнальные линки только в файле /etc/asterisk/ss7.conf
(в примере прописан mtp2, но после запуска это можно убрать, так как потом начинает работать mtp2 от chan_ss7)
Added after 1 minutes:
http://asteriskforum.ru/viewtopic.php?p= ... conf#45415
| adt2k писал(а): |
| вы путаете timeslot и CIC обратите внимание, при использовании chan_ss7 нужно в /etc/dahdi/system.conf нужно описывать все таймслоты а сигнальные линки только в файле /etc/asterisk/ss7.conf (в примере прописан mtp2, но после запуска это можно убрать, так как потом начинает работать mtp2 от chan_ss7) Added after 1 minutes: http://asteriskforum.ru/viewtopic.php?p= ... conf#45415 |
Не то чтобы путаю - я пытаюсь понять, как соотносятся таймслоты, каналы в dahdi и CIC-и
chan_ss7 вроде работает и с текущими настройками (см. мой system.conf, он с mtp2). Не понятно, почему при одном и том же system.conf chan_ss7 поднимает оба линка, а libss7 только один. Я грешил сначала на родную libss7, которая не понимает настройки SLC. Но в итоге взял патченную/улучшенную (в первом посте приводил ссылку на инструкцию для сангомы, там как раз она была), и в ней видно, что SLC стоит какой нужно, 0 и 1 соответственно.
system.conf
| Код: |
| loadzone=ru defaultzone=ru #Sangoma A104 port 1 [slot:4 bus:7 span:1] span=1,0,0,ccs,hdb3,crc4 bchan=1-31 #Sangoma A104 port 2 [slot:4 bus:7 span:2] span=2,0,0,ccs,hdb3,crc4 bchan=32-62 #Sangoma A104 port 3 [slot:4 bus:7 span:3] span=3,0,0,ccs,hdb3,crc4 bchan=63-93 #Sangoma A104 port 4 [slot:4 bus:7 span:4] span=4,0,0,ccs,hdb3,crc4 bchan=94-124 #Sangoma A104 port 1 [slot:4 bus:5 span:5] span=5,0,0,ccs,hdb3,crc4 bchan=125-155 #Sangoma A104 port 2 [slot:4 bus:5 span:6] span=6,0,0,ccs,hdb3,crc4 bchan=156-186 #Sangoma A104 port 3 [slot:4 bus:5 span:7] span=7,0,0,ccs,hdb3,crc4 bchan=187-217 #Sangoma A104 port 4 [slot:4 bus:5 span:8] span=8,0,0,ccs,hdb3,crc4 bchan=218-248 |
chan_dahdi.conf
| Код: |
| ;autogenerated by /usr/sbin/wancfg_dahdi do not hand edit ;autogenrated on 2009-01-15 ;Dahdi Channels Configurations ;For detailed Dahdi options, view /etc/asterisk/chan_dahdi.conf.bak [trunkgroups] [channels] language=ru context=from-pstn usecallerid=yes hidecallerid=no callwaiting=yes usecallingpres=yes callwaitingcallerid=yes threewaycalling=no transfer=yes canpark=yes cancallforward=yes callreturn=yes echocancel=no echocancelwhenbridged=no relaxdtmf=yes rxgain=0.0 txgain=0.0 group=0 callgroup=1 pickupgroup=1 immediate=no |
ss7.conf
| Код: |
| [linkset-A] enabled => yes enable_st => yes use_connect => no hunting_policy => even_mru subservice => auto context => from-pstn language=>ru t35 => 15000,timeout variant => ITU [link-a1] linkset => A channels => 1-31 schannel => firstcic => 1 enabled => yes [link-a2] sls => 0 linkset => A channels => 1-15,17-31 schannel => 16 firstcic => 33 enabled => yes [link-a3] linkset => A channels => 1-31 schannel => firstcic => 65 enabled => yes [link-a4] linkset => A channels => 1-31 schannel => firstcic => 97 enabled => yes [link-a5] linkset => A channels => 1-31 schannel => firstcic => 129 enabled => yes [link-a6] linkset => A channels => 1-31 schannel => firstcic => 161 enabled => yes [link-a7] sls => 1 linkset => A channels => 1-15,17-31 schannel => 16 firstcic => 193 enabled => yes [link-a8] linkset => A channels => 1-31 schannel => firstcic => 225 enabled => yes [host-HOSTNAME] enabled => yes if-1 => HOST_IP opc => 0xXXX dpc => A:0xYYY links => a1:1,a2:2,a3:3,a4:4,a5:5,a6:6,a7:7,a8:8 [jitter] jbenable = yes jbmaxsize = 1000 jbresyncthreshold = 1000 jbimpl = adaptiv |
Added after 3 minutes:
а вот ещё момент. у меня так работает chan_ss7 1.3, проверено на 1.4.* - то же работает
| adt2k писал(а): |
| мои конфиги |
Ну да, всё так же по сути, кроме mtp2 в system.conf...
| adt2k писал(а): |
| а вот ещё момент. у меня так работает chan_ss7 1.3, проверено на 1.4.* - то же работает |
Кстати, да. У меня chan_ss7 2.1, протупил что-то, что можно ещё постарше попробовать версию.
Added after 33 minutes:
Удивительно, но chan_ss7 1.4.3 исправил проблему с кодеком
| Shurman писал(а): | ||
| |
| Код: |
| [Jan 23 19:15:07] DEBUG[30254] devicestate.c: Changing state for SS7/siuc/1 - state 0 (Unknown) [Jan 23 19:15:07] DEBUG[32053] channel.c: Set channel SS7/siuc/1 to write format gsm ..... [Jan 23 19:15:07] NOTICE[32053] channel.c: Dropping incompatible voice frame on SS7/siuc/1 of format ulaw since our native format has changed to 0x8 (alaw) |
То есть в логах ошибок этих нет и судя по всему всё проигралось.
Остальное без изменения....
Added after 1 hours 42 minutes:
Но самое интересно вот что.
Написано в chan_dahdi.conf:
cicbeginswith=33
channel=33-47
Имеем:
29 ss7 default In Service
30 ss7 default In Service
31 ss7 default In Service
33 ss7 default R Not In Ser
34 ss7 default Not In Ser
35 ss7 default Not In Ser
Меняем на
cicbeginswith=35
channel=35-47
Имеем:
29 ss7 default In Service
30 ss7 default In Service
31 ss7 default In Service
35 ss7 default R Not In Ser
36 ss7 default Not In Ser
R -это результат chan_dahdi.c: Unequiped Circuit Id Code on CIC 35
Но почему он всегда на первом в списке канале?
С chan_ss7 то же самое
Цензурно не сказать...
Отчет по ОКС7 для стандартного chan_dahdi на основе libss7.
Собственно говоря, все работает. Используется Asterisk 10.1.0 (ибо хочется T.38 на переходе SIP - TDM). svn-овский libss7 (ибо лень было портировать chan_ss7 под 10-ю ветку).
Тестировалось:
- "Юнител" - Asterisk, 2xE1 от "Юнител", входящие и исходящие вызовы. Уже в полукоммерческом режиме, нагрузка около 10000 вызовов/сутки. Используется в качестве конвертора протоколов, T.38 для TDM endpoint и вылавливания всяких полезных фич из ОКСа.
- Подключение к "Beeline" (тест), 1xE1, синхра от него. Все работает. Впрочем, beeline всегда был пофигистом (это я к CLIP-ам, номерным планам, категориям и т.п.).
Предупреждение!
1. Не работает DTMF со стороны TDM, если вызов был инициирован по цепочке SIP -> Asterisk -> TDM, а DTMF сигнализация для SIP установлена в виде любого outband-типа. Причина - в chan_dahdi забыли после установки соединения разобраться с голосовым каналом (в частности, повесить на него DSP). Пофиксил, патч см. на https://issues.asterisk.org Фиксится легко, патч может быть портирован на любые версии минут за 5.
2. Не передаются состояния BUSY/INCOMPLETE/CONGESTION на сторону TDM, если вызов был инициирован по цепочке TDM->Asterisk->любой_канал. Причина - в sig_ss7 забыли, что эти индикации все-таки являются причиной для REL и ждать в этом случае таймаута совсем не обязательно))). Пофиксил. Патч там же. Очень легкий, может быть портирован на любую версию.
Ну, как-то так...
С уважением,
Игорь Николаев.
А что-нибудь слышно про кластерность на libss7?