Sip 183 session progress что это
SIP ответы и их значения
1xx – информационные ответы
SIP/2.0 100 Trying
Запрос обрабатывается.
SIP/2.0 180 Ringing
Местоположение вызываемого пользователя определено. Выдан сигнал о входящем вызове.
SIP/2.0 181 Call is Being Forwarded
Прокси-сервер переадресует вызов к другому пользователю.
SIP/2.0 182 Call is Queued
Вызываемый абонент временно не доступен. вызов поставлен в очередь.
SIP/2.0 183 Session Progress
Используется для того, чтобы заранее получить описание сеанса информационного обмена от шлюзов на пути к вызываемому пользователю.
2xx – ответы о завершении запроса
SIP/2.0 200 OK
Успешное завершение.
SIP/2.0 202 Accepted
Запрос принят для обработки. Используется для справки о состоянии обработки.
3xx – сообщения о переадресации
SIP/2.0 300 Multiple Choices
Указывает несколько SIP-адресов, по которым можно найти вызываемого пользователя.
SIP/2.0 301 Moved Permanently
Вызываемый пользователь больше не находится по адресу, указанному в запросе.
SIP/2.0 302 Moved Temporarily
Пользователь временно сменил местоположение. (Настроена переадресация по SIPUA в т.ч. с VOIP-телефона)
SIP/2.0 305 Use Proxy
Вызываемый пользователь не доступен непосредственно. Входящий вызов должен пройти через прокси-сервер.
SIP/2.0 380 Alternative Service
Запрошенная услуга недоступна, но доступны альтернативные услуги.
4xx – невозможность обработать запрос
SIP/2.0 400 Bad Request
Запрос не распознан из-за синтаксических ошибок или ошибок в сигнализации.
SIP/2.0 401 Unauthorized
Нормальный ответ сервера о том, что пользователь еще не авторизовался. Обычно после этого абонентское оборудование отправляет на сервер новый запрос, содержащий логин и пароль.
SIP/2.0 401 AUTH Error: Stall nonce
1.Разные данные в поле NONCE (шифр пароля), проверить дату/время или проблема с протоколом шифрования
2. П роверить на клиентской стороне не заблокирован ли sipnet.ru (212.53.40.40)
SIP/2.0 401 Expired Authorization
Время регистрации истекло.
SIP/2.0 402 Payment Required
Требуется оплата (зарезервирован для использования в будущем).
SIP/2.0 403 No Such User
Нет такого пользователя. Ошибка в номере, логине или пароле.
SIP/2.0 403 No license available
Кончились лицензия на SIP
SIP/2.0 403 You
Нет такого пользователя. Ошибка в номере, логине или пароле.
SIP/2.0 403 User Disabled
Пользователь отключен.
SIP/2.0 403 You do not have the required right
Не верный логин в поле FROM
SIP/2.0 403 Wrong Guess
Ошибка в пароле.
SIP/2.0 403 Conflict
Такой SIP-номер уже используется.
SIP/2.0 403 Forbidden
Абонент не зарегистрирован.
SIP/2.0 403 Empty Route Set
Нет ни одного шлюза в роутинге.
SIP/2.0 403 Caller Not Registered
Нет такого пользователя.
SIP/2.0 403 Out of Look-Ahead Retries
Перебор узлов закончен.
SIP/2.0 403 Invalid Phone Number
Нет такого направления.
SIP/2.0 403 No Money Left on RFC Account
На счету не достаточно денежных средств для совершения вызова.
SIP/2.0 404 Not found
Вызываемый абонент не найден, нет такого SIP-номера.
SIP/2.0 404 Undefined Reason
Неопределенное направление.
SIP/2.0 404 Unknown user account
Логин и пароль не найдены.
SIP/2.0 404 Out of Order
В заявке на маршрутизацию по этому направлению нет принимающих шлюзов.
SIP/2.0 405 Method Not Allowed
Метод не поддерживается. Может возникать если пользователь пытается отправлять голосовую почту и т.п.
SIP/2.0 406 No codecs match
Неправильная конфигурация кодеков.
SIP/2.0 406 Not Acceptable
Пользователь не доступен.
SIP/2.0 407 Proxy Authentication Required
Необходима аутентификация на прокси-сервере.
SIP/2.0 407 User not found
Проверить ID на CGP
SIP/2.0 408 Request Timeout
Время обработки запроса истекло. Абонента не удалось найти за отведенное время. (Проблема с firewall, нет ответ на Invite от сервера)
SIP/2.0 408 Login timed out
За отведенное время не получен ответ от сервера на запрос авторизации.
SIP/2.0 410 No Route
Вариант «SIP/2.0 403 Empty Route Set». Нет доступа к ресурсу или ресурс по указанному адресу больше не существует.
SIP/2.0 413 Request Entity Too Large
Размер запроса слишком велик для обработки на сервере.
SIP/2.0 415 No Media
Звонок совершается неподдерживаемым кодеком.
SIP/2.0 416 Unsupported Scheme
Сервер не может обработать запрос из-за того, что схема адреса не распознана.
SIP/2.0 420 Bad extension
Неизвестное расширение. Сервер не распознал расширение протокола SIP.
SIP/2.0 421 Extension Required
В заголовке запроса не указано, какое расширение сервер должен применить для его обработки.
SIP/2.0 423 Interval Too Brief
Сервер отклоняет запрос, так как время действия ресурса короткое.
SIP/2.0 480 Invalid Phone Number
Неправильный номер телефона, не соответствует количество цифр или неправильный код страны или города.
SIP/2.0 480 Destination Not Found In Client Plan
Направления нет в тарифном плане абонента.
SIP/2.0 480 Wrong DB Response
Проблемы с центральной базой данных.
SIP/2.0 480 DB Timeout
Проблемы с центральной базой данных.
SIP/2.0 480 Database Error
Проблемы с центральной базой данных.
SIP/2.0 480 Codec Mismatch
Несоответствие кодеков.
SIP/2.0 480 No Money Left on RFC Account
Не достаточно денежных средств на счету.
SIP/2.0 480 Empty Route Set
Пустое направление. Нет принимающих шлюзов.
SIP/2.0 480 No money left
Не достаточно денежных средств на счету.
SIP/2.0 480 Temporarily Unavailable
Временно недоступное направление. (Возможно статус DND)
SIP/2.0 481 Call Leg/Transaction Does Not Exist
Действие не выполнено. Нормальный ответ при поступлении дублирующего пакета.
SIP/2.0 482 Loop Detected
Обнаружен замкнутый маршрут передачи запроса.
SIP/2.0 483 Too Many Hops
Запрос на своем пути прошел через большее число прокси-серверов, чем разрешено.
SIP/2.0 484 Address Incomplete
Принят запрос с неполным адресом.
SIP/2.0 485 Ambiguous
Адрес вызываемого пользователя не однозначен.
SIP/2.0 486 Busy Here
Абонент занят.
SIP/2.0 487 Request Terminated
Запрос отменен. Обычно приходит при отмене вызова.
SIP/2.0 488 Codec Mismatch
Нет шлюзов с поддержкой заказанного кодека.
SIP/2.0 488 Private IP Address
Адрес RTP media из сетей RFC1918.
SIP/2.0 488 Not acceptable here
Не совпадают кодеки
SIP/2.0 491 Request Pending
Запрос поступил в то время, когда сервер еще не закончил обработку другого запроса, относящегося к тому же диалогу.
SIP/2.0 493 Undeciperable
Сервер не в состоянии подобрать ключ дешифрования. Невозможно декодировать тело S/MIME сообщения.
SIP/2.0 499 Codec Mismatch
Отсутствует кодек.
5xx – ошибки сервера
SIP/2.0 500 Internal Server Error
Внутренняя ошибка сервера.
SIP/2.0 500 DB Timeout
Нет ответа от базы данных.
SIP/2.0 500 Database Error
То же самое, но в другой момент.
SIP/2.0 500 Wrong DB Response
Неправильный ответ базы данных.
SIP/2.0 500 Undefined Reason
Неопределенная причина.
SIP/2.0 500 account has been moved to a remote system
Аккаунт перенесен в удаленную систему (дословно).
SIP/2.0 500 Call placing quota exceeded
Превышен CPS.
SIP/2.0 501 Method Not Supported Here
В сервере не реализованы какие-либо функции, необходимые для обслуживания запроса. Метод запроса SIP не поддерживается.
SIP/2.0 502 Bad Gateway
Сервер, функционирующий в качестве шлюза или прокси-сервера, принимает некорректный ответ от сервера, к которому он направил запрос.
SIP/2.0 503 Service Unavailable
Сервер не может в данный момент обслужить вызов вследствие перегрузки или проведения технического обслуживания.
SIP/2.0 504 Server time-out
Сервер не получил ответа в течение установленного промежутка времени от сервера, к которому он обратился для завершения вызова.
SIP/2.0 505 SIP Version not supported
Версия не поддерживается. Сервер не поддерживает эту версию протокола SIP.
SIP/2.0 513 Message too big
Сервер не в состоянии обработать запрос из-за большой длины сообщения.
6xx – глобальная ошибка
SIP/2.0 600 Busy everywhere
Вызываемый пользователь занят и не желает принимать вызов в данный момент.
SIP/2.0 603 Decline
Вызываемый пользователь не желает принимать входящие вызовы, не указывая причину отказа.
SIP/2.0 604 Does Not Exist Anywhere
Вызываемого пользователя не существует.
SIP/2.0 606 Not Acceptable
Соединение с сервером было установлено. Отдельные параметры, такие как тип запрашиваемой информации, полоса пропускания, вид адресации не доступны.
Lync и SIP. Объявление медиа-возможностей и ошибка КПВ
Вместо предисловия
Во время Teched Russia 2011 самым задаваемым мне вопросом оказался вопрос про отсутствие длинного гудка при вызове абонента Lync из ТфОП. При этом, все спрашивающие являлись читателями ITBand.RU. Так что, первым делом по возвращении домой с MVP Open Days, я решил перенести уже готовую статью по данной теме из собственного блога (являющегося для меня чем-то вроде инкубатора) сюда. Надеюсь будет полезно.
Урок номер 3
Продолжаем разговор про использование SIP в Lync Server 2010. На этот раз мы разберем SDP пакет, генерируемый Lync при видео-вызове в части предлагаемых способов аудио/видео взаимодействия и ответим на пару вопросов из предыдущей статьи, включая наиболее популярный: про отсутствие гудков при звонке на Lync.
Домашнее задание
Для начала, проверим домашнее задание – посмотрим, какие кодеки использует Lync.
Как и в прошлый раз, я выложил разбор в отдельный PDF.
Разбор ошибки с отсутствие гудков
Во второй части статьи опишу причину наиболее часто возникающей ошибки при настройке Lync Server в качестве АТС. А именно, отсутствие контроля посылки вызовов (КПВ) при поступающих на Lync звонках. Проще говоря, отсутствие гудков.
Идеальная ситуация
Упрощенно, процесс телефонного вызова из ТфОП в IP-телефонию выглядит так:
Сигнал КПВ генерирует голосовой шлюз, непосредственно подключенный к аналоговым/цифровым телефонным линиям. При IP-to-IP вызовах сеть передачей КПВ вообще не нагружается, так как КПВ генерирует сам вызывающий клиент, получив 180 Ringing.
Но это в идеале. Почему же при работе с решением от MS генерация КПВ в некоторых случаях не происходит?Ноги у этой проблемы растут довольно далеко. Все началось в далеком 2007-ом году… (театральная пауза).
Истоки проблемы
В OCS 2007 в Microsoft внедрили поддержку протокола ICE (Interactive Connectivity Establishment), позволяющего обходить «двойной NAT» для голосового трафика. Это обеспечило возможность приема/передачи голоса и видео для пользователей OCS, подключаемых из сети Интернет. Однако, технология предусматривала последовательный опрос нескольких точек подключения, что требует
некоторого времени. Источник вызова не мог начать опрос возможных вариантов соединения до получения сообщения 200 ОК, содержащий вложение SDP со списком возможных способов связи. Как результат, какое-то время в трубке была слышна тишина, а первые сказанные фразы могли потеряться. Исключение составляли вызовы на голосовой шлюз.
Приблизительная схема выглядит так: 
Имеем стандартную схему. Внутренний пользователь, сервер с ролью Front End, Сервер с ролью Edge (условно его можно разделить на Access Edge и Audio/Video Edge), внешний пользователь. 
Попытки соединения для передачи RTP трафика и сам трафик от вызываемого абонента не рассматриваю, так как его можно стартовать сразу после сообщения INVITE, потому что оно уже содержит описание возможностей вызывающего.
В OCS 2007 R2, чтоб избежать такой ситуации была использована одна хитрость, заложенная в RFC 3960, и связанная с обработкой ответов 183 Session in progress.
Ответ 183 Session Progress и RFC
Тут нужно сделать паузу и немного рассказать про ответ 183 Session in progress.
Из RFC 3621, описывающему протокол SIP:
The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress
Никакой конкретики. В реальности, ответ 183 Session progress обычно используется для передачи голоса до установления соединения, Early Media (Например, чтоб проиграть голосовое сообщение или музыку, пока абонент не возьмет трубку). Так вот, если ответ получен, но голосовые пакеты еще не пошли,
то согласно RFC 3960 IP-АТС / голосовому шлюзу рекомендуется передавать КПВ.
Из RFC 3960
With this in mind, a UAC should develop its local policy regarding local ringing generation. For example, a POTS («Plain Old Telephone Service»)-like SIP User Agent (UA) could implement the following local policy:
Как видно, в примере используется ответ 180. Многие понимают эту фразу буквально и не учитывают в настройках другие ответы класса 1XX. Отсюда и ошибки. Но об этом чуть позже.
Реализация Early Media от MS
MS использует ответ 183 Session progress дважды. Первый раз после отправки 100 Trying, просто чтоб показать, что работа в разгаре. Сам не знаю, зачем. Второй раз, когда запрос дошел до конечной точки маршрута. На этот раз уже ответ cодержит SDP. Покажу на примере. На этот раз разберем обмен сообщениями чуть подробнее.
Получаем, что сессия устанавливается еще до того, как абонент поднял трубку. Если одновременно запущен только один клиент Lync, то он и ответит на вызов и в ответе 200 ОК будут те же данные, что и в 183
Session progress. Сессия установлена заранее. Как только получен ответ – голосовой/видео трафик пошел. PROFIT!
Что имеем
Основой для статьи (в части разбора ошибки с КПВ) является серия статей в блоге Криса Нормана, ака voipnorm. Там же вы можете много подробностей сопряжения Lync/OCS с Cisco/Avaya.
Lync и SIP. Объявление медиа-возможностей и ошибка КПВ
Вместо предисловия
Во время Teched Russia 2011 самым задаваемым мне вопросом оказался вопрос про отсутствие длинного гудка при вызове абонента Lync из ТфОП. При этом, все спрашивающие являлись читателями ITBand.RU. Так что, первым делом по возвращении домой с MVP Open Days, я решил перенести уже готовую статью по данной теме из собственного блога (являющегося для меня чем-то вроде инкубатора) сюда. Надеюсь будет полезно.
Урок номер 3
Продолжаем разговор про использование SIP в Lync Server 2010. На этот раз мы разберем SDP пакет, генерируемый Lync при видео-вызове в части предлагаемых способов аудио/видео взаимодействия и ответим на пару вопросов из предыдущей статьи, включая наиболее популярный: про отсутствие гудков при звонке на Lync.
Домашнее задание
Для начала, проверим домашнее задание – посмотрим, какие кодеки использует Lync.
Как и в прошлый раз, я выложил разбор в отдельный PDF.
Разбор ошибки с отсутствие гудков
Во второй части статьи опишу причину наиболее часто возникающей ошибки при настройке Lync Server в качестве АТС. А именно, отсутствие контроля посылки вызовов (КПВ) при поступающих на Lync звонках. Проще говоря, отсутствие гудков.
Идеальная ситуация
Упрощенно, процесс телефонного вызова из ТфОП в IP-телефонию выглядит так:
Сигнал КПВ генерирует голосовой шлюз, непосредственно подключенный к аналоговым/цифровым телефонным линиям. При IP-to-IP вызовах сеть передачей КПВ вообще не нагружается, так как КПВ генерирует сам вызывающий клиент, получив 180 Ringing.
Но это в идеале. Почему же при работе с решением от MS генерация КПВ в некоторых случаях не происходит?Ноги у этой проблемы растут довольно далеко. Все началось в далеком 2007-ом году… (театральная пауза).
Истоки проблемы
В OCS 2007 в Microsoft внедрили поддержку протокола ICE (Interactive Connectivity Establishment), позволяющего обходить «двойной NAT» для голосового трафика. Это обеспечило возможность приема/передачи голоса и видео для пользователей OCS, подключаемых из сети Интернет. Однако, технология предусматривала последовательный опрос нескольких точек подключения, что требует
некоторого времени. Источник вызова не мог начать опрос возможных вариантов соединения до получения сообщения 200 ОК, содержащий вложение SDP со списком возможных способов связи. Как результат, какое-то время в трубке была слышна тишина, а первые сказанные фразы могли потеряться. Исключение составляли вызовы на голосовой шлюз.
Приблизительная схема выглядит так:
Имеем стандартную схему. Внутренний пользователь, сервер с ролью Front End, Сервер с ролью Edge (условно его можно разделить на Access Edge и Audio/Video Edge), внешний пользователь.
Попытки соединения для передачи RTP трафика и сам трафик от вызываемого абонента не рассматриваю, так как его можно стартовать сразу после сообщения INVITE, потому что оно уже содержит описание возможностей вызывающего.
В OCS 2007 R2, чтоб избежать такой ситуации была использована одна хитрость, заложенная в RFC 3960, и связанная с обработкой ответов 183 Session in progress.
Ответ 183 Session Progress и RFC
Тут нужно сделать паузу и немного рассказать про ответ 183 Session in progress.
Из RFC 3621, описывающему протокол SIP:
The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress
Никакой конкретики. В реальности, ответ 183 Session progress обычно используется для передачи голоса до установления соединения, Early Media (Например, чтоб проиграть голосовое сообщение или музыку, пока абонент не возьмет трубку). Так вот, если ответ получен, но голосовые пакеты еще не пошли,
то согласно RFC 3960 IP-АТС / голосовому шлюзу рекомендуется передавать КПВ.
Из RFC 3960
With this in mind, a UAC should develop its local policy regarding local ringing generation. For example, a POTS («Plain Old Telephone Service»)-like SIP User Agent (UA) could implement the following local policy:
Как видно, в примере используется ответ 180. Многие понимают эту фразу буквально и не учитывают в настройках другие ответы класса 1XX. Отсюда и ошибки. Но об этом чуть позже.
Реализация Early Media от MS
MS использует ответ 183 Session progress дважды. Первый раз после отправки 100 Trying, просто чтоб показать, что работа в разгаре. Сам не знаю, зачем. Второй раз, когда запрос дошел до конечной точки маршрута. На этот раз уже ответ cодержит SDP. Покажу на примере. На этот раз разберем обмен сообщениями чуть подробнее.
Получаем, что сессия устанавливается еще до того, как абонент поднял трубку. Если одновременно запущен только один клиент Lync, то он и ответит на вызов и в ответе 200 ОК будут те же данные, что и в 183
Session progress. Сессия установлена заранее. Как только получен ответ – голосовой/видео трафик пошел. PROFIT!
Что имеем
Основой для статьи (в части разбора ошибки с КПВ) является серия статей в блоге Криса Нормана, ака voipnorm. Там же вы можете много подробностей сопряжения Lync/OCS с Cisco/Avaya.
Коды ответа и их значения в протоколe SIP
Коды ответов сервера (коды состояния запроса) в протоколе SIP, согласно RFC2543
Код ответа от сервера (код состояния запроса) состоит из трех цифр и показывает информацию об обработке запроса сервером или оконечным устройством. Рядом с любым кодом, передается поясняющая фраза, краткое текстовое описание, кода ответа. Код ответа необходим для серверов и оконечных устройств, при этом, они не смотрят поясняющие фразы. А поясняющие фразы необходимы лишь для конечных пользователей.
Первая цифра кода состояния запроса определяет класс ответа. Последние две цифры не имеют определенной роли в классификации. Протокол SIP/2.0 определяет 6 значение для первой цифры:
Далее рассмотрим часто встречающиеся коды состояния запросов и поясняющие фразы к ним, используемые в SIP/2.0. Поясняющие фразы- это рекомендация, пользователи могут изменить их, без воздействия на протокол SIP/2.0. Обратите внимание, что много кодов ответов взято из протокола HTTP/1.1. В SIP/2.0 добавлены коды в диапазоне с x80, так же, в отличие от HTTP/1.1, добавлен новый класс кодов 6xx.
Коды ответов SIP являются расширяемыми. SIP приложению не требуется понимать смысл всех зарегистрированных кодов ответа, хотя такое понимание желательно. Тем не менее, приложения ДОЛЖНЫ понимать класс любого кода ответа, как это указано в первой цифре, и обрабатывать любой нераспознанный ответ как эквивалент кода ответа x00 этого класса. Например, если клиент получает незарегистрированный код ответа 431, он может смело предположить, что было что-то не так в его запросе, и должен обработать ответ, как если бы был получен код 400 (Bad Request). В таких случаях агентам пользователя СЛЕДУЕТ представить пользователю тело сообщения, возвращаемого с ответом, так как в теле сообщения, вероятно, включена информация, которая поясняет нестандартный ответ.
Успех выполнения запроса:
Всё о Microsoft UC
Lync и SIP. Объявление медиа-возможностей и ошибка КПВ
Продолжаем разговор про использование SIP в Lync Server 2010. На этот раз мы разберем SDP пакет, генерируемый Lync при видео-вызове в части предлагаемых способов аудио/видео взаимодействия и ответим на пару вопросов из предыдущей статьи, включая наиболее популярный: про отсутствие гудков при звонке на Lync.
Домашнее задание
Для начала, проверим домашнее задание – посмотрим, какие кодеки использует Lync.
Как и в прошлый раз, я выложил разбор в отдельный PDF.
Разбор ошибки с отсутствие гудков
Во второй части статьи опишу причину наиболее часто возникающей ошибки при настройке Lync Server в качестве АТС. А именно, отсутствие контроля посылки вызовов (КПВ) при поступающих на Lync звонках. Проще говоря, отсутствие гудков.
Идеальная ситуация
Упрощенно, процесс телефонного вызова из ТфОП в IP-телефонию выглядит так:
Сигнал КПВ генерирует голосовой шлюз, непосредственно подключенный к аналоговым/цифровым телефонным линиям. При IP-to-IP вызовах сеть передачей КПВ вообще не нагружается, так как КПВ генерирует сам вызывающий клиент, получив 180 Ringing.
Но это в идеале. Почему же при работе с решением от MS генерация КПВ в некоторых случаях не происходит?Ноги у этой проблемы растут довольно далеко. Все началось в далеком 2007-ом году… (театральная пауза).
Истоки проблемы
В OCS 2007 в Microsoft внедрили поддержку протокола ICE (Interactive Connectivity Establishment), позволяющего обходить «двойной NAT» для голосового трафика. Это обеспечило возможность приема/передачи голоса и видео для пользователей OCS, подключаемых из сети Интернет. Однако, технология предусматривала последовательный опрос нескольких точек подключения, что требует некоторого времени. Источник вызова не мог начать опрос возможных вариантов соединения до получения сообщения 200 ОК, содержащий вложение SDP со списком возможных способов связи. Как результат, какое-то время в трубке была слышна тишина, а первые сказанные фразы могли потеряться. Исключение составляли вызовы на голосовой шлюз.
Приблизительная схема выглядит так: 
Имеем стандартную схему. Внутренний пользователь, сервер с ролью Front End, Сервер с ролью Edge (условно его можно разделить на Access Edge и Audio/Video Edge), внешний пользователь. 
Попытки соединения для передачи RTP трафика и сам трафик от вызываемого абонента не рассматриваю, так как его можно стартовать сразу после сообщения INVITE, потому что оно уже содержит описание возможностей вызывающего.
В OCS 2007 R2, чтоб избежать такой ситуации была использована одна хитрость, заложенная в RFC 3960, и связанная с обработкой ответов 183 Session in progress.
Ответ 183 Session Progress и RFC
Тут нужно сделать паузу и немного рассказать про ответ 183 Session in progress.
Из RFC 3621, описывающему протокол SIP:
The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress
Никакой конкретики. В реальности, ответ 183 Session progress обычно используется для передачи голоса до установления соединения, Early Media (Например, чтоб проиграть голосовое сообщение или музыку, пока абонент не возьмет трубку). Так вот, если ответ получен, но голосовые пакеты еще не пошли, то согласно RFC 3960 IP-АТС / голосовому шлюзу рекомендуется передавать КПВ.
Из RFC 3960
With this in mind, a UAC should develop its local policy regarding local ringing generation. For example, a POTS («Plain Old Telephone Service»)-like SIP User Agent (UA) could implement the following local policy:
Как видно, в примере используется ответ 180. Многие понимают эту фразу буквально и не учитывают в настройках другие ответы класса 1XX. Отсюда и ошибки. Но об этом чуть позже.
Реализация Early Media от MS
MS использует ответ 183 Session progress дважды. Первый раз после отправки 100 Trying, просто чтоб показать, что работа в разгаре. Сам не знаю, зачем. Второй раз, когда запрос дошел до конечной точки маршрута. На этот раз уже ответ cодержит SDP.
Покажу на примере. На этот раз разберем обмен сообщениями чуть подробнее.
Получаем, что сессия устанавливается еще до того, как абонент поднял трубку. Если одновременно запущен только один клиент Lync, то он и ответит на вызов и в ответе 200 ОК будут те же данные, что и в 183 Session progress. Сессия установлена заранее. Как только получен ответ – голосовой/видео трафик пошел. PROFIT!
Что имеем
Проблему решили, но, в результате получили новую. 🙂 Идеей загорелись, и ответ 183 Session progress начали передавать даже в сторону голосовых шлюзов/IP-АТС. Однако, как оказалось, ответ 183 Session progress — одна из давних головных болей IP-АТС. Одни IP-АТС перестают отдавать КПВ, получая ответ 183, содержащий SDP, и ждут, когда пойдет голосовой трафик. У других «сносит крышу» от ответа 183, не содержащего SDP. А теперь еще и Microsoft, в продуктах которого традиционно почти нет настроек сопряжения с продуктами «партнеров».
Некоторые производители в очередных обновлениях по просьбам трудящихся добавили корректную обработку 183 Session progress (Например, Avaya). Другие предлагают срезать приходящие ответы 183 от Microsoft (Cisco).
Один из инженеров MS даже написал плагин для OCS 2007 R2, генерирующий КПВ пока не будет установлен настоящий вызов. Но, видимо, это шло вразрез с политикой партии, и в Lync Server данный функционал добавлен не был.
В общем, пока проблема есть и решается индивидуально. Так и живем….
Основой для статьи (в части разбора ошибки с КПВ) является серия статей в блоге Криса Нормана, ака voipnorm. Там же вы можете много подробностей сопряжения Lync/OCS с Cisco/Avaya.