Описание спецификации RFC 3261 (линк цепляется автоматически, это не я)[]

Вступление[]

Протокол SIP (Session Initiation Protocol) описан в документе RFC 3261, (смотри также [6] и The Internet Protocol Journal V6, N1, March 2003, William Stallings, “The Session Initiation Protocol”), и служит для запуска, модификации и завершения сессий реального времени между партнерами IP-сети. SIP может поддерживать как моно так и мультимедийные приложения, включая видеоконференции.

Протокол SIP является лишь одним из протоколов, которые обеспечивают мультимедийный обмен через Интернет. SIP представляет собой сигнальный протокол, который позволяет одному партнеру послать запрос другому и согласовать параметры мультимедиа сессии (см. RFC-2848, -3050, -3261-65, -3311-13, -3319,-3325-3329, -3351, -3398, -3428, -3455, -3485, -3487, -3515, -3666, -3840, -3891-93, -4123, -4354, -4458, -4497, -4504, -4508, -4538, -4575, -4579, -4596, -4662, -4730, -4740, -4780, -4916, -5002, -5009, -5039, -5049, -5079, -5118).

Собственно транспортировка мультимедиа данных обычно осуществляется с помощью протокола RTP (Real-Time Transport Protocol).

Базовым стимулом создания протокола SIP являлась необходимость реализации работы с VoIP (Voice over IP). Протокол поддерживает пять аспектов, сопряженных с установлением и завершением мультимедийных коммуникаций:

Положение пользователя: Пользователи могут менять свое положение и сохранять доступ к телефонии и другим приложениям дистанционно.

Доступность пользователя: Предполагается проверка готовности парнера-адресата участвовать в коммуникациях.

Возможности пользователя: Определяются параметры среды, которые должны быть использованы.

Формирование сессии: Создается соединение точка-точка или сессия с несколькими партнерами при заданных коммуникационных параметрах.

Управление сессией: Предполагается создание и завершение сессий, модификация параметров сессии и сервисов.

SIP базируется на модели транзакций, сходных с запросами/откликами в протоколе HTTP. Каждая транзакция состоит из запроса клиента, который включает в себя определенный метод, или функцию, для сервера и, по крайней мере, один отклик. SIP использует большинство полей заголовков, правил кодирования и коды статуса протокола HTTP. Это позволяет работать с данными легко читаемого и отображаемого формата. SIP использует протокол SDP (Session Description Protocol), который с помощью набора типов данных, используемых в MIME (Multipurpose Internet Mail Extensions), определяет содержимое сессии.

Компоненты и протоколы SIP[]

Система, использующая SIP, может рассматриваться состоящей из клиентов, серверов и индивидуальных сетевых элементов. RFC 3261 определяет клиента и сервер следующим образом:

Клиент: Клиент является субъектом сети, который посылает SIP запросы и получает SIP отклики. Клиенты, если это требуется, могут непосредственно взаимодействовать с человеком. Агент пользователя клиента и прокси являются клиентами

Сервер: Сервер является сетевым элементом, который получает запросы и который должен их обслуживать, посылая отклики. Примерами серверов являются прокси, агенты пользователя серверов, серверы переадресации и регистраторы

Индивидуальные элементы стандартной конфигурации включают в себя:

Агент пользователя: Агент пользователя резидентно присутствует в каждой конечной станции SIP. Он выполняет две роли. Агент пользователя клиента UAC (User Agent Client): Посылает запросы SIP. Агент пользователя сервера UAS (User Agent Server): получает SIP-запросы, генерирует отклики, принимает, отклоняет или перенаправляет запросы

Сервер переадресации: Сервер переадресации используется во время инициализации сессии, чтобы определить адрес запрашиваемого устройства. Сервер переадресации отсылает полученную информацию устройству, инициировавшему запрос, направляя UAC, который может использоваться для контакта с альтернативным URI (Universal Resource Identifier). URI является универсальным идентификатором, используемым для именования любого ресурса в Интернет. URL, используемое для Web адресов имеет тип URI. Подробнее это рассмотрено в RFC 2396 [1].

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

Регистратор: Регистратор является сервером, который принимает запросы REGISTER и помещает информацию, которую он получает (SIP-адрес и ассоциированный IP-адрес регистрирующего устройства) из этих запросов, в службу локализации для домена, который им обслуживается.

Служба локализации: Служба локализации используется серверами переадресации SIP или прокси, чтобы получить информацию о возможном положении источника запроса. Для этой цели служба локализации поддерживает базу данных SIP-адресов/ IP-адресов. В RFC 3261 в качестве логических устройств определены различные серверы. Они могут быть использованы в качестве отдельных серверов в Интернет или они могут объединяться в рамках одного приложения, которое работает резидентно на определенном физическом сервере

На рис. 1 показано, как некоторые SIP компоненты связаны друг с другом и с протоколами, которые они используют. Агент пользователя А использует SIP для установления сессии с другим агентом пользователя B, который выступает в роли сервера. Диалог запуска сессии использует SIP и включает один или более прокси серверов, чтобы переадресовать запросы и отклики между двумя агентами пользователя. Агенты пользователя используют также протокол SDP (Session Description Protocol), который служит для описания медийной сессии.

Прокси серверы могут, если это требуется, работать в качестве серверов переадресации. Система DNS (Domain Name System) является важной частью, реализующей протокол SIP. Обычно, UAC осуществляет запрос, используя доменное имя UAS, а не IP-адрес. Прокси сервер вынужден консультироваться у DNS-сервера, чтобы найти прокси сервер для зоны места назначения.

Из эксплуатационных соображений SIP часто работает поверх UDP (User Datagram Protocol), и обеспечивает свои собственные механизмы обеспечения надежности доставки, но может использовать и TCP. Если необходим безопасный или криптографический транспортный механизм, сообщения SIP могут передаваться посредством протокола TLS (Transport Layer Security).

С протоколом SIP ассоциирован SDP, описанный в RFC 2327 [4]. SIP используется для приглашения одного или более партнеров для участия в сессии, в то время как кодированные SDP тела сообщений содержат информацию о типе медиа данных (например, голос, видео). После того как эта информация отправлена и подтверждена, все участники знают IP-адреса, доступную полосу и тип данных. Затем начинается передача информации, с использованием соответствующего транспортного протокола. Обычно используется RTP. Во время сессии участники, используя сообщения SIP, могут изменить параметры сессии, такие как новые медиа типы или новые участники сессии.

