sip options что это

База знаний

Протокол SIP

Этот документ описывает Session Initiation Protocol (SIP), протокол контроля и сигнализации уровня приложения для создания, модификации, и завершения сеансов с одним или несколькими участниками. Эти сеансы включают в себя: телефонные вызовы через Интернет, презентация мультимедийных данных, и мультимедийные конференции.

При создании сеансов, используется SIP приглашение с описанием сессии, что позволяет участникам подтвердить совместимость используемых настроек для передачи медиаданных. SIP дает возможность использования таких элементов, как прокси сервер, в функции которого входит помощь в доставке запросов к конечному пользователю, установка подлинности и разграничение доступа пользователей к различным сервисам, поддерживает правила маршрутизацию вызовов, задаваемых провайдерами, а также поддерживает различные возможности, ориентированные на конечных пользователей. Так же в протоколе SIP имеется механизм регистрации, который дает возможность пользователям подключаться из своего текущего местоположения к сервисам, через прокси сервер. Протокол SIP может использовать несколько основных протоколов различного транспортного уровня.

Также, протокол SIP может преодолевать ограничение, связанные с использованием NAT или файрволов. (Обратите внимание на раздел: NAT and VOIP)

Протокол SIP

Принципы протокола SIP

Протокол инициирования сеансов – Session Initiation Protocol (SIP) является протоколом прикладного уровня и предназначается для организации, модификации и завершения сеансов связи: мультимедийных конференций, телефонных соединений и распределения мультимедийной информации. Пользователи могут принимать участие в существующих сеансах связи, приглашать других пользователей и быть приглашенными ими к новому сеансу связи. Приглашения могут быть адресованы определенному пользователю, группе пользователей или всем пользователям.

Протокол SIP разработан группой MMUSIC (Multiparty Multimedia Session Control) комитета IETF (Internet Engineering Task Force), а спецификации протокола представлены в документе RFC 2543]. В основу протокола рабочая группа MMUSIC заложила следующие принципы:

Расширение функций протокола SIP может быть произведено за счет введения новых заголовков сообщений, которые должны быть зарегистрированы в уже упоминавшейся ранее организации IANA. При этом, если SIP,сервер принимает сообщение с неизвестными ему полями, то он просто игнорирует их и обрабатывает лишь те поля, которые он знает.

Для расширения возможностей протокола SIP могут быть также добавлены и новые типы сообщений.

Интеграция в стек существующих протоколов Интернет, разработанных IETF. Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом Internet Engineering Task Force IETF. Эта архитектура включает в себя также протокол резервирования ресурсов (Resource Reservation Protocol – RSVP, RFC 2205), транспортный протокол реального времени (Real,Time Transport Pro,tocol – RTP, RFC 1889), протокол передачи потоковой информации в реальном времени (Real,Time Streaming Protocol – RTSP, RFC 2326),
протокол описания параметров связи (Session Description Protocol – SDP, RFC 2327). Однако функции протокола SIP не зависят ни от одного из этих протоколов.

Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с протоколом Н.323. Возможно также взаимодействие протокола SIP с системами сигнализации ТфОП – DSS1 и ОКС7. Для упрощения такого взаимодействия сигнальные сообщения протокола SIP могут переносить не только специфический SIP адрес, но и телефонный номер формата Е.164 или любого другого формата. Кроме того, протокол SIP, наравне с протоколами H.323 и ISUP/IP, может применяться для синхронизации работы устройств управления шлюзами; в этом случае он должен взаимодействовать с протоколом MGCP. Другой важной особенностью протокола SIP является то, что он приспособлен к организации доступа пользователей сетей IP телефонии к услугам интеллектуальных сетей, и существует мнение, что именно этот протокол станет основным при организации связи между указанными сетями.

Методы SIP протокола, определенные в SIP RFC.

В протоколе SIP определено несколько методов, используемых при коммуникации.

Расширенные методы SIP протокола из других RFC:

Ответы на SIP сообщения

После приема и интерпретации запроса, адресат (прокси сервер) передает ответ на этот запрос. Содержание ответов бывает разным:
подтверждение установления соединения, передача запрошенной информации, сведения о неисправностях и т.д.
Структуру ответов и их виды протокол SIP унаследовал от протокола НТТР.

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

Источник

Прямая маршрутия — протокол SIP

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

