Держи плюс. Наверное это лучшее что тут можно предложить и для автора этого достаточно, но в целом ами у астериска явно оставляет желать лучшего. На первый взгляд кажется что там всё что только может быть но когда пытаешься отследить состояния атс с помощью ами, находишь проблемы, line24 тоже везде пишут что лучше использовать userevent (сорри не удержался что бы не пожаловаться АМИ =) ) P.S. В последних версиях Link заменили на Bridge
kasper (
2011-09-07 11:43:15 +0400
)редактировать
ХЗ с чем вы там столкнулись, но у меня эта задача решена в сотне строк кода на ПХП, работает железно без прослушивания всех эвентов.
switch (
2011-09-07 13:12:19 +0400
)редактировать
В коментарии форматирование отстой, но да ладно. Я написал не о конкретном случае автора а в общем, я считаю что это проблема ами, что события генерятся не где нить в одном месте и за них отвечает 1 человек а в каждом модуле, поэтому разработчики модуля на свой вкус решают что где и как, конечно пытаясь при этом сделать что бы было как то похоже на остальных. Например MusicOnHold вот почему все написали Uniqueid а вот в этом событии UniqueId, это отличный пример моей предидущего утверждения. Из более конкретных проблем ну например в текущем проекте: я немогу привязываться к именам каналов, т.к. эти уникальные магические цифры в имени канала есть ничто иное как адрес структуры в памяти, и ничто не гарантирует что когда канал удалён другой не будет иметь тоже имя. Конечно ами команды работают с именами каналов и тут мы можем надеятся только на то что пока мы не обработали hangup канала такой ситуации не случится, но например в моём случае задержка между клиентом моей программы уже существенна.
kasper (
2011-09-07 15:56:20 +0400
)редактировать
Вроде бы очевидный выход делать привязку по uniqueId, он полностью уникален. Идём этим путём и получаем следующее при трасфере видим masquerade с каналом Transfered/SIP/ХХХ-ХХХХХХХХ, но почему небыло события newchannel для этого канала с uniqueid и почему у события masquerade нет uniqueid каналов? В итоге при такой комбинации теряется uniqueid одного из каналов. Какое облегчение что обе эти проблемы решены в 1.8. К сожелению немогу привести остальных доводов(давно потеряно в памяти, остались только выводы), но тут есть ZZUZ надеюсь он опишет нам точку зрения line24, давно хотел услышать их доводы по этому поводу.
kasper (
2011-09-07 15:56:48 +0400
)редактировать
Опишите по подробнее, насчёт uniqueid исходники не смотрел но всегда думал что он уникален...<br>Добавлено: ast_string_field_build(tmp, uniqueid, "%li.%d", (long) time(NULL), ast_atomic_fetchadd_int(&uniqueint, 1)); Вот код генерации uniqueid т.е. таймер и счётчик, он вроде как ни может быть не уникальным, ну если только не создадутся 0xFFFFFFFF каналов за одну милисекунду =)
kasper (
2011-09-07 21:44:33 +0400
)редактировать
ага. это теория. на практике трансфер по крайней мере в 1.8.х делается дупликацией канала. даже cdr получаются с одинаковым uniqueid. вообще трансфер создает 4 сдр вместо бывшей одной. 1 оригинал, 1 звоните Б, 1 после трансфера и 1 кусок оригинала до трансфера. вот одна из них с тем же uniqueid.
meral (
2011-09-08 06:08:50 +0400
)редактировать
Могу предположить что это тот же самый канал =) Операция masquerade может быть тому причиной, она почти полностью меняет внутренности 2-х каналов, даже имена у них меняет местами, но uniqueid оставляет прежним, таким образом может создастся впечатление что другой канал имеет тот же uniqueid. Это всё предположение, может на недельке найду как нить время исследовать алгоритм трансфера. И кстати должен добавить что как оказалось моё утверждение про именование сип каналов уже давно не актуально, так было в 1.4, начиная с 1.6 в имени сип канала используется не адрес в памяти а счётчик, так что с уникальностью имени канала можно расслабится, алилуя.
kasper (
2011-09-08 10:28:20 +0400
)редактировать
