сбрасывается вызов
FreeBPX через шлюз астеройд в аналоговую сеть МГТС москвы.
столкнулся с такой проблемой, что если звонить на определенный номер (например домашний), вызов сбрасывается после 4 гудка.
звонок просходит с кода 495 на код 499 если это как то поможет с догадками.
возможно ли как про диагностировать проблему?
может какие то есть дополнительные настройки астеройда?
в качестве sip телефонов cisco 303.
прописал лог сервер "Syslog Server:"
ниже есть "Debug Level:" у меня он в "0" там 3 уровня, интересно какой из них самый болтливый?
_________________
Asterisk 1.4.30 @ Ubuntu 9.04 + Cisco MC3810 + NEC NEAX 2000IPS + Polycom IP Phones
| exec @ Ср Мар 26, 2014 01:17 писал(а): |
| возможно ли как про диагностировать проблему? |
Можно. Подключитесь к консоли астера и скопируйте лог звонка.
вот лог:
| Код: |
| ... -- Called DAHDI/g3/8xxxxxxxxxx -- DAHDI/18-1 answered SIP/3xx-000a5c89 [2016-05-26 12:25:01] NOTICE[18072]: manager.c:2479 authenticate: Seems to have passed... -- Executing [h@macro-dialout-trunk:1] Macro("SIP/3xx-000a5c89", "hangupcall,") in new stack -- Executing [s@macro-hangupcall:1] GotoIf("SIP/3xx-000a5c89", "1?theend") in new stack -- Goto (macro-hangupcall,s,3) -- Executing [s@macro-hangupcall:3] ExecIf("SIP/3xx-000a5c89", "0?Set(CDR(recordingfile)=)") in new stack -- Executing [s@macro-hangupcall:4] Hangup("SIP/3xx-000a5c89", "") in new stack == Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/3xx-000a5c89' in macro 'hangupcall' == Spawn extension (macro-dialout-trunk, h, 1) exited non-zero on 'SIP/3xx-000a5c89' -- Hanging up on 'DAHDI/18-1' -- Hungup 'DAHDI/18-1' == Spawn extension (macro-dialout-trunk, s, 22) exited non-zero on 'SIP/3xx-000a5c89' in macro 'dialout-trunk' == Spawn extension (from-internal, 98xxxxxxxxxx, 5) exited non-zero on 'SIP/3xx-000a5c89' == MixMonitor close filestream (mixed) == End MixMonitor Recording SIP/3xx-000a5c89 |
_________________
платный суппорт по мере возможностей
и так. у нас есть отдельная линия подключенная к МГТС без freebpx на которой стоит обычный телефон. номер от остальных линий отличается тремя последними цифрами.
звонок с этого телефона показал что вызов идет в течении 24 гудков, потом сбрасывается МГТС-ом.
следующие что я сделал. стал звонить через freebpx-шлюз-МГТС по разным линиям себе на мобилку ну и смотрю по определившимся номерам что звонок идет с разных линий. ну то есть через номер 1, номер 2, номер 3. во всех трех случаях результат один и тот же, после 4-5 гудков отбой. пока у меня складывается впечатление что проблема с моей стороны(freebpx шлюз), а не у МГТС.
Так вот и смотрите таймеры.
Мое мнение - срабатывает таймер детектора сигнала "занято". Стоит его найти и покрутить.
| Цитата: |
| Что такое гудки? Есть нормальная единица измерения длительности - секунда. |
с момента нажатия на моем sip телефоне cisco 303 до момента сбрасывания вызова, проходит 23 секунды.
| Цитата: |
| Так вот и смотрите таймеры. |
так вот его то я и пытаюсь найти. пока мне не удалось.
| Цитата: |
| Мое мнение - срабатывает таймер детектора сигнала "занято". |
не исключено. как это выявить?
проблема в шлюзе? у меня он называется Asteroid и по dashdi соединен с freebpx
проблема в настройках FreeBPX ?
На такущий момент, методом научного тыка перебираю раздел "FreePBX Advanced Settings"
меняю цифорки на большие и обратно.
пока результата нету....
мой chan_dashdi.conf
| Код: |
| [trunkgroups] [channels] language=ru relaxdtmf=yes rxflash=850 ;== busy busydetect=yes busycount=3 ;== pulse pulsedial=no pulse=no ;== Calls handling == callwaiting=yes threewaycalling=yes transfer=yes cancallforward=yes ;== Caller ID == usecallerid=yes callerid=asreceived hidecallerid=no ;;callwaitingcallerid=yes useincomingcalleridonzaptransfer=yes ; cidsignalling=bell cidstart=ring restrictcid=no callreturn=yes echocancel=no echotraining=no echocancelwhenbridged=no ;;;;;;;;;;;;; group=3 context=from-trunk signalling=fxs_ls channel=16,18,19,20,21,22,24,25,26,27,28,29,30 group=0 callgroup=1 pickupgroup=1 immediate=no faxdetect=incoming #include dahdi-channels.conf group=1 ;Include AMP configs #include chan_dahdi_additional.conf |
на текущий момент нащупал причину.
заключается она в параметре
busycount=3
увеличение этого значения, увеличивает время отбоя.
я так понимаю, что железка не понимает что вызов, это не сигналы занято.
или эта функция упрощена на столько что не различает сигналы "занято" или "идет вызов" ???
отключить я ее тоже наверное не могу, так так получу зависшие линии. или я не прав?
подскажите, что делать?
сейчас я установил значение в 20, так сказать поставил костыль.
но надо как то девайс научить различать сигналы.
Последний раз редактировалось: exec (Пт Май 27, 2016 11:36)
| Код: |
| language=ru relaxdtmf=yes rxflash=850 |
возможно стоит присмотреться к параметру rxflash=850
есть такая инфа:
http://www.voip-info.org/wiki/view/Aster ... dahdi.conf
| Цитата: |
| ; prewink: Pre-wink time (default 50ms) ; preflash: Pre-flash time (default 50ms) ; wink: Wink time (default 150ms) ; flash: Flash time (default 750ms) ; start: Start time (default 1500ms) ; rxwink: Receiver wink time (default 300ms) ; rxflash: Receiver flashtime (default 1250ms) ; debounce: Debounce timing (default 600ms) |
с пониманием туга, так как я тоже могу назвать "дерево" как нибудь "палкорост", а потом по тихому угарать, над тем как мучаются с переводом японцы.
но судя из описания это какой то "время мерцающего приемника"
интересно, есть ли уже какие то готовые значения для Москвы?
или надо брать осцелограф и мерить интервалы, частоты ?
ну и логику мы не упостим? мож это значение спецом занижено, что бы отрубало все. так сказать наверняка!
из соображения лучше поздний отбой, чем отсутствие свободных линий (из за переполнения весиками)
вот еще что попалось:
busypattern=500,500
интересно, цифры для меня подходят?
прицепил картинку.
на ней видно, что сначало идут длинные гудки, потом короткие.
короткие гудки железкой не распознаются, и вырубаются по "busycount=20"
внизу так же приведен частотный график. вопрос доверия наверное к ниму не большой,
но порядки оценить можно. 500 ?
есть смысл как то калиброваться?
и в какую сторону округлять? в меньшую? большую?
установка параметров:
busycount=3
busypattern=500,500
привела к тому, что вызов "длинные гудки" не отбиваются,
но и после того как МГТС сбрасывает вызов, и шлет "короткие гудки", железка не реагирует (хотя должна через 3 гудка)
в результате, зависшие линии.