Обработка входящих запросов: поиск клиента и пользователя

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

Заглавные данные SIP не содержат userinfo в используемом URI SIP. В соответствии с RFC 3261, разделом 19.1.1userinfo URI является необязательным и может отсутствовать, если конечного хоста нет представления о пользователях или когда хост является идентифицированным ресурсом. Если знак @ присутствует в URI SIP, поле пользователя НЕ ДОЛЖНО быть пустым. Обратите внимание, что URI SIPS не следует использовать с direct Routing, так как он не поддерживается. Проверьте конфигурацию контроллера границы сеанса и убедитесь, что в запросах SIP не используется заглавная «Замена». Прямая маршрутия отклоняет запросы SIP с задаваемой заменой.

Во время входящих зовов прокси-сервер SIP должен найти клиент, на который он перенапрался, и конкретного пользователя в этом клиенте. Администратор клиента может настроить номера без DID, например +1001, в нескольких клиентах. Поэтому важно найти конкретный клиент, для которого нужно выполнить поиск номеров, так как неИдационные числа могут быть одинаковыми в Microsoft 365 или Office 365 организациях.

В этом разделе описано, как прокси-сервер SIP находит клиента и пользователя, а также выполняет проверку подлинности SBC при входящих подключениях.

Ниже приводится пример приглашения SIP во входящий звонок:

При получении приглашения прокси-сервер SIP выполняет следующие действия:

Проверьте сертификат. По первоначальному подключению служба прямой маршрутизовывания принимает имя FQDN, которое представлено в заглавной части контакта, и совпадает с именем «Общее имя» или «Тема альтернативы» для представленного сертификата. Имя SBC должно соответствовать одному из следующих вариантов:

Вариант 1. Полное полное имя FQDN, которое есть в заглавном тексте контакта, должно совпадать с именем «Общее имя/тема» для сертификата.

Вариант 2. Часть домена имени FQDN, представленная в заглавной части контакта (например, adatum.biz имени FQDN sbc1.adatum.biz), должна соответствовать поддеревной знаку в названии «Общее имя» или «Альтернативное имя субъекта» (например, *.adatum.biz).

Попробуйте найти клиента, используя полное имя FQDN, которое представлено в заглавном тексте контакта.

Проверьте, зарегистрировано ли имя FQDN из заглавного sbc1.adatum.biz контакта в любой организации Microsoft 365 или Office 365 DNS. При обнаружении выполняется подсмотр пользователя в клиенте, в доменном имени которого зарегистрированО FQDN SBC. Если она не найдена, применяется шаг 3.

Шаг 3 применяется только в случае сбойного шага 2.

Удалите часть хоста из FQDN, представленную в заглавном имени контакта (FQDN: sbc12.adatum.biz, после удаления части хоста: adatum.biz) и проверьте, зарегистрировано ли это имя как имя DNS в любой организации Microsoft 365 или Office 365. При обнаружении в этом клиенте выполняется пользовательский просмотр. Если он не найден, звонок не удастся найти.

Используя номер телефона, представленный в URI-запроса, выполните обратный просмотр номера в клиенте, найденном в шаге 2 или 3. Сопопошать представленный номер телефона с пользовательским URI SIP в клиенте, найденном на предыдущем шаге.

Применим параметры туловища. Найдите параметры, заданные администратором клиента для этого SBC.

Корпорация Майкрософт не поддерживает наличие прокси-сервера SIP сторонних пользователей или сервера агента пользователя между прокси-сервером SIP Майкрософт и сопряженным сервером SBC, который может изменить URI запроса, созданный парным SBC.

Требования для двух подысков (этапов 2 и 3), необходимых для сценария, в котором один SBC взаимосвязан с множеством клиентов (сценарий оператора связи), см. далее в этой статье.

Подробные требования для загона контактов и запроса URI

Заглавная связь с контактом

Для всех входящих сообщений SIP (OPTIONS, INVITE) на прокси-сервер SIP Майкрософт закаглавная запись контакта должна иметь сопряженное FQDN SBC в имени хоста URI следующим образом:

В соответствии с RFC 3261, раздел 11.1, поле заглавного поля контакта может присутствовать в сообщении OPTIONS. В прямой маршрутике требуется заглавная линия контакта. Для сообщений INVITE в формате выше для сообщений OPTIONS, которые userinfo можно удалить из SIP URI и только FQDN, отправленных в формате:

