и типа не делайте нам голову, мы предупреждали

всё через... либу

эрланг вроде норм

казу же пилит

насчет эрланга хз, вообще в глаза его не видел ни разу

а-ля питон

никто не мешает поднять event_socket-server на любом удобном ЯП и не дергать скрипты напрямую

именно

никто не мешает поднять event_socket-server на любом удобном ЯП и не дергать скрипты напрямую

опыта нет. Хотя что-то такое нужно, да

а-ля питон

это про erlang? змеюка рядом не стояла

впрочем, сейчас через xml_curl и сделано

xml_curl и event_socket не совсем сопоставимы по возможностям

курл это отдача конфы

по сути

вопрос в том, как передать тогда весь канальный массив в обработку, а ответ скрипта в диалплане дальше обрабатывать

дык там можно сделать всё что хочешь, и uuid_dump в том числе

можешь из ивентов надергать

....или идти ниже и в dialplan-генераторе вкорячить обработчик

дык задача то какая?

изначально стоит

да есть *96 - вход в очередь, оно говорит "вы вошли" и кидает кастом ивент для реал входа. А надо теперь получить, реально ли вошли, или вообще нет очередей, и дать ошибку

вход агента в СС?

да, с клавы

можно переделать вообще на стадии генерации диалплана, там будут данные как раз через курл

но не хотел втягивать эту обработку в код

погоди, тебе по сути зная agent-name проверить его существование впринципе и наличие его в каких либо очередях, я правильно понимаю?

типа

вся эта логика уже есть

в обработчике кастом ивента

но она пост-фактум

и там довольно много логики...

т.е. логика вся уже построена и результат у тебя по сути уже есть, но ты его поздно получаешь?

ивент не имеет возврата )

оно асинхронно

эт понятно

а еще это другой модуль.. отдельно - конфигурации, отдельно - все эти хуки..

сходу чот даже в голову не приходит ничего

по сути происходит callcenter_config agent set status 'Available' после этого отлавливаются callcenter::info и в них отлавливаются изменения статуса, стейта тиера и тп? я правильно всё понял?

сорян, надо валить

та же хрень

9 вечера

я с 10 утра )

аналогично

по сути происходит callcenter_config agent set status 'Available' после этого отлавливаются callcenter::info и в них отлавливаются изменения статуса, стейта тиера и тп? я правильно всё понял?

не.

ивент и есть причина для available

лучше перенесем на завтра)

думать можно и в дороге )

думать можно и в дороге )

ды чот уже тяжко соображается)

о народ попёр)

На хабре статью со списком интересных каналов в телеграмме опубликовали. https://m.geektimes.ru/post/285704/

На всех каналах теперь это и обсуждают)))

а в ru_kamailio как было 20 человек так и осталось :D

И везде ругают)

а в ru_kamailio как было 20 человек так и осталось :D

нет в списке

И везде ругают)

каналы ругают? )

хабр ругают)

ну по мне норм

По мне тоже норм)

неадекватов выпнем, норм останутся..

Но куда я вступал везде вышел)

Во мноих местах просто бред несут)

мы не такие) мы несем бред только по делу)

а я во многие чатики зашел

социализация!

реально эта группа хоть мола но свою роль выполняет и все цивилизовано)

я вот хочу для сравнения на канал астера зайтить

там вроде норм)

ребят, подскажите такую вещь есть у меня кама, все с ней хорошо, роутит все на свичи и обратно, соотвественно свич подставляет свой айпишник в контакт хедер но вот есть кастомер, который игнорирует Contact header и в URI для ACK подставляет айпишник самой камы, из-за чего ACK-и не доходят до свичей

я помню что как-то лечил это, но вот как - забыл начисто

может кто подсказать что делать и как с этим жить?

ребят, подскажите такую вещь есть у меня кама, все с ней хорошо, роутит все на свичи и обратно, соотвественно свич подставляет свой айпишник в контакт хедер но вот есть кастомер, который игнорирует Contact header и в URI для ACK подставляет айпишник самой камы, из-за чего ACK-и не доходят до свичей

кама и фс на одном ip или разных?

кама и фс на одном ip или разных?

на разных

на разных

тогда вся ситуация какая-то странная, не подскажу, наверное

ребят, подскажите такую вещь есть у меня кама, все с ней хорошо, роутит все на свичи и обратно, соотвественно свич подставляет свой айпишник в контакт хедер но вот есть кастомер, который игнорирует Contact header и в URI для ACK подставляет айпишник самой камы, из-за чего ACK-и не доходят до свичей

ткнуть кастомера в RFC?

ткнуть кастомера в RFC?

да я что-т не могу найти пункт где написано про то, что нужно в ack подставлять uri из contact хедера

может кто помнит где оно?

мне кажется не ACK надо искать, а в описание взаимодействия и обработки 3ХХ кодов

сейчас не смогу посмотреть точно

2хх коды же...

кама редиректит?

да

ну знач там есть или 301 или 302 изначально

а

тьфу, нет

не редиректит

просто прокся

https://i.imgur.com/twkkJ9t.png

во, ток хотел попросить

вот так выглядит проблемная часть