Прямая маршрутизация — протоколы мультимедиа

В этой статье описывается, как прямая маршрутизация поддерживает обход мультимедиа с пограничным контроллером сеансов (SBC), включенным для ICE Lite, как описано в RFC 5245. Эта статья предназначена для администраторов голосовой связи, которые отвечают за настройку подключения между локальным SBC и службой прокси-сервера SIP.

В этой статье приводятся общие сведения о сценариях ICE Lite и требованиях к взаимодействию. В этой статье описываются форматы сообщений и необходимые переходы конечных машин для обеспечения надежного потока вызовов и мультимедиа.

Терминология

• First Hello — первые слова, произнесенные вызывающим и вызывающим. Важно, чтобы были предприняты все усилия для обеспечения надежной доставки первых пакетов из конечных точек в большинстве вариантов использования.

• Вилка. Предложение от вызывающего объекта может быть доставлено в несколько конечных точек вызываемого абонента, если вызываемый доступен на нескольких устройствах (например, пользователь Teams может войти в Teams для Windows и Teams для Android или iPhone).

• Временный ответ (183) — конечные точки вызываемого объекта для более быстрой настройки вызова отправляют ответ с кандидатами и ключами, необходимыми для создания потока мультимедиа. Этот ответ выполняется в ожидании того, что пользователь может ответить на вызов (200OK) от конкретного вызываемого экземпляра. При наличии вилки вызывающий должен быть готов к получению нескольких предварительных ответов.

• Re-Invite — предложение с окончательными кандидатами, выбранными конечной точкой управления ICE. Это предложение имеет атрибут a=remote-candidate для разрешения любых условий гонки при обработке нескольких вилок.

• Конечная точка Teams — эта конечная точка может быть сервером (обработчик мультимедиа, транспортный ретранслятор) или клиентом Teams.

Формат сообщения

Инфраструктура Teams соответствует СТАНДАРТУ RFC 5245 для ICE-Lite. Все сообщения STUN соответствуют стандарту RFC 5389.

SBC, как того требует RFC 5389, должны игнорировать все атрибуты STUN, которые они не распознают, и продолжать обрабатывать сообщения с известными атрибутами.

Если получены какие-либо неправильно сформированные пакеты, пакеты должны быть отменены, не влияя на создание сеанса мультимедиа.

Требования ICE Lite

В этом разделе кратко описаны требования для ICE Lite.

Сбор кандидатов

SBC должен предложить только одного кандидата. В настоящее время поддерживаются только кандидаты IPV4.

Проверки подключения

Реализация ICE Lite должна реагировать на все полученные проверки подключения. Конечная точка ICE Lite не должна отправлять запросы на подключение проверка. (Если проверки подключения отправляются с нарушением, ответит полная реализация, что может привести к обнаружению непредвиденных кандидатов, производных от одноранговых узлов, и, возможно, к сбоям вызовов.)

Номинациях

Конечная точка полной реализации ICE — это управляющая конечная точка, которая следует за номинациями "Обычные" для выбора окончательных кандидатов, которые будут использоваться для потока мультимедиа. Конечная точка ICE Lite может использовать номинации, чтобы заключить путь, который будет использоваться для мультимедиа и завершить создание вызова.

Если при вилке с одноранговых конечных точек отправляется 183 предварительных ответа, SBC должен быть готов отвечать на проверки из нескольких конечных точек, а также на выдвижения из нескольких конечных точек, если номинации происходят до 200OK. В зависимости от конвергенции конечного пути и времени ответа пользователя, номинации могут выполняться до или после 200OK. SBC должен иметь возможность обрабатывать оба случая.

Конвергентирование для вилки

Если предложение от вилки SBC до нескольких конечных точек Teams, конечные точки Teams могут ответить предварительным ответом и начать проверки подключения. SBC должен быть готов к получению проверок подключения и реагированию на проверки подключения из нескольких одноранговых конечных точек. Например, пользователь Teams может войти как на настольный компьютер, так и на мобильный телефон. Оба устройства получают уведомление о входящем вызове и будут пытаться проверить подключение к SBC.

В конечном итоге только одна из конечных точек отвечает на вызов (200OK). При получении 200OK SBC может настроить правильный контекст для обработки пакетов мультимедиа.

Scenarios

Входящий вызов из SBC

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

• Конечные точки сервера обычно отвечают напрямую 200OK. Эти конечные точки ICE Full обычно участвуют в сценариях голосовой почты, очереди вызовов и автосекретаря.

• Клиентские конечные точки могут отправлять несколько предварительных ответов с разными тегами From/To (183), за которым следует 200OK от конечной точки, которая отвечает на вызов. Эти конечные точки ICE Full обычно представляют клиентов конечных пользователей.

• Другие конечные точки SBC. Эти конечные точки ICE Lite обычно участвуют в сценарии одновременного вызова конечных точек клиента и других номеров телефонов.

SBC должен отвечать на все допустимые подключения проверка запросы, полученные от конечных точек ICE Full. В rfc конечные точки ICE Full становятся конечными точками Управления. Конечные точки Teams (клиент или сервер) выполняют обычные номинации для выполнения проверок подключения. Последнее значение 200Ok может быть либо из конечной точки, отправивающей ранний носитель, либо из другой конечной точки. При получении 200Ok SBC должен настроить правильный контекст для потока мультимедиа.