Универсальные локаторы ресурсов SIP[]

Ресурсы в конфигурации SIP идентифицируются URI. Примерами ресурсов могут служить:

Обмен данными в реальном масштабе времени.

Появление многоканального телефонного вызова.

Почтовый ящик системы обмена сообщениями.

Телефонной номер услуг шлюза.

Группа (такая как "группа продаж" или "группа поддержки") в организации.

URI SIP имеют формат, базирующийся на формате адресов e-mail, в частности user@domain. Существует две общие схемы. Обычные URI имеют форму: sip:ааа@itep.com

URI могут также включать пароль, номер порта, и сопряженные параметры. Если требуется безопасная передача, sip: заменяется на sips:. В последнем случае сообщения SIP передаются с привлечением протокола TLS.

Примеры работы[]

Спецификация SIP достаточно сложна; главный документ, RFC 3261, содержит 269 страниц. Для пояснения работы протокола рассмотрим несколько примеров.

На рис. 10.35 показана успешная попытка пользователя А установить сессию с пользователем B, чье URI bbb@itep.com. [9] UAC А сконфигурирован для работы с прокси сервером (выходной сервер) в своем домене и начинает работу с посылки сообщения INVITE прокси серверу, которое указывает на намерение подключить к сессии UAS (1); сервер подтверждает получение запроса (2). Хотя UAS B определяется его URI, выходной прокси сервер должен учесть возможность того, что B в данный момент не доступен или что B поменял адрес. Соответственно, выходной прокси сервер должен переадресовать запрос INVITE прокси серверу, который ответственен за домен itep.com. Выходной прокси сервер, таким образом, консультируется с локальным серером DNS, чтобы получить IP-адрес прокси сервера itep.com (3), путем запроса ресурсной записи DNS SRV, которая содержит информацию о прокси для домена itep.com.

DNS-сервер откликается (4) отправкой IP-адреса прокси сервера itep.com. Прокси сервер А может теперь переадресовать сообщение INVITE выходному прокси серверу (5), который посылает подтверждение сообщения (6). Входной прокси сервер теперь консультируется с сервером локализации для определения адреса B (7), а сервер локализации откликается посылкой адреса B, что позволяет послать ему сообщение SIP (8)..

Прокси сервер может теперь послать сообщение INVITE B (9). Посылается отклик от B к А (10, 11, 12), в то время как UAS B обращается к локальному медийному приложению (например, телефонии). Когда медиа приложение воспринимает вызов, UAS B посылает отклик OK А (13, 14, 15)..

Наконец, UAC А посылает сообщение подтверждения UAS B, чтобы подтвердить получения окончательного отклика (16). В этом примере, ACK посылается непосредственно от А к B, обходя два прокси. Это происходит потому, что конечные точки уже знают адрес своего партнера из обмена INVITE/200 (OK). Медиа сессия началась, А и B могут обмениваться данными через одно или более RTP-соединения..

В следующем примере (рис. 10.36) используется два типа сообщений, которые пока еще не входят в стандарт SIP, но которые описаны в документе RFC 2848 [5] и которые вероятно будут включены в последующие версии SIP. Эти типы сообщений поддерживают телефонные приложения. Предположим, что в предыдущем примере А была проинформирована о том, что B не доступен. UAC А может выдать сообщение SUBSCRIBE (1), указывающее, что он хочет быть проинформирован, когда B будет доступен..

Этот запрос будет переадресован в нашем случае через два прокси к серверу PINT (Public Switched Telephone Network [PSTN]-Internet Networking – общедоступную коммутируемую телефонную сеть) (2, 3). Сервер PINT работает как шлюз между IP-сетью, из которой пришел запрос установить телефонное соединение, и телефонной сетью, которая осуществляет соединение с адресатом. В этом примере, мы предполагаем, что логика сервера PINT совмещена со службой локализации. Может также случиться, что B подключен к Интернет, а не к PSTN, в этом варианте нужна система, эквивалентная логике PINT, чтобы обрабатывать запросы SUBSCRIBE. В этом примере, мы предполагаем, что функциональность PINT встроена в службу локализации. Служба локализации авторизует подписку, прислав сообщение OK (4), которое передается А (5, 6). Служба локализации, затем немедленно посылает сообщение NOTIFY с текущим статусом B (7, 8, 9), которое подтверждается UAC А (10, 11, 12)..

На рис. 10.37 показано продолжение обмена. B подключается к системе локализации, послав сообщение REGISTER прокси серверу своего домена (1). Прокси обновляет базу данных службы локализации, отражая факт регистрации (2). Обновление подтверждается прокси (3), что подтверждает регистрацию B (4). PINT воспринимает новый статус B от сервера локализации и посылает сообщение NOTIFY, содержащее новый статус B (5). Это сообщение переадресуется А (6, 7). UAC А подтверждает получение уведомления (8, 9, 10)..

Как было замечено, SIP является протоколом, базирующемся на текстах, с синтаксисом, сходным с HTTP. Существует два разных типа SIP сообщений, запросы и отклики. Различие форматов этих сообщений проявляется в первой строке. Первая строка запроса содержит метод, определяющий природу запроса, и URI запроса, указывающий, куда следует послать запрос. Первая строка отклика содержит код отклика. Все сообщения имеют заголовок, состоящий из нескольких строк, каждая строка начинается с метки заголовка. Сообщение может содержать в себе описание транспортируемых данных SDP. Для запросов SIP RFC 3261 определяет следующие методы:

REGISTER (регистр): Используется агентом пользователя, чтобы проинформировать конфигурацию SIP о своем текущем IP адресе и URL, для которого желательно получать вызовы.

INVITE (приглашение): Используется, чтобы установит медийную сессию между агентами пользователей.

ACK: Подтверждает надежную доставку сообщения.

CANCEL (аннулирование): Прерывает обслуживание незавершенного запроса, но не изменяет статуса завершенных вызовов.

BYE: Завершает сессию между двумя пользователями.

OPTIONS (опции): Запрашивает информацию об источнике запроса, но не реализует сам запрос

Например, заголовок сообщения (1) на рис. 6.2 может выглядеть следующим образом:

