Презентация "Протокол сигнализации SIP"
Подписи к слайдам:
Протокол сигнализации
SIP
Определение
Организации стандартизации
Тело сообщения
- «SIP*- является протоколом управления прикладного уровня для создания, изменения и завершения сеансов связи с одним или большим количеством участников. В понятие сеанса входят мультимедиа конференции, обучение на расстоянии, Internet-телефония и подобные приложения» (RFC 2543)
- *SIP – Session Initiation Protocol – Протокол инициализации сессии
- Session Invitation Protocol:
- Установление сеанса
- Элементарные возможности согласования
- Работа только поверх UDP
- SDP для описания сеанса
- Simple Conference Invitation Protocol:
- Базировался на TCP
- Использовал HTTP и SMTP
- Session Initiation Protocol:
- Работа поверх UDP
- Использование SDP
- Поддержка TCP
- …
- Разработкой протокола занимается группа MMUSIC (Multiparty Multimedia Session Control) комитета IETF
- 1996 – создания первой версии SIP
- 1999 – 11 версий документа Draft-ietf-mmusic-SIP
- В настоящее время действующей редакцией является RFC 3261
- Персональная мобильность пользователя
- Масштабируемость сети
- Расширяемость протокола SIP
- Интеграция в стек существующих протоколов Интернет
- Взаимодействие с различными протоколами сигнализации
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- телефония
- Международный союз электросвязи
- ITU-T
- (ех. CCITT)
- H.323, E.164, Z.100
- Интернет
- Группа разработчиков Интернет
- (IETF – Internet Engineering Task Force)
- RFC 2543, RFC 2030
- Расширяемость протокола – возможность дополнения протокола новыми функциями
- Масштабируемость сети – возможность увеличения элементов в сети при её расширении
- Интеграция в стек существующих протоколов Интернет
- Взаимодействие с другими протоколами сигнализации
- Персональная мобильность - возможность быть доступными в любом месте с любым терминалам в любое время (сообщение REGISTER) единый номер для всех услуг электросвязи
- Основан на НТТР проверенная технология для работы в Интернет
- Использует и UDP, и TCP
- Работает поверх различных транспортных протоколов (IP, IPX, X.25, ATM)
- Использует адресацию типа e-mail ([email protected])
- Текстовый формат сообщений простота и удобство техобслуживания и программирования
- Высокая информативность сообщений минимальное время установления соединения
- SIP поддерживает пять аспектов организации и завершения мультимедийной связи:
- Определение местоположения пользователя
- Определение готовности пользователя участвовать в сеансе
- Установление сеанса связи как для вызывающей, так и для вызываемой сторон, управление сеансом связи
- Передача пользовательской информации
- Организация конференций трех видов:
- В режиме многоадресной рассылки
- При помощи устройства управления конференцией, которому участники передают информацию в режиме точка-точка, а оно, в свою очередь, обрабатывает эту информацию и рассылает участникам конференции
- Соединение каждого пользователя с каждым в режиме точка-точка
- Определение функциональной возможности терминалов пользователей
- Назначение: для IP-коммуникаций
- Архитектура: peer-to-peer
- Преемственность: не пытается воспроизвести ТфОП
- Стандарты: IETF-стандарт RFC
- Интеллект: рассредоточен по элементам сети
- Сложность: еще простой, хотя уже содержит 13 запросов
- Масштабируемость: высшая степень
- Передача информации: речь, данные, видео
- Описание функциональных возможностей конечного оборудования: использование протокола SDP для обмена данными о функциональных возможностях
- Контроль доступа: поддерживается
- Качество обслуживания: процедуры QoS
- Адресация: поддержка IP- адресов и имен доменов через DNS
- Обнаружение закольцованных маршрутов: с помощью специальных заголовков
- Защита информации: протоколы IPSec, TLS, SSL и HTTP Digest
- Кодирование: текстовое кодирование
- В Интернет – URL (Uniform Resource Location)
- В SIP – SIP URL (sip:name@host)
- тип адреса пример
- «имя@домен» - sip:[email protected]
- «имя@хост» - sip:[email protected]
- «имя@IP-адрес» - sip:[email protected]
- «№ телефона@шлюз» - sip:[email protected]
- Первый уровень – отвечает за синтаксис и кодирование
- Второй уровень – транспортный – определяет, как клиент передает запросы и принимает ответы, и как сервер получает запросы и передает ответы по сети
- Третий уровень – уровень транзакций – производит повторную передачу сообщений прикладного уровня, определяет соответствие ответов запросу и уведомляет верхний уровень о срабатывании таймера.
- Четвертый уровень – пользователь транзакций – создает/отменяет клиентские запросы
- Транзакция - это запрос, переданный клиентской стороной серверной стороне с использованием транспортного уровня SIP, вместе со всеми ответами на этот запрос, переданными серверной стороной клиенту.
- запрос
- ответ
- Агент пользователя (UA – User Agent)
- Прокси-сервер (proxy server)
- Сервер переадресации (redirect server)
- Сервер определения местоположения (location server) (не стандартизирован в RFC 2543)
- Агент пользователя (User Agent):
- Клиент агента пользователя (User Agent Client) – часть программного обеспечения агента пользователя, которая создает новые запросы, отправляет их и обрабатывает принятые ответы.
- Сервер агента пользователя (User Agent Server) - часть программного обеспечения агента пользователя, которая принимает запросы и генерирует ответы, основываясь на действиях пользователя, полученных сообщениях, результатах выполнения программ или на каких-либо других событиях.
- запрос
- запрос
- ответ
- ответ
- разговор
- Запрос, составленный клиентом агента пользователя включает в себя :
- Стартовую строку, в кот. указан тип запроса
- Поле request-URI и версию SIP
- Базовый набор полей заголовков: To, from, Cseq, Call-ID, Max-Forwards и Via
- Эти заголовки:
- Обязательны для всех SIP-запросов
- Яв-ся основными частями SIP-сообщения
- Обеспечивают большинство услуг маршрутизации сообщений, в т.ч. адресацию, маршр-ю ответов, сохранение очередности сообщений, уникальную идентификацию
- Пошаговая обработка запроса:
- Аутентификация
- Анализ типа запроса
- Анализ полей заголовков
- …
- Если запрос принимается – должны быть произведены изменения состояния соединения, если не принимается – ни одно из изменений производиться не должно
- принимает запросы, обрабатывает их и, в зависимости от типа запроса, выполняет определенные действия.
- Бывает двух типов:
- Без сохранения состояний (Stateless) –принимает запросы, перенаправляет их дальше и забывает
- С сохранением состояний (Stateful) – принимает запросы, перенаправляет их и ждет ответы
- Сообщения SIP
- Запросы
- Ответы
- INVITE
- ACK
- BYE
- CANCEL
- OPTION
- REGISTER
- Временные
- Финальные
- 1хх - информационный
- 2хх – успех
- 3хх – перенаправление
- 4хх – ошибка клиента
- 5хх – ошибка сервера
- 6хх – глобальный сбой
- Начальная строка любого SIP сообщения. Если сообщение является запросом, то в этой строке указывается тип запроса, адресат и номер версии протокола. Если сообщение является ответом на запрос, в стартовой строке указывается номер версии протокола, тип ответа и его короткая расшифровка, предназначенная только для пользователя.
- служат для передачи информации об отправителе, адресате, пути следования и других сведений, т.е. переносят необходимую для обслуживания данного сообщения информацию. О типе заголовка можно узнать из его имени. В протоколе SIP определено 4 типа заголовков:
- Общие заголовки
- Заголовки содержания
- Заголовки, передающие дополнительную информацию о запросе
- Заголовки, передающие дополнительную информацию об ответе
- Каждое поле состоит из имени поля, знака «:» и значение поля:
- Имя поля: значение поля
- Поля заголовков могут быть расширены на несколько строк, тогда каждая следующая строка отделяется пробелом или знаком табуляции
- Порядок следования заголовков не имеет значения
- Формат значения заголовка зависит от имени заголовка
- Заголовок может иметь неограниченное число параметров
- Одно и то же имя параметра не может использоваться более одного раза
- Заголовок Call-ID – уникальный идентификатор сеанса связи (call reference - DSS-1): [email protected]
- Заголовок То – определяет адресата. Если необходим визуальный вывод имени пользователя, например, на дисплей, то имя пользователя также размещается в поле То.
- Заголовок From – идентифицирует отправителя запроса; по структуре аналогичен полю То.
- Заголовок CSeq - уникальный идентификатор запроса, относящегося к одному соединению. Он служит для корреляции запроса с ответом на него. CSeq: 2 INVITE.
- Заголовок Via указывается весь путь, пройденный запросом: каждый прокси-сервер добавляет поле со своим адресом.
- Например, запрос на своем пути обрабатывался двумя прокси-серверами: сначала сервером loniis.ru, потом sip.telecom.com. Тогда в запросе появятся следующие поля:
- Via: SIP/2.0/UDP sip.telecom.com:5060;branch=721e418c4.1
- Via: SIP/2.0/UDP loniis.ru:5060
- Заголовок Content-Type определяет формат описания сеанса связи. Само описание сеанса, например, в формате протокола SDP включается в тело сообщения.
- Заголовок Content-Length указывает размер тела сообщения
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Запросы:
- Содержит описание сеансов связи
- Тело сообщения есть не во всех сообщениях (например, сообщение BYE не содержит тела сообщения)
- Ответы:
- Любые ответы могут содержать тело сообщения, но содержимое тела в них может быть разным
- Запросы предназначены для выполнения широкого круга задач при предоставлении базовых и дополнительных услуг связи в стационарных сетях и сетях подвижной связи.
- С помощью запросов клиент сообщает о своем текущем местоположении, приглашает пользователей принять участие в сеансах связи, модифицирует уже установленные сеансы, завершает их и т.д.
- Тип запроса
- Описание запроса
- INVITE
- Приглашает пользователя к сеансу связи. Содержит SDP-описание сеанса
- ACK
- Подтверждает прием окончательного ответа на запрос INVITE
- BYE
- Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе
- CANCEL
- Отменяет обработку запросов с теми же заголовками Call-ID, To, From и CSeq, что и в самом запросе CANCEL
- REGISTER
- Переносит адресную информацию для регистрации пользователя на сервере определения местоположения
- OPTION
- Запрашивает информацию о функциональных возможностях сервера
- Тип запроса
- Описание запроса
- UPDATE
- Предлагает новыt параметры сеанса связи до прихода окончательного ответа на запрос INVITE
- INFO
- Переносит дополнительную информацию во время сеанса связи.
- PRACK
- Аналог сообщения ACK для предварительных ответов
- SUBSCRIBE
- NOTIFY
- Используются для предоставления дополнительных услуг
- REFER
- Команда перевода вызова
- MESSAGE
- Обеспечивает передачу пользовательской информации без установления сеанса связи
- PUBLISH
- Обеспечивает передачу информации о состоянии агента пользователя.
- SIP – запросы характеризуются наличием строки Request-Line в стартовой строке.
- Request-Line состоит из названия типа запроса, Request-URI и версии протокола, разделенных пробелом.
- Request-Line заканчивается символами возврата каретки и перевода строки (CRLF).
- Оба символа вместе или по одиночке не должны встречаться в других частях строки.
- Использование линейного пробела не допускается.
- 6 типов запросов (RFC 3261):
- REGISTER
- INVITE
- ACK
- CANCEL
- BYE
- OPTION
- Указывает пользователя или услугу, к которой адресован запрос. Поле Request-URI не должно содержать пробелов и управляющих символов, а также не должно быть заключено в угловые скобки «<>»
- И запросы и ответы содержат данные действующей версии SIP-протокола, принимая во внимание порядок, соответствие требованиям и изменение численного индекса версии
- приглашает вызываемого пользователя принять участие в сеансе связи.
- содержит описание сессии, в котором передается вид принимаемой информации и параметры, необходимые для приема информации, также может указываться вид информации, который вызываемый пользователь желает передавать.
- В ответе на запрос INVITE указывается вид информации, которая будет приниматься вызываемым пользователем, кроме того, может указываться вид информации, которую вызываемый пользователь собирается передавать (возможные параметры передачи информации).
- INVITE sip: [email protected] SIP/2.0
- Via: SIP/2.0/UDP kton.loniis.ru
- From: Anton <sip: [email protected]>
- To: Alexander <sip: [email protected]>
- Call-ID: [email protected]
- Cseq: 1 INVITE
- Content-Type: application/sdp
- Content-Length: ...
- v=0
- o=bell 53655765 2353687637 IN IP4 128.3.4.5
- C=IN IP4 kton.loniis.ru
- m=audio 3456 RTP/AVP 0 3 4
- ACK
- подтверждает прием ответа на команду INVITE.
- оборудование вызывающего пользователя показывает, что оно получило окончательный ответ на свой запрос INVITE.
- может содержаться окончательное описание сессии, передаваемое вызывающим пользователем.
- CANCEL
- отменяет обработку ранее переданных запросов.
- В этом запросе пользователи сообщают свое текущее местоположение.
- В этом сообщении содержатся следующие заголовки:
- То содержит адресную информацию, которую надо сохранить или модифицировать на сервере.
- From содержит адрес инициатора регистрации.
- Contact содержит новый контактный адрес пользователя, по которому должны посылаться все дальнейшие запросы INVITE.
- Expires указывается время в секундах, по истечении которого регистрация заканчивается.
- предназначен для обмена сигнальной информацией по SIP сигнальному тракту в процессе установления и поддержания соединения.
- Запрос INFO не изменяет состояния SIP вызовов, также как не изменяет состояния сессий, инициированных при помощи протокола SIP.
- Обеспечивает передачу дополнительной информации прикладного уровня, которая в дальнейшем может способствовать более производительному функционированию приложений, использующих протокол SIP для доставки данной информации.
- Возможными применениями для типа запроса INFO являются:
- Перенос текущих сигнальных сообщений ТфОП между шлюзами ТфОП в течении разговорной сессии
- Перенос DTMF сигналов, сгенерированных в ходе сессии
- Перенос защищённой информации сигналов беспроводных систем для поддержки беспроводной мобильности приложений
- Перенос информации об остатке на счёте (билинговой информации)
- Перенос изображений и другой не потоковой информации между участниками сессии
- Используется, когда необходимо изменить параметры сеанса:
- Вызывающая сторона создаёт начальную INVITE-транзакцию.
- В поле заголовка Allow запроса INVITE среди прочих типов запроса указывается UPDATE для того, чтобы указать способность вызывающей стороны принимать запросы этого типа. INVITE-транзакция протекает надлежащим образом. Любой ответ (предварительный или окончательный) от вызываемой стороны также содержит заголовок Allow с указанным в нём значением UPDATE.
- После установления диалога (находящегося на ранней стадии или установленного), вызывающая сторона может создать запрос UPDATE, который содержит информацию offer (предложение с описанием сеанса связи в формате SDP), предназначенное для обновления параметров сессии.
- Ответ на этот запрос переносит информацию answer (ответ на предложение с указанием принятых параметров также в формате SDP)
- Запрос UPDATE является запросом, обновляющим текущий адрес удалённого пользователя (target refresh request).
- Для услуг, которые требуют взаимодействия между конечными точками, необходима возможность запрашивать асинхронное уведомление о событиях
- Эти услуги включают:
- услуги автоматического обратного вызова (связанные с событиями изменения состояния терминала пользователя)
- интерактивные списки контактов «buddy lists» (связанные с событиями присутствия пользователя), оповещение об ожидающем сообщении (связанные с событиями изменения состояния почтового ящика)
- передача информации о состоянии вызова при взаимодействии сетей Internet и ТфОП.
- Для услуг, которые требуют взаимодействия между конечными точками, необходима возможность запрашивать асинхронное уведомление о событиях
- Эти услуги включают:
- услуги автоматического обратного вызова (связанные с событиями изменения состояния терминала пользователя)
- интерактивные списки контактов «buddy lists» (связанные с событиями присутствия пользователя), оповещение об ожидающем сообщении (связанные с событиями изменения состояния почтового ящика)
- передача информации о состоянии вызова при взаимодействии сетей Internet и ТфОП.
- (1) – запрос подписки на предоставление информации о состоянии
- (2) – подтверждение подписки
- (3) – передача информации о текущем состоянии
- (4) – подтверждение приёма
- (5) – передача информации о текущем состоянии
- (6) – подтверждение приёма
- Запрос SUBSCRIBE используется для запроса информации о текущем состоянии и информации об обновлениях состояния удалённого ресурса.
- SUBSCRIBE – это запрос, создающий диалог.
- Если начальное сообщение SUBSCRIBE представляет собой запрос вне диалога, его формирование проходит с привлечение процедур по созданию запроса вне диалога для UAC.
- Идентификация событий, на которые осуществляется подписка, обеспечивается с помощью трёх компонентов запроса SUBSCRIBE: поля Request URI, заголовка Event и опционально тела сообщения.
- Запрос SUBSCRIBE должен быть подтверждён окончательным ответом.
- После того, как подписка была успешно создана или обновлена, уведомитель должен незамедлительно отослать сообщение NOTIFY, чтобы сообщить подписчику текущее состояние ресурса
- Запрос NOTIFY посылается в том же диалоге, который был создан ответом на запрос SUBSCRIBE (если не существовало заранее установленного диалога).
- Тип запроса NOTIFY используется для уведомления узла SIP о том, что событие, информация о котором запрашивалась в запросе SUBSCRIBE, произошло.
- Запрос типа MESSAGE предназначен для передачи мгновенных текстовых сообщений (instant massages), используя модель, походящую на функционирование двустороннего пейджера или работу телефона при отправке SMS.
- Каждое текущее сообщение (IM) независимо – информация о том, что происходит взаимодействие, переговоры между участниками, может быть отражена только в пользовательском интерфейсе клиента
- Такой подход полностью противоположен сессионной модели, где происходит однозначное взаимодействие участников с чётко определённым началом и концом.
- Когда один пользователь решает послать другому пользователю текущее текстовое сообщение (IM), отправитель формирует запрос типа MESSAGE и передаёт его.
- Поле Request-URI запроса как обычно будет указывать публичный адрес получателя текущего сообщения, однако оно может содержать и адрес устройства в случаях, когда клиент владеет информацией о текущем местонахождении получателя
- Тело сообщения будет включать текстовое сообщение, которое необходимо доставить.
- Запрос MESSAGE пройдёт через группу прокси-серверов и будет доставлен получателю.
- Получив запрос, UA получателя перейдёт к его обработке и в случае успеха в итоге отошлёт окончательный ответ с кодом 200 (OK); это означает, что текстовое сообщение было доставлено пользователю, но указывает на то, что пользователь с ним ознакомился.
- MESSAGE sip:[email protected] SIP/2.0
- Via: SIP/2.0/TCP serv3.niits.ru;branch=z9hG4bK776sgdkse
- Max-Forwards: 70
- From: sip:[email protected];tag=49583
- To: sip:[email protected]
- Call-ID: [email protected]
- CSeq: 1 MESSAGE
- Content-Type: text/plain
- Content-Length: 18
- Александр, иди сюда.
- Шесть типов ответов:
- 1хх – информационные
- 2хх – успех
- 3хх – перенаправление
- 4хх – ошибка клиента
- 5хх – ошибка сервера
- 6хх – глобальная ошибка
- 100 Trying - Запрос обрабатывается, например, сервер обращается к базам данных, но местоположение вызываемого пользователя в настоящий момент не определено
- 180 Ringing - Местоположение вызываемого пользователя определено. Ему дается сигнал о входящем вызове
- 183 Session Progress – Этот ответ используется для того, чтобы заранее получить от шлюзов, стоящих на пути к вызываемому пользователю, описание сессии для проключения разговорного тракта в предответном состоянии
- Информационные ответы
- Ответы об успешной обработке запроса
- 200 ОК - Kоманда успешно выполнена
- 202 Accepted – Запрос принят для обработки, но она еще не завершена.
- Ответы переадресации вызова
- 300 Multiple Choices - Вызываемый пользователь доступен по нескольким адресам. Вызывающий пользователь может выбрать любой из них.
- 301 Moved Permanently - Пользователь изменил свое местоположение, его новый адрес указан в поле Contact
- 302 Moved Temporarily Пользователь временно изменил свое местоположение, его новый адрес указан в поле Contact
- 400 Bad Request - В запросе обнаружена синтаксическая ошибка
- 401 Unauthorized – Запрос требует проведения процедуры авторизации пользователя
- 404 Not Found – Вызываемый пользователь не обнаружен
- 407 Proxy Authentication Required – Перед вызовом требуется пройти процедуру аутентификации
- 486 Busy Here – Вызываемый пользователь в данный момент либо не желает либо не имеет возможности принять еще один вызов в дополнение к уже принятым
- Ответы об отказе сервера
- 500 Internal Server Error - Внутренняя ошибка сервера
- 501 Not Implemented - Сервер не может обслужить запрос, потому что в сервере не реализованы соответствующие функции
- 503 Service Unaviable – Обслуживание временно невозможно вследствие перегрузки или из-за проведения технического обслуживания
- 600 Busy Everywhere Вызываемый пользователь занят и не желает принимать вызов в данный момент. Ответ может указывать подходящее для вызова время.
- 603 Decline Вызываемый пользователь не может или не желает принять входящий вызов, не указывая причины отказа
- 604 Does Not Exist Anywhere – Вызываемый пользователь не существует
- Ответы о полной невозможности установить соединение
- Равноправное взаимодействие двух агентов пользователя по протоколу SIP, которое длится определённое время.
- Диалог устанавливает последовательность сообщений между UA и обеспечивает верную маршрутизацию запросов.
- Идентифицируется каждым агентом пользователя с помощью идентификатора диалога (dialog ID), который состоит из значения Call-ID, локальной метки (local tag) и удалённой метки (remote tag).
- У участвующих в диалоге сторон идентификатор диалога имеет свои отличия: локальная метка одного UA идентична удалённой метке другого и наоборот.
- Идентификатор диалога напрямую связан со всеми запросами, имеющими параметр «tag» в поле заголовка To.
- Компоненты, описывающие состояние диалога и используемые для передачи сообщений в ходе диалога:
- идентификатор диалога
- локальный порядковый номер (для упорядочивания запросов UA, направляемых своему собеседнику),
- удалённый порядковый номер (для упорядочивания запросов от собеседника к UA)
- локальный URI
- удалённый URI
- текущий адрес удалённого пользователя (remote target)
- булев флаг «secure»
- установленный маршрут (route set)
- Диалоги создаются путём возврата ответов, не информирующих об ошибках, на запросы определённых типов.
- В данной версии протокола установить диалог возможно только ответами 101-199 и 2хх с параметром «tag» в поле заголовка To на запрос INVITE.
- Диалог, установленный предварительным ответом на запрос, называется диалогом «на ранней стадии» (early dialog).
- Как только соединение между двумя агентами пользователя установлено, любой из них может стать инициатором новых транзакций, необходимых в рамках диалога:
- UA, отсылающий запросы будет выполнять роль клиента в транзакции,
- UA, принимающий запросы, будет выполнять роль сервера.
- Эти роли могут отличаться от тех, которые исполняли агенты пользователя в транзакции создания диалога.
- Когда на любой запрос вне диалога приходит окончательный ответ класса, отличного от 2хх, диалоги, находящиеся на «ранней стадии», созданные посредством предварительных ответов, разрушаются.
- Для разрушения установленных диалогов используется запрос BYE
- Транзакция состоит из запроса и любого количества ответов на него.
- Транзакция имеет клиентскую сторону и серверную сторону, соответственно они носят название клиентской транзакции и серверной транзакции.
- Клиентская транзакция занимается отправкой запросов,
- Серверная транзакция – отправкой ответов.
- Они создаются в агентах пользователя и прокси-серверах с сохранением состояний (stateful).
- Когда TU нужно инициировать новую транзакцию, он создает клиентскую транзакцию и передаёт ей:
- SIP-запрос, предназначенный для отправки,
- IP-адрес,
- номер порта,
- тип транспортного протокола, на которые должен быть передан запрос.
- Существует два конечных автомата клиентских транзакций в зависимости от типа запроса, который передаёт TU:
- Один из них поддерживает клиентские транзакции для запросов INVITE (клиентская INVITE-транзакция)
- Второй тип поддерживает клиентские транзакции всех типов запросов, исключая INVITE и ACK
- Не существует отдельной клиентской транзакции для запроса ACK: когда у TU возникает необходимость передать этот запрос (при подтверждении ответа класса 2хх на запрос INVITE), он отправляет его напрямую транспортному уровню SIP для доставки по сети.
- Когда транспортный уровень клиента принимает ответ, он должен выяснить, какой клиентской транзакции он принадлежит.
- Для этой цели существует параметр «branch» в верхнем заголовке Via.
- Ответ соответствует клиентской транзакции при выполнении двух условий:
- Верхний заголовок Via ответа имеет то же значение параметра «branch», что и аналогичный верхний заголовок запроса, инициировавшего транзакцию.
- Поле типа запроса в заголовке CSeq соответствует типу запроса, создавшему транзакцию.
- Серверная транзакция отвечает за доставку запросов TU и надёжную передачу ответов.
- Серверные транзакции создаются при получении запросов при условии, что создание транзакции желаемо для запроса.
- Как в клиентских транзакциях механизм функционирования зависит от типа запроса.
- Запрос соответствует транзакции, когда:
- параметр «branch» запроса совпадает с аналогичным параметром в первом заголовке Via запроса, создавшего транзакцию.
- имя хоста и номер порта в первом значении заголовка Via совпадают с аналогичными в первом значении заголовка Via запроса, создавшего транзакцию.
- тип запроса соответствует типу запроса, создавшего транзакцию, за исключением запроса ACK, для которого тип запроса, создавшего транзакцию, будет INVITE.
- Прокси-сервер
- Запрос установления соединения
- Сервер
- определения
- местоположения
- это элементы сети SIP, которые маршрутизируют SIP-запросы серверам агента пользователя и SIP-ответы – клиентам агента пользователя.
- Запрос может проходить несколько прокси-серверов на пути к UAS.
- Каждый из них будет принимать решения о дальнейшей маршрутизации, внося изменения в запрос перед его пересылкой следующему элементу сети.
- Ответы будут маршрутизироваться через ту же группу прокси-серверов, которая была пройдена запросами, но в обратном порядке.
- В режиме с сохранением состояний прокси-сервер действует как механизм обработки SIP-транзакций.
- При функционировании прокси-сервер задействует серверную транзакцию и одну или несколько клиентских транзакций
- Входящие запросы обрабатываются серверной транзакцией.
- От серверной транзакции запросы направляются ядру прокси-сервера.
- Ядро прокси-сервера определяет, куда маршрутизировать запрос, выбирая один или несколько мест назначения для следующей пересылки запроса.
- Для каждого запроса элемент, выполняющий роль прокси-сервера, должен осуществлять следующие функции:
- Проверка правильности составления запроса
- Предварительная обработка маршрутной информации
- Определение адреса (адресов) для пересылки
- Пересылка запроса
- Обработка всех ответов
- Работает как ретранслирующий узел сети
- Он пересылает каждый запрос следующему элементу, принимая решения о маршрутизации исходя из информации, содержащейся в запросе.
- Полученные ответы он просто пересылает обратно.
- Он удаляет информацию о прошедшем сообщении, как только сообщение было ретранслировано.
- Сервер переадресации предназначен для определения текущего адреса пользователя
- Не генерирует своих запросов
- Не терминирует вызовы
- Не содержит клиентскую часть программного обеспечения
- Сервер
- переадресации
- Запрос установления соединения
- Ответ с
- текущим
- адресом
- Сервер
- определения
- местоположения
- Служит для хранения текущего адреса пользователя.
- Позволяет агентам регистрировать свое местоположение , обеспечивая тем самым мобильность пользователя
- Может быть совмещен с прокси-сервером
- О своем местоположении пользователь информирует сервер при помощи сообщения REGISTER. 2 режима регистрации:
- Новый адрес сообщается один раз
- Новый адрес сообщается через определенные промежутки времени
- Локальная Удаленная
- SIP-сервер
- БД
- SIP-сервер
- БД
- LDAP
- <number>
- Tesla
- Marconi
- INVITE
- 180 Ringing
- 200 OK
- ACK
- Media Session
- BYE
- 200 OK
- Пример установления соединения в SIP сети
- <number>
- SUBSCRIBE
- 200 OK
- NOTIFY
- 200 OK
- …
- NOTIFY
- 200 OK
- MESSAGE
- 200 OK
- MESSAGE
- 200 OK
- Пример услуги «мгновенного обмена сообщениями»
- <number>
- Alice
- Registrar Server
- REGISTER
- Contact: sip:[email protected]
- 200 OK
- Пример регистрации в сети SIP
- <number>
- Alice
- Registrar Server
- SIP/2.0 200 OK
- Via: SIP/2.0/UDP 128.175.13.50:5060;
- branch=z9hG4bKus19
- To: Alice <sip:[email protected]>
- From: Alice <sip:[email protected]>;tag=3431
- Call-ID: [email protected]
- CSeq: 1 REGISTER
- Contact: <sip:[email protected]>;expires=3600
- Content-Length: 0
- REGISTER sip:registrar.udel.edu
- Via: SIP/2.0/UDP 128.175.13.50:5060;
- branch=z9hG4bKus19
- Max-Forwards: 70
- To: Alice <sip:[email protected]>
- From: Alice <sip:[email protected]>;tag=3431
- Call-ID: [email protected]
- CSeq: 1 REGISTER
- Contact: sip:[email protected]
- Content-Length: 0
- <number>
- INVITE sip:[email protected] SIP/2.0
- Via: SIP/2.0/UDP 100.101.102.103:5060;
- branch=z9hG4bKmp17a
- To: Bob <sip:[email protected]>
- From: Alice <sip:[email protected]>;tag=42
- Subject: Where are you exactly?
- Contact: <sip:[email protected]>
- Alice
- Bob
- Redirect Server
- SIP/2.0 302 Moved Temporarily
- Via: SIP/2.0/UDP 100.101.102.103:5060;
- branch=z9hG4bKmp17a
- To: Bob <sip:[email protected]>;tag=64
- From: Alice <sip:[email protected]>;tag=42
- Subject: Where are you exactly?
- Contact: sip:[email protected]
- ACK
- INVITE sip:[email protected] SIP/2.0
- Via: SIP/2.0/UDP 100.101.102.103:5060;
- branch=z9hG4bKmp17a
- To: Bob <sip:[email protected]>
- From: Alice <sip:[email protected]>;tag=13473
- Subject: Where are you exactly?
- Contact: <sip:[email protected]>
- Вызывающий
- пользователь
- Вызываемый
- пользователь
- Сервер
- перенаправления
- Сервер определения
- местоположения
- INVITE (SDP A)
- Запрос определения местоположения
- Ответ с текущим адресом
- 302 (текущий адрес)
- АСК
- INVITE (SDP A)
- 180 Ringing
- КПВ
- 200 ОК (SDP B)
- АСК
- Разговор
- BYE
- 200 ОК
- 100 Trying
- <number>
- Alice
- Bob
- Outbound proxy server
- Inbound proxy server
- Location server
- DNS server
- Media (RTP)
- INVITE sip:[email protected] SIP/2.0
- Via: SIP/2.0/UDP 100.101.102.103:5060;
- branch=z9hG4bKmp17a
- To: Bob <sip:[email protected]>
- From: Alice <sip:[email protected]>;tag=42
- Subject: Where are you exactly?
- Contact: <sip:[email protected]>
- INVITE sip:[email protected] SIP/2.0
- Via: SIP/2.0/UDP proxy.yahoo.com:5060;
- branch=z9hG4bKtiop3
- Via: SIP/2.0/UDP proxy.udel.com:5060;
- branch=z9hG4bK83842.1
- Via: SIP/2.0/UDP 100.101.102.103:5060;
- branch=z9hG4bKmp17a
- To: Bob <sip:[email protected]>
- From: Alice <sip:[email protected]>;tag=42
- Subject: Where are you exactly?
- Contact: <sip:[email protected]>
- 100 Trying
- 100 Trying
- 180 Ringing
- 180 Ringing
- 180 Ringing
- 200 OK
- 200 OK
- 200 OK
- ACK
- BYE
- 200 OK
- INVITE sip:[email protected] SIP/2.0
- Via: SIP/2.0/UDP proxy.udel.com:5060;
- branch=z9hG4bK83842.1
- Via: SIP/2.0/UDP 100.101.102.103:5060;
- branch=z9hG4bKmp17a
- To: Bob <sip:[email protected]>
- From: Alice <sip:[email protected]>;tag=42
- Subject: Where are you exactly?
- Contact: <sip:[email protected]>
- SIP Trapezoid
- УУД
- УУД
- Softswitch
- Сервер определения
- местоположения
- INVITE
- Запрос определения местоположения
- Ответ с текущим адресом
- INVITE
- 180 Ringing
- КПВ
- 200 ОК
- АСК
- Разговор
- BYE
- 200 ОК
- вызов
- ответ
- 180 Ringing
- 200 ОК
- АСК
- <number>
- INVITE Bob
- Alice
- Bob’s voicemail
- Bob’s Phone
- INVITE Bob
- 486 Busy Here
- INVITE Bob
- <number>
- INVITE Bob
- Alice
- Bob’s Cell Phone
- INVITE Bob
- INVITE Bob
- Bob’s Office Phone
- INVITE Bob
- Bob’s Home Phone
- 200 OK
- 200 OK
- CANCEL
- CANCEL
- Отвечает за перенос запросов и ответов через сеть с использованием ее транспортных протоколов
- Отвечает за управление соединениями таких протоколов как TCP и SCTP
- Имеет клиентскую и серверную стороны
- Соединение контролируется как на клиентской так и на серверной стороне
- Соединения идентифицируются указателем, состоящим из:
- Адреса
- Порта
- Транспортного протокола на удаленном конце
- Соединение должно сохранятся в течение некоторого интервала времени после того, как последнее сообщение было передано или получено через это соединение
- Сигнализация
- Речь
- Требование к сети IP-телефонии это возможность так называемой прозрачности услуг относительно ТфОП. Традиционные телефонные услуги, такие как call waiting, услуга 800 и т.д. реализуются с помощью системы сигнализации №7.
- SIP-T
- Инкапсуляция сообщений ОКС7/DSS-1 в сообщения SIP
- Использование информации из сообщений ОКС7/DSS-1
- IAM
- INVITE (SDP A)
- 100 Trying
- IAM
- ACM
- 180 Ringing
- ACM
- ANM
- 200 OK (SDP B)
- ACK
- Разговор
- REL
- BYE
- REL
- 200 OK
- ANM
- ISUP
- ISUP
- SIP
- IAM 1
- INVITE
- ст. строка
- заголовок
- SDP
- IAM(00101001010101001010101…)
- IAM 2
- IAM 2 = IAM 1
- Услуга «Переключение связи»
- Услуга «Переадресация вызова»
- Услуга «Уведомление о вызове во время связи»
- Сотовые сети нового поколения 3G
- SIP для установления мультимедийных сессий
- SIP for Telephony (SIP-T)
- SIP – перспективный современный подход к построению сетей IP-телефонии
- SIP – удобный и простой для реализации и техобслуживания
- SIP легко интегрируем в существующий стек протоколов Интернет
- SIP выбран в качестве протокола установления соединения в сотовых сетях поколения 3G
- SIP начинает использоваться в программных продуктах современных компаний (напр., Microsoft)
- SIP стремятся поддержать почти все производители оборудования IP-телефонии (Cisco, 3Com, Alcatel-Lucent)
Информатика - еще материалы к урокам:
- Презентация "Разработка интернет - магазина по продаже спортивного питания ИП «БЕЛЯЕВ»"
- Презентация "Технологии локальных сетей"
- Презентация "Курсовой проект на тему «ИС Интернет - магазина компьютерной техники»
- Презентация "Мобильные 4G сети"
- Презентация "Сети широкополосного доступа"
- Презентация "Спам и защита от него"