Это имя (FQDN) также должно быть в полях «Общее имя» или «Альтернативные имена субъекта» в сертификате. Корпорация Майкрософт поддерживает использование поддеревных значений имен в полях «Общее имя» или «Альтернативное имя субъекта» сертификата.

Поддержка поддеревных знаков описана в разделе 3.1 RFC 2818. Специально:

Если SBC отправляет несколько значений в заглавном сообщении контакта, используемой SBC, используется только часть FQDN первого значения в заглавном сообщении контакта.

Как правило, при прямой маршрутике для заполнения URI SIP вместо IP-адреса используется FQDN. Сообщение о входящих ПРИГЛАШЕНИЯх и параметрах на прокси-сервер SIP с названием контакта, в котором имя сервера представлено IP, а не FQDN, подключение будет отклонено с помощью параметра 403 Запрещено.

URI запроса

Для всех входящих звонков для совпадения номера телефона с пользователем используется запрос-URI.

В настоящее время номер телефона должен содержать знак «плюс» (+), как показано в примере ниже.

Из области «Заглавная»

Для всех входящих звонков закаглавка «От» используется для совпадения номера телефона звоня с заблокированным списком номеров телефонов вызываемого.

Номер телефона должен содержать +, как показано в примере ниже.

Контактные и Record-Route с Record-Route.

Прокси-сервер SIP должен вычислить FQDN следующего перехода для новых клиентских транзакций в диалоговом оке (например, Bye или Re-Invite), а также при ответе на параметры SIP. Используются контакты или Record-Route контактов.

Согласно RFC 3261, разделу 8.1.1.8в любом запросе, который может привести к новому диалоговом оклу, требуется заглавная связь контакта. Этот Record-Route требуется только в том случае, если прокси-сервер хочет оставаться на пути будущих запросов в диалоговом окке. Если прокси-сервер SBC используется с локальной оптимизацией мультимедиа для прямой маршрутизации, необходимо настроить маршрут записи, так как прокси-сервер должен оставаться в маршруте.

Корпорация Майкрософт рекомендует использовать только заглавную запись контакта, если не используется прокси-сервер SBC:

В соответствии с RFC 3261, раздел 20.30, Record-Route используется, если прокси-сервер хочет оставаться на пути будущих запросов в диалоговом окке, что не важно, если ни один прокси-сервер SBC не настроен, так как весь трафик проходит между прокси-сервером Microsoft SIP и сопряженным SBC.

Прокси-сервер SIP (Майкрософт) использует только заглавную запись контакта (а не Record-Route) для определения следующего перехода при отправке параметров исходящие связи. Настройка только одного параметра (Контакт) вместо двух (Contact и Record-Route) упрощает администрирование, если прокси-сервер SBC не используется.

Для вычисления следующего перехода прокси-сервер SIP использует:

Приоритет 1. Запись верхнего уровня. Если имя FQDN Record-Route верхнего уровня, имя FQDN используется для соединения исходящие в диалоговом окну.

Приоритет 2. Заглавная связь с контактом. Если Record-Route не существует, прокси-сервер SIP будет искать значение в заглавной части контакта, чтобы сделать исходящие подключения. (Рекомендуемая конфигурация.)

Если используются как contact, так и Record-Route, администратор SBC должен сохранить одинаковые значения, что приводит к накладным расходовам администратора.

Использование имени FQDN в контакте или Record-Route

Использование IP-адреса не поддерживается ни в Record-Route, ни в контакте. Единственным поддерживаемым вариантом является FQDN, которое должно совпадать с общим именем или альтернативным именем субъекта сертификата SBC (поддерживаются поддеревные знаки в сертификате).

Если IP-адрес присутствует в record-route или Contact, проверка сертификата не проходит, а звонок не проходит.

Если FQDN не соответствует значению общего или альтернативного имени субъекта в представляемом сертификате, вызов не происходит.

Входящий звонок: описание диалогового окно SIP

В следующей таблице ниже общались различия и сходства потока зовов между режимами обхода и обхода:

Поток обхода без мультимедиа

У Teams может быть несколько конечных точек одновременно. Например, Teams для Windows, Teams для iPhone и Teams Телефон (Teams клиента Android). Каждая конечная точка может сигнализировать об отстаке HTTP следующим образом:

