Ответы полной невозможности установления соединения (6xx)

Передаваемый пользователем запрос не может обслужить ни один сервер. Соединение с вызываемым пользователем установить невозможно.

		Таблица
Назад

	SIP-ответы полной невозможности
		установления соединения.
Код		Назначение
600		Busy Everywhere. Вызываемый пользователь занят и не желает принимать вызов в
		данный момент. Ответ может указывать подходящее для вызова время. Если с
		пользователем можно связаться по другому адресу или, к примеру, оставить
		сообщение на речевой почтовый ящик, то используется ответ 486 (Busy Here).
603		Decline. Вызываемый пользователь не может или не желает принять входящий
		вызов без указания причины отказа.
604		Does Not Exist Anywhere. Вызываемый пользователь не существует.
606		Not Acceptable. Соединение с сервером было установлено, но отдельные элементы
		описания сеанса связи, такие как тип запрашиваемой информации, полоса
		пропускания, вид адресации не допустимы. Ответ может содержать заголовок
		Warning с указанием причин невозможности установления сеанса связи

Содержание

Назад

Адресация в сетях SIP

Для организации взаимодействия с существующими приложениями IP-сетей и для обеспечения мобильности пользователей протокол SIP использует адрес, подобный адресу электронной почты. В качестве адресов рабочих станций используются специальные универсальные указатели ресурсов - URL (Universal Resource Locators), так называемые SIP URL

SIP-адреса бывают четырех типов:имя@домен;имя@хост,

имя@IР-адрес;№телефона@шлюз

Содержание

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

Тело сообщения	Заголовки
необязательно.	Пустая строка
	Тело сообщения

Содержание

Заголовки сообщений

В протоколе SIP определено четыре вида заголовков :

Общие заголовки, присутствующие в запросах и ответах;

Заголовки содержания, переносят информацию о размере тела сообщения или об источнике запроса (начинаются со слова «Content»);

Заголовки запросов, передающие дополнительную информацию о запросе;

Заголовки ответов, передающие дополнительную информацию об ответе.

Каждое поле заголовка имеет вид:

Имя поля: значение поля

Содержание

Заголовок Call-ID - уникальный идентификатор сеанса связи

или всех регистрации отдельного клиента. Значение идентификатору присваивает сторона, которая инициирует вызов.

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

Заголовок From - идентифицирует отправителя запроса.

Заголовок CSeq - уникальный идентификатор запроса, относящегося к одному соединению. Он служит для корреляции запроса с ответом на него.

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

В заголовок Record-route прокси-сервер вписывает свой адрес - SIP URL, - если хочет, чтобы последующие запросы прошли через него.

Заголовок Content-Type определяет формат описания сеанса связи. Само описание сеанса, например, в формате протокола SDP, включается в тело сообщения.

Заголовок Content-Length указывает размер тела сообщения.

Содержание

Реализация услуг телефонии на базе протокола SIP

Протоколом SIP предусмотрены 3 основных сценария установления соединения:

1.С участием прокси-сервера 2.С участием сервера переадресации

3.Непосредственно между пользователями.

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

Содержание

Процедура управления соединением

Диалог представляет собой равноправное взаимодействие двух агентов пользователя по протоколу SIP, которое длится определенное время. Диалог устанавливает последовательность сообщений между UA и обеспечивает верную маршрутизацию запросов.

Клиент агента пользователя (UAC) формирует запрос, который включает в себя:

-стартовую стоки, в которой указывается тип запроса, -поле Request-URI и версию SIP,

-базовый набор полей заголовков: To, From, CSeq, Call-

ID, Max-Forwards, Via.

Содержание

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

После того как новый запрос создан, и базовые заголовки составлены должным образом в сообщение добавляются необязательные заголовки и запрос отправляется.

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

Сервер агента пользователя (UAS) получает запрос и выполняет набор процедур обработки. Обработка запросов элементарна.

Содержание

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

UAS обрабатывает запрос пошагово: 1 Аутентификация пользователя.

2 Определение типа запроса. Если UAS определил тип запроса, но не поддерживает его, он должен передать ответ с кодом 405.

3 Обработка поля To. В поле To вызывающий пользователь указывает адрес получателя запроса. Если UAS решает отклонить запрос, он должен создать ответ с кодом 403 и отправить его.

4 Обработка поля Request-URI. Поле Request-URI идентифицирует UAS, который должен обрабатывать запрос. Если в Request-URI используется адресация, не поддерживаемая сервером, запрос отклоняется и посылается ответ с кодом 416.

Содержание