INVITE sip:bbb@ itep.com SIP/2.0

Via: SIP/2.0/UDP 12.26.17.91:5060

Max-Forwards: 70

To: B <sip:bbb@ itep.com

From: A <sip:aaa@iae.com;tag=1928301774

Call-ID: a84b4c76e66710@12.26.17.91

CSeq: 314159 INVITE

Contact: <sip:aaa@iae.com>

Content-Type: application/sdp

Content-Length: 142

Первая строка содержит название метода (INVITE), SIP URI, номер используемой версии протокола SIP. Последующие строки представляют собой список полей заголовка. В данном примере представлен минимально необходимый набор.

Заголовки Via показывают путь запроса через конфигурацию SIP (отправитель и промежуточные прокси), и используются при передаче по тому же маршруту откликов. Когда посылается сообщение INVITE, оно имеет только заголовок, вставленный А. Строка содержит IP адрес (12.26.17.91), номер порта (5060), и транспортный протокол (UDP), которые B должен использовать в отклике.

Заголовок Max-Forwards ограничивает число шагов, которые запрос может сделать до точки назначения. Содержимое этого поля является целым числом, которое декрементируется на 1 каждым прокси, переадресующим запрос. Если значение Max-Forwards станет равным 0, прежде чем запрос достигнет места назначения, он отвергается с кодом ошибки в отклике равным 483 (Too Many Hops – слишком много шагов).

Поле заголовка To содержит имя (B) и URI SIP или SIPS (sip:bbb@ itep.com), которому первоначально предназначался запрос. Поле заголовка From также содержит имя (A) и URI SIP или SIPS (sip:aaa@iae.com), которое указывает на отправителя запроса. Это поле заголовка имеет также свободный параметр, который содержит произвольную строку (1928301774), которая добавляется к URI UAC. Она используется для идентификации сессии.

Поле заголовка Call-ID содержит глобально уникальный идентификатор данного вызова, генерируемый из комбинации псевдослучайной строки и имени ЭВМ или IP-адреса. Комбинация тэгов To, From и Call-ID полностью определяет отношение SIP партнеров А и B.

CSeq или поле заголовка Command Sequence содержит целое число и имя метода. Число CSeq инициализируется в начале вызова (в данном примере 314159), инкрементируется для каждого нового запроса в рамках диалога, и является традиционным порядковым номером. CSeq используется, чтобы отличить повторную передачу от нового запроса. Поле заголовка Contact содержит SIP URI для непосредственной коммуникации между агентами пользователя. Несмотря на то, что поле заголовка Via говорит другим элементам, куда следует посылать отклик, поле заголовка Contact сообщает другим элементам, куда посылать будущие запросы для заданного диалога. Поле заголовка Content-Type указывает на тип тела сообщения. Поле заголовка Content-Length содержит длину тела сообщения в октетах.

Типы откликов SIP, определенных в RFC 3261 имеют следующие категории:

Условный (переходной 1xx): Запрос получен и обрабатывается.

Успех (2xx): Задание успешно получено, понято и воспринято.

Перенаправление (3xx): Нужны дальнейшие действия, чтобы завершить реализацию запроса.

Ошибка клиента (4xx): Запрос содержит некорректный синтаксис или не может быть обслужен сервером.

Ошибка сервера (5xx): Сервер не смог выполнить заведомо корректный запрос.

Глобальный отказ (Global Failure: 6xx): Запрос не может быть выполнен любым сервером

Например, заголовок сообщения (13) на рис. 6.2 может выглядеть следующим образом:

SIP/2.0 200 OK

Via: SIP/2.0/UDP server10.itep.com

Via: SIP/2.0/UDP bgb3.site3.iae.com

Via: SIP/2.0/UDP 12.26.17.91:5060

To: B <sip:bbb@itep.com;tag=a6c85cf

From: A <sip:aaa@iae.com;tag=1928301774

Call-ID: a84b4c76e66710@12.26.17.91

CSeq: 314159 INVITE

Contact: <sip:bbb@itep.com>

Content-Type: application/sdp

Content-Length: 131

Первая строка содержит номер версии SIP, которая используется, код отклика и имя. Последующие строки представляют собой список полей заголовка. Поля заголовка Via, To, From, Call-ID и CSeq копируются из запроса INVITE. (Существует три значения поля заголовка Via — одно связано с UAC А, другое введено прокси iae.com proxy, и одно добавлено прокси itep.com). Телефонный номер B добавлен в тэг параметра поля заголовка To. Этот тэг вводится обеими сторонами диалога и включается во все будущие запросы в рамках заданного вызова.

Протокол описания сессии[]

Протокол SDP (Session Description Protocol), определенный в RFC 2327, описывает содержимое сессий, включая телефонию, Интернет радио, приложения мультимедиа. SDP содержит информацию о [8]:

Медиа потоках: Сессия может реализовывать несколько потоков данных. В протоколе SDP в настоящее время определены аудио, видео, данные, управление и приложения (поточные), сходные с MIME типами электронной почты в Интернет.

Адресах: SDP указывает адреса места назначения, которые могут быть для медиа потоков мультикастинг-адресами.

Портах: Для каждого потока специфицируются номера UDP портов для отправителя и получателя.

Типах данных: Для каждого используемого типа потока (например, телефония), тип поля данных указывает на медиа форматы, которые могут использоваться во время сессии.

Времене старта и остановки: Эти данные используются в случае широковещательных сессий, например, телевизионных или радио программ. Указываются время начала, завершения и времена повторов сессии.

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

Несмотря на то, что SDP предоставляет возможность описания мультимедиа данных, здесь нахватает механизмов согласования параметров сессии, которые намерены использовать партнеры. Документ RFC 3264 [7] предоставляет модель согласования на основе механизма предложения/отклика, в которой партнеры обмениваются SDP сообщениями с целью достичь согласия относительно природы данных, подлежащих пересылке. Одним из применений протокола SIP является организация сессий передачи голоса по каналам Интернет (VoIP).

Сообщения[]

метод INVITE[]