Ход выполнения звонка — преобразуется прокси-сервером SIP в сообщение SIP 180. При получении сообщения 180 SBC должен создать локальный звонок.

Медиаотобращение— преобразуется прокси-сервером SIP в сообщение 183 с кандидатами на мультимедиа в протоколе SDP. При получении сообщения 183 SBC рассчитывает подключиться к медиаимумам, полученным в сообщении SDP.

В некоторых случаях ответ на вопрос «Мультимедиа» может не быть создан, а конечный пункт может ответить сообщением «Звонок принят».

Звонок принят — преобразуется прокси-сервером SIP в сообщение SIP 200 с SDP. При получении сообщения 200 ожидается отправка и получение мультимедиа для предоставленных кандидатов SDP и от них.

Прямая маршрутная маршрутия не поддерживает приглашение с задержкой предложения (приглашение без SDP).

Несколько конечных точек, которые звонят с временным ответом

При получении первого приглашения из SBC прокси-сервер SIP отправляет сообщение «SIP SIP/2.0 100 Trying» и сообщает конечным точкам пользователей о входящих звонках.

После уведомления каждая конечная точка начнет звонить на прокси-сервер SIP и отправлять сообщения о ходе выполнения зовов. Так как Teams может иметь несколько конечных точек, прокси-сервер SIP может получать несколько сообщений о ходе выполнения зовов.

Для каждого сообщения о ходе выполнения звонка, полученного от клиентов, прокси-сервер SIP преобразует сообщение о ходе выполнения звонка в сообщение SIP «SIP SIP/2.0 180 Trying». Интервал для отправки таких сообщений определяется интервалом получения сообщений от контроллера звонка. На приведенной ниже схеме прокси-сервером SIP создается 180 сообщений. Эти сообщения приходят из двух Teams конечных точек пользователя. У каждого клиента есть уникальный ИД тега. Каждое сообщение из другой конечной точки будет отдельным сеансом (параметр «тег» в поле «To» будет разным). Однако конечная точка может не создать сообщение 180 и отправить сообщение 183 сразу, как показано на приведенной ниже схеме.

После того как конечная точка создает сообщение «Ответ на мультимедиа» с IP-адресами кандидатов на поддержку мультимедиа конечной точки, прокси-сервер SIP преобразует полученное сообщение в сообщение «Ход выполнения сеанса SIP 183», а SDP клиента будет заменена SDP-сервером из процессора мультимедиа. На приведенной ниже схеме конечная точка из Висяча 2 ответила на звонок. Если ни одна из сторон связи не обойдена, сообщение SIP 183 создается только один раз (ring bot или client end point). На 183-й может быть уже существующий висячий или новый.

Вместе с конечными кандидатами конечной точки, которые приняли звонок, будет отправлено сообщение о приеме звонка. Сообщение о приемке вызовов преобразуется в сообщение SIP 200.

Несколько конечных точек, которые звонят без предварительного ответа

При получении первого приглашения из SBC прокси-сервер SIP отправляет сообщение «SIP SIP/2.0 100 Trying» и сообщает конечным точкам пользователей о входящих звонках.

После уведомления каждая конечная точка начнет звонить и отправлять сообщение «Ход выполнения звонка» на прокси-сервер SIP. Так как Teams может иметь несколько конечных точек, прокси-сервер SIP может получать несколько сообщений о ходе выполнения зовов.

Для каждого сообщения о ходе выполнения звонка, полученного от клиентов, прокси-сервер SIP преобразует сообщение о ходе выполнения звонка в сообщение SIP «SIP SIP/2.0 180 Trying». Интервал для отправки сообщений определяется интервалом получения сообщений с контроллера звонка. На рисунке ниже 180 сообщений, созданных прокси-сервером SIP, то есть пользователь вошел в три клиента Teams и каждый клиент отправил ход выполнения звонка. Каждое сообщение будет отдельным сеансом (параметр «тег» в поле «To» отличается)

Вместе с конечными кандидатами конечной точки, которые приняли звонок, будет отправлено сообщение о приеме звонка. Сообщение о приемке вызовов преобразуется в сообщение SIP 200.

Поток обхода мультимедиа

Те же сообщения (100 trying, 180, 183) используются в сценарии обхода мультимедиа.

