Если не изменяет память , то это поведение не app_dial.c , а непосредственно в channel.c
zzuz ( 2014-10-17 23:12:08 +0400 )редактироватьМне надо понять кто кому звонил. К примеру 106 звонит 107 или наоборот. Как это точно определить? Как тут понять кто где? Запускаю CoreShowChannels из AMI и получаю вот это:
Action: CoreShowChannels
Response: Success
EventList: start
Message: Channels will follow
Event: CoreShowChannel
Channel: SIP/106-00000011
UniqueID: 1413439783.19
Context: from-internal
Extension:
Priority: 1
ChannelState: 6
ChannelStateDesc: Up
Application: AppDial
ApplicationData: (Outgoing Line)
CallerIDnum: 106
CallerIDname: 106
ConnectedLineNum: 107
ConnectedLineName: 107
Duration: 00:37:43
AccountCode:
BridgedChannel: SIP/107-00000010
BridgedUniqueID: 1413439783.18
Event: CoreShowChannel
Channel: SIP/107-00000010
UniqueID: 1413439783.18
Context: macro-dial-one
Extension: s
Priority: 43
ChannelState: 6
ChannelStateDesc: Up
Application: Dial
ApplicationData: SIP/106,,TtrI
CallerIDnum: 107
CallerIDname: 107
ConnectedLineNum: 106
ConnectedLineName: 106(Away)
Duration: 00:37:43
AccountCode:
BridgedChannel: SIP/106-00000011
BridgedUniqueID: 1413439783.19
в вашем понятии всегда при звонке через Dial
вообще это так выставляется командой Dial. можете ее перписать для ясности. исходники то есть
Если не изменяет память , то это поведение не app_dial.c , а непосредственно в channel.c
zzuz ( 2014-10-17 23:12:08 +0400 )редактироватьСамый простой способ определить какой канал Caller, а какой Called:
Для этого можно проанализировать UniqueID, а он генерируется инкрементированно. По сути основа UID это время создания канала.
Когда во множестве каналов у одного канала UniqueID равен BridgedUniqueID друого канала, то можно рассматривать эти два канала как пару каналов Caller, Called.
Следовательно если в паре каналов где у оного из каналов в паре значение UniqueID меньше чем у другого, то этот канал инициатор - Caller, если меньше, то Called.
Ещё можно анализировать контекст и т.п., но на практике это оказалось избыточным ибо простой метод оказался исчерпывающим ))
анализировать инкрементное значение после точки - это конечно Вы молодцы. Я тоже люблю ботинком в ухе ковыряться. Да уж . channel.c - это код , где описываются канал "родитель" и "наследуемый" канал. Почувствуйте разницу прежде , чем советы выдавать о сравнении каналов.
zzuz ( 2014-10-21 13:49:17 +0400 )редактироватьо. зашибись. супер експерты подошли. ненадо так делать. uniqueid НЕ ВСЕГДА генерируется так. в частности после трансфера или bridge может быть как угодно.
meral ( 2014-10-21 19:52:37 +0400 )редактироватьТем более при перезагрузки некоторых модулей инкремент в uniqueid может сбросится.
zzuz ( 2014-10-21 20:53:18 +0400 )редактироватьmeral и после трансфера генерируется всё как я сказал. проверь у себя и убедись. Мой способ работает для обычных звонков, с bridging понять кто кому звонит данной коммандой не предстваляется возможным(даже обсурдно), а с конференциями надо юзать специальные комманды конференций для meetme свои, а для confbridge свои - тут CoreShowChannels не панацея.
CallCenterCoder ( 2014-10-22 10:19:08 +0400 )редактироватьzzuz назови хоть один модуль после перезагрузки которого uniqueid сбросится при сохранении активных звонков? такого быть не может. Если такое было бы возможно, тогда бы возникали каналы с одинаковым Uniqueid, что не может быть.
CallCenterCoder ( 2014-10-22 10:38:05 +0400 )редактироватьПервая часть до точки генерируется случайно , вторая инкремент . При перезапуске app_queue.so на некоторых версиях инкремент сбрасывается.
zzuz ( 2014-10-22 10:50:58 +0400 )редактироватьНо ваш удаленный комментарий про "производную от времени в формате linux" порадовал . Уровень!))
zzuz ( 2014-10-22 10:53:49 +0400 )редактироватьzzuz ты перед тем как троллить для начала почитай исходный код как генерируется uniqueid.
А теперь загадка. Когда был сгенерён канал с UniqueID: 1413969778.36 ?
Подсказка: echo '1413969778' | gawk '{ print strftime("%c", $0); }'
CallCenterCoder ( 2014-10-22 13:29:15 +0400 )редактироватьподсказка неверная. посмотрите код masquarade/transfer. вариантов трансфера воз и малая тележка. не во всехвариантах совпадает первая часть uniqueid.
meral ( 2014-10-22 20:32:05 +0400 )редактироватьВ вашем примере звонок с 107 на 106.
Потому как событие канала SIP/106-00000011
вызвало приложение AppDial и канал связан с SIP/107-00000010
, что указано в BridgedChannel.
Канал SIP/107-00000010
вызвал команду Dial
с параметрами SIP/106,,TtrI
.
Задан: 2014-10-17 10:12:01 +0400
Просмотрен: 1,384 раз
Обновлен: Oct 21 '14
Проект компании "АТС Дизайн"
Asterisk® и Digium® являются зарегистрированными торговыми марками компании
Digium, Inc., США.
IP АТС Asterisk распространяется под лицензией
GNU GPL.
meral поясните пожалуйста свой ответ "в вашем понятии всегда при звонке через Dial". Всегда при звонке через Dial что именно я должен понять? Как мне определить какой анал - телефон инициировал звонок, а по какому приняли звонок? Или это сделать в принципе нельзя с помощью это комманды Asterisk?
TheBestAsterisk ( 2014-10-20 15:56:33 +0400 )редактироватьна вашем уровне понимания астериска это неважно. вы не поймете в чем разница и не поймете в каких условиях не будет этой надписи.
meral ( 2014-10-20 23:42:49 +0400 )редактироватьмне не нужно никакой надписи. мне нужно из CoreShowChannels понять кто кому звонит, разве для этой задачи нужны супер экспертные навыки? Так всё сложно что нельзя это нормально описать?
TheBestAsterisk ( 2014-10-21 09:12:56 +0400 )редактироватьChannel и BridgedChannel связать никак не получается?
zzuz ( 2014-10-21 13:37:51 +0400 )редактироватьцель то какая всего этого сексуального действа? что конкретно Вы хотите сделать?
Zavr2008 ( 2014-10-21 17:30:44 +0400 )редактироватьв простейшем случае смотрите просто application и bridged channel. в более сложных это не всегда работает(трансферы, pickup, parking, meetme, chanbridge, chanspy может давать другую картину в зависимости от версии)
meral ( 2014-10-21 19:56:10 +0400 )редактироватьзачем морочиться с UNIQUEID? есть вариант выставлять в диалплане имя исходящего пира в канальную переменную - например __ORIGINATINGPEERNAME (с бесконечным наследованием). соотвественно проверять эту переменную для опрашиваемых пиров. если переменная есть, то сравнивать. если нет или не совпадает - вызов для этого пира входящий.
octopas ( 2014-11-06 08:15:20 +0400 )редактировать