Если у клиента пользователя возникает желание инициировать сеанс связи (например, передачи речи, видео или для игр), он формирует запрос INVITE. Запрос INVITE запрашивает установление сеанса связи с сервером. Этот запрос может быть переслан при помощи SIP прокси сервера и, в итоге, достигнет одного или нескольких SIP клиентов: UAS?, которые, в принципе, могут подтвердить установку этого сеанса. Этим, вызываемым клиентам (UAS), часто требуется запросить у своего пользователя разрешения на подтверждение поступающего запроса на установку сеанса связи. Через некоторое время, данные клиенты (UAS), могут подтвердить запрос на инициацию сеанса (это подразумевает, что сеанс связи будет установлен), отправив ответ с кодом из диапазона 2xx.

Если приглашение установить сеанс связи не подтверждается удаленным абонентом, то будет отправлен ответ с кодом 3xx, 4xx, 5xx или 6xx, в зависимости от причины, по которой было отказано. Перед отправкой окончательного ответа, вызываемые клиенты (UAS) могут отправить предварительные ответы (1xx) для извещения вызывающего клиента UAC?, что производятся попытки вызвать вызываемого пользователя.

метод re-INVITE[]

...Эта модификация позволяет менять адреса или порты сеансов, может добавлять поток медиаданных, удалять поток медиаданных, и т.д. Это достигается отправкой нового запроса INVITE, в пределах диалога уже установленного сеанса связи. Запрос INVITE, который отправлен для уже установленного сеанса связи, называется методом re-INVITE.

Обратите внимание: что один запрос re-INVITE может модифицировать параметры диалога и параметры сеанса одновременно.

метод REGISTER[]

Регистрация влечет за собой отправку запроса REGISTER клиенту UAS? специального типа, который так же известен как сервер SIP регистрации. Этот сервер выступает в роли front end сервиса поиска абонентов в домене, считывает и записывает карту для маршрутизации вызовов, основываясь на данных запроса REGISTER. Эта задача поиска вызываемого абонента обычно возлагается на proxy сервер, который отвечает за маршрутизацию вызовов в пределах своего домена.

метод CANCEL[]

Запрос CANCEL, как и следует из его названия, используется для отмены предыдущего запроса, отправленного клиентом. Если быть более точным, то он спрашивает у клиента (UA) по возможности прекратить обработку предыдущего запроса и сгенерировать на него ответ с ошибкой выполнения. Запрос CANCEL не производит никакого эффекта, если на запрос, отправленный клиенту (UAS), уже был получен окончательный ответ о его выполнении.

По этой причине, CANCEL в основном используется для отмены запросов, требующих довольно длительное время на их обработку. По этой же причине, CANCEL является наилучшим вариантом для отмены запроса INVITE, которому нужно длительное время на формирование ответа. В таком варианте использования, клиент (UA), который получает запрос CANCEL на предыдущий INVITE (на который еще не был получен окончательный ответ), делает следующее: перестает "звонить" и после этого отвечает на запрос INVITE, сообщением со специальным кодом ошибки (487).

метод ACK[]

SIP описывает трехшаговую систему установки соединения:

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

Если в первом сообщении INVITE включает тело с описанием параметров вызова в SDP, тогда в первое сообщение ACK включаются SDP поля вызываемого абонента.

Если в первом сообщении INVITE не включено тело, содержащее SDP сообщение, тогда первое сообщение ACK будет содержать SDP сообщение вызываемого абонента. Другая сторона соединения, которая может и не быть источником вызова, отправит сообщение ACK для завершения процесса установления соединения, которое будет содержать нужные поля в SDP для установки этого соединения.

метод PRACK[]

Метод PRACK определен в RFC 3262: Надежность Предварительных Ответов на полученные запросы в Протоколе Инициирования Сеанса (SIP).

Запрос PRACK играет ту же роль, что и ACK, но предназначен для предварительных ответов. Однако, это очень важное отличие. PRACK - является обычным SIP сообщением, как BYE. По существу, это сообщение гарантирует надежность передачи изменений состояний через каждый прокси сервер, на пути сеанса. Также как и сообщение BYE, но в отличие от ACK, сообщение PRACK имеет свой ответ на запрос. Вследствие этого, в этом случае, сообщение PRACK не может проследовать через прокси сервера, поддерживающие RFC 2543.

метод BYE[]

Запрос BYE используется для завершения указанного сеанса связи или для завершения попытки установить сеанс связи. В этом случае, указанный сеанс - это один из тех диалогов, который установлен между клиентом (UA) и удаленной стороной. Если в процессе диалога будет получен запрос BYE, все сеансы, связанные с этим диалогом, ДОЛЖНЫ БЫТЬ ЗАВЕРШЕНЫ. Клиент (UA) НЕ ДОЛЖЕН отправлять запросы BYE, если он не находиться в режиме диалога с удаленным клиентом. Вызывающий клиент (UA) МОЖЕТ отправлять запросы BYE, как для уже подтвержденных, так и для еще только инициируемых диалогов, а вызываемые клиенты (UA) МОГУТ отправлять сообщение BYE только для уже подтвержденного диалога, но НЕ МОГУТ отправлять это сообщение на стадии инициации диалога.

метод OPTIONS[]

Метод SIP протокола ``OPTIONS`` позволяет пользователям (UA) отправлять запросы другим пользователям (UA) или прокси серверам, для проверки совместимости с ними. Это позволяет клиенту получить информацию о том, какие методы поддерживает удаленный клиент, поддерживаемые "content types", расширения, кодеки, и т.д., без необходимости совершения вызова этого удаленного абонента.

Например, перед тем как заполнить поле заголовка "Require" в сообщении INVITE, списком параметров, в которых нет уверенности, что устройство назначения (UA) их поддерживает. Клиент может послать запрос OPTIONS этому устройству, для того, чтобы увидеть, есть ли те параметры, что мы хотим поместить в поле "Require" сообщения INVITE, в возвращенном поле "Supported", в ответе на наш запрос OPTIONS.

Все пользователи (UA) ДОЛЖНЫ поддерживать метод OPTIONS.

Сигнальные сообщения[]

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 - пользователь временно сменил местоположение

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 Expired Authorization - время регистрации истекло

SIP/2.0 402 Payment Required - требуется оплата (зарезервирован для использования в будущем)

SIP/2.0 403 No Such User - нет такого пользователя, ошибка в номере, логине или пароле