В приведенной ниже схеме показан пример обхода потока зова.

Кандидаты на выбор мультимедиа могут быть из разных конечных точек.

Параметр «Заменяет»

SBC должен поддерживать приглашение на замену.

Размер аспектов SDP

Интерфейс прямой маршрутизации может отправить сообщение SIP, превышающий 1500 тол. Это главным образом связано с размером SDP. Однако если за SBC находится магистраль UDP, оно может отклонить сообщение, если оно будет перенапрано с прокси-сервера SIP Майкрософт на неизмененную. Корпорация Майкрософт рекомендует обрезать некоторые значения в SDP на SBC при отправке сообщения на ленту UDP. Например, можно удалить соитли ICE или неиспользованые кодеки.

передача вызовов;

Прямая маршрутия поддерживает два способа перенаправки вызовов:

Вариант 1. Процессы прокси-сервера SIP. Они относятся к локальному клиенту и выступают в качестве посредника, как описано в разделе 7.1 RFC 3892.

При этом прокси-сервер SIP прекращает передачу и добавляет новое приглашение.

Вариант 2. Прокси-сервер SIP отправляет ссылку на SBC и выступает в качестве переносителя, как описано в разделе 6 RFC 5589.

При этом прокси-сервер SIP отправляет ссылку на SBC и ожидает, что SBC полностью обработать передачу.

Прокси-сервер SIP выбирает метод на основе возможностей, о возможностях, о которые сообщает SBC. Если SBC указывает на то, что он поддерживает метод «Refer», прокси-сервер SIP будет использовать вариант 2 для перенаправок.

Ниже по образцу SBC отправляется сообщение о том, что метод Refer поддерживается:

Если SBC не указывает на то, что «Ссылка как поддерживаемый способ», прямая маршрутия будет использовать вариант 1 (прокси-сервер SIP выступает в качестве подмножества). Кроме того, SBC должен сигнализировать о том, что он поддерживает метод Notify:

Пример SBC, указывающий на то, что метод Refer не поддерживается:

Процессы прокси-сервера SIP. Ссылаются на локального клиента и выступают в качестве посредника

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