Ранние медиа

Если есть ранний поток мультимедиа, SBC должен защелкивать первую конечную точку, которая запускает потоковую передачу мультимедиа; Поток мультимедиа может начаться до того, как кандидаты будут выдвинуты. SBC должен иметь поддержку отправки DTMF на этом этапе, чтобы включить сценарии IVR/голосовой почты. SBC должен использовать путь с наивысшим приоритетом, по которому он получил проверку, если номинации не завершены.

Исходящий вызов SBC

Конечные точки Teams являются вызывающим элементом для этого сценария и являются управляющей конечной точкой. При получении предварительного ответа (183) или окончательного ответа (200OK) конечная точка Teams запускает проверки подключения и переходит к категории "Обычные" для завершения проверок подключения.

Примечание. Если SBC отправляет предварительный ответ (183), SBC должен быть готов к приему запросов на подключение проверка и потенциально завершить номинации до отправки 200OK. Если проверки и /или номинации завершены до получения 200OK, проверки и /или номинации не будут выполняться повторно после получения 200OK. SBC не должен изменять кандидаты ICE, пароль и ufrag (фрагмент имени пользователя) между 183 и 200.

Для поддержки ранних носителей SBC может начать потоковую передачу мультимедиа в одноранговый кандидат ICE с наивысшим приоритетом на основе полученных проверок подключения, даже до того, как конечная точка Teams завершит выдвижение. SBC должен ожидать, что средства массовой информации от Teams от любого кандидата не будут завершены. После выдвижения кандидата SBC должен вернуться в правильный контекст для отправки и получения пакетов мультимедиа.

Обработка линий M в SDP

В некоторых сценариях вызова в вызове ТСОП могут предлагаться другие модалы мультимедиа. Например, m=video, если видеозвонок Teams перенаправлен в ТСОП. Если клиент SBC настроен с обходом мультимедиа, то эти строки не будут удалены службой и должны обрабатываться SBC следующим RFC3264: Для каждой строки, не "m=audio" в предложении, SBC должен содержать соответствующую строку "m=" в ответе, а номер порта в этой строке должен быть равен нулю. эффективно отклоняет все не звуковые потоки.

Требования к поддержке SRTP

SBC должен поддерживать шифр SRTP AES_CM_128_HMAC_SHA1_80 для предложения и ответа в следующем формате:

"inline:" <key||salt> ["|" lifetime]

Ниже приведен пример атрибута crypto в предложении SDP из SBC:

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:V/Lr6Lsvhad/crSB9kCQ28jrYDxR2Yfk5bXryH5V|2^31

Параметры MKI и Length не требуются.

Дополнительные сведения см. в статье RFC 4568, раздел 6.1.

Требования к поддержке SDES

Устройство должно иметь возможность предлагать SDES в следующем формате. Обработчики мультимедиа Майкрософт всегда предпочитают SDES.

• При обходе, отличном от посредника, даже если клиент поддерживает только DTLS, обработчики мультимедиа преобразуются в SDES.

• При обходе мультимедиа, если клиент является только DTLS (будущее состояние Google Chrome), прямая маршрутизация вставляет mp в путь, преобразуя вызов из обхода мультимедиа в обход без посредника. Между компонентом SBC и обработчика мультимедиа прямой маршрутизации всегда используется SDES.

В настоящее время нет клиента Teams, который предлагает только DTLS; однако Google объявил, что в какой-то момент времени они прекратят поддержку SDES.

Формат предложения из SBC в режиме обхода

Предложение должно содержать SDES и может содержать необязательный DTLS в следующем формате:

m=audio 54056 UDP/TLS/RTP/SAVP 0 8 76 77 18 9 101 13
a=rtcp:54056
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:krXco0QRglwErMqtbMs2zSw29tBdmdgXpEYZhQmp|2^31
a=fingerprint:sha-256 AE:24:07:15:5C:B7:45:1A:E4:45:60:C1:1E:68:0E:CC:8D:A6:78:3B:76:65:BB:B0:77:88:07:F8:98:18:62:34
a=setup:actpass
a=rtcp-mux

Формат ответа, содержащего SDES в SBC

m=audio 54056 RTP/SAVP 111 103 104 9 0 8 description 106 13 110 112 113 126
a=rtcp:54056
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:fBc61ikv1kMy0sF85DblNqTzVAbFa7hJQ9GKb6Yj|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:O1qT9tWbs/NwJVwhfrgF5tCrbNOxnVDqkIqTx4rz|2^31
a=rtcp-mux

Формат предложения из Teams в SBC

Формат предложения только SDES для SBC

m=audio 52884 RTP/SAVP 111 103 104 9 0 8 106 13 110 112 113 126
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:Hr4D2cgUu9+Uza5Igz/JkVx59DAxDbaxJg862ibQ|2^31
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:JPEaIxHegfuv53ykBPZk8hV0GO8kTiiqRMfHimEE|2^31
a=rtcp:52884
a=rtcp-mux