B2B_ENTITIES
Реализация модели B2B разделена на два уровня:
- нижний, который реализует этот модуль, для базовых функций UAS и UAC;
- верхний, который реализует модуль b2b_logic (см. ниже), для всей логики B2BUA.
Этот модуль хранит записи соответствующих диалогов, в которых используется модель B2BUA. Он представляет API для других модулей, которые используют свои функции для создания нового диалога, для отправки сообщений этого диалога и заодно оповещает модуль верхнего уровня о поступлении сообщения внутри диалога. Записи разделяются на два типа: b2b записи сервера и b2b записи клиента, в зависимости от того, в каком режиме они созданы. Записи созданные для полученного начального запроса будут серверными, в то время как записи, для которых будут оправлены начальные запросы (т.е. создан новый диалог), станут записями b2b клиента. Этот модуль не реализует модель B2BUA самостоятельно, к нему ещё нужен модуль B2B логики.
Модуль b2b_entities может отвечать на запросы аутентификации, если загружен модуль uac_auth. Список реквизитов для аутентификации так же предоставляется модулем uac_auth.
Зависимости: b2b_logic, tm, db, uac_auth (если нужна аутентификация)
B2B_LOGIC
Это модуль верхнего уровня B2BUA, вместе с b2b_entities они используются для предоставления различных сервисов B2BUA.
B2B сессия может быть вызвана двумя путями:
- из скрипта, после получения начального INVITE;
- внешней командой из cli, в этом случае два абонента будут соединены сессией (Third Party Call Control).
После инициализации B2B сессии, плечи вызова будут управляться модулем b2b_logic, и первым шагом будет соединение абонентов. Запросы и ответы, принадлежащие этим диалогам, не будут обрабатываться в стандартных маршрутах скрипта, вместо это они попадут в выделенные маршруты b2b_logic, заданные параметрами модуля script_req_route и script_reply_route или параметрами функции b2b_init_request(). Дальнейшие шаги сценария могут быть заданы в этих маршрутах, путем вызова функций b2b_logic. Обычные "прокси" функции OpenSIPS не будут запущены в маршрутах b2b_logic.
Некоторые сообщения будут обработаны модулем автоматически, и не вообще попадут в маршруты b2b_logic (например, запросы BYE, полученные во время соединения абонентов, ответы ACK/BYE для рассоединенных абонентов). Также, если не заданы маршруты b2b_logic для ответов, то ответы будут обработаны модулем самостоятельно, с тем же эффектом, как если бы была вызвана функция b2b_handle_reply().
Зависимости: b2b_entities, db
CALL-CENTER
Этот модуль реализует модель распределения потока входящих вызовов для колл-центра, т.е. фактически очереди звонков.
Очереди вызовов, распределение по агентам, управление агентами, свои CDR, статистика вызовов и активности агентов - весь основной функционал за исключением проигрывания медиа.
Это также контакт-центр с возможность одновременной обработки RTP и MSRP (т.е. текстовых сообщений, чатов).
Модуль обладает внутренней логиков для распределения вызовов и чатов по агентам, но может использовать и внешнюю логику для диспетчеризации (см. MI команду cc_dispatch_call_to_agent).
Основными объектами модуля являются потоки (очереди) и агенты. Каждый объект имеет соответствующую таблицу в БД (cc_flows и cc_agents). Данные загружаются в память при запуске, обновление возможно командой MI cc_reload.
Дополнительно есть таблица cc_cdrs для записи CDR, перекрывающих все возможные варианты окончания вызова. Записей CDR может быть несколько для одного вызова.
Таблица cc_calls хранит информацию об обслуживаемых вызовах с указанием их статуса: в очереди, разговор, завершен и т.п. Она заполняется в реальном времени, и не должна правиться вручную.
Очереди поддерживают механизм навыков (skill) и приоритетов. Соответственно, агенты тоже поддерживают скилы, а также возможность залогиниваться в определенную очередь. Каждый агент единовременно может вести один разговор и несколько чатов.
Зависимости: b2b_logic, db
DIALOG
Модуль диалога обеспечивает, вот неожиданность-то, поддержку диалогов. Его задача отслеживать текущие диалоги, предоставлять информацию о них (например, количество активных диалогов). Помимо отслеживания, модуль предлагает дополнительный функционал в виде флагов и атрибутов диалога (т.е. постоянных данных для всего диалога), профилирование диалогов и их завершение (по таймауту или внешней команде).
С помощью внутреннего API возможно решение более комплексных диалоговых задач через другие модули OpenSIPS.
Для создания диалога, ассоциированного с начальным запросом, нужно использовать функцию create_dialog(), с параметрами или без. Диалог автоматически завершается с получением запроса BYE. Если такой запрос не получен, то завершение происходит по таймаутам.
После завершения, диалог может быть сразу удален из памяти или оставлен на время (см. опцию delete_delay) в режиме только чтения. Такая задержка позволяет осуществлять маршрутизацию опоздавших диалоговых запросов (таких, как повторная передача BYE, опоздавшие ACK на REINVITE и т.п.).
Зависимости: tm, rr
NAT TRAVERSAL
Модуль для обеспечения прохождения NAT сообщениями SIP на удаленной стороне. Включает в себя функционал для детектирования клиентов за NAT, модифицирования SIP заголовков и посылки keep-alive сообщений. Модуль позволяет работать с клиентами как за каскадом устройств NAT, так и за одиночными шлюзами.
Модуль спроектирован для работы в комплексном окружении, где несколько SIP прокси могут быть вовлечены в обработку регистраций и роутинга, и где входящие и исходящие маршруты могут различаться, в том числе между последовательными диалогами.
Зависимости: sl, tm, dialog
NATHELPER
Тоже модуль для преодоления NAT. В частности, он помогает симметричным UAS, которые не афишируют свою симметричность и не могу определить свой внешний IP.
Доступны stateful SIP пинги, которые позволяют убрать контакт из таблицы usrloc, если клиент не отвечает.
Зависимости: usrloc
OPTIONS
Этот модуль предоставляет возможность ответа на запросы OPTIONS, адресованные самому серверу OpenSIPS. Т.е. те запросу, которые содержат адрес сервера в RURI, но не содержат username. Модуль отправит ответ 200.
Зависимости: sl, signaling
REGISTRAR
Модуль содержит логику обработки запросов REGISTER. Поддерживает механизмы PATH, GRUU и оповещений PUSH.
Зависимости: usrloc, signaling, event_routing (для PUSH)
SIGNALING
Модуль signaling является "обёрткой" для модулей tm и sl, предоставляет одну функцию, которая может быть вызвана модулями, которые хотят отправить ответ.
Логика следующая: сначала определить, создана ли транзакция, и если создана, то отправить stateful ответ используя модуль tm. А если транзакции нет, то ответ отправить модулем sl в состоянии stateless. Таким образом, автор скрипта по-прежнему имеет возможность решить, как должна обрабатываться транзакция — с сохранением состояния или без сохранения, и ответ отправляется в соответствии с его выбором.
Т.е. мы имеем возможность одним и тем же модулем отправлять и stateful, и stateless ответы, просто контролируя это созданием транзакции. А если нам в скрипте нужны ответы только в одном состоянии, то и подгружать можно только один из модулей sl или tm.
Зависимости: sl, tm (можно один из них)
UAC REGISTRANT
Этот модуль позволяет OpenSIPS регистрировать самого себя на удаленном сервере регистрации.
Зависимости: uac_auth
TM
Модуль TM добавляет stateful обработку транзакций SIP. Stateful логика, потребляющая ресурсы памяти и ЦПУ, требуется сервисам, которые по своей сути имеют состояние. Например, аккаунтинг на основе транзакций (модуль acc) должен обрабатывать состояние транзакции, а не отдельные сообщения, и любые виды разветвления должны быть реализованы с учетом состояния.
Ну а с нашей пользовательской точки зрения наиболее важна функция t_relay(). Она устанавливает состояние транзакции, поглощает повторные передачи аплинку, генерирует повторные передачи даунлинку и сопоставляет ответы с запросами.
Важно знать, что модуль TM клонирует полученные сообщения SIP в разделяемую (shared) память. Это тратит время ЦПУ и саму память. Отметим, что функции, не относящиеся к модулю TM, работают с полученным сообщением в частной (private) памяти (т.е. в памяти конкретного процесса, недоступной другим процессам), а это значит, что никакие операции ядра не повлияют на stateful сообщения после создания транзакции. Например, вызов функции record_route после t_relay бесполезен, т.к. Record-Route добавляется к сообщению в приватной памяти, в то время как TM отправит исходный клон этого сообщения.
Зависимости: нет
SL
Модуль SL позволяет OpenSIPS работать как stateless прокси и генерировать ответы на SIP запросы без фиксации состояния. Это удобно во многих сценариях, в которых вы хотите не тратить попусту память.
Этот модуль должен фильтровать запросы ACK, посланные после того, как был сгенерирован stateless ответ на INVITE. Для распознавания таких ACK, OpenSIPS добавляет специальную "сигнатуру" к to-tag. Эта сигнатура проверяется во входящих ACK, и если она добавлена, то ACK поглощается.
Для ускорения фильтрации используется механизм тайм-аутов. Когда ответ отправлен, включается таймер. Пока тайм-аут не наступил, входящие запросы ACK будут проверяться с использованием значения to-tag. После истечения таймера все ACK пропускаются — прошло слишком много времени после отправки ответа, поэтому не ожидаются никакие ACK, которые нужно будет заблокировать.
Зависимости: нет
MEDIA EXCHANGE
Модуль предоставляет средства для обмена данными SDP между разными проксируемыми вызовами, а также вызовами, запущенными или полученными с медиа-сервера. Модуль сам по себе не имеет каких-либо медиа возможностей, он просто предоставляет примитивы для обмена SDP между двумя или более различными вызовами.
Модуль может инициировать вызовы, передавать существующие SDP медиа серверу, проигрывать или записывать существующие RTP, а также считывать SDP из нового или вставлять SDP в существующий проксируемый вызов. Для манипулирования новыми вызовами, неважно инициируемыми или терминируемыми, модуль действует как B2BUA.
back-to-back user agent with the aim of the OpenSIPS B2B entities module.
В терминах обмена данными SDP модуль имеет два режима:
1) двустороннее медиа - в этом режиме медиа нового вызова будет направлено в одно из плечей существующего вызова. Это приведет к тому, что сторона вызова будет общаться с медиа сервером. По-умолчанию, другой участник вызова будет поставлен на удержание, но это поведение можно настроить при инициации нового плеча.
2) ветвление медиа - в этом режиме новый B2B вызов, как инициируемый, так и терминируемый, будет просто иметь копию RTP, разветвленную механизмом медиа прокси. При этом, проксированный вызов должен был иметь путь к RTP обработчику до того, как начнется ветвление. Ветвить можно как одно медиа плечо вызова, так и оба. ВАЖНО: RTPProxy в настоящий момент не поддерживает остановку медиа потока, поэтому если вызов завершается, то RTPProxy продолжит передачу потока, даже если его никто не слушает на другом конце.
Этот модуль предоставляет набор инструментов, которые могут быть использованы в различных ситуациях, таких как:
- запись вызова - подобно модулю SIPREC, Media Exchange может быть использован для ветвления RTP потока новому SIP получателю, но без дополнительной нагрузки SIPREC;
- прослушивание вызова - можно подключиться к OpenSIPS и прослушать существующий вызов;
- оповещения - проиграть абоненту оповещение с медиа сервера.
Зависимости: tm, dialog, rtp relay, b2b_entities
CALLING OPERATIONS
Этот модуль предоставляет набор функций, которые позволяют контролировать текущие вызовы. Его можно использовать для инициирования перевода вызова (как слепого, так и сопровождаемого) или перевода вызова на удержание со стороны прокси-сервера, а не со стороны конечного устройства. Этот модуль монтируется поверх модуля dialog для получения информации о текущих вызовах, так же как для хранения информации о новых вызовах, которые будут инициированы.
Ещё модуль инициирует набор оповещений через интерфейс оповещений (Event Interface), предоставляя внешним приложениям информацию о переведенных вызовах и о связях между ними.
Одной из самых больших проблем при выполнении сценариев перевода вызовов является привязка новых вызовов к старым, которые, собственно, переводятся, особенно в сценариях слепого перевода. Чтобы решить эту проблему, модуль можно настроить для отсылки к старым плечам вызова в двух разных режимах:
- автоматически (режим по-умолчанию), путем добавления специального параметра к URI получателя, которое передается в сообщение REFER. Когда новый вызов возвращается, параметр будет представлен в его RURI. Модуль обнаружит его, свяжет новый вызов со старым и удалит параметр из URI;
- вручную, используя внешнюю логику (например, БД) для нахождения старого вызова. В этом режиме пользователь должен явно вызвать функцию call_blind_replace() для связи двух вызовов.
Модуль так же можно использовать для перехвата событий перевода Notify и ответа на них с уровня OpenSIPS. Обратите внимание, что в автоматическом режиме даже если NOTIFY обрабатывается при сопоставлении диалога, запрос все равно продолжит выполнение скрипта, в отличие от ручного режима, когда используется функция call_transfer_notify(). Тут чтобы не слать NOTIFY, придется удалить его вручную.
Зависимости: tm, dialog
B2B SDP DE-MULTIPLEXER
Этот модуль содержит логику конвертации вызова с мультипотоковым SDP в несколько вызовов, содержащих подмножество потоков исходного вызова. Модуль работает только с сигнальной частью вызова, без взаимодействия с медиа, которое будет проходить из конца в конец. Единственная манипуляция, которую делает модуль, это отключение на уровне SDP медиа потоков, которые не используются получателем.
Указанная логика реализована поверх модуля B2B, она демультиплексирует сервер B2B (первоначальный вызов с несколькими потоками) на несколько клиентов B2B (с их собственным подмножеством потоков). Внутридиалоговые запросы, которые приходят от инициатора вызова, будут разделены между каждым получателем, а их ответы агрегированы обратно инициатору. Внутридиалоговые запросы от получателей передаются отправителю так, как будто изменился только их поток.
Распространенный сценарий, в котором этот модуль может быть полезен, — настройка OpenSIPS в качестве прокси-сервера SIPREC SRS. Используя этот модуль, вы можете получать с одной стороны SIPREC INVITE, которые обычно имеют два или более потоков SDP (по одному для каждого участника вызова/конференции), и разделять/демультиплексировать каждый поток в новом вызове даунлинку, обычно в направлении медиа сервера, который может выполнять запись вызовов. Таким образом, медиа сервер должен будет обрабатывать вызовы, содержащие один медиапоток.
Другой вариант использования — балансировка нескольких потоков на разные медиа серверы. Например, если вы предлагаете как аудио-, так и видеоуслуги, вы можете разделить двухпотоковый вызов (с аудио- и видеопотоком) на два разных вызова и отправить их на обработку на разные серверы. Таким образом, вы можете разделить медиа серверы, выделенные для обработки аудио, а также один, выделенный для обработки видео. Конечно, этого можно достичь, если вы можете обрабатывать потоки отдельно, например, для записи.
Зависимости: b2b_entities
MSRP UA
Этот модуль реализует функционал MSRP UA (RFC 4976) для обмена сообщениями.
Сугубо специфическая штука.
Зависимости: proto_msrp, b2b_entities
Комментариев нет:
Отправить комментарий