SIP/2.0 403 User Disabled - пользователь отключен

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 408 Request Timeout - время обработки запроса истекло: Абонента не удалось найти за отведенное время

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 - временно недоступное направление попробуйте позвонить позже

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 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 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 - соединение с сервером было установлено, но отдельные параметры, такие как тип запрашиваемой информации, полоса пропускания, вид адресации не доступны

Примеры[]

Регистрация линии[]

Первое сообщение "REGISTER" от пользователя к серверу. Максимальное количество "hop'ов", допустимое, при путешествии сообщения: "Max-Forwards: 70".

U 10.206.3.100:5060 -> 195.239.253.4:5060

REGISTER sip:195.239.253.4 SIP/2.0.
Via: SIP/2.0/UDP 10.206.3.100;branch=z9hG4bKac1612199523.
Max-Forwards: 70.
From: <sip:c3_d100_ln2@195.239.253.4;user=phone>;tag=1c1612087025.
To: <sip:c3_d100_ln2@195.239.253.4;user=phone>.
Call-ID: 16113805012932000193413@10.206.3.100.
CSeq: 2 REGISTER.
Authorization: Digest username="c3_d100_ln2",realm="sip1.gldn.net",nonce="65568485",uri="sip:195.239.253.4",algorithm=MD5,response="fdf1e61036eca7e4e6b64c420b577104".
Contact: <sip:c3_d100_ln2@10.206.3.100;user=phone>;expires=3600.
Supported: em,timer,replaces,path,resource-priority.
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE.
Expires: 3600.
User-Agent: Audiocodes-Sip-Gateway-MP-124 FXS/v.5.00A.024.
Content-Length: 0.
.

#

Ответное сообщение от сервера "100 Trying", информирующее клиента, что сообщение в процессе обработки, но на пути встретилось еще оборудование обрабатывающее траффик. Тот самый "hop".

U 195.239.253.4:5060 -> 10.206.3.100:5060

SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 10.206.3.100;branch=z9hG4bKac1612199523;received=10.206.3.100.
From: <sip:c3_d100_ln2@195.239.253.4;user=phone>;tag=1c1612087025.
To: <sip:c3_d100_ln2@195.239.253.4;user=phone>.
Call-ID: 16113805012932000193413@10.206.3.100.
CSeq: 2 REGISTER.
User-Agent: Beeline B2B.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces.
Content-Length: 0.
.

#

Ответное сообщение от сервера "OK", регистрация прошла успешно.

U 195.239.253.4:5060 -> 10.206.3.100:5060

SIP/2.0 200 OK.
Via: SIP/2.0/UDP 10.206.3.100;branch=z9hG4bKac1612199523;received=10.206.3.100.
From: <sip:c3_d100_ln2@195.239.253.4;user=phone>;tag=1c1612087025.
To: <sip:c3_d100_ln2@195.239.253.4;user=phone>;tag=as51c97378.
Call-ID: 16113805012932000193413@10.206.3.100.
CSeq: 2 REGISTER.
User-Agent: Beeline B2B.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces.
Expires: 3600.
Contact: <sip:c3_d100_ln2@10.206.3.100;user=phone>;expires=3600.
Date: Thu, 02 Feb 2012 09:21:21 GMT.
Content-Length: 0.
.

#

Неудачная регистрация линии[]

U 10.206.3.100:5060 -> 195.239.253.4:5060

REGISTER sip:195.239.253.4 SIP/2.0.
Via: SIP/2.0/UDP 10.206.3.100;branch=z9hG4bKac321251647.
Max-Forwards: 70.
From: <sip:c3_d100_ln1@195.239.253.4;user=phone>;tag=1c321248357.
To: <sip:c3_d100_ln1@195.239.253.4;user=phone>.
Call-ID: 3205001202932000211130@10.206.3.100.
CSeq: 1 REGISTER.
Contact: <sip:c3_d100_ln1@10.206.3.100;user=phone>;expires=3600.
Supported: em,timer,replaces,path,resource-priority.
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE.
Expires: 3600.
User-Agent: Audiocodes-Sip-Gateway-MP-124 FXS/v.5.00A.024.
Content-Length: 0.
.

#

U 195.239.253.4:5060 -> 10.206.3.100:5060
SIP/2.0 404 Not found.
Via: SIP/2.0/UDP 10.206.3.100;branch=z9hG4bKac321251647;received=10.206.3.100.
From: <sip:c3_d100_ln1@195.239.253.4;user=phone>;tag=1c321248357.
To: <sip:c3_d100_ln1@195.239.253.4;user=phone>;tag=as624a0a0f.
Call-ID: 3205001202932000211130@10.206.3.100.
CSeq: 1 REGISTER.
User-Agent: Beeline B2B.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces.
Content-Length: 0.
.

Отбой по занято[]

Входящий "INVITE" от "4959613186" на "sip:c3_d248_ln1@10.206.3.248"

U 195.239.253.4:5060 -> 10.206.3.248:5060

INVITE sip:c3_d248_ln1@10.206.3.248 SIP/2.0.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK32d968c9;rport.
From: "4959613186" <sip:4959613186@195.239.253.4>;tag=as20cb6320.
To: <sip:c3_d248_ln1@10.206.3.248>.
Contact: <sip:4959613186@195.239.253.4>.
Call-ID: 3be895a6636ebf1d68fc1a6812da0e45@195.239.253.4.
CSeq: 102 INVITE.
User-Agent: Beeline B2B.
Max-Forwards: 70.
Date: Fri, 03 Feb 2012 11:54:04 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces.
Content-Type: application/sdp.
Content-Length: 242.
.
v=0.
o=root 27483 27483 IN IP4 195.239.253.4.
s=session.
c=IN IP4 195.239.253.4.
t=0 0.
m=audio 10754 RTP/AVP 8 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

#

Ответный "Trying" - запрос в процессе обработки.

U 10.206.3.248:5060 -> 195.239.253.4:5060

SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK32d968c9;rport.
From: "4959613186" <sip:4959613186@195.239.253.4>;tag=as20cb6320.
To: <sip:c3_d248_ln1@10.206.3.248>;tag=1c1117285468.
Call-ID: 3be895a6636ebf1d68fc1a6812da0e45@195.239.253.4.
CSeq: 102 INVITE.
Supported: em,timer,replaces,path,resource-priority.
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE.
Server: Audiocodes-Sip-Gateway-MP-114 FXS/v.5.00A.024.
Content-Length: 0.
.