Запрос на ссылку, который приходит от клиента, будет прекращен на прокси-сервере SIP. (На приведенной ниже схеме запрос на передачу от клиента показан как «Передача вызовов Е. Дополнительные сведения см. в разделе 7.1 RFC 3892.

Прокси-сервер SIP отправляет ссылку на SBC и выступает в качестве посредника

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

Стандартная процедура объясняется в разделе 6 RFC 5589. Связанными будут:

Предполагается, что прокси-сервер SIP выступает в качестве переносителя и отправляет в SBC сообщение «Ссылка». SBC выступает в качестве переносимой и обрабатывает ссылку для создания нового предложения для передачи. Возможны два случая:

Если звонок переносится от одного Teams пользователя к другому через SBC, предполагается, что SBC выдает новое приглашение (начать новое диалоговое окно) для целевого Teams, используя сведения, полученные в сообщении.

Чтобы заполнить поля To/Transferor для транзакции запроса внутри нее, прокси-сервер SIP должен передавать эти сведения в заглавных полях REFER-TO/REFERRED-BY.

Прокси-сервер SIP будет формировать REFER-TO как URI SIP, состоящий из FQDN прокси-сервера SIP в имени хоста и одного из следующих uri:

Номер телефона E.164 в части URI имени пользователя, если целевым объектом передачи является номер телефона или

Параметры x-m и x-t, кодющие полную передачу параметров MRI и ИД клиента соответственно

Заглавный код REFERRED-BY — это URI SIP с кодом MRI-кода переносителя, а также кодом клиента переноса и другими параметрами контекста передачи, как показано в таблице ниже.

В этом случае размер заглавной ссылки может быть не более 400 символов. SBC должен поддерживать обработку ссылок с сообщениями размером до 400 символов.

Сеансовой timer

Прокси-сервер SIP поддерживает (всегда предлагает) время сеанса при звонках без обхода, но не предлагает его при обходе звонков. Использование SBC timer сеанса не является обязательным.

Использование параметра Request-URI user=phone

Прокси-сервер SIP анализирует запрос-URI, и если параметр user=phone присутствует, служба будет обрабатывать request-URI как номер телефона, совпадая с номером пользователя. Если параметра нет, прокси-сервер SIP применяет авристику для определения типа пользователя Request-URI (номер телефона или SIP-адрес).

Корпорация Майкрософт рекомендует всегда применять параметр user=phone, чтобы упростить настройку звонков.

History-Info загона

Заглавная History-Info используется для перенанабножать запросы SIP и «предоставлять» стандартный механизм сбора сведений об истории запросов, чтобы обеспечить поддержку широкого круга служб для сетей и конечных пользователей». Дополнительные сведения см. в разделе RFC 4244 — раздел 1.1. В Телефон (Майкрософт) система этот замещающий

При отправке History-Info включено следующим образом:

Прокси-сервер SIP вставит параметр, содержащий связанный номер телефона, в отдельные записи History-Info, которые включают History-Info, отправленные на контроллер ЗВОНКОВ. Если использовать только записи с параметром номера телефона, контроллер ЗВОНКОВ перестроит новый History-Info и передаст его поставщику услуг связи SIP через прокси-сервер SIP.

History-Info будут добавлены загон для одновременных звонка и случаев переад вызовов.

History-Info не будет добавлен для случаев перена передачи вызовов.

В восстановленном History-Info записи истории будет параметр номера телефона, предоставленный в сочетании с FQDN прямой маршрутии (sip.pstnhub.microsoft.com), заданным в качестве хост-части URI; Параметр «user=phone» будет добавлен в URI SIP. Любые другие параметры, связанные с исходным History-Info, за исключением контекстных параметров телефона, будут передаваться в повторно построенном History-Info.

Частные записи (в соответствии с механизмами, определенными в разделе 3.3 RFC 4244) будут перенаправлены так же, как и частные записи, так как поставщик услуг связи SIP является доверенным пиром.

Входящие History-Info игнорируются.

Ниже приводится формат заглавного заглавного адреса «История-сведения», отправленного прокси-сервером SIP:

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

Пример заглавного за

Этот History-Info защищен с помощью обязательного механизма TLS.

Подключение SBC к прямой маршрутике и механизму отбойного управления

См. раздел Механизм отрезка для сигнального сигнала SIP в статье Планирование прямой маршрутизации.

Retry-After

Если центр обработки данных Direct Routing занят, служба может отправить Retry-After с интервалом в одну секунду в SBC. Когда SBC получает сообщение 503 с Retry-After в ответ на приглашение, он должен прекратить подключение и попробовать следующий доступный центр обработки данных Майкрософт.

Обработка ирисовки (603 ответа)

Если конечный пользователь наблюдает несколько пропущенных звонков для одного звонка после отступа, это означает, что механизм повторной работы поставщика услуг связи SBC или STN неправильно сконфигурировали. Чтобы остановить попытку ответа 603, необходимо перенастроить SBC.

Перезапуск ICE: звонок «Обход мультимедиа» переносится на конечную точку, которая не поддерживает обход мультимедиа

SBC должен поддерживать перезапуски ICE, как описано в разделе 9.1.1.1.1 RFC 5245.

Перезапуск в прямой маршрутике выполняется в соответствии со следующими абзацами RFC:

Чтобы перезапустить ICE, агент должен изменить в предложении как льдовый, так и льдовый уфраг для потока мультимедиа. Обратите внимание, что атрибуты уровня сеанса можно использовать в одном предложении, но использовать тот же атрибут ice-pwd или ice-ufrag, что и атрибуты уровня мультимедиа в последующих предложениях. Это не изменение пароля, а изменение его представления и не приведет к перезапуску ICE.

Агент задает остальные поля в SDP для этого потока мультимедиа так же, как в первоначальном предложении этого потока мультимедиа (см. раздел 4.3). Следовательно, в набор кандидатов могут быть некоторые, никто или все предыдущие кандидаты для этого потока, а также новый набор кандидатов, собранный в соответствии с разделом 4.1.1.

Если звонок был изначально установлен с помощью обхода мультимедиа и перенаправлен в клиент Skype для бизнеса, необходимо вставить процессор мультимедиа, так как прямая маршрутия не может использоваться с клиентом Skype для бизнеса с обходом мультимедиа. Прямая маршрутизации запускает процесс перезапуска ICE, изменяя льдом и льдом-ufrag и предлагая новых кандидатов мультимедиа в повторной обработке.

Источник