Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)
О документе
Рабочая группа Network Working Group J. Rosenberg
Запрос комментариев: 3725 dynamicsoft
BCP: 85 J. Peterson
Категория: Лучшая современная практика Neustar
H. Schulzrinne
Columbia University
G. Camarillo
Ericsson
Апрель 2004
Лучшие современные практики управления вызовами третьей стороны (3pcc)
в протоколе установления сессии (SIP)
1. Введение
В традиционном контексте телефонии управление вызовами третьей стороны
позволяет одной сущности (которую мы называем контроллером) устанавливать
и управлять коммуникационным отношением между двумя или более другими
сторонами. Управление вызовами третьей стороны (именуемое 3pcc) часто
используется для операторских услуг (когда оператор создаёт вызов,
соединяющий двух участников) и конференций.
Аналогично, посредством управления вызовами третьей стороны возможны
многие службы SIP. К ним относятся традиционные службы в PSTN, а также
новые, такие как click-to-dial. Click-to-dial позволяет пользователю
щёлкнуть веб-страницу, когда он желает поговорить с представителем службы
поддержки клиентов. Затем веб-сервер создаёт вызов между пользователем и
представителем службы поддержки клиентов. Вызов может быть между двумя
телефонами, телефоном и IP-узлом или двумя IP-узлами.
Управление вызовами третьей стороны возможно, используя только механизмы,
определённые в RFC 3261 [1]. Действительно, возможны многие различные
потоки вызовов, каждый из которых будет работать с SIP-совместимыми
пользовательскими агентами. Однако каждый из этих потоков имеет
преимущества и недостатки. Использование управления вызовами третьей
стороны также становится более сложным, когда аспекты вызова используют
расширения SIP или необязательные возможности SIP. В частности,
использование RFC 3312 [2] (применяемого для связывания сигнализации с
резервированием ресурсов) вместе с управлением вызовами третьей стороны
нетривиально и рассматривается в разделе 9. Аналогично, использование
ранних медиа (когда данные сессии обмениваются до принятия вызова) вместе
с управлением вызовами третьей стороны нетривиально; оба они определяют
способ, которым пользовательские агенты создают SDP и отвечают на него, и
неясно, как выполнять оба действия одновременно. Это подробнее
рассматривается в разделе 8.
Этот документ служит лучшей современной практикой реализации управления
вызовами третьей стороны без использования каких-либо расширений,
специально разработанных для этой цели. В разделе 4 представлены известные
потоки вызовов, которые можно использовать для реализации управления
вызовами третьей стороны, и приведены рекомендации по их использованию. В
разделе 9 рассматриваются взаимодействия RFC 3312 [2] с управлением
вызовами третьей стороны. В разделе 8 рассматриваются взаимодействия
ранних медиа с управлением вызовами третьей стороны. В разделе 10 приведены
примеры приложений, использующих рекомендованные здесь потоки.
2. Терминология
В этом документе ключевые слова «ДОЛЖЕН (MUST)», «НЕ ДОЛЖЕН (MUST NOT)»,
«ДОЛЖЕН (REQUIRED)», «ДОЛЖЕН (SHALL)», «НЕ ДОЛЖЕН (SHALL NOT)»,
«СЛЕДУЕТ (SHOULD)», «НЕ СЛЕДУЕТ (SHOULD NOT)»,
«СЛЕДУЕТ (RECOMMENDED)», «МОЖЕТ (MAY)» и «НЕОБЯЗАТЕЛЬНО (OPTIONAL)»
должны интерпретироваться, как описано в RFC 2119 [3], и указывают
уровни требований для соответствующих реализаций.
3. Определения
В этом документе используются следующие термины:
3pcc: Управление вызовами третьей стороны, означающее общую способность
управлять вызовами между другими сторонами.
Контроллер: Контроллер — это пользовательский агент SIP, желающий создать
сессию между двумя другими пользовательскими агентами.
4. Установление вызова 3pcc
Основной элементарной операцией управления вызовами третьей стороны
является установление сессии между участниками A и B. Установление этой
сессии координируется третьей стороной, именуемой контроллером.
В этом разделе документируются три потока вызовов, которые контроллер
может использовать для предоставления этой элементарной операции.
4.1. Поток I
A Controller B
|(1) INVITE no SDP | |
|<------------------| |
|(2) 200 offer1 | |
|------------------>| |
| |(3) INVITE offer1 |
| |------------------>|
| |(4) 200 OK answer1 |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) ACK answer1 | |
|<------------------| |
|(7) RTP | |
|.......................................|
Рисунок 1
Поток вызова для потока I показан на рисунке 1. Контроллер сначала
отправляет A INVITE (1). Этот INVITE не содержит описания сессии. Телефон
A звонит, и A отвечает. В результате получается 200 OK (2), содержащий
предложение [4]. Контроллеру необходимо отправить свой ответ в ACK, как
предписано [1]. Чтобы получить ответ, он отправляет предложение, полученное
от A (offer1), в INVITE для B (3). Телефон B звонит. Когда B отвечает,
200 OK (4) содержит ответ на это предложение, answer1. Контроллер
отправляет ACK B (5), а затем передаёт answer1 A в отправленном ему ACK
(6). Поскольку предложение было создано A, а ответ создан B, фактическая
медиасессия находится между A и B. Поэтому между ними передаются медиа (7).
Этот поток прост, не требует от контроллера манипулирования SDP и работает
для любых типов медиа, поддерживаемых обеими конечными точками. Однако у
него есть серьёзная проблема тайм-аута. Пользователь B может не ответить на
вызов немедленно. В результате контроллер не может сразу отправить ACK A.
Это заставляет A периодически повторно передавать ответ 200 OK. Как
определено в разделе 13.3.1.4 RFC 3261, 200 OK будет повторно передаваться
в течение 64*T1 секунд. Если к тому времени ACK не поступит, вызов
считается неуспешным. Это ограничивает применимость этого потока
сценариями, в которых контроллер знает, что B немедленно ответит на INVITE.
4.2. Поток II
A Controller B
|(1) INVITE bh sdp1 | |
|<------------------| |
|(2) 200 sdp2 | |
|------------------>| |
| |(3) INVITE sdp2 |
| |------------------>|
|(4) ACK | |
|<------------------| |
| |(5) 200 OK sdp3 |
| |<------------------|
| |(6) ACK |
| |------------------>|
|(7) INVITE sdp3 | |
|<------------------| |
|(8) 200 OK sdp2 | |
|------------------>| |
|(9) ACK | |
|<------------------| |
|(10) RTP | |
|.......................................|
Рисунок 2
Альтернативный поток, поток II, показан на рисунке 2. Контроллер сначала
отправляет пользователю A INVITE (1). Это стандартный INVITE, содержащий
предложение (sdp1) с одной строкой аудиомедиа, одним кодеком, случайным
номером порта (но не нулевым) и адресом соединения 0.0.0.0. Это создаёт
начальный медиапоток, который «направляется в чёрную дыру», поскольку от A
не будет передаваться ни медиа, ни пакеты RTCP [8]. INVITE заставляет
телефон A звонить.
Обратите внимание, что использование 0.0.0.0, хотя и рекомендовано
RFC 3264, имеет многочисленные недостатки. Ожидается, что будущая
спецификация будет рекомендовать использование домена в домене DNS
верхнего уровня .invalid вместо IP-адреса 0.0.0.0. В результате
разработчикам предлагается отслеживать такие изменения, когда они
появятся.
Когда A отвечает (2), 200 OK содержит ответ sdp2 с действительным адресом
в строке соединения. Контроллер отправляет ACK (4). Затем он создаёт второй
INVITE (3). Этот INVITE адресован пользователю B и содержит sdp2 в качестве
предложения для B. Обратите внимание, что роль sdp2 изменилась. В 200 OK
(сообщение 2) это был ответ, но в INVITE это предложение. К счастью, все
действительные ответы являются действительными
начальными предложениями. Этот INVITE заставляет телефон B звонить. Когда
B отвечает, он создаёт 200 OK (5) с ответом sdp3. Затем контроллер создаёт
ACK (6). Далее он отправляет A повторный INVITE (7), содержащий sdp3 в
качестве предложения. И вновь произошла смена ролей. sdp3 был ответом, а
теперь является предложением. К счастью, ответ на ответ, представленный как
предложение, в свою очередь является действительным предложением. Этот
повторный INVITE создаёт 200 OK (8) с sdp2, предполагая, что A не решит
изменить какие-либо аспекты сессии в результате этого повторного INVITE.
Этот 200 OK подтверждается ACK (9), и затем медиа могут передаваться от A
к B. Медиа от B к A уже могли начать передаваться после отправки сообщения
5.
Этот поток имеет то преимущество, что все окончательные ответы
немедленно подтверждаются ACK. Поэтому он не страдает от проблем
тайм-аутов и неэффективности сообщений, свойственных потоку 1. Однако
у него также есть недостатки. Во-первых, он требует, чтобы контроллер
знал типы медиа, которые будут использоваться для вызова (поскольку он
должен сгенерировать SDP «чёрной дыры», для которого требуются строки
медиа). Во-вторых, первый INVITE к A (1) содержит медиа с адресом
соединения 0.0.0.0. Контроллер ожидает, что ответ будет содержать для A
корректный ненулевой адрес соединения. Однако опыт показал, что многие
UA отвечают на предложение с адресом соединения 0.0.0.0 ответом,
содержащим адрес соединения 0.0.0.0. Спецификация offer-answer [4]
прямо предписывает разработчикам не делать этого, но на момент
публикации этого документа многие реализации всё ещё так поступали.
Если A ответит адресом соединения 0.0.0.0 в sdp2, поток не будет
работать.
Однако наиболее серьёзный недостаток этого потока — предположение,
что 200 OK на re-INVITE (сообщение 8) содержит тот же SDP, что и
сообщение 2. Это может быть не так. Если это не так, контроллеру
необходимо направить B re-INVITE с этим SDP (скажем, sdp4), что может
привести к получению другого SDP, sdp5, в 200 OK от B. Затем
контроллеру нужно снова направить re-INVITE A, и так далее. Результатом
становится бесконечный цикл re-INVITE. Этот цикл возможно разорвать,
используя очень интеллектуальные UA, которые могут по возможности
возвращать один и тот же SDP, либо действительно интеллектуальные
контроллеры, способные проанализировать SDP, чтобы определить,
действительно ли требуется re-INVITE. Однако мы стремимся сохранить
этот механизм простым и избежать осведомлённости контроллера о SDP. В
результате этот поток фактически неработоспособен. Поэтому его
использовать НЕ СЛЕДУЕТ (NOT RECOMMENDED).
4.3. Поток III
A Controller B
|(1) INVITE no SDP | |
|<---------------------| |
|(2) 200 offer1 | |
|--------------------->| |
|(3) ACK answer1 (bh) | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| |(5) 200 OK offer2 |
| |<---------------------|
|(6) INVITE offer2' | |
|<---------------------| |
|(7) 200 answer2' | |
|--------------------->| |
| |(8) ACK answer2 |
| |--------------------->|
|(9) ACK | |
|<---------------------| |
|(10) RTP | |
|.............................................|
Рисунок 3
Третий поток, Поток III, показан на рисунке 3.
Сначала контроллер отправляет пользователю A INVITE (1) без какого-либо
SDP (что хорошо, поскольку это означает, что контроллеру не требуется
делать предположения о составе медиа сеанса). Телефон A звонит. Когда A
отвечает, генерируется 200 OK (2), содержащий его предложение, offer1.
Контроллер генерирует немедленный ACK, содержащий ответ (3). Этот ответ
представляет собой SDP «чёрной дыры» с адресом соединения, равным
0.0.0.0.
Затем контроллер отправляет B INVITE без SDP (4). Это вызывает звонок
телефона B. Когда B отвечает, отправляется 200 OK, содержащий его
предложение, offer2 (5). Этот SDP используется для создания re-INVITE,
направляемого обратно A (6). Этот re-INVITE основан на offer2, но может
нуждаться в реорганизации для сопоставления строк медиа или удаления
строк медиа. Например, если offer1 содержал строку аудио и строку
видео в таком порядке, а offer2 содержал лишь строку аудио, контроллеру
потребовалось бы добавить к предложению строку видео (установив её порт
в ноль), чтобы создать offer2'. Поскольку это re-INVITE, в общем случае
он должен завершиться быстро. Это хорошо, поскольку пользователь B
повторно передаёт свой 200 OK, ожидая ACK. SDP в 200 OK (7) от A,
answer2', также может нуждаться в реорганизации или сокращении перед
отправкой его в ACK B (8) как answer2. Наконец, A отправляется ACK (9),
после чего может передаваться медиа.
Этот поток имеет много преимуществ. Во-первых, он обычно будет работать
без каких-либо ложных повторных передач или тайм-аутов (хотя это всё
ещё может произойти, если на re-INVITE не ответят быстро). Во-вторых,
он не требует от контроллера угадывать медиа, которые будут
использоваться участниками.
У него есть некоторые недостатки. Контроллеру действительно необходимо
выполнять манипуляции с SDP. В частности, он должен взять некоторый
SDP и сгенерировать другой SDP, имеющий тот же состав медиа, но с
адресами соединения, равными 0.0.0.0. Это необходимо для сообщения 3.
Во-вторых, ему может потребоваться изменить порядок и сократить SDP X,
чтобы его строки медиа соответствовали строкам в некотором другом SDP,
Y. В-третьих, предложение от B (offer2) может не иметь общих кодеков
или медиапотоков с предложением от A (offer 1). Контроллеру потребуется
обнаружить это состояние и завершить вызов. Наконец, этот поток намного
сложнее простого и элегантного Потока I (рисунок 1).
4.4. Поток IV
A Controller B
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
|(2) 200 answer1 | |
|no media | |
|--------------------->| |
|(3) ACK | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| |(5) 200 OK offer2 |
| |<---------------------|
|(6) INVITE offer2' | |
|<---------------------| |
|(7) 200 answer2' | |
|--------------------->| |
| |(8) ACK answer2 |
| |--------------------->|
|(9) ACK | |
|<---------------------| |
|(10) RTP | |
|.............................................|
Рисунок 4
Поток IV показывает вариант Потока III, снижающий его сложность.
Фактический поток сообщений идентичен, но размещение и построение SDP
отличаются. Начальный INVITE (1) содержит SDP без какого-либо медиа,
то есть без строк m. Это корректно и подразумевает, что состав медиа
сеанса будет установлен позднее посредством re-INVITE [4]. После
получения INVITE пользователь A оповещается. Когда A отвечает на
вызов, 200 OK (2) также содержит ответ без медиа. Контроллер
подтверждает его (3). Начиная с этого момента поток идентичен Потоку
III. Однако манипуляции, требуемые для преобразования offer2 в offer2'
и answer2' в answer2, существенно проще. Действительно, никакие
манипуляции с медиа вообще не требуются. Единственное необходимое
изменение состоит в изменении строк origin, чтобы строка origin в
offer2' была корректной на основе значения в offer1 (корректность
требует, чтобы версия увеличивалась на единицу, а остальные параметры
оставались неизменными).
С этим потоком связаны некоторые ограничения. Во-первых, пользователь
A будет оповещён до того, как будут установлены какие-либо медиа. Это
означает, что пользователь A не сможет отклонить или принять вызов на
основании его состава медиа. Во-вторых, и A, и B в итоге ответят на
вызов (то есть сгенерируют 200 OK), прежде чем станет известно, есть ли
совместимые медиа. Если общих медиа нет, вызов можно завершить позднее
с помощью BYE. Однако пользователи уже будут оповещены, что вызовет
недовольство пользователей и, возможно, события тарификации.
5. Рекомендации
Поток I (рисунок 1) представляет собой простейший и наиболее
эффективный поток. Этот поток СЛЕДУЕТ (SHOULD) использовать
контроллеру, если он достоверно знает, что пользователь B в
действительности является автоматом, который немедленно ответит на
вызов. Это относится, например, к таким устройствам, как медиасерверы,
серверы конференций и серверы сообщений. Поскольку мы ожидаем, что
значительная часть управления вызовами третьей стороны будет
осуществляться для автоматов, специальная обработка этого сценария
разумна.
Для вызовов к неизвестным сущностям или к сущностям, которые, как
известно, представляют людей, для управления вызовами третьей стороны
РЕКОМЕНДУЕТСЯ (RECOMMENDED) использовать Поток IV (рисунок 4). Вместо
него МОЖЕТ (MAY) использоваться Поток III, однако он не даёт
дополнительных преимуществ по сравнению с Потоком IV. Однако Поток II
использовать НЕ СЛЕДУЕТ (SHOULD NOT) из-за возможности бесконечного
обмена re-INVITE туда и обратно.
В нескольких из этих потоков используется адрес соединения «чёрной
дыры» 0.0.0.0. Это адрес IPv4 со свойством, что пакеты, отправленные на
него, никогда не покидают отправивший их хост; они просто
отбрасываются. Поэтому эти потоки специфичны для IPv4. Для других типов
сети или адресов СЛЕДУЕТ (SHOULD) использовать адрес с эквивалентным
свойством.
В большинстве случаев, включая рекомендуемые потоки, пользователь A
будет слышать тишину, пока завершается вызов B. Это не всегда может
быть идеальным. Это можно исправить, подключив вызывающего абонента к
источнику музыки при удержании, пока выполняется вызов B.
6. Обработка ошибок
Существует множество случаев ошибок, заслуживающих обсуждения.
Во всех потоках вызова из раздела 4 сначала устанавливается один вызов
к A, а затем контроллер пытается установить вызов к B. Однако эта
попытка вызова может завершиться неудачей по множеству причин.
Пользователь B может быть занят (что приведёт к ответу 486 на INVITE),
могут отсутствовать общие медиа, запрос может превысить время ожидания
и так далее. Если попытка вызова B завершится неудачей, контроллеру
РЕКОМЕНДУЕТСЯ (RECOMMENDED) отправить A BYE. Этот BYE СЛЕДУЕТ (SHOULD)
включать заголовок Reason [5], содержащий код состояния из ответа с
ошибкой. Это сообщит A точную причину сбоя. Эта информация важна с
точки зрения пользовательского интерфейса. Например, если A звонил с
чёрного телефона, а B сгенерировал 486, BYE будет содержать код Reason
486, и его можно использовать для формирования локального сигнала
«занято», чтобы A знал, что B занят.
A Controller B
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
|(2) 200 answer1 | |
|no media | |
|--------------------->| |
|(3) ACK | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| |(5) 180 |
| |<---------------------|
|(6) INVITE offer2 | |
|--------------------->| |
|(7) 491 | |
|<---------------------| |
| |(8) ACK |
| |--------------------->|
Рисунок 5
Ещё одно заслуживающее обсуждения условие ошибки показано на рисунке 5. После того как контроллер устанавливает диалог с A (сообщения 1–3), он пытается связаться с B (сообщение 4). Установление связи с B может занять некоторое время. В течение этого интервала A, возможно, попытается выполнить re-INVITE, предоставив обновлённое предложение. Однако контроллер не может передать это предложение B, поскольку у него с B находится в ожидании транзакция INVITE. В результате контроллеру необходимо отклонить запрос. РЕКОМЕНДУЕТСЯ (RECOMMENDED) использовать ответ 491. Ситуация здесь аналогична состоянию коллизии, описанному в [1], поэтому та же обработка ошибок разумна. Однако A, вероятно, повторит свой запрос (вследствие 491), и это может произойти до завершения обмена с B. В таком случае контроллер ответит ещё одним 491.
7. Продолжение обработки
После установления вызовов оба участника считают, что находятся в
единственном двухточечном вызове. Однако они обмениваются медиаданными
непосредственно друг с другом, а не с контроллером. Контроллер
участвует в двух диалогах, однако не видит медиаданные.
Поскольку контроллер всё ещё является центральной точкой сигнализации,
теперь он имеет полный контроль над вызовом. Если он получает BYE от
одного из участников, он может создать новый BYE и завершить вызов с
другим участником. Это показано на рисунке 6.
A Controller B
|(1) BYE | |
|------------------>| |
|(2) 200 OK | |
|<------------------| |
| |(3) BYE |
| |------------------>|
| |(4) 200 OK |
| |<------------------|
Рисунок 6
Аналогично, если он получает re-INVITE от одного из участников,
он может переслать его другому участнику. В зависимости от того,
какой поток использовался, перед пересылкой может потребоваться
некоторая обработка SDP.
Однако контроллеру не обязательно «проксировать» сообщения SIP,
полученные от одной из сторон. Поскольку он является Back-to-Back User
Agent (B2BUA), он может задействовать в каждом диалоге любой механизм
сигнализации по своему усмотрению. Например, если контроллер получает
BYE от A, он может сгенерировать новый INVITE третьей стороне, C, и
вместо этого соединить B с этим
участником. Поток вызова для этого показан на рисунке 7, при
предположении случая, в котором C представляет конечного пользователя,
а не автомат. Обратите внимание, что это просто поток IV.
A Controller B C
|(1) BYE | | |
|--------------->| | |
|(2) 200 OK | | |
|<---------------| | |
| |(3) INV no media| |
| |-------------------------------->|
| |(4) 200 no media| |
| |<--------------------------------|
| |(5) ACK | |
| |-------------------------------->|
| |(6) INV no SDP | |
| |--------------->|
| |(7) 200 offer3 | |
| |<---------------|
| |(8) INV offer3' | |
| |-------------------------------->|
| |(9) 200 answer3'| |
| |<--------------------------------|
| |(10) ACK | |
| |-------------------------------->|
| |(11) ACK answer3| |
| |--------------->|
| | |(12) RTP |
| | |................|
Рисунок 7
Начиная с этого момента новые стороны могут добавляться, удаляться,
переводиться и так далее, как сочтёт нужным контроллер. Во многих
случаях для осуществления этих изменений контроллеру потребуется
изменить SDP, которым обмениваются участники. В частности, в
определённых случаях контроллеру потребуется изменить номер версии в
SDP. Если контроллер сам выпустит предложение SDP (например, чтобы
перевести вызов в удержание), ему потребуется увеличить номер версии в
предложении SDP. Другой участник вызова не будет знать, что контроллер
сделал это, и любое последующее предложение, которое он сгенерирует,
будет иметь неверный номер версии с точки зрения его однорангового
узла. В результате контроллеру потребуется изменять номер версии в
сообщениях SDP, чтобы он соответствовал тому, что ожидает получатель.
Важно отметить, что для использования обработки из этого раздела
вызов не обязательно должен быть установлен контроллером. Напротив,
контроллер мог действовать как B2BUA во время вызова, установленного
A по направлению к B (или наоборот).
8. 3pcc и ранние медиаданные
Ранние медиаданные представляют собой состояние, при котором сеанс
установлен (в результате завершения обмена предложением/ответом), но
сам вызов ещё не принят. Обычно это используется для передачи тоновых
сигналов или объявлений о ходе выполнения вызова. Обработка ранних
медиаданных в вызове с участием третьей стороны проста.
A Controller B
| | |
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
| | |
|<ring> | |
| | |
|<answer> | |
| | |
|(2) 200 answer1 | |
|no media | |
|--------------------->| |
|(3) ACK | |
|<---------------------| |
| |(4) INVITE no SDP |
| |--------------------->|
| | |<ring>
| |(5) 183 offer2 |
| |<---------------------|
|(6) INVITE offer2' | |
|<---------------------| |
|(7) 200 answer2' | |
|--------------------->| |
|(8) ACK | |
|<---------------------| |
| |(9) PRACK answer2 |
| |--------------------->|
| |(10) 200 PRACK |
| |<---------------------|
|(11) RTP | |
|.............................................|
| | |<answer>
| |(12) 200 OK |
| |<---------------------|
| |(13) ACK |
| |--------------------->|
Рисунок 8
Рисунок 8 показывает случай, в котором пользователь B генерирует
ранние медиаданные до ответа на вызов. Поток почти идентичен потоку IV
с рисунка 4. Единственное различие состоит в том, что пользователь B
генерирует надёжный предварительный ответ (5) [6] вместо окончательного
ответа, а answer2 передаётся в PRACK (9), а не в ACK. Когда сторона B
наконец принимает вызов (12), состояние сеанса не изменяется, и,
следовательно, выполнять сигнализацию с пользователем A не требуется.
Контроллер просто подтверждает диалог, отправляя ACK для 200 OK (13).
A Controller B
| | |
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
| | |
|ring | |
| | |
|(2) 183 answer1 | |
|no media | |
|--------------------->| |
|(3) PRACK | |
|<---------------------| |
|(4) 200 PRACK | |
|--------------------->| |
| |(5) INVITE no SDP |
| |--------------------->|
| | |ring
| | |
| | |answer
| | |
| |(6) 200 OK offer2 |
| |<---------------------|
|(7) UPDATE offer2' | |
|<---------------------| |
| | |
|(8) 200 answer2' | |
|--------------------->| |
| |(9) ACK answer2 |
| |--------------------->|
|(10) RTP | |
|.............................................|
| | |
|answer | |
| | |
|(11) 200 OK | |
|--------------------->| |
|(12) ACK | |
|<---------------------| |
Рисунок 9
Случай, в котором пользователь A генерирует ранние медиаданные,
более сложен и показан на рисунке 9. Поток основан на потоке IV.
Контроллер отправляет пользователю A INVITE (1) с предложением,
не содержащим медиапотоков. Пользователь A генерирует надёжный
предварительный ответ (2), содержащий ответ без медиапотоков.
Контроллер отправляет PRACK для этого предварительного ответа (3).
Теперь контроллер отправляет INVITE
без SDP пользователю B (5). Телефон пользователя B звонит, и он
отвечает, в результате чего формируется 200 OK (6) с предложением
offer2. Теперь контроллеру необходимо обновить параметры сеанса с
пользователем A. Однако, поскольку на вызов ещё не был дан ответ, он
не может использовать re-INVITE. Вместо этого он использует запрос SIP
UPDATE (7) [7], передавая предложение (после его изменения для
корректного поля origin). Пользователь A генерирует свой ответ в 200
OK на UPDATE (8). Этот ответ передаётся пользователю B в ACK (9).
Когда пользователь A наконец отвечает (11), состояние сеанса не
изменяется, поэтому контроллер просто отправляет ACK для 200 OK (12).
Обратите внимание, что в этом потоке вызова вероятно обрезание
медиаданных. Пользователь A, вероятно, является шлюзом PSTN и
сгенерировал предварительный ответ из-за ранних медиаданных со стороны
PSTN. PSTN будет передавать эти медиаданные, даже несмотря на то, что
шлюзу некуда их отправлять, поскольку первоначальное предложение от
контроллера не содержало медиапотоков. Когда пользователь B отвечает,
медиаданные могут начать передаваться. Однако все медиаданные,
отправленные в шлюз из PSTN до этого момента, будут потеряны.
9. Управление вызовами третьей стороной и предварительные условия SDP
Было определено расширение SIP, допускающее связывание сигнализации
и резервирования ресурсов [2]. Эта спецификация опирается на
обмены описаниями сеансов до завершения установления вызова.
Эти потоки инициируются, когда определённые параметры SDP
передаются в исходном INVITE. В результате взаимодействие этого
механизма с управлением вызовом третьей стороной не является очевидным
и заслуживает подробного рассмотрения.
9.1. Инициирует контроллер
В одном из сценариев использования контроллер желает использовать
предусловия, чтобы избежать сценариев сбоя вызова, документированных
в разделе 4.4. В частности, контроллер может использовать предусловия,
чтобы гарантировать, что ни одна из сторон не будет оповещена, пока не
появится общий набор медиа и кодеков. Он также может предоставить обеим
сторонам информацию о составе медиа вызова до того, как они решат
принять его.
User A Controller Customer Service
(User B)
| | |
|(1) INVITE no SDP | |
|require precon | |
|<------------------| |
|(2) 183 offer1 | |
|optional precon | |
|------------------>| |
| |(3) INVITE offer1 |
| |------------------>|
| | |
| | |<answer>
| |(4) 200 OK answer1 |
| |no precon |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) PRACK answer1 | |
|<------------------| |
|<ring> | |
| | |
|(7) 200 PRACK | |
|------------------>| |
|<answer> | |
| | |
|(8) 200 INVITE | |
|------------------>| |
|(9) ACK |
|<------------------| |
Рисунок 10
Поток для этого сценария показан на рисунке 10. В этом примере мы
предполагаем, что пользователь B является автоматом или агентом
некоторого рода, который немедленно ответит на вызов. Поэтому поток
основан на потоке I. Контроллер отправляет пользователю A INVITE,
не содержащий SDP, но с заголовком Require, указывающим, что требуются
предусловия. Этот конкретный сценарий (INVITE без предложения, но с
заголовком Require, указывающим на предусловия) не описан в [2].
СЛЕДУЕТ (RECOMMENDED), чтобы UAS отвечал предложением в сообщении 1xx,
включающим потоки медиа, которые он желает использовать для вызова, и
для каждого из них перечислял все поддерживаемые им предусловия как
необязательные. Разумеется, пользователь в этот момент не оповещается.
Контроллер берёт это предложение и передаёт его пользователю B (3).
Пользователь B не поддерживает предусловия либо поддерживает их, но
не заинтересован в них. Поэтому, когда он отвечает на вызов,
сообщение 200 OK содержит ответ без перечисленных предусловий (4).
Этот ответ передаётся пользователю A в PRACK (6). В этот момент
пользователь A знает, что для вызова фактически не используются
предусловия, и поэтому может оповестить пользователя. Когда на вызов
отвечают, пользователь A отправляет контроллеру 200 OK (8), и вызов
завершён.
В случае, если предложение, сформированное пользователем A, было
неприемлемо для пользователя B (например, из-за непересекающихся
кодеков или медиа), пользователь B немедленно отклонил бы INVITE
(сообщение 3). Затем контроллер отправил бы CANCEL для запроса к
пользователю A. В этой ситуации ни пользователь A, ни пользователь B
не были бы оповещены, что обеспечило бы желаемый эффект. Интересно
отметить, что это свойство достигается с помощью предусловий, хотя не
имеет значения, какие именно типы предусловий поддерживаются
пользователем A.
Также вполне возможно, что пользователь B действительно желает
предусловий. В таком случае он мог бы сформировать собственное 1xx с
ответом, содержащим предусловия. Этот ответ всё равно был бы передан
пользователю A, и обе стороны приступили бы к тем мерам, которые
необходимы для выполнения предусловий. Ни один пользователь не был бы
оповещён до выполнения предусловий.
9.2. Инициирует сторона A
В разделе 9.1 контроллер запросил использование предусловий для
достижения конкретной цели. Также возможно, что контроллеру нет дела
до предусловий (или, возможно, он даже не знает о них), но одному из
участников вызова они важны. Поток вызова для этого случая показан на
рисунке 11.
A Controller B
|(1) INVITE offer1 | |
|no media | |
|<---------------------| |
|(2) 183 answer1 | |
|no media | |
|--------------------->| |
|(3) PRACK | |
|<---------------------| |
|(4) 200 OK | |
|--------------------->| |
| |(5) INVITE no SDP |
| |--------------------->|
| |(6) 183 offer2 |
| |des=sendrecv |
| |conf=recv |
| |cur=none |
| |<---------------------|
|(7) UPDATE offer2' | |
|des=sendrecv | |
|conf=recv | |
|cur=none |
|<---------------------| |
|(8) 200 UPDATE | |
|answer2' | |
|des=sendrecv | |
|conf=recv |
|cur=none |
|--------------------->| |
| |(9) PRACK answer2 |
| |des=sendrecv |
| |conf=recv |
| |cur=none |
| |--------------------->|
| |(10) 200 PRACK |
| |<---------------------|
|(11) reservation | |
|-------------------------------------------->|
|(12) reservation | |
|<--------------------------------------------|
|(13) UPDATE offer3 | |
|des=sendrecv | |
|conf=recv |
|cur=recv |
|--------------------->| |
| |(14) UPDATE offer3' |
| |des=sendrecv |
| |conf=recv |
| |cur=recv |
| |--------------------->|
| |(15) 200 UPDATE |
| |answer3' |
| |des=sendrecv |
| |conf=recv |
| |cur=send |
| |<---------------------|
|(16) 200 UPDATE | |
|answer3 | |
|des=sendrecv | |
|conf=recv |
|cur=send |
|<---------------------| |
| | |<ring>
| |(17) UPDATE offer4 |
| |des=sendrecv |
| |conf=recv |
| |cur=sendrecv |
| |<---------------------|
| |(18) UPDATE offer4' |
| |des=sendrecv |
| |conf=recv |
| |cur=sendrecv |
| |<---------------------|
|<ring> | |
|(19) 200 UPDATE | |
|answer4' | |
|des=sendrecv | |
|conf=recv |
|cur=sendrecv |
|--------------------->| |
| |(20) 200 UPDATE |
| |answer4 |
| |des=sendrecv |
| |conf=recv |
| |cur=sendrecv |
| |--------------------->|
| |(21) 180 INVITE |
| |--------------------->|
| |(22) 180 INVITE |
| |<---------------------|
|<answer> | |
|(23) 200 INVITE | |
|--------------------->| |
|(24) ACK | |
|<---------------------| |
| | |<answer>
| |(25) 200 INVITE |
| |<---------------------|
| |(26) ACK |
| |--------------------->|
Рисунок 11
Контроллер следует потоку IV; у него нет конкретных требований к
поддержке спецификации предусловий [2]. Поэтому он отправляет INVITE
(1) с SDP, не содержащим строк медиа. Пользователь A заинтересован в
поддержке предусловий и не хочет, чтобы его телефон звонил, пока не
будут зарезервированы ресурсы. Поскольку в INVITE нет потоков медиа,
он не может резервировать ресурсы для потоков медиа и, следовательно,
не может позволить телефону звонить, пока они не будут переданы в
последующем предложении и затем зарезервированы. Поэтому он формирует
183 с ответом и не оповещает пользователя (2). Контроллер отправляет
PRACK на это сообщение (3), а A отвечает на PRACK (4).
На этом этапе контроллер пытается включить B в вызов. Он
отправляет B INVITE без SDP (5). B заинтересован в наличии
предусловий для этого вызова. Поэтому он формирует своё предложение в
ответе 183, который содержит соответствующие атрибуты SDP (6).
Контроллер передаёт это предложение A в запросе UPDATE (7). Контроллер
использует UPDATE, поскольку на вызов ещё не был дан ответ и,
следовательно, он не может использовать re-INVITE. Пользователь A
видит, что его одноранговая сторона способна поддерживать
предусловия. Поскольку он желает предусловий для вызова, он формирует
ответ в 200 OK (8) на UPDATE. Этот ответ, в свою очередь, передаётся
B в PRACK для предварительного ответа (9). Теперь обе стороны
выполняют резервирование ресурсов. Пользователь A достигает успеха
первым и передаёт обновлённое описание сеанса в запросе UPDATE (13).
Контроллер просто передаёт это A (после манипулирования полем origin,
как требуется в Flow IV) в UPDATE (14), а ответ (15) передаётся
обратно A (16). Тот же поток происходит, но от B к A, когда
резервирование B завершается успешно (17-20). Поскольку предусловия
выполнены, обе стороны подают сигнал вызова (21 и 22), а затем обе
отвечают (23 и 25), завершая вызов.
В этом потоке важно то, что контроллер ничего не знает о
предусловиях. Он лишь передаёт SDP туда и обратно по мере
необходимости. Хитрость заключается в использовании UPDATE и PRACK
для передачи SDP, когда это необходимо. Это решение принимается
исключительно на основе правил предложения/ответа, описанных в [6] и
[7], и не зависит от предусловий.
10. Примеры потоков вызовов
10.1. Click-to-Dial
Первым рассматриваемым нами применением этой возможности является
click-to-dial. В этой услуге пользователь просматривает веб-страницу
сайта электронной коммерции и хотел бы поговорить с представителем
службы поддержки клиентов. Пользователь щёлкает по ссылке, и вызов
направляется представителю службы поддержки клиентов. Когда
представитель снимает трубку, звонит телефон на столе пользователя.
Когда пользователь снимает трубку, представитель службы поддержки
клиентов уже на линии и готов разговаривать с пользователем.
Customer Service Controller User's Phone User's Browser
| |(1) HTTP POST | |
| |<--------------------------------------|
| |(2) HTTP 200 OK | |
| |-------------------------------------->|
|(3) INVITE offer1 | | |
|no media | | |
|<------------------| | |
|(4) 200 answer1 | | |
|no media | | |
|------------------>| | |
|(5) ACK | | |
|<------------------| | |
| |(6) INVITE no SDP | |
| |------------------>| |
| |(7) 200 OK offer2 | |
| |<------------------| |
|(8) INVITE offer2' | | |
|<------------------| | |
|(9) 200 answer2' | | |
|------------------>| | |
| |(10) ACK answer2 | |
| |------------------>| |
| |(11) ACK | |
|<------------------| | |
| |(12) RTP | |
|.......................................| |
Рисунок 12
Поток вызова для этой услуги приведён на Рисунке 12. Он идентичен
потоку на Рисунке 4, за исключением того, что услуга запускается
запросом HTTP POST, когда пользователь щёлкает по ссылке. Обычно этот
POST-запрос не содержал бы ни номера пользователя, ни номера
представителя службы поддержки клиентов. Номер пользователя обычно
получался бы веб-приложением из внутренних баз данных, поскольку
пользователь, предположительно, вошёл бы на сайт, предоставив серверу
необходимый контекст. Номер службы поддержки клиентов обычно
получался бы посредством предварительного конфигурирования
(provisioning). Таким образом, HTTP POST фактически предоставляет
серверу лишь указание на то, что требуется вызов.
Отметим, что эта услуга может предоставляться другими механизмами,
а именно PINT [9]. Однако между способом предоставления услуги PINT и
способом её предоставления здесь имеются многочисленные различия:
o Решение PINT позволяет выполнять вызовы только между двумя
конечными точками PSTN. Описанное здесь решение позволяет
выполнять вызовы между телефонами PSTN (через шлюзы с поддержкой
SIP) и нативными IP-телефонами.
o При использовании для вызовов между двумя телефонами PSTN решение,
описанное здесь, может привести к маршрутизации части вызова через
Интернет. В PINT вызов всегда маршрутизируется только через PSTN.
Это может обеспечить лучшее качество вызовов при использовании
решения PINT в зависимости от используемого кодека и возможностей
QoS сети, маршрутизирующей интернет-часть вызова.
o Решение PINT требует расширений SIP (PINT является расширением
SIP), тогда как описанное здесь решение выполняется с базовым SIP.
o Решение PINT позволяет контроллеру (действующему как клиент PINT)
«выйти» после установления вызова. Описанное здесь решение требует,
чтобы контроллер поддерживал состояние вызова в течение всей
длительности вызова.
10.2. Возможность объявления во время вызова
Описанный здесь механизм управления вызовом третьей стороной также
может использоваться для реализации объявлений во время вызова.
Рассмотрим услугу для предоплаченных телефонных карт. После
установления предоплаченного вызова системе необходимо установить
таймер, который сработает, когда минуты закончатся. Когда этот таймер
срабатывает, мы хотели бы, чтобы пользователь услышал объявление,
сообщающее ему ввести данные кредитной карты, чтобы продолжить. После
того как он вводит данные кредитной карты, к предоплаченной карте
добавляются дополнительные средства, а пользователь повторно
подключается к вызываемой стороне.
Здесь мы рассматриваем использование управления вызовом третьей
стороной исключительно для воспроизведения диалога во время вызова,
предназначенного для сбора сведений о кредитной карте.
Pre-Paid User Controller Called Party Media Server
| |(1) INV SDP c=bh | |
| |------------------>| |
| |(2) 200 answer1 | |
| |<------------------| |
| |(3) ACK | |
| |------------------>| |
|(4) INV no SDP | | |
|<------------------| | |
|(5) 200 offer2 | | |
|------------------>| | |
| |(6) INV offer2 | |
| |-------------------------------------->|
| |(7) 200 answer2 | |
| |<--------------------------------------|
|(8) ACK answer2 | | |
|<------------------| | |
| |(9) ACK | |
| |-------------------------------------->|
|(10) RTP | | |
|...........................................................|
| |(11) BYE | |
| |-------------------------------------->|
| |(12) 200 OK | |
| |<--------------------------------------|
| |(13) INV no SDP | |
| |------------------>| |
| |(14) 200 offer3 | |
| |<------------------|
|(15) INV offer3' | | |
|<------------------| | |
|(16) 200 answer3' | | |
|------------------>| | |
| |(17) ACK answer3' | |
| |------------------>| |
|(18) ACK | | |
|<------------------| | |
|(19) RTP | | |
|.......................................| |
Рисунок 13
Мы предполагаем, что вызов установлен так, что контроллер находится
в вызове в качестве B2BUA. Когда срабатывает таймер, мы хотим
подключить вызывающего абонента к медиасерверу. Поток для этого
показан на Рисунке 13. Когда таймер истекает, контроллер устанавливает
для вызываемой стороны адрес подключения 0.0.0.0 (1). Это фактически
«отключает» вызываемую сторону. Затем контроллер отправляет
предоплаченному вызывающему абоненту INVITE без SDP (4).
Предложение, возвращённое вызывающим абонентом (5), используется в
INVITE к медиасерверу, который будет собирать цифры (6). Это является
экземпляром Flow I. Этот поток можно использовать здесь только
потому, что медиасервер является автоматами (automata) и немедленно
ответит на INVITE. Если бы контроллер соединял предоплаченного
пользователя с другим конечным пользователем, потребовалось бы
использовать Flow III. Медиасервер возвращает немедленный 200 OK (7)
с ответом, который передаётся вызывающему абоненту в ACK (8). В
результате медиапотоки медиасервера и предоплаченного вызывающего
абонента соединены.
Медиасервер воспроизводит объявление и предлагает пользователю ввести
номер кредитной карты. После сбора номера номер карты проверяется.
Затем медиасервер передаёт номер карты контроллеру (используя
некоторое средство, находящееся вне области действия этой
спецификации), а затем завершает вызов (11).
После завершения вызова с медиасервером контроллер повторно соединяет
пользователя с исходной вызываемой стороной. Для этого контроллер
отправляет вызываемой стороне INVITE без SDP (13). 200 OK (14)
содержит предложение offer3. Контроллер изменяет SDP (как это делается
в Flow III) и передаёт предложение в INVITE предоплаченному
пользователю (15). Предоплаченный пользователь формирует ответ в 200
OK (16), который контроллер передаёт пользователю B в ACK (17). На
этом этапе вызывающий абонент и вызываемая сторона повторно соединены.
11. Рекомендации по реализации
Большая часть работы, связанной с поддержкой управления вызовом
третьей стороной, выполняется в контроллере. Стандартным SIP UA
следует иметь возможность управлять с помощью описанных здесь
механизмов. Однако управление вызовом третьей стороной опирается на
несколько возможностей, которые могут быть не реализованы. Поэтому
мы РЕКОМЕНДУЕМ (RECOMMEND), чтобы разработчики серверов пользовательских
агентов поддерживали следующее:
o Предложения и ответы, содержащие строку подключения с адресом
0.0.0.0.
o Запросы re-INVITE, изменяющие порт, на который следует отправлять
медиаданные.
o re-INVITE, изменяющие адрес подключения.
o re-INVITE, добавляющие медиапоток.
o re-INVITE, удаляющие медиапоток (устанавливая его порт в ноль).
o re-INVITE, добавляющие кодек среди набора кодеков в медиапотоке.
o Адрес подключения SDP, равный нулю.
o Исходные запросы INVITE с адресом подключения, равным нулю.
o Исходные запросы INVITE без SDP.
o Исходные запросы INVITE с SDP, но без строк медиаданных.
o re-INVITE без SDP.
o Метод UPDATE [7].
o Надёжность предварительных ответов [6].
o Интеграцию управления ресурсами и SIP [2].
12.1. Авторизация и аутентификация
В большинстве случаев использования SIP INVITE то, принимается ли
вызов, зависит от решения, принимаемого человеком, которому
представлена информация о вызове, например идентичность вызывающего
абонента. В других случаях на вызовы отвечают автоматы, и то,
отвечают ли они, может зависеть от конкретного приложения, в котором
применяется SIP. Например, если вызывающий абонент совершает SIP-вызов
к службе голосового портала, вызов может быть отклонён, если
вызывающий абонент ранее не зарегистрировался (возможно, через
веб-сайт). В других случаях политики обработки вызовов формируются
на основе автоматизированных сценариев, таких как описанные в языке
обработки вызовов (Call Processing Language) [11]. Нередко эти
решения также принимаются на основе идентичности вызывающего
абонента.
Эти механизмы авторизации применялись бы к обычным вызовам первой
стороны и вызовам третьей стороны, поскольку эти два вида вызовов
неразличимы. Вследствие этого важно, чтобы эти политики авторизации
продолжали корректно работать для вызовов третьей стороны. Разумеется,
вызовы третьей стороны вводят новую сторону — сторону, инициирующую
вызов третьей стороны. Применяются ли политики авторизации на основе
идентичности этой третьей стороны или на основе участников вызова?
В идеале участники могли бы знать идентичности обеих других сторон, а
политики авторизации основывались бы на них в соответствующих
случаях. Однако с использованием существующих механизмов это
невозможно. Поэтому следующим наилучшим решением является включение
идентичности третьей стороны в запросы INVITE. В конечном счёте это
пользователь, запрашивающий связь, и разумно, чтобы политики
авторизации вызовов основывались на этой идентичности.
Это, в свою очередь, требует, чтобы контроллер аутентифицировал себя
как эту третью сторону. Это может быть непростой задачей, а
подходящий механизм зависит от конкретного сценария применения.
В одном распространённом сценарии контроллер действует от имени одного
из участников вызова. Типичный пример — click-to-dial, где контроллер
и представитель службы поддержки клиентов управляются одним и тем же
административным доменом. Действительно, для целей идентификации
контроллер может правомерно заявлять, что является представителем
службы поддержки клиентов. В этом сценарии уместно, чтобы INVITE,
направляемый конечному пользователю, содержал поле From, идентифицирующее
представителя службы поддержки клиентов, а запрос аутентифицировался с
использованием S/MIME (см. RFC 3261 [1], раздел 23), подписанного
ключом представителя службы поддержки клиентов (который хранится у
контроллера).
Это требует, чтобы контроллер действительно имел учётные данные, с
помощью которых он может аутентифицировать себя как представителя
службы поддержки клиентов. Во многих других случаях контроллер
представляет одного из участников, но не располагает его учётными
данными. К сожалению, в настоящее время не существует
стандартизированных механизмов, позволяющих пользователю делегировать
учётные данные контроллеру способом, ограничивающим их использование
конкретными операциями управления вызовами третьей стороны. В отсутствие
такого механизмов наилучшее, что можно сделать, — использовать
отображаемое имя в поле From для указания идентичности пользователя,
от имени которого выполняется вызов. СЛЕДУЕТ (RECOMMENDED), чтобы
отображаемому имени присваивалось значение "[controller] on behalf of [user]",
где user и controller являются текстовыми идентичностями пользователя и
контроллера соответственно. В этом случае URI в поле From идентифицировал
бы контроллер.
В других ситуациях между контроллером и участниками вызова нет реальных
отношений. В этих ситуациях в идеале контроллер располагал бы средством
заявить, что вызов исходит от определённой идентичности (которая в
зависимости от приложения могла бы быть одним из участников или даже
третьей стороной), и подтвердить это заявление подписью с использованием
ключа контроллера.
12.2. Сквозное шифрование и целостность
При управлении вызовами третьей стороны контроллер фактически является
одним из участников с точки зрения SIP-диалога. Поэтому шифрование и
целостность SIP-сообщений, обеспечиваемые S/MIME, будут осуществляться
между участниками и контроллером, а не непосредственно между
участниками.
Однако целостность, аутентичность и конфиденциальность медиасеансов
могут обеспечиваться через контроллер. Сквозная безопасность медиа
основана на обмене ключевым материалом в SDP [10].
Правильная работа этих механизмов при управлении вызовами третьей
стороны зависит от надлежащего поведения контроллера. Пока он не
пытается явно отключить эти механизмы, протоколы будут правильно
работать между участниками, обеспечивая защищённый медиасеанс, который
даже контроллер не сможет прослушивать или изменять. Поскольку
управление вызовами третьей стороны основано на модели доверия между
пользователями и контроллером, разумно предполагать, что он ведёт себя
надлежащим образом. Однако не существует криптографического средства,
способного предотвратить вмешательство контроллера в первоначальный
обмен ключевым материалом. Вследствие этого контроллеру тривиально
возможно встроить себя как посредника в обмен медиа, если он того
пожелает.
13. Благодарности
Авторы хотели бы поблагодарить Paul Kyzivat, Rohan Mahy, Eric
Rescorla, Allison Mankin и Sriram Parameswar за их комментарии.
14.1. Нормативные ссылки
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Camarillo, G., Ed., Marshall, W., Ed. and J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Schulzrinne, H., Oran, D. and G. Camarillo, "The Reason Header
Field for the Session Initiation Protocol (SIP)", RFC 3326,
December 2002.
[6] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002.
[7] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
14.2. Информационные ссылки
[8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
3550, July 2003.
[9] Petrack, S. and L. Conroy, "The PINT Service Protocol:
Extensions to SIP and SDP for IP Access to Telephone Call
Services", RFC 2848, June 2000.
[10] Andreasen, F., Baugher, M. and D. Wing, "SDP Security
Descriptions for Media Streams", Work in Progress, October 2003.
[11] Lennox, J., Wu, X. and H. Schulzrinne, "CPL: A Language for User
Control of Internet Telephony Services", Work in Progress,
August 2003.
15. Адреса авторов
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Jon Peterson
Neustar
1800 Sutter Street
Suite 570
Concord, CA 94520
US
Phone: +1 925 363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027
US
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Gonzalo Camarillo
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
EMail: Gonzalo.Camarillo@ericsson.com
16. Полное заявление об авторских правах
Copyright (C) The Internet Society (2004). Этот документ подпадает под
права, лицензии и ограничения, содержащиеся в BCP 78, и, кроме случаев,
установленных в нём, авторы сохраняют все свои права.
Этот документ и содержащаяся в нём информация предоставляются на основе
"КАК ЕСТЬ", И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ ИЛИ
КОТОРАЯ ЕГО/ЕЁ СПОНСИРУЕТ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ), THE INTERNET SOCIETY И
INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ
ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО
ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ,
ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ЛИБО ПРИГОДНОСТИ
ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.