Страница 2 из 3
Re: Проблема с Call Transfer.
Добавлено: 08 фев 2012, 16:18
ded
attented transfer в Астериске работает хорошо.
Но есть функционал attented transfer средствами телефона, а есть средствами Астериска (feature codes). Ставитm на Hold и потом склеивать - это вообще не attented transfer.
Re: Проблема с Call Transfer.
Добавлено: 12 апр 2012, 11:21
Obi Van
Дабы не плодить тем, спрошу тут. При отладке системы (Asterisk 10.3 на Debian squeeze/testing), а именно функционала перевода вызовов, возникла проблема. Касается она attended transfer. Проблем со слепым переводом не возникает. Схема звонка достаточно типовая: А звонит В, В переводит вызов на С и спрашивает будет ли он общаться с А, далее варианты получаются таковыми:
1) С не отвечает - вызов возвращается назад по таймауту в features.conf к А (тут всё нормально);
2) С жаждет общения - В кладёт трубку и абоненты А и С общаются (тоже всё хорошо);
3) По какой-либо причине А кладёт трубку - абоненты В и С общаются
;
4) С не хочет общаться и кладёт трубку - при этом полностью прибивается вся цепочка. Идёт отбой и у абонента А и у В.
Вот 4-й вариант как раз и похож на бред. Как я понимаю, в логике работы такого перевода не должно быть такого исхода (банальный пример с аналогичного сценария перевода на Samsung OS500). Гугление привело к известным результатам с dtmf, КПВ и отсутствием звука. Ничего такого не наблюдается. Где может быть косяк (наблюдается на 2-х разных системах)? Может кто сталкивался с таким странным поведением?
sip.conf (пример одного пользователя)
Код: Выделить всё
[101]
deny=0.0.0.0/0.0.0.0
permit=192.168.1.0/255.255.255.0
type = friend
qualify = yes
port = 5060
call-limit = 1
defaultuser = 101
secret = pass
canreinvite = no
callerid=Employee 1 <101>
context = clients_default
host = dynamic
progressinband = never
insecure = port,invite
disallow = all
allow=ulaw
allow=alaw
features.conf
Код: Выделить всё
transferdigittimeout => 3
xfersound = beep
xferfailsound = beeperr
pickupexten = *8
pickupsound = beep
pickupfailsound = beeperr
featuredigittimeout = 1000
atxfernoanswertimeout = 15
atxferdropcall = no
atxferloopdelay = 10
atxfercallbackretries = 2
[featuremap]
blindxfer => #1
disconnect => *0
automon => *1
atxfer => *2
parkcall => #8
automixmon => *3
Re: Проблема с Call Transfer.
Добавлено: 12 апр 2012, 11:41
Vlad1983
попробовать в features.conf в [general] закомментить все начинающиемся с "atxf" кроме atxfernoanswertimeout
Re: Проблема с Call Transfer.
Добавлено: 12 апр 2012, 12:39
Obi Van
Vlad1983
Пичаль. Ничего не поменялось. Если тот, на кого переводят кладёт трубку, разваливается весь звонок. В логах от последнего звена прилетает BYE, asterisk любезно говорит 200 ОК и дальше всё уходит в h экстеншен. Вообще сделал как, стал ngrep 'ом между первым абонентом и *, далее между вторым абонентом и *, а общение с третьим я вижу в консоли *. Что происходит. После того как абонент С отвечает, а потом кладёт трубку (т.е не желает общения), астериск всем остальным абонентам рассылает BYE и весь вызов разваливается. Очевидно должно происходить восстановление разговора А с В, но этого почему-то не происходит и последний абонент рушит весь вызов.
Re: Проблема с Call Transfer.
Добавлено: 12 апр 2012, 12:44
Vlad1983
тогда последний шанс atxferdropcall = yes
Re: Проблема с Call Transfer.
Добавлено: 12 апр 2012, 12:54
Obi Van
По барабану.
Попробую заменить свой мудрёный контекст на простенький и там это сделать.
Re: Проблема с Call Transfer.
Добавлено: 12 апр 2012, 13:41
Obi Van
Сделал примитивный рингплан такого вида:
Код: Выделить всё
[clients_default_2]
exten => _1XX,1,NoOp()
exten => _1XX,n,Dial(SIP/${EXTEN},15,Ttm)
exten => _1XX,n,Hangup()
В нём всё работает. Буду смотреть что не так.
Re: Проблема с Call Transfer.
Добавлено: 15 май 2012, 13:58
Obi Van
Нашёл времечко для экпериментов и вот что выяснилось. К моей же печали из-за громоздкого рингплана на это ушло побольше времени чем я рассчитывал. Схема та же: А звонит Б, а Б переводит на В. Если В не желает говорить, то он кладёт трубку. Клиент А - это внешняя по отношению к астериску АТС Samsung OS500, клиент Б - это софтфон Zoiper, а клиент В - это Zyxel P2300RDL EE хардфон DECT. Т.е клиенты разношёрстные.Выяснилось, что если в рингплане переводящего вызов (т.е Б) присутствует екстеншен h, то вызов валится.
Даже написание такой строки как:
ничего не изменило, т.е разваливается вся цепочка. Всё бы ничего, возьми да убери h, да вот не хочется, т.к в нём делается такая обработка:
Код: Выделить всё
exten => h,1,Goto(hangup_log)
[hangup_log]
exten => log,1,JabberSend(asterisk,${JABBER_PEER_ADDR},"Исходящий вызов в ${STRFTIME(,,%Y-%m-%d)}_${STRFTIME(,,%H-%M-%S)} от ${CDR(src)} на номер ${dialed_num} длительностью ${ANSWEREDTIME} сек. был завершён со статусом HANGUPCAUSE = ${HANGUPCAUSE}. Статус вызова ${DIALSTATUS}. Оператор связи был '${CDR(accountcode)}'.")
exten => log,n,Hangup()
Эта строчка даёт возможность человеку понять почему развалился вызов, т.к вываливает код ошибки. Для продвинутых юзверей, кои у нас в офисе имеются это оказалось находкой. Они теперь если и звонят в суппорт, то имеют на руках инфу, почему этот вызов "не пошёл". Т.е плюшка для меня и для других. Как быть? Или это дурацкий баг?
Re: Проблема с Call Transfer.
Добавлено: 15 май 2012, 15:38
Aven
А на 1.8.12.0 тоже самое?
Перевод средствами оборудования пробовали?
Re: Проблема с Call Transfer.
Добавлено: 15 май 2012, 17:57
trscod
На 12 то же самое.
https://issues.asterisk.org/jira/browse/ASTERISK-19633
Вот здесь уже, оказывается, есть решение проблемы.
Сегодня наложил патчик на версию 1.8.12.0
проблема ушла.
Для Asterisk 10 тоже патч имеется.
https://issues.asterisk.org/jira/browse/ASTERISK-19717