Проблема с Call Transfer.

[ded]

attented transfer в Астериске работает хорошо.
Но есть функционал attented transfer средствами телефона, а есть средствами Астериска (feature codes). Ставитm на Hold и потом склеивать - это вообще не attented transfer.

[Obi Van]

Дабы не плодить тем, спрошу тут. При отладке системы (Asterisk 10.3 на Debian squeeze/testing), а именно функционала перевода вызовов, возникла проблема. Касается она attended transfer. Проблем со слепым переводом не возникает. Схема звонка достаточно типовая: А звонит В, В переводит вызов на С и спрашивает будет ли он общаться с А, далее варианты получаются таковыми:
1) С не отвечает - вызов возвращается назад по таймауту в features.conf к А (тут всё нормально);
2) С жаждет общения - В кладёт трубку и абоненты А и С общаются (тоже всё хорошо);
3) По какой-либо причине А кладёт трубку - абоненты В и С общаются ;
4) С не хочет общаться и кладёт трубку - при этом полностью прибивается вся цепочка. Идёт отбой и у абонента А и у В.
Вот 4-й вариант как раз и похож на бред. Как я понимаю, в логике работы такого перевода не должно быть такого исхода (банальный пример с аналогичного сценария перевода на Samsung OS500). Гугление привело к известным результатам с dtmf, КПВ и отсутствием звука. Ничего такого не наблюдается. Где может быть косяк (наблюдается на 2-х разных системах)? Может кто сталкивался с таким странным поведением?
sip.conf (пример одного пользователя)

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

Код: Выделить всё

[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

PRIME_BBCODE_SPOILER_SHOW PRIME_BBCODE_SPOILER:

Код: Выделить всё

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   

[Vlad1983]

попробовать в features.conf в [general] закомментить все начинающиемся с "atxf" кроме atxfernoanswertimeout

[Obi Van]

Vlad1983
Пичаль. Ничего не поменялось. Если тот, на кого переводят кладёт трубку, разваливается весь звонок. В логах от последнего звена прилетает BYE, asterisk любезно говорит 200 ОК и дальше всё уходит в h экстеншен. Вообще сделал как, стал ngrep 'ом между первым абонентом и *, далее между вторым абонентом и *, а общение с третьим я вижу в консоли *. Что происходит. После того как абонент С отвечает, а потом кладёт трубку (т.е не желает общения), астериск всем остальным абонентам рассылает BYE и весь вызов разваливается. Очевидно должно происходить восстановление разговора А с В, но этого почему-то не происходит и последний абонент рушит весь вызов.

[Vlad1983]

тогда последний шанс atxferdropcall = yes

[Obi Van]

По барабану.
Попробую заменить свой мудрёный контекст на простенький и там это сделать.

[Obi Van]

Сделал примитивный рингплан такого вида:

Код: Выделить всё

[clients_default_2]
exten => _1XX,1,NoOp()
exten => _1XX,n,Dial(SIP/${EXTEN},15,Ttm)
exten => _1XX,n,Hangup()

В нём всё работает. Буду смотреть что не так.

[Obi Van]

Нашёл времечко для экпериментов и вот что выяснилось. К моей же печали из-за громоздкого рингплана на это ушло побольше времени чем я рассчитывал. Схема та же: А звонит Б, а Б переводит на В. Если В не желает говорить, то он кладёт трубку. Клиент А - это внешняя по отношению к астериску АТС Samsung OS500, клиент Б - это софтфон Zoiper, а клиент В - это Zyxel P2300RDL EE хардфон DECT. Т.е клиенты разношёрстные.Выяснилось, что если в рингплане переводящего вызов (т.е Б) присутствует екстеншен h, то вызов валится. Даже написание такой строки как:

Код: Выделить всё

exten => h,1,NoOp()

ничего не изменило, т.е разваливается вся цепочка. Всё бы ничего, возьми да убери 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()

Эта строчка даёт возможность человеку понять почему развалился вызов, т.к вываливает код ошибки. Для продвинутых юзверей, кои у нас в офисе имеются это оказалось находкой. Они теперь если и звонят в суппорт, то имеют на руках инфу, почему этот вызов "не пошёл". Т.е плюшка для меня и для других. Как быть? Или это дурацкий баг?

[Aven]

А на 1.8.12.0 тоже самое?
Перевод средствами оборудования пробовали?

[trscod]

На 12 то же самое.
https://issues.asterisk.org/jira/browse/ASTERISK-19633
Вот здесь уже, оказывается, есть решение проблемы.
Сегодня наложил патчик на версию 1.8.12.0
проблема ушла.
Для Asterisk 10 тоже патч имеется.
https://issues.asterisk.org/jira/browse/ASTERISK-19717