28

2.5.5 Проц едуры поддержки обмена пользовательскими сообщения ми 2.5.5.1 Процедура подписки на предоставление информации Для большинства реализован ных на базе протокола SIP услуг, которые тре буют взаимодействия между конечными точками, представляет интерес воз можность запрашивать асинхронное уведомление о событиях. Эти услуги вк лючают: услуги автоматического обратного вызова (связанные с событиями изменения состояния терминала пользователя), интер активные списки контактов (связанные с событиями пр исутствия пользователя), оповещение об ожидающем сообщении (связанные с событиями изменения состояния почтового ящика) и передача информации о состоянии вызова при взаимодействии сетей Internet и ТфОП. Объекты сети SIP могут подписаться на предоставление информации о со стоянии определённого ресурса или вызова в сети, и объекты, располагающи е этими сведения ми, будут отсыла ть уведомления каждый раз, когда это состояние изменится. Типичный вариа нт обмена сообщениями представлен ниже: Рис. 2. 5.5.1 Процедура подписки на предоставление информации (1) – запрос подписки на предоставление информации о состоянии (2) – подтверждение подписки (3) – передача информации о текущем состоянии (4) – подтверждение приёма (5) – передача информации о текущем состоянии (6) – подтверждение приёма Когда аг ент пользователя желает подписаться на получение и нформации о конкретном состоянии ресурса, он формирует запрос SUBSCRIBE . Идентификация событий, на которые осуществляется п одписка, обеспечивается с помощью трёх компонентов запроса SUBSCRIBE : поля Request URI , заголовка Event и опцио нально тела сообщения. В запросе SUBSCRIBE должен присутствовать ровно один заго ловок Event , указывающий событие или класс со бытий, на которое осуществляется подписка. Заголовок содержит значение, указывающее тип состояния, информация о котором затребована подписчик ом. Когда время действия подпис ки истекает, подписчик может обновить таймер для соответствующей подпи ски путём отсылки ещё одного сообщения SUBSCRIBE с таким же значением параметра « id » заголовка Event в том же диалоге, где существует начальная подписка. Процедура отказа от подписки протекает так же, как и процедура обновления подписки с единственным отличием, заключающимс я в том, что значение поля заголовка Expires уст анавливается в нулевое состояние. Запрос SUBSCRIBE должен быть подтверждён окончательным ответом. Если уведомитель способен незамедлительно определить, что не существует др угих препятствий, чтобы создат ь подписку, он создаёт подписку, а затем возвращает ответ с кодом 200 ( OK ). Также может быть отослан ответ с кодом 202 ( Accepted ). Такой ответ означает, что запрос был по лучен и понят, но подписка может быть ещё не авторизована. После того, как подписка был а успешно создана или обновлена, уведомитель должен незамедлительно от ослать сообщение NOTIFY , чтобы сообщить подпи счику текущее состояние ресурса. Запрос NOTIFY посылается в том же диалоге, который был создан ответ ом на запрос SUBSCRIBE . Когда происходит изменен ие в состоянии, на которое была открыта подписка, подписчику также напра вляется запрос NOTIFY . Таким образом тип запро са NOTIFY используется для уведомления узла SIP о том, что событие, информация о котором з апрашивалась в запросе SUBSCRIBE , произошло. После того, как подписчик принимает уведомление, подписчик должен возвр атить ответ с кодом 200 ( OK ). Дополнительные св едения о запросах SUBSCRIBE и NOTIFY даны в RFC 3265. 2.5.5.2 Про цедура передачи вызова третьей сторон е Запрос REFER , посылаемый отправителем, предписывает получателю связаться с третьей стороной, используя контактную информа цию, которая содержится в сообщении. Такой механизм может быть использов ан для многих целей, включая передачу вызова . Например, если Anton нахо дится в состоянии вызова с пользователем Vladimir и решает, что Vladimir должен поговорить с пользователем Alexander , Anton может поручить своему SIP UA отправить запрос REFER SIP агенту п ользователя Vladimir , снабдив его контактной ин формацией пользователя Alexander . Если Vladimir даст своё согласие, его UA попытается связаться с Alexander , используя контактный адрес. После этого UA пользователя Vladimir увед омит UA пользователя Anton , насколько успешно прошла попытка установления связ и с пользователем Alexander . В запрос REFER включается заголовок Refer - To . Значени е, содержащееся в заголовке, указывает адрес третьей стороны, с которой о тправитель предлагает связаться получателю запроса REFER . Например, sip:a nton @ niits . ru . Если запрос принят, UAS должен возвратить от вет с кодом 202 ( Accepted ) до того, как истечёт время действия REFER -транзакции. Вслед за этим UA получателя создаёт подписку. Подписка, с оздаваемая запросом REFER по своей сути явля ется такой же, как подписка, создаваемая запросом SUBSCRIBE . REFER – это только механ изм, который создаёт подписку на событие передачи вызова - « refer ». Создание подписки влечёт за собой незамедлительну ю отправку запроса NOTIFY . Механизм отправки с ообщений NOTIFY используется для информирова ния UA , передавшего REFER , о статусе пересланного вызова . NOTIFY содержит тело сообщения типа message / sipfrag , содер жащее исчерпывающую информацию о состоянии действия по пересылке вызо ва . Запрос NOTIFY может быть создан всякий раз, когда появляется новая информация о статусе события пересылки вызова. Ниже представлен пример обмена сообщениями между Agent A и Agent B при успешной пересылке вызова, где Agent B пересылает вызов ком у-либо. Дополнительные сведения о запросе REFER даны в RFC 3515. Рис. 2. 5.5.2 Пример использования запроса REFER Содержание с ообщени я ( 1) REFER sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293940223 To: From: ;tag=193402342 Call-ID: [email protected] CSeq: 93809823 REFER Max-Forwards: 70 Refer-To: ( любой URI ) Contact: sip:[email protected] Content-Length: 0 Содержание с ообще ни я (5) NOTIFY sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP agentb.atlanta.example.com;branch=z9hG4bK9323394234 To: ;tag=193402342 From: ;tag=4992881234 Call-ID: [email protected] CSeq: 1993403 NOTIFY Max-Forwards: 70 Event: refer Subscription-State: terminated;reason=noresource Contact: sip:[email protected] Content-Type: message/sipfrag;version=2.0 Content - Length : 16 SIP /2.0 200 OK 2.5.5.3 Процедура обмена текстовыми сообщениями Интеракти вный обмен текстовыми сообщениями ( Instant Messaging ) происходит между группой участников в режиме , близком к реальному времени . Как правило , сообщения имеют м алый размер и не сохраняются . SIP запрос типа MESSAGE предна значен для передачи мгновенных текстовых сообщений ( instant m e ssages ), исп ользуя модель, подобную рабо те телефона при отправке SMS , т о есть не существует прямой свя зи между сообщениями. Каждое текущее сообщение ( IM ) независимо – информация о том, что происходит взаим одействие, переговоры между участниками, может быть отражена только в по льзовательском интерфейсе клиента или в воображении самого пользователя . Когда один пользовател ь решает послать другому пользователю те кущее текстовое сообщение (IM), отправитель формирует запрос типа MESSAGE и передаёт его . Тело со общения будет включать текстовое сообщение , к оторое необходимо доставить . Это тело может быть любого MIME-типа (зачастую - text / plain), в ключая тип message/cpim. Запрос MESSAGE пройдёт через группу прокси -серверов и будет доставлен получа телю . Получив запрос , UA получателя перейдёт к его обработке и в случае успеха в и тоге отошлёт окончательный ответ с кодом 200 (OK); это означает , что текстовое сообщен и е было доставлено пользо вателю . Запросы MESSAGE не устан авливают диалога . UAC может передавать запрос MESSAGE в существующем диалоге . В этом случае запр ос также происходит в рамках сессии или сессий , связанных с этим диалогом . Текущи е текстовые сообщения (IM) могут адресоваться с помощью Instant Message URI в форме "im:[email protected]". URI со схемой « im» абстрактные , поэтому они должны преобразовыв аться в конкретный URI в зависимости от прот окола (в данном случае SIP URI). То есть если в качестве адреса UA-получателя сообщения представлен IM URI, он должен быть переведён в SIP URI и помещён в поле Request-URI запроса MESSAGE перед отп равкой . Ниже представлен пример обмена сообще ниями . В примере USER1 передаёт пользователю USER2 начальное сообщение , оба пользователя находятся в одном домене domain.com ; между ними действует посре дник – прокси -сервер . Дополнительные сведени я о запросе MESSAGE даны в RFC 3428. Рис. 2. 5.5.3 Пример использования запроса MESSAGE Содержание сообщения ( 1 ) : MESSAGE sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP user1pc.domain.com;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 Watson, come here.

Приложенные файлы

  • rtf 23847279
    Размер файла: 1 005 kB Загрузок: 0

Добавить комментарий