#

Ответный "Busy Here"

U 10.206.3.248:5060 -> 195.239.253.4:5060

SIP/2.0 486 Busy Here.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK32d968c9;rport.
From: "4959613186" <sip:4959613186@195.239.253.4>;tag=as20cb6320.
To: <sip:c3_d248_ln1@10.206.3.248>;tag=1c1117285468.
Call-ID: 3be895a6636ebf1d68fc1a6812da0e45@195.239.253.4.
CSeq: 102 INVITE.
Supported: em,timer,replaces,path,resource-priority.
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE.
Server: Audiocodes-Sip-Gateway-MP-114 FXS/v.5.00A.024.
Reason: Q.850 ;cause=17.
Content-Length: 0.
.

#

Входящее подтверждение "ACK" об успешном прохождении сообщений.

U 195.239.253.4:5060 -> 10.206.3.248:5060

ACK sip:c3_d248_ln1@10.206.3.248 SIP/2.0.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK32d968c9;rport.
From: "4959613186" <sip:4959613186@195.239.253.4>;tag=as20cb6320.
To: <sip:c3_d248_ln1@10.206.3.248>;tag=1c1117285468.
Contact: <sip:4959613186@195.239.253.4>.
Call-ID: 3be895a6636ebf1d68fc1a6812da0e45@195.239.253.4.
CSeq: 102 ACK.
User-Agent: Beeline B2B.
Max-Forwards: 70.
Content-Length: 0.
.

#

Успешный разговор[]

Входящий "INVITE" From: "4955764054" To: <sip:c3_d248_ln1@10.206.3.248>

U 195.239.253.4:5060 -> 10.206.3.248:5060

INVITE sip:c3_d248_ln1@10.206.3.248 SIP/2.0.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK27e05cb0;rport.
From: "4955764054" <sip:4955764054@195.239.253.4>;tag=as319fbddb.
To: <sip:c3_d248_ln1@10.206.3.248>;tag=1c164897441.
Contact: <sip:4955764054@195.239.253.4>.
Call-ID: 7c780e7560c217d06f84bf2653a402ef@195.239.253.4.
CSeq: 104 INVITE.
User-Agent: Beeline B2B.
Max-Forwards: 70.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces.
Content-Type: application/sdp.
Content-Length: 242.
.
v=0.
o=root 27483 27485 IN IP4 195.239.253.4.
s=session.
c=IN IP4 195.239.253.4.
t=0 0.
m=audio 13388 RTP/AVP 8 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

#

Ответный "ОК" на "INVITE"

U 10.206.3.248:5060 -> 195.239.253.4:5060

SIP/2.0 200 OK.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK27e05cb0;rport.
From: "4955764054" <sip:4955764054@195.239.253.4>;tag=as319fbddb.
To: <sip:c3_d248_ln1@10.206.3.248>;tag=1c164897441.
Call-ID: 7c780e7560c217d06f84bf2653a402ef@195.239.253.4.
CSeq: 104 INVITE.
Contact: <sip:c3_d248_ln1@10.206.3.248>.
Supported: em,timer,replaces,path,resource-priority.
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE.
Server: Audiocodes-Sip-Gateway-MP-114 FXS/v.5.00A.024.
Content-Type: application/sdp.
Content-Length: 264.
.
v=0.
o=AudiocodesGW 164920670 164920554 IN IP4 10.206.3.248.
s=Phone-Call.
c=IN IP4 10.206.3.248.
t=0 0.
m=audio 6000 RTP/AVP 8 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:20.
a=sendrecv.
a=rtcp:6001 IN IP4 10.206.3.248.

#

Входящее подтверждение об успешной доствке ответа на "INVITE", оно же "Гнусное трололо" ибо данное сообщение имеет несколько значений.

U 195.239.253.4:5060 -> 10.206.3.248:5060

ACK sip:c3_d248_ln1@10.206.3.248 SIP/2.0.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK64695375;rport.
From: "4955764054" <sip:4955764054@195.239.253.4>;tag=as319fbddb.
To: <sip:c3_d248_ln1@10.206.3.248>;tag=1c164897441.
Contact: <sip:4955764054@195.239.253.4>.
Call-ID: 7c780e7560c217d06f84bf2653a402ef@195.239.253.4.
CSeq: 104 ACK.
User-Agent: Beeline B2B.
Max-Forwards: 70.
Content-Length: 0.
.

#

"BYE" с нормальной причиной

U 195.239.253.4:5060 -> 10.206.3.248:5060

BYE sip:c3_d248_ln1@10.206.3.248 SIP/2.0.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK1b33ea8d;rport.
From: "4955764054" <sip:4955764054@195.239.253.4>;tag=as319fbddb.
To: <sip:c3_d248_ln1@10.206.3.248>;tag=1c164897441.
Call-ID: 7c780e7560c217d06f84bf2653a402ef@195.239.253.4.
CSeq: 105 BYE.
User-Agent: Beeline B2B.
Max-Forwards: 70.
X-Asterisk-HangupCause: Normal Clearing.
X-Asterisk-HangupCauseCode: 16.
Content-Length: 0.
.

#

Ответный "ОК" на "BYE"

U 10.206.3.248:5060 -> 195.239.253.4:5060

SIP/2.0 200 OK.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK1b33ea8d;rport.
From: "4955764054" <sip:4955764054@195.239.253.4>;tag=as319fbddb.
To: <sip:c3_d248_ln1@10.206.3.248>;tag=1c164897441.
Call-ID: 7c780e7560c217d06f84bf2653a402ef@195.239.253.4.
CSeq: 105 BYE.
Contact: <sip:c3_d248_ln1@10.206.3.248>.
Supported: em,timer,replaces,path,resource-priority.
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE.
Server: Audiocodes-Sip-Gateway-MP-114 FXS/v.5.00A.024.
Content-Length: 0.
.

#

А звонит В, слушет 1 кпв и отменяет вызов не дождавшись ответа[]

Входящий "INVITE" от "4959613186" к "sip:c3_d248_ln1".

U 2012/02/07 13:31:15.074121 195.239.253.4:5060 -> 10.206.3.248:5060

INVITE sip:c3_d248_ln1@10.206.3.248 SIP/2.0.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK61c7d9b7;rport.
From: "4959613186" <sip:4959613186@195.239.253.4>;tag=as5f73b36f.
To: <sip:c3_d248_ln1@10.206.3.248>.
Contact: <sip:4959613186@195.239.253.4>.
Call-ID: 14848c0a31a45fee014745f85fb39cae@195.239.253.4.
CSeq: 102 INVITE.
User-Agent: Beeline B2B.
Max-Forwards: 70.
Date: Tue, 07 Feb 2012 09:31:15 GMT.
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
Supported: replaces.
Content-Type: application/sdp.
Content-Length: 242.
.
v=0.
o=root 27483 27483 IN IP4 195.239.253.4.
s=session.
c=IN IP4 195.239.253.4.
t=0 0.
m=audio 12538 RTP/AVP 8 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=silenceSupp:off - - - -.
a=ptime:20.
a=sendrecv.

#

Ответный "Trying" на "INVITE" - запрос в процессе обработки.

U 2012/02/07 13:31:15.131666 10.206.3.248:5060 -> 195.239.253.4:5060

SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK61c7d9b7;rport.
From: "4959613186" <sip:4959613186@195.239.253.4>;tag=as5f73b36f.
To: <sip:c3_d248_ln1@10.206.3.248>;tag=1c1041564518.
Call-ID: 14848c0a31a45fee014745f85fb39cae@195.239.253.4.
CSeq: 102 INVITE.
Supported: em,timer,replaces,path,resource-priority.
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE.
Server: Audiocodes-Sip-Gateway-MP-114 FXS/v.5.00A.024.
Content-Length: 0.
.

#

Ответ на "INVITE" с указанием параметров соединения (кодеки, тип вызова.).

U 2012/02/07 13:31:15.157696 10.206.3.248:5060 -> 195.239.253.4:5060

SIP/2.0 183 Session Progress.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK61c7d9b7;rport.
From: "4959613186" <sip:4959613186@195.239.253.4>;tag=as5f73b36f.
To: <sip:c3_d248_ln1@10.206.3.248>;tag=1c1041564518.
Call-ID: 14848c0a31a45fee014745f85fb39cae@195.239.253.4.
CSeq: 102 INVITE.
Contact: <sip:c3_d248_ln1@10.206.3.248>.
Supported: em,timer,replaces,path,resource-priority.
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE.
Server: Audiocodes-Sip-Gateway-MP-114 FXS/v.5.00A.024.
Content-Type: application/sdp.
Content-Length: 266.
.
v=0.
o=AudiocodesGW 1041587142 1041587022 IN IP4 10.206.3.248.
s=Phone-Call.
c=IN IP4 10.206.3.248.
t=0 0.
m=audio 6000 RTP/AVP 8 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-15.
a=ptime:20.
a=sendrecv.
a=rtcp:6001 IN IP4 10.206.3.248.

#

Входящий "CANCEL".

U 2012/02/07 13:31:17.996499 195.239.253.4:5060 -> 10.206.3.248:5060

CANCEL sip:c3_d248_ln1@10.206.3.248 SIP/2.0.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK61c7d9b7;rport.
From: "4959613186" <sip:4959613186@195.239.253.4>;tag=as5f73b36f.
To: <sip:c3_d248_ln1@10.206.3.248>.
Call-ID: 14848c0a31a45fee014745f85fb39cae@195.239.253.4.
CSeq: 102 CANCEL.
User-Agent: Beeline B2B.
Max-Forwards: 70.
Content-Length: 0.
.

#

Ответный "Request Terminated" на "INVITE", потому что был "CANCEL".

U 2012/02/07 13:31:18.044675 10.206.3.248:5060 -> 195.239.253.4:5060

SIP/2.0 487 Request Terminated.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK61c7d9b7;rport.
From: "4959613186" <sip:4959613186@195.239.253.4>;tag=as5f73b36f.
To: <sip:c3_d248_ln1@10.206.3.248>;tag=1c1041564518.
Call-ID: 14848c0a31a45fee014745f85fb39cae@195.239.253.4.
CSeq: 102 INVITE.
Supported: em,timer,replaces,path,resource-priority.
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE.
Server: Audiocodes-Sip-Gateway-MP-114 FXS/v.5.00A.024.
Reason: SIP ;cause=487 ;text="487 Request Terminated".
Content-Length: 0.
.

#

Входящее сообщение о корректной доставке всех сигнальных сообщений.

U 2012/02/07 13:31:18.044798 195.239.253.4:5060 -> 10.206.3.248:5060

ACK sip:c3_d248_ln1@10.206.3.248 SIP/2.0.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK61c7d9b7;rport.
From: "4959613186" <sip:4959613186@195.239.253.4>;tag=as5f73b36f.
To: <sip:c3_d248_ln1@10.206.3.248>;tag=1c1041564518.
Contact: <sip:4959613186@195.239.253.4>.
Call-ID: 14848c0a31a45fee014745f85fb39cae@195.239.253.4.
CSeq: 102 ACK.
User-Agent: Beeline B2B.
Max-Forwards: 70.
Content-Length: 0.
.

#

Ответный "OK" на входящий "CANCEL".

U 2012/02/07 13:31:18.051712 10.206.3.248:5060 -> 195.239.253.4:5060

SIP/2.0 200 OK.
Via: SIP/2.0/UDP 195.239.253.4:5060;branch=z9hG4bK61c7d9b7;rport.
From: "4959613186" <sip:4959613186@195.239.253.4>;tag=as5f73b36f.
To: <sip:c3_d248_ln1@10.206.3.248>;tag=1c1041564518.
Call-ID: 14848c0a31a45fee014745f85fb39cae@195.239.253.4.
CSeq: 102 CANCEL.
Contact: <sip:c3_d248_ln1@10.206.3.248>.
Supported: em,timer,replaces,path,resource-priority.
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE.
Server: Audiocodes-Sip-Gateway-MP-114 FXS/v.5.00A.024.
Content-Length: 0.
.

#

2[]

->INVITE

17d:6h:34m:18s INVITE sip:2211751@10.208.22.84:5060;user=phone SIP/2.0
Accept: application/sdp
Allow: INVITE,ACK,CANCEL,BYE,INFO,PRACK,UPDATE,OPTIONS,REGISTER,REFER,SUBSCRIBE
Call-ID: njd8s-snc0h@10.208.22.18
Contact: "84957871049" <sip:84957871049@10.208.22.18:5060;user=phone>
CSeq: 400 INVITE
Expires: 3600
From: "84957871049" <sip:84957871049@10.208.22.18:5060;user=phone>;tag=8ar7jpnb6h
To: "2211751" <sip:2211751@10.208.22.18:5060;user=phone>
Organization: Iskratel
Supported: 100rel
Via: SIP/2.0/UDP 10.208.22.18:5060;branch=z9hG4bK-x2m7c-57huh
Max-Forwards: 70
P-Asserted-Identity: "84957871049" <sip:84957871049@10.208.22.18:5060;user=phone>
Privacy: none 
Content-Length:  244
Content-Type: application/sdp
Content-Disposition: session;handling=required

v=0
o=- 3117068 2417365 IN IP4 10.208.22.19
s=-
c=IN IP4 10.208.22.19
b=AS:64
t=0 0
m=audio 17614 RTP/AVP 8 101
a=rtpmap:8 PC

<-TRYING

17d:6h:34m:18s (      lgr_flow)(721615    )  ---- Outgoing SIP Message to 10.208.22.18:5060 from SIPInterface #0 ----
17d:6h:34m:18s SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.208.22.18:5060;branch=z9hG4bK-x2m7c-57huh
From: "84957871049" <sip:84957871049@10.208.22.18:5060;user=phone>;tag=8ar7jpnb6h
To: "2211751" <sip:2211751@10.208.22.18:5060;user=phone>;tag=1c1554820939
Call-ID: njd8s-snc0h@10.208.22.18
CSeq: 400 INVITE
Supported: em,timer,replaces,path,resource-priority
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Server: Audiocodes-Sip-Gateway-/v.5.80A.023.006
Content-Length: 0

<-RINGING

17d:6h:34m:18s (   lgr_psbrdif)(721617    )  UpdateChannelParams, Channel 14 

17d:6h:34m:18s (   lgr_psbrdif)(721618    )  #14:GenerateRing: ChannelNum=14 RingType:0
17d:6h:34m:18s (   lgr_psbrdex)(721619    )  IsUseDistinctiveRing - MP124_REV > MP124_REVB
17d:6h:34m:18s (      lgr_flow)(721620    )  ---- Outgoing SIP Message to 10.208.22.18:5060 from SIPInterface #0 ----
17d:6h:34m:18s SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.208.22.18:5060;branch=z9hG4bK-x2m7c-57huh
From: "84957871049" <sip:84957871049@10.208.22.18:5060;user=phone>;tag=8ar7jpnb6h
To: "2211751" <sip:2211751@10.208.22.18:5060;user=phone>;tag=1c1554820939
Call-ID: njd8s-snc0h@10.208.22.18
CSeq: 400 INVITE
Contact: <sip:2211751@10.208.22.84:5060>
Supported: em,timer,replaces,path,resource-priority
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Require: 100rel
RSeq: 1
Server: Audiocodes-Sip-Gateway-/v.5.80A.023.006
Content-Length: 0

->PRACK

17d:6h:34m:18s (      lgr_flow)(721622    )  ---- Incoming SIP Message from 10.208.22.18:5060 to SIPInterface #0 ----
17d:6h:34m:18s PRACK sip:2211751@10.208.22.84:5060 SIP/2.0
Call-ID: njd8s-snc0h@10.208.22.18
CSeq: 401 PRACK
From: "84957871049" <sip:84957871049@10.208.22.18:5060;user=phone>;tag=8ar7jpnb6h
To: "2211751" <sip:2211751@10.208.22.18:5060;user=phone>;tag=1c1554820939
Via: SIP/2.0/UDP 10.208.22.18:5060;branch=z9hG4bK-jdm1r-75sl8
Max-Forwards: 70
RAck: 1 400 INVITE
Content-Length: 0

<-OK

17d:6h:34m:18s (      lgr_flow)(721624    )  ---- Outgoing SIP Message to 10.208.22.18:5060 from SIPInterface #0 ----
17d:6h:34m:18s SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.208.22.18:5060;branch=z9hG4bK-jdm1r-75sl8
From: "84957871049" <sip:84957871049@10.208.22.18:5060;user=phone>;tag=8ar7jpnb6h
To: "2211751" <sip:2211751@10.208.22.18:5060;user=phone>;tag=1c1554820939
Call-ID: njd8s-snc0h@10.208.22.18
CSeq: 401 PRACK
Contact: <sip:2211751@10.208.22.84:5060>
Supported: em,timer,replaces,path,resource-priority
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Server: Audiocodes-Sip-Gateway-/v.5.80A.023.006
Content-Length: 0

->CANCEL

17d:6h:35m:17s (      lgr_flow)(721626    )  ---- Incoming SIP Message from 10.208.22.18:5060 to SIPInterface #0 ----
17d:6h:35m:17s CANCEL sip:2211751@10.208.22.84:5060;user=phone SIP/2.0
Call-ID: njd8s-snc0h@10.208.22.18
CSeq: 400 CANCEL
From: "84957871049" <sip:84957871049@10.208.22.18:5060;user=phone>;tag=8ar7jpnb6h
To: "2211751" <sip:2211751@10.208.22.18:5060;user=phone>
Via: SIP/2.0/UDP 10.208.22.18:5060;branch=z9hG4bK-x2m7c-57huh
Reason: Q.850;cause=16;text="Normal call clearing"
Max-Forwards: 70
Content-Length: 0

<-REQUEST TERMINATED

17d:6h:35m:17s (      lgr_flow)(721628    )  ---- Outgoing SIP Message to 10.208.22.18:5060 from SIPInterface #0 ----
17d:6h:35m:17s SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 10.208.22.18:5060;branch=z9hG4bK-x2m7c-57huh
From: "84957871049" <sip:84957871049@10.208.22.18:5060;user=phone>;tag=8ar7jpnb6h
To: "2211751" <sip:2211751@10.208.22.18:5060;user=phone>;tag=1c1554820939
Call-ID: njd8s-snc0h@10.208.22.18
CSeq: 400 INVITE
Supported: em,timer,replaces,path,resource-priority
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Server: Audiocodes-Sip-Gateway-/v.5.80A.023.006
Reason: SIP ;cause=487 ;text="487 Request Terminated"
Content-Length: 0