Можно. «клиент должен где то логиниться?» это в телефонии называется регистрация, делается это для того чтоб сервер знал какой юзер за какими апйи: портом и т.д. для входящих звонков к этому юзеру. Вы же собираетесь делать клик ту колл, там просто нужно достаточно посылать инвайт. У Voximplant вроде как что то есть, zingaya… погуглите в эту сторону, уже не помню.
Есть еще очень моцная. но платная тулза www.voipmonitor.org, очень полезно когда у клиента 100-200 звонков в минуту, а тебе звонят и говорят: «у нас поза вчера звонок оборался, что то там загудело, я его слышал а он меня нет, а это был начальник, и теперь он очень злой». И вот если был запущен войпмонитор, то можно отыскать и посмотреть что там было и даже послушать, графики посмотреть… только жрет проц овер 9000.
Coroutine — сопрограмма, а если следовать логике вашего перевода, то Coroutine — копрограмма, что уже совсем другая история :) Я не спорю, мне просто интересно.
Если хотите более умные бэкбон модели то предлагаю вам посмотреть на ampersand-model. У них есть и другие компоненты, но мы используем именно модели в ангуляр проекте.
Много разных моделей проверял смотрел, для мeня лучше всех кажеться ampersand-model. Это как бэкбоун на стероидах. Завернули у себя в ангуляровский сервис и все очень хорошо. Мне не совсем понятно как у вас реализованы derived fields, кэшируемые и нет. Есть ли у вас понятие проксированя модели в REST API? Если да, то как определаються поля которые нужно передать на сервер а какие нет? Проверка типов и валидация? Значения по умолчанию?
Если человеку достаточно дыр в самом Астериске, то дополнительные дыры FreePBX, ему не особо нужны. Лично для меня FreePBX абсолютно не юзабелен. Большая часть модулей, которые там есть, не достаточно гибкие, что б ими пользоваться. Это мое личное мнение.
Опция: «M(callanswered)», запускает макро отдельно, так сказать в отдельном треде. и не влияет например на продолжение исполнения «дайлплана» в контексте from-inside, но в нем буду доступны «inherited variables», с канала который это тригернул.
Здеся, когда кого-то набираем, указиваем опцию: «M(callanswered)», это макро которое тригернеться српазу перед тем когда делаеться бридж:
[from-inside]
exten => _X.,1,Noop(DIALING OUT)
same => n,Set(__CALLEE=${MACRO_EXTEN})
same => n,Dial(SIP/${MACRO_EXTEN}@TrunkOut,50,M(callanswered))
Здесь, мы делаем ориджинейт, одна нога пойдет в bargein, который врежеться в звонок, вторая нога, проиграет файл:
[macro-callanswered]
exten => s,1,Noop(${CALLEE} answered the call)
same => n,Originate(Local/${CALLEE}@bargein,app,Playback,/var/lib/asterisk/sounds/AllCallsRec)
Здесь просто врезаемся в звонок:
[bargein]
exten => _X.,1,Noop(PLAY MUSIC THROUGH CHANSPY)
same => n,Answer()
same => n,ChanSpy(SIP/${EXTEN},BEq)
same => n,Hangup()
Таким образом сразу после соединения, оба услышат одно и тоже сообщение. Это на половину псевдокод, так что нуждаеться в правках для вашей ситуации.
Против того, что, если я правильно понял берем текущую дату и получаем N сообщений, берем дату самого старого и получаем ещё N и так далее. Все одним и тем же запросом.
Это почти то, что мы сделаем на сервере, но вернём номера страниц и ссылки на них. ХМРР не сможет сделать то, что вы говорите из коробки. А Пейджинг мне кажется более удобным, так ка при поиске по тексту сообщений, можно просто вернуть номера страниц, в которых этот текст встречался.
При первом взаимодействии с контактом (вы открыли чата с ним, или он написал вам сообщение), посылаем запрос на получение N последних сообщений, теперь у нас есть коллекция, в которой есть N или N+1 сообщений или пустой ответ, в этом случае ничего не надо делать. Теперь, как только это произошло, и ответ не был пустым — посылаем запрос на пейджинейдет историю, и как параметр запроса указываем дату самого первого(earliest) сообщения, что у нас уже есть. Ответ кешируем. Теперь можно пользоваться пейджингом без проблем и не будет никаких дубликатов. Конечно, если у вас нет машины времени. То есть в моем варианте — мы берем точку отсчета: Самое раннее сообщение, которое есть на клиенте, и продолжаем с шагом назад. В случае реализации ХМРР, нам нужно указать дату в прошлом и от нее с шагом вперед. Пейджинг, он и тут есть из коробки, только не в ту сторону: Result Set Management (XEP-0059).
https://issues.asterisk.org/jira/browse/ASTERISK-24146 Эту лично я чинил, тестируйте, должно ломаться на 11.13, почти все на это уже продакшине натыкаються.
https://issues.asterisk.org/jira/browse/ASTERISK-25265 Это входящие в фоксе лечит.
Но это кончно проблемы в chan_sip, а на pjsip а в 11 только chan_sip.
Здеся, когда кого-то набираем, указиваем опцию: «M(callanswered)», это макро которое тригернеться српазу перед тем когда делаеться бридж:
Здесь, мы делаем ориджинейт, одна нога пойдет в bargein, который врежеться в звонок, вторая нога, проиграет файл:
Здесь просто врезаемся в звонок:
Таким образом сразу после соединения, оба услышат одно и тоже сообщение. Это на половину псевдокод, так что нуждаеться в правках для вашей ситуации.