Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)
RFC 3725 описывает лучшие современные практики применения SIP для управления вызовом третьей стороной (3pcc), когда контроллер устанавливает и управляет сеансом между другими участниками. Документ сопоставляет четыре потока установления вызова и рекомендует Flow IV для вызовов к неизвестным адресатам или людям; Flow I следует применять, только когда достоверно известно, что B как автоматизированная система немедленно ответит. Рассмотрены обработка ошибок, дальнейшее управление вызовом через B2BUA, ранний медиаобмен, предусловия SDP, click-to-dial и объявления во время вызова. Также документ определяет рекомендации по поддержке SIP UA и ограничения авторизации, аутентификации и сквозной защиты.
Рабочая группа Network Working Group J. Rosenberg
Запрос комментариев: 3725 dynamicsoft
BCP: 85 J. Peterson
Категория: Лучшая современная практика Neustar
H. Schulzrinne
Columbia University
G. Camarillo
Ericsson
Апрель 2004
Лучшие современные практики управления вызовами третьей стороны (3pcc)
в протоколе установления сессии (SIP)
Статус настоящей записки
Этот документ определяет Internet Best Current Practices для
интернет-сообщества и запрашивает обсуждение и предложения по
улучшениям. Распространение этой записки не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (2004). Все права защищены.
Аннотация
Управление вызовами третьей стороны означает способность одной сущности
создавать вызов, в котором обмен данными фактически происходит между
другими сторонами. Управление вызовами третьей стороны возможно с
использованием механизмов, определённых в протоколе установления сессии
(SIP). Однако существует несколько возможных подходов, каждый со своими
преимуществами и недостатками. В этом документе рассматриваются лучшие
современные практики использования SIP для управления вызовами третьей
стороны.
Содержание
1. Введение . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Терминология . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Определения . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Установление вызова 3pcc . . . . . . . . . . . . . . . . . . 3
4.1. Поток I . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Поток II. . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Поток III . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Поток IV. . . . . . . . . . . . . . . . . . . . . . . . 8
5. Рекомендации . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Обработка ошибок . . . . . . . . . . . . . . . . . . . . . . 10
7. Продолжение обработки . . . . . . . . . . . . . . . . . . . . 11
8. 3pcc и ранние медиа . . . . . . . . . . . . . . . . . . . . . 13
Rosenberg и др. Лучшая современная практика [Страница 1]
RFC 3725 SIP 3pcc Апрель 2004
9. Управление вызовами третьей стороны и предварительные условия SDP . 16
9.1. Инициирует контроллер . . . . . . . . . . . . . . . . . 16
9.2. Инициирует сторона A. . . . . . . . . . . . . . . . . . 18
10. Примеры потоков вызовов . . . . . . . . . . . . . . . . . . . 21
10.1. Click-to-Dial. . . . . . . . . . . . . . . . . . . . . 21
10.2. Возможность объявления в ходе вызова . . . . . . . . . . 23
11. Рекомендации по реализации . . . . . . . . . . . . . . . . . 25
12. Соображения безопасности. . . . . . . . . . . . . . . . . . . 26
12.1. Авторизация и аутентификация . . . . . . . . . . . . . . 26
12.2. Сквозное шифрование и целостность. . . . . . . . . . . . 27
13. Выражение признательности . . . . . . . . . . . . . . . . . . 28
14. Ссылки . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.1. Нормативные ссылки . . . . . . . . . . . . . . . . . . . 28
14.2. Информативные ссылки . . . . . . . . . . . . . . . . . . 29
15. Адреса авторов . . . . . . . . . . . . . . . . . . . . . . . 30
16. Полное заявление об авторских правах . . . . . . . . . . . . . 31
1. Введение
В традиционном контексте телефонии управление вызовами третьей стороны
позволяет одной сущности (которую мы называем контроллером) устанавливать
и управлять коммуникационным отношением между двумя или более другими
сторонами. Управление вызовами третьей стороны (именуемое 3pcc) часто
используется для операторских услуг (когда оператор создаёт вызов,
соединяющий двух участников) и конференций.
Аналогично, посредством управления вызовами третьей стороны возможны
многие службы SIP. К ним относятся традиционные службы в PSTN, а также
новые, такие как click-to-dial. Click-to-dial позволяет пользователю
щёлкнуть веб-страницу, когда он желает поговорить с представителем службы
поддержки клиентов. Затем веб-сервер создаёт вызов между пользователем и
представителем службы поддержки клиентов. Вызов может быть между двумя
телефонами, телефоном и IP-узлом или двумя IP-узлами.
Управление вызовами третьей стороны возможно, используя только механизмы,
определённые в RFC 3261 [1]. Действительно, возможны многие различные
потоки вызовов, каждый из которых будет работать с SIP-совместимыми
пользовательскими агентами. Однако каждый из этих потоков имеет
преимущества и недостатки. Использование управления вызовами третьей
стороны также становится более сложным, когда аспекты вызова используют
расширения SIP или необязательные возможности SIP. В частности,
использование RFC 3312 [2] (применяемого для связывания сигнализации с
резервированием ресурсов) вместе с управлением вызовами третьей стороны
нетривиально и рассматривается в разделе 9. Аналогично, использование
ранних медиа (когда данные сессии обмениваются до принятия вызова) вместе
с управлением вызовами третьей стороны нетривиально; оба они определяют
способ, которым пользовательские агенты создают SDP и отвечают на него, и
неясно, как выполнять оба действия одновременно. Это подробнее
рассматривается в разделе 8.
Rosenberg и др. Лучшая современная практика [Страница 2]
RFC 3725 SIP 3pcc Апрель 2004
Этот документ служит лучшей современной практикой реализации управления
вызовами третьей стороны без использования каких-либо расширений,
специально разработанных для этой цели. В разделе 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. Установление этой
сессии координируется третьей стороной, именуемой контроллером.
В этом разделе документируются три потока вызовов, которые контроллер
может использовать для предоставления этой элементарной операции.
Rosenberg и др. Лучшая современная практика [Страница 3]
RFC 3725 SIP 3pcc Апрель 2004
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.
Rosenberg и др. Лучшая современная практика [Страница 4]
RFC 3725 SIP 3pcc Апрель 2004
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 это предложение. К счастью, все
действительные ответы являются действительными
Rosenberg и др. Лучшая современная практика [Страница 5]
RFC 3725 SIP 3pcc Апрель 2004
начальными предложениями. Этот 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).
Rosenberg, et al. Best Current Practice [Page 6]
RFC 3725 SIP 3pcc April 2004
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
Rosenberg, et al. Best Current Practice [Page 8]
RFC 3725 SIP 3pcc April 2004
Поток 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 со свойством, что пакеты, отправленные на
него, никогда не покидают отправивший их хост; они просто
Rosenberg, et al. Best Current Practice [Page 9]
RFC 3725 SIP 3pcc April 2004
отбрасываются. Поэтому эти потоки специфичны для 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
Rosenberg, et al. Best Current Practice [Page 10]
RFC 3725 SIP 3pcc April 2004
Ещё одно заслуживающее обсуждения условие ошибки показано на рисунке 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 с этим
Rosenberg, et al. Best Current Practice [Страница 11]
RFC 3725 SIP 3pcc Апрель 2004
участником. Поток вызова для этого показан на рисунке 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, чтобы он соответствовал тому, что ожидает получатель.
Rosenberg, et al. Best Current Practice [Страница 12]
RFC 3725 SIP 3pcc Апрель 2004
Важно отметить, что для использования обработки из этого раздела
вызов не обязательно должен быть установлен контроллером. Напротив,
контроллер мог действовать как B2BUA во время вызова, установленного
A по направлению к B (или наоборот).
8. 3pcc и ранние медиаданные
Ранние медиаданные представляют собой состояние, при котором сеанс
установлен (в результате завершения обмена предложением/ответом), но
сам вызов ещё не принят. Обычно это используется для передачи тоновых
сигналов или объявлений о ходе выполнения вызова. Обработка ранних
медиаданных в вызове с участием третьей стороны проста.
Rosenberg, et al. Best Current Practice [Страница 13]
RFC 3725 SIP 3pcc Апрель 2004
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).
Rosenberg, et al. Best Current Practice [Страница 14]
RFC 3725 SIP 3pcc Апрель 2004
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
Rosenberg, et al. Best Current Practice [Страница 15]
RFC 3725 SIP 3pcc Апрель 2004
без 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. В частности, контроллер может использовать предусловия,
чтобы гарантировать, что ни одна из сторон не будет оповещена, пока не
появится общий набор медиа и кодеков. Он также может предоставить обеим
сторонам информацию о составе медиа вызова до того, как они решат
принять его.
Rosenberg, et al. Best Current Practice [Page 16]
RFC 3725 SIP 3pcc April 2004
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 не поддерживает предусловия либо поддерживает их, но
Rosenberg, et al. Best Current Practice [Page 17]
RFC 3725 SIP 3pcc April 2004
не заинтересован в них. Поэтому, когда он отвечает на вызов,
сообщение 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 |
Rosenberg, et al. Best Current Practice [Page 18]
RFC 3725 SIP 3pcc April 2004
| |<---------------------|
|(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 |
Rosenberg, et al. Best Current Practice [Page 19]
RFC 3725 SIP 3pcc April 2004
| |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).
Rosenberg, et al. Best Current Practice [Page 20]
RFC 3725 SIP 3pcc April 2004
На этом этапе контроллер пытается включить 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. В этой услуге пользователь просматривает веб-страницу
сайта электронной коммерции и хотел бы поговорить с представителем
службы поддержки клиентов. Пользователь щёлкает по ссылке, и вызов
направляется представителю службы поддержки клиентов. Когда
представитель снимает трубку, звонит телефон на столе пользователя.
Когда пользователь снимает трубку, представитель службы поддержки
клиентов уже на линии и готов разговаривать с пользователем.
Rosenberg, et al. Лучшая современная практика [Страница 21]
RFC 3725 SIP 3pcc Апрель 2004
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 и
способом её предоставления здесь имеются многочисленные различия:
Rosenberg, et al. Лучшая современная практика [Страница 22]
RFC 3725 SIP 3pcc Апрель 2004
o Решение PINT позволяет выполнять вызовы только между двумя
конечными точками PSTN. Описанное здесь решение позволяет
выполнять вызовы между телефонами PSTN (через шлюзы с поддержкой
SIP) и нативными IP-телефонами.
o При использовании для вызовов между двумя телефонами PSTN решение,
описанное здесь, может привести к маршрутизации части вызова через
Интернет. В PINT вызов всегда маршрутизируется только через PSTN.
Это может обеспечить лучшее качество вызовов при использовании
решения PINT в зависимости от используемого кодека и возможностей
QoS сети, маршрутизирующей интернет-часть вызова.
o Решение PINT требует расширений SIP (PINT является расширением
SIP), тогда как описанное здесь решение выполняется с базовым SIP.
o Решение PINT позволяет контроллеру (действующему как клиент PINT)
«выйти» после установления вызова. Описанное здесь решение требует,
чтобы контроллер поддерживал состояние вызова в течение всей
длительности вызова.
10.2. Возможность объявления во время вызова
Описанный здесь механизм управления вызовом третьей стороной также
может использоваться для реализации объявлений во время вызова.
Рассмотрим услугу для предоплаченных телефонных карт. После
установления предоплаченного вызова системе необходимо установить
таймер, который сработает, когда минуты закончатся. Когда этот таймер
срабатывает, мы хотели бы, чтобы пользователь услышал объявление,
сообщающее ему ввести данные кредитной карты, чтобы продолжить. После
того как он вводит данные кредитной карты, к предоплаченной карте
добавляются дополнительные средства, а пользователь повторно
подключается к вызываемой стороне.
Здесь мы рассматриваем использование управления вызовом третьей
стороной исключительно для воспроизведения диалога во время вызова,
предназначенного для сбора сведений о кредитной карте.
Rosenberg, et al. Лучшая современная практика [Страница 23]
RFC 3725 SIP 3pcc Апрель 2004
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).
Rosenberg, et al. Лучшая современная практика [Страница 24]
RFC 3725 SIP 3pcc Апрель 2004
Предложение, возвращённое вызывающим абонентом (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, добавляющие кодек среди набора кодеков в медиапотоке.
Rosenberg, et al. Лучшая современная практика [Страница 25]
RFC 3725 SIP 3pcc Апрель 2004
o Адрес подключения SDP, равный нулю.
o Исходные запросы INVITE с адресом подключения, равным нулю.
o Исходные запросы INVITE без SDP.
o Исходные запросы INVITE с SDP, но без строк медиаданных.
o re-INVITE без SDP.
o Метод UPDATE [7].
o Надёжность предварительных ответов [6].
o Интеграцию управления ресурсами и SIP [2].
12. Вопросы безопасности
12.1. Авторизация и аутентификация
В большинстве случаев использования SIP INVITE то, принимается ли
вызов, зависит от решения, принимаемого человеком, которому
представлена информация о вызове, например идентичность вызывающего
абонента. В других случаях на вызовы отвечают автоматы, и то,
отвечают ли они, может зависеть от конкретного приложения, в котором
применяется SIP. Например, если вызывающий абонент совершает SIP-вызов
к службе голосового портала, вызов может быть отклонён, если
вызывающий абонент ранее не зарегистрировался (возможно, через
веб-сайт). В других случаях политики обработки вызовов формируются
на основе автоматизированных сценариев, таких как описанные в языке
обработки вызовов (Call Processing Language) [11]. Нередко эти
решения также принимаются на основе идентичности вызывающего
абонента.
Эти механизмы авторизации применялись бы к обычным вызовам первой
стороны и вызовам третьей стороны, поскольку эти два вида вызовов
неразличимы. Вследствие этого важно, чтобы эти политики авторизации
продолжали корректно работать для вызовов третьей стороны. Разумеется,
вызовы третьей стороны вводят новую сторону — сторону, инициирующую
вызов третьей стороны. Применяются ли политики авторизации на основе
идентичности этой третьей стороны или на основе участников вызова?
В идеале участники могли бы знать идентичности обеих других сторон, а
политики авторизации основывались бы на них в соответствующих
случаях. Однако с использованием существующих механизмов это
невозможно. Поэтому следующим наилучшим решением является включение
идентичности третьей стороны в запросы INVITE. В конечном счёте это
пользователь, запрашивающий связь, и разумно, чтобы политики
авторизации вызовов основывались на этой идентичности.
Rosenberg, et al. Best Current Practice [Page 26]
RFC 3725 SIP 3pcc April 2004
Это, в свою очередь, требует, чтобы контроллер аутентифицировал себя
как эту третью сторону. Это может быть непростой задачей, а
подходящий механизм зависит от конкретного сценария применения.
В одном распространённом сценарии контроллер действует от имени одного
из участников вызова. Типичный пример — 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].
Rosenberg, et al. Best Current Practice [Page 27]
RFC 3725 SIP 3pcc April 2004
Правильная работа этих механизмов при управлении вызовами третьей
стороны зависит от надлежащего поведения контроллера. Пока он не
пытается явно отключить эти механизмы, протоколы будут правильно
работать между участниками, обеспечивая защищённый медиасеанс, который
даже контроллер не сможет прослушивать или изменять. Поскольку
управление вызовами третьей стороны основано на модели доверия между
пользователями и контроллером, разумно предполагать, что он ведёт себя
надлежащим образом. Однако не существует криптографического средства,
способного предотвратить вмешательство контроллера в первоначальный
обмен ключевым материалом. Вследствие этого контроллеру тривиально
возможно встроить себя как посредника в обмен медиа, если он того
пожелает.
13. Благодарности
Авторы хотели бы поблагодарить Paul Kyzivat, Rohan Mahy, Eric
Rescorla, Allison Mankin и Sriram Parameswar за их комментарии.
14. Ссылки
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.
Rosenberg, et al. Best Current Practice [Page 28]
RFC 3725 SIP 3pcc April 2004
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.
Rosenberg, et al. Best Current Practice [Page 29]
RFC 3725 SIP 3pcc April 2004
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
Rosenberg, et al. Best Current Practice [Page 30]
RFC 3725 SIP 3pcc April 2004
16. Полное заявление об авторских правах
Copyright (C) The Internet Society (2004). Этот документ подпадает под
права, лицензии и ограничения, содержащиеся в BCP 78, и, кроме случаев,
установленных в нём, авторы сохраняют все свои права.
Этот документ и содержащаяся в нём информация предоставляются на основе
"КАК ЕСТЬ", И УЧАСТНИК, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ ИЛИ
КОТОРАЯ ЕГО/ЕЁ СПОНСИРУЕТ (ЕСЛИ ТАКОВАЯ ИМЕЕТСЯ), THE INTERNET SOCIETY И
INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ
ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО
ИСПОЛЬЗОВАНИЕ СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ,
ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ЛИБО ПРИГОДНОСТИ
ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Интеллектуальная собственность
IETF не занимает позиции относительно действительности или объёма каких-либо
прав интеллектуальной собственности либо иных прав, которые могут быть
заявлены как относящиеся к реализации или использованию технологии,
описанной в этом документе, или относительно того, может ли быть доступна
какая-либо лицензия в рамках таких прав; также IETF не заявляет, что
предприняла какие-либо независимые усилия по выявлению таких прав.
Информацию о процедурах в отношении прав в документах RFC можно найти в
BCP 78 и BCP 79.
Копии раскрытий IPR, направленных в Секретариат IETF, и любые заверения о
лицензиях, которые будут предоставлены, либо результат попытки получить
общую лицензию или разрешение на использование таких прав собственности
разработчиками или пользователями этой спецификации можно получить из
онлайнового репозитория IPR IETF по адресу http://www.ietf.org/ipr.
IETF приглашает любую заинтересованную сторону довести до её сведения
информацию о любых авторских правах, патентах или патентных заявках либо
иных правах собственности, которые могут охватывать технологию, которая
может потребоваться для реализации этого стандарта. Просьба направлять
информацию в IETF по адресу ietf-ipr@ietf.org.
Благодарность
Финансирование функции RFC Editor в настоящее время предоставляется
The Internet Society.
Rosenberg, et al. Best Current Practice [Page 31]
Network Working Group J. Rosenberg
Request for Comments: 3725 dynamicsoft
BCP: 85 J. Peterson
Category: Best Current Practice Neustar
H. Schulzrinne
Columbia University
G. Camarillo
Ericsson
April 2004
Best Current Practices for Third Party Call Control (3pcc)
in the Session Initiation Protocol (SIP)
Status of this Memo
This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Third party call control refers to the ability of one entity to
create a call in which communication is actually between other
parties. Third party call control is possible using the mechanisms
specified within the Session Initiation Protocol (SIP). However,
there are several possible approaches, each with different benefits
and drawbacks. This document discusses best current practices for
the usage of SIP for third party call control.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
4. 3pcc Call Establishment . . . . . . . . . . . . . . . . . . 3
4.1. Flow I . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. Flow II. . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Flow III . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Flow IV. . . . . . . . . . . . . . . . . . . . . . . . 8
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . 9
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 10
7. Continued Processing . . . . . . . . . . . . . . . . . . . . 11
8. 3pcc and Early Media . . . . . . . . . . . . . . . . . . . . 13
Rosenberg, et al. Best Current Practice [Page 1]
RFC 3725 SIP 3pcc April 2004
9. Third Party Call Control and SDP Preconditions . . . . . . . 16
9.1. Controller Initiates . . . . . . . . . . . . . . . . . 16
9.2. Party A Initiates. . . . . . . . . . . . . . . . . . . 18
10. Example Call Flows . . . . . . . . . . . . . . . . . . . . . 21
10.1. Click-to-Dial. . . . . . . . . . . . . . . . . . . . . 21
10.2. Mid-Call Announcement Capability . . . . . . . . . . . 23
11. Implementation Recommendations . . . . . . . . . . . . . . . 25
12. Security Considerations. . . . . . . . . . . . . . . . . . . 26
12.1. Authorization and Authentication . . . . . . . . . . . 26
12.2. End-to-End Encryption and Integrity. . . . . . . . . . 27
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.1. Normative References . . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . 29
15. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
16. Full Copyright Statement . . . . . . . . . . . . . . . . . . 31
1. Introduction
In the traditional telephony context, third party call control allows
one entity (which we call the controller) to set up and manage a
communications relationship between two or more other parties. Third
party call control (referred to as 3pcc) is often used for operator
services (where an operator creates a call that connects two
participants together) and conferencing.
Similarly, many SIP services are possible through third party call
control. These include the traditional ones on the PSTN, but also
new ones such as click-to-dial. Click-to-dial allows a user to click
on a web page when they wish to speak to a customer service
representative. The web server then creates a call between the user
and a customer service representative. The call can be between two
phones, a phone and an IP host, or two IP hosts.
Third party call control is possible using only the mechanisms
specified within RFC 3261 [1]. Indeed, many different call flows are
possible, each of which will work with SIP compliant user agents.
However, there are benefits and drawbacks to each of these flows.
The usage of third party call control also becomes more complex when
aspects of the call utilize SIP extensions or optional features of
SIP. In particular, the usage of RFC 3312 [2] (used for coupling of
signaling to resource reservation) with third party call control is
non-trivial, and is discussed in Section 9. Similarly, the usage of
early media (where session data is exchanged before the call is
accepted) with third party call control is not trivial; both of them
specify the way in which user agents generate and respond to SDP, and
it is not clear how to do both at the same time. This is discussed
further in Section 8.
Rosenberg, et al. Best Current Practice [Page 2]
RFC 3725 SIP 3pcc April 2004
This document serves as a best current practice for implementing
third party call control without usage of any extensions specifically
designed for that purpose. Section 4 presents the known call flows
that can be used to achieve third party call control, and provides
guidelines on their usage. Section 9 discusses the interactions of
RFC 3312 [2] with third party call control. Section 8 discusses the
interactions of early media with third party call control. Section
10 provides example applications that make usage of the flows
recommended here.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and
indicate requirement levels for compliant implementations.
3. Definitions
The following terms are used throughout this document:
3pcc: Third Party Call Control, which refers to the general ability
to manipulate calls between other parties.
Controller: A controller is a SIP User Agent that wishes to create a
session between two other user agents.
4. 3pcc Call Establishment
The primary primitive operation of third party call control is the
establishment of a session between participants A and B.
Establishment of this session is orchestrated by a third party,
referred to as the controller.
This section documents three call flows that the controller can
utilize in order to provide this primitive operation.
Rosenberg, et al. Best Current Practice [Page 3]
RFC 3725 SIP 3pcc April 2004
4.1. Flow 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 | |
|.......................................|
Figure 1
The call flow for Flow I is shown in Figure 1. The controller first
sends an INVITE A (1). This INVITE has no session description. A's
phone rings, and A answers. This results in a 200 OK (2) that
contains an offer [4]. The controller needs to send its answer in
the ACK, as mandated by [1]. To obtain the answer, it sends the
offer it got from A (offer1) in an INVITE to B (3). B's phone rings.
When B answers, the 200 OK (4) contains the answer to this offer,
answer1. The controller sends an ACK to B (5), and then passes
answer1 to A in an ACK sent to it (6). Because the offer was
generated by A, and the answer generated by B, the actual media
session is between A and B. Therefore, media flows between them (7).
This flow is simple, requires no manipulation of the SDP by the
controller, and works for any media types supported by both
endpoints. However, it has a serious timeout problem. User B may
not answer the call immediately. The result is that the controller
cannot send the ACK to A right away. This causes A to retransmit the
200 OK response periodically. As specified in RFC 3261 Section
13.3.1.4, the 200 OK will be retransmitted for 64*T1 seconds. If an
ACK does not arrive by then, the call is considered to have failed.
This limits the applicability of this flow to scenarios where the
controller knows that B will answer the INVITE immediately.
Rosenberg, et al. Best Current Practice [Page 4]
RFC 3725 SIP 3pcc April 2004
4.2. Flow 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 | |
|.......................................|
Figure 2
An alternative flow, Flow II, is shown in Figure 2. The controller
first sends an INVITE to user A (1). This is a standard INVITE,
containing an offer (sdp1) with a single audio media line, one codec,
a random port number (but not zero), and a connection address of
0.0.0.0. This creates an initial media stream that is "black holed",
since no media (or RTCP packets [8]) will flow from A. The INVITE
causes A's phone to ring.
Note that the usage of 0.0.0.0, though recommended by RFC 3264,
has numerous drawbacks. It is anticipated that a future
specification will recommend usage of a domain within the .invalid
DNS top level domain instead of the 0.0.0.0 IP address. As a
result, implementors are encouraged to track such developments
once they arise.
When A answers (2), the 200 OK contains an answer, sdp2, with a valid
address in the connection line. The controller sends an ACK (4). It
then generates a second INVITE (3). This INVITE is addressed to user
B, and it contains sdp2 as the offer to B. Note that the role of sdp2
has changed. In the 200 OK (message 2), it was an answer, but in the
INVITE, it is an offer. Fortunately, all valid answers are valid
Rosenberg, et al. Best Current Practice [Page 5]
RFC 3725 SIP 3pcc April 2004
initial offers. This INVITE causes B's phone to ring. When it
answers, it generates a 200 OK (5) with an answer, sdp3. The
controller then generates an ACK (6). Next, it sends a re-INVITE to
A (7) containing sdp3 as the offer. Once again, there has been a
reversal of roles. sdp3 was an answer, and now it is an offer.
Fortunately, an answer to an answer recast as an offer is, in turn, a
valid offer. This re-INVITE generates a 200 OK (8) with sdp2,
assuming that A doesn't decide to change any aspects of the session
as a result of this re-INVITE. This 200 OK is ACKed (9), and then
media can flow from A to B. Media from B to A could already start
flowing once message 5 was sent.
This flow has the advantage that all final responses are immediately
ACKed. It therefore does not suffer from the timeout and message
inefficiency problems of flow 1. However, it too has troubles.
First off, it requires that the controller know the media types to be
used for the call (since it must generate a "blackhole" SDP, which
requires media lines). Secondly, the first INVITE to A (1) contains
media with a 0.0.0.0 connection address. The controller expects that
the response contains a valid, non-zero connection address for A.
However, experience has shown that many UAs respond to an offer of a
0.0.0.0 connection address with an answer containing a 0.0.0.0
connection address. The offer-answer specification [4] explicitly
tells implementors not to do this, but at the time of publication of
this document, many implementations still did. If A should respond
with a 0.0.0.0 connection address in sdp2, the flow will not work.
However, the most serious flaw in this flow is the assumption that
the 200 OK to the re-INVITE (message 8) contains the same SDP as in
message 2. This may not be the case. If it is not, the controller
needs to re-INVITE B with that SDP (say, sdp4), which may result in
getting a different SDP, sdp5, in the 200 OK from B. Then, the
controller needs to re-INVITE A again, and so on. The result is an
infinite loop of re-INVITEs. It is possible to break this cycle by
having very smart UAs which can return the same SDP whenever
possible, or really smart controllers that can analyze the SDP to
determine if a re-INVITE is really needed. However, we wish to keep
this mechanism simple, and avoid SDP awareness in the controller. As
a result, this flow is not really workable. It is therefore NOT
RECOMMENDED.
Rosenberg, et al. Best Current Practice [Page 6]
RFC 3725 SIP 3pcc April 2004
4.3. Flow 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 | |
|.............................................|
Figure 3
A third flow, Flow III, is shown in Figure 3.
First, the controller sends an INVITE (1) to user A without any SDP
(which is good, since it means that the controller doesn't need to
assume anything about the media composition of the session). A's
phone rings. When A answers, a 200 OK is generated (2) containing
its offer, offer1. The controller generates an immediate ACK
containing an answer (3). This answer is a "black hole" SDP, with
its connection address equal to 0.0.0.0.
The controller then sends an INVITE to B without SDP (4). This
causes B's phone to ring. When they answer, a 200 OK is sent,
containing their offer, offer2 (5). This SDP is used to create a
re-INVITE back to A (6). That re-INVITE is based on offer2, but may
need to be reorganized to match up media lines, or to trim media
lines. For example, if offer1 contained an audio and a video line,
in that order, but offer2 contained just an audio line, the
controller would need to add a video line to the offer (setting its
port to zero) to create offer2'. Since this is a re-INVITE, it
should complete quickly in the general case. That's good, since user
B is retransmitting their 200 OK, waiting for an ACK. The SDP in the
Rosenberg, et al. Best Current Practice [Page 7]
RFC 3725 SIP 3pcc April 2004
200 OK (7) from A, answer2', may also need to be reorganized or
trimmed before sending it an the ACK to B (8) as answer2. Finally,
an ACK is sent to A (9), and then media can flow.
This flow has many benefits. First, it will usually operate without
any spurious retransmissions or timeouts (although this may still
happen if a re-INVITE is not responded to quickly). Secondly, it
does not require the controller to guess the media that will be used
by the participants.
There are some drawbacks. The controller does need to perform SDP
manipulations. Specifically, it must take some SDP, and generate
another SDP which has the same media composition, but has connection
addresses equal to 0.0.0.0. This is needed for message 3. Secondly,
it may need to reorder and trim SDP X, so that its media lines match
up with those in some other SDP, Y. Thirdly, the offer from B
(offer2) may have no codecs or media streams in common with the offer
from A (offer 1). The controller will need to detect this condition,
and terminate the call. Finally, the flow is far more complicated
than the simple and elegant Flow I (Figure 1).
4.4. Flow 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 | |
|.............................................|
Figure 4
Rosenberg, et al. Best Current Practice [Page 8]
RFC 3725 SIP 3pcc April 2004
Flow IV shows a variation on Flow III that reduces its complexity.
The actual message flow is identical, but the SDP placement and
construction differs. The initial INVITE (1) contains SDP with no
media at all, meaning that there are no m lines. This is valid, and
implies that the media makeup of the session will be established
later through a re-INVITE [4]. Once the INVITE is received, user A
is alerted. When they answer the call, the 200 OK (2) has an answer
with no media either. This is acknowledged by the controller (3).
The flow from this point onwards is identical to Flow III. However,
the manipulations required to convert offer2 to offer2', and answer2'
to answer2, are much simpler. Indeed, no media manipulations are
needed at all. The only change that is needed is to modify the
origin lines, so that the origin line in offer2' is valid based on
the value in offer1 (validity requires that the version increments by
one, and that the other parameters remain unchanged).
There are some limitations associated with this flow. First, user A
will be alerted without any media having been established yet. This
means that user A will not be able to reject or accept the call based
on its media composition. Secondly, both A and B will end up
answering the call (i.e., generating a 200 OK) before it is known
whether there is compatible media. If there is no media in common,
the call can be terminated later with a BYE. However, the users will
have already been alerted, resulting in user annoyance and possibly
resulting in billing events.
5. Recommendations
Flow I (Figure 1) represents the simplest and the most efficient
flow. This flow SHOULD be used by a controller if it knows with
certainty that user B is actually an automata that will answer the
call immediately. This is the case for devices such as media
servers, conferencing servers, and messaging servers, for example.
Since we expect a great deal of third party call control to be to
automata, special casing in this scenario is reasonable.
For calls to unknown entities, or to entities known to represent
people, it is RECOMMENDED that Flow IV (Figure 4) be used for third
party call control. Flow III MAY be used instead, but it provides no
additional benefits over Flow IV. However, Flow II SHOULD NOT be
used, because of the potential for infinite ping-ponging of re-
INVITEs.
Several of these flows use a "black hole" connection address of
0.0.0.0. This is an IPv4 address with the property that packets sent
to it will never leave the host which sent them; they are just
Rosenberg, et al. Best Current Practice [Page 9]
RFC 3725 SIP 3pcc April 2004
discarded. Those flows are therefore specific to IPv4. For other
network or address types, an address with an equivalent property
SHOULD be used.
In most cases, including the recommended flows, user A will hear
silence while the call to B completes. This may not always be ideal.
It can be remedied by connecting the caller to a music-on-hold source
while the call to B occurs.
6. Error Handling
There are numerous error cases which merit discussion.
With all of the call flows in Section 4, one call is established to
A, and then the controller attempts to establish a call to B.
However, this call attempt may fail, for any number of reasons. User
B might be busy (resulting in a 486 response to the INVITE), there
may not be any media in common, the request may time out, and so on.
If the call attempt to B should fail, it is RECOMMENDED that the
controller send a BYE to A. This BYE SHOULD include a Reason header
[5] which carries the status code from the error response. This will
inform A of the precise reason for the failure. The information is
important from a user interface perspective. For example, if A was
calling from a black phone, and B generated a 486, the BYE will
contain a Reason code of 486, and this could be used to generate a
local busy signal so that A knows that B is busy.
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 | |
|--------------------->| |
Figure 5
Rosenberg, et al. Best Current Practice [Page 10]
RFC 3725 SIP 3pcc April 2004
Another error condition worth discussion is shown in Figure 5. After
the controller establishes the dialog with A (messages 1-3) it
attempts to contact B (message 4). Contacting B may take some time.
During that interval, A could possibly attempt a re-INVITE, providing
an updated offer. However, the controller cannot pass this offer on
to B, since it has an INVITE transaction pending with it. As a
result, the controller needs to reject the request. It is
RECOMMENDED that a 491 response be used. The situation here is
similar to the glare condition described in [1], and thus the same
error handling is sensible. However, A is likely to retry its
request (as a result of the 491), and this may occur before the
exchange with B is completed. In that case, the controller would
respond with another 491.
7. Continued Processing
Once the calls are established, both participants believe they are in
a single point-to-point call. However, they are exchanging media
directly with each other, rather than with the controller. The
controller is involved in two dialogs, yet sees no media.
Since the controller is still a central point for signaling, it now
has complete control over the call. If it receives a BYE from one of
the participants, it can create a new BYE and hang up with the other
participant. This is shown in Figure 6.
A Controller B
|(1) BYE | |
|------------------>| |
|(2) 200 OK | |
|<------------------| |
| |(3) BYE |
| |------------------>|
| |(4) 200 OK |
| |<------------------|
Figure 6
Similarly, if it receives a re-INVITE from one of the participants,
it can forward it to the other participant. Depending on which flow
was used, this may require some manipulation on the SDP before
passing it on.
However, the controller need not "proxy" the SIP messages received
from one of the parties. Since it is a Back-to-Back User Agent
(B2BUA), it can invoke any signaling mechanism on each dialog, as it
sees fit. For example, if the controller receives a BYE from A, it
can generate a new INVITE to a third party, C, and connect B to that
Rosenberg, et al. Best Current Practice [Page 11]
RFC 3725 SIP 3pcc April 2004
participant instead. A call flow for this is shown in Figure 7,
assuming the case where C represents an end user, not an automata.
Note that it is just Flow 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 |
| | |................|
Figure 7
From here, new parties can be added, removed, transferred, and so on,
as the controller sees fit. In many cases, the controller will be
required to modify the SDP exchanged between the participants in
order to affect these changes. In particular, the version number in
the SDP will need to be changed by the controller in certain cases.
If the controller should issue an SDP offer on its own (for example,
to place a call on hold), it will need to increment the version
number in the SDP offer. The other participant in the call will not
know that the controller has done this, and any subsequent offer it
generates will have the wrong version number as far as its peer is
concerned. As a result, the controller will be required to modify
the version number in SDP messages to match what the recipient is
expecting.
Rosenberg, et al. Best Current Practice [Page 12]
RFC 3725 SIP 3pcc April 2004
It is important to point out that the call need not have been
established by the controller in order for the processing of this
section to be used. Rather, the controller could have acted as a
B2BUA during a call established by A towards B (or vice versa).
8. 3pcc and Early Media
Early media represents the condition where the session is established
(as a result of the completion of an offer/answer exchange), yet the
call itself has not been accepted. This is usually used to convey
tones or announcements regarding progress of the call. Handling of
early media in a third party call is straightforward.
Rosenberg, et al. Best Current Practice [Page 13]
RFC 3725 SIP 3pcc April 2004
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 |
| |--------------------->|
Figure 8
Figure 8 shows the case where user B generates early media before
answering the call. The flow is almost identical to Flow IV from
Figure 4. The only difference is that user B generates a reliable
provisional response (5) [6] instead of a final response, and answer2
is carried in a PRACK (9) instead of an ACK. When party B finally
does accept the call (12), there is no change in the session state,
and therefore, no signaling needs to be done with user A. The
controller simply ACKs the 200 OK (13) to confirm the dialog.
Rosenberg, et al. Best Current Practice [Page 14]
RFC 3725 SIP 3pcc April 2004
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 | |
|<---------------------| |
Figure 9
The case where user A generates early media is more complicated, and
is shown in Figure 9. The flow is based on Flow IV. The controller
sends an INVITE to user A (1), with an offer containing no media
streams. User A generates a reliable provisional response (2)
containing an answer with no media streams. The controller PRACKs
this provisional response (3). Now, the controller sends an INVITE
Rosenberg, et al. Best Current Practice [Page 15]
RFC 3725 SIP 3pcc April 2004
without SDP to user B (5). User B's phone rings, and they answer,
resulting in a 200 OK (6) with an offer, offer2. The controller now
needs to update the session parameters with user A. However, since
the call has not been answered, it cannot use a re-INVITE. Rather,
it uses a SIP UPDATE request (7) [7], passing the offer (after
modifying it to get the origin field correct). User A generates its
answer in the 200 OK to the UPDATE (8). This answer is passed to
user B in the ACK (9). When user A finally answers (11), there is no
change in session state, so the controller simply ACKs the 200 OK
(12).
Note that it is likely that there will be clipping of media in this
call flow. User A is likely a PSTN gateway, and has generated a
provisional response because of early media from the PSTN side. The
PSTN will deliver this media even though the gateway does not have
anywhere to send it, since the initial offer from the controller had
no media streams. When user B answers, media can begin to flow.
However, any media sent to the gateway from the PSTN up to that point
will be lost.
9. Third Party Call Control and SDP Preconditions
A SIP extension has been specified that allows for the coupling of
signaling and resource reservation [2]. This specification relies on
exchanges of session descriptions before completion of the call
setup. These flows are initiated when certain SDP parameters are
passed in the initial INVITE. As a result, the interaction of this
mechanism with third party call control is not obvious, and worth
detailing.
9.1. Controller Initiates
In one usage scenario, the controller wishes to make use of
preconditions in order to avoid the call failure scenarios documented
in Section 4.4. Specifically, the controller can use preconditions in
order to guarantee that neither party is alerted unless there is a
common set of media and codecs. It can also provide both parties
with information on the media composition of the call before they
decide to accept it.
Rosenberg, et al. Best Current Practice [Page 16]
RFC 3725 SIP 3pcc April 2004
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 | |
|<------------------| |
Figure 10
The flow for this scenario is shown in Figure 10. In this example,
we assume that user B is an automata or agent of some sort which will
answer the call immediately. Therefore, the flow is based on Flow I.
The controller sends an INVITE to user A containing no SDP, but with
a Require header indicating that preconditions are required. This
specific scenario (an INVITE without an offer, but with a Require
header indicating preconditions) is not described in [2]. It is
RECOMMENDED that the UAS respond with an offer in a 1xx including the
media streams it wishes to use for the call, and for each, list all
preconditions it supports as optional. Of course, the user is not
alerted at this time. The controller takes this offer and passes it
to user B (3). User B does not support preconditions, or does, but
Rosenberg, et al. Best Current Practice [Page 17]
RFC 3725 SIP 3pcc April 2004
is not interested in them. Therefore, when it answers the call, the
200 OK contains an answer without any preconditions listed (4). This
answer is passed to user A in the PRACK (6). At this point, user A
knows that there are no preconditions actually in use for the call,
and therefore, it can alert the user. When the call is answered,
user A sends a 200 OK to the controller (8) and the call is complete.
In the event that the offer generated by user A was not acceptable to
user B (because of non-overlapping codecs or media, for example),
user B would immediately reject the INVITE (message 3). The
controller would then CANCEL the request to user A. In this
situation, neither user A nor user B would have been alerted,
achieving the desired effect. It is interesting to note that this
property is achieved using preconditions even though it doesn't
matter what specific types of preconditions are supported by user A.
It is also entirely possible that user B does actually desire
preconditions. In that case, it might generate a 1xx of its own with
an answer containing preconditions. That answer would still be
passed to user A, and both parties would proceed with whatever
measures are necessary to meet the preconditions. Neither user would
be alerted until the preconditions were met.
9.2. Party A Initiates
In Section 9.1, the controller requested the use of preconditions to
achieve a specific goal. It is also possible that the controller
doesn't care (or perhaps doesn't even know) about preconditions, but
one of the participants in the call does care. A call flow for this
case is shown in Figure 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 |
Rosenberg, et al. Best Current Practice [Page 18]
RFC 3725 SIP 3pcc April 2004
| |<---------------------|
|(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 |
Rosenberg, et al. Best Current Practice [Page 19]
RFC 3725 SIP 3pcc April 2004
| |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 |
| |--------------------->|
Figure 11
The controller follows Flow IV; it has no specific requirements for
support of the preconditions specification [2]. Therefore, it sends
an INVITE (1) with SDP that contains no media lines. User A is
interested in supporting preconditions, and does not want to ring its
phone until resources are reserved. Since there are no media streams
in the INVITE, it can't reserve resources for media streams, and
therefore it can't ring the phone until they are conveyed in a
subsequent offer and then reserved. Therefore, it generates a 183
with the answer, and doesn't alert the user (2). The controller
PRACKs this (3) and A responds to the PRACK (4).
Rosenberg, et al. Best Current Practice [Page 20]
RFC 3725 SIP 3pcc April 2004
At this point, the controller attempts to bring B into the call. It
sends B an INVITE without SDP (5). B is interested in having
preconditions for this call. Therefore, it generates its offer in a
183 that contains the appropriate SDP attributes (6). The controller
passes this offer to A in an UPDATE request (7). The controller uses
UPDATE because the call has not been answered yet, and therefore, it
cannot use a re-INVITE. User A sees that its peer is capable of
supporting preconditions. Since it desires preconditions for the
call, it generates an answer in the 200 OK (8) to the UPDATE. This
answer, in turn, is passed to B in the PRACK for the provisional
response (9). Now, both sides perform resource reservation. User A
succeeds first, and passes an updated session description in an
UPDATE request (13). The controller simply passes this to A (after
the manipulation of the origin field, as required in Flow IV) in an
UPDATE (14), and the answer (15) is passed back to A (16). The same
flow happens, but from B to A, when B's reservation succeeds (17-20).
Since the preconditions have been met, both sides ring (21 and 22),
and then both answer (23 and 25), completing the call.
What is important about this flow is that the controller doesn't know
anything about preconditions. It merely passes the SDP back and
forth as needed. The trick is the usage of UPDATE and PRACK to pass
the SDP when needed. That determination is made entirely based on
the offer/answer rules described in [6] and [7], and is independent
of preconditions.
10. Example Call Flows
10.1. Click-to-Dial
The first application of this capability we discuss is click-to-dial.
In this service, a user is browsing the web page of an e-commerce
site, and would like to speak to a customer service representative.
The user clicks on a link, and a call is placed to a customer service
representative. When the representative picks up, the phone on the
user's desk rings. When the user pick up, the customer service
representative is there, ready to talk to the user.
Rosenberg, et al. Best Current Practice [Page 21]
RFC 3725 SIP 3pcc April 2004
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 | | |
|.......................................| |
Figure 12
The call flow for this service is given in Figure 12. It is
identical to that of Figure 4, with the exception that the service is
triggered through an HTTP POST request when the user clicks on the
link. Normally, this POST request would contain neither the number
of the user or of the customer service representative. The user's
number would typically be obtained by the web application from back-
end databases, since the user would have presumably logged into the
site, giving the server the needed context. The customer service
number would typically be obtained through provisioning. Thus, the
HTTP POST is actually providing the server nothing more than an
indication that a call is desired.
We note that this service can be provided through other mechanisms,
namely PINT [9]. However, there are numerous differences between the
way in which the service is provided by PINT, and the way in which it
is provided here:
Rosenberg, et al. Best Current Practice [Page 22]
RFC 3725 SIP 3pcc April 2004
o The PINT solution enables calls only between two PSTN endpoints.
The solution described here allows calls between PSTN phones
(through SIP enabled gateways) and native IP phones.
o When used for calls between two PSTN phones, the solution here may
result in a portion of the call being routed over the Internet.
In PINT, the call is always routed only over the PSTN. This may
result in better quality calls with the PINT solution, depending
on the codec in use and QoS capabilities of the network routing
the Internet portion of the call.
o The PINT solution requires extensions to SIP (PINT is an extension
to SIP), whereas the solution described here is done with baseline
SIP.
o The PINT solution allows the controller (acting as a PINT client)
to "step out" once the call is established. The solution
described here requires the controller to maintain call state for
the entire duration of the call.
10.2. Mid-Call Announcement Capability
The third party call control mechanism described here can also be
used to enable mid-call announcements. Consider a service for pre-
paid calling cards. Once the pre-paid call is established, the
system needs to set a timer to fire when they run out of minutes.
When this timer fires, we would like the user to hear an announcement
which tells them to enter a credit card to continue. Once they enter
the credit card info, more money is added to the pre-paid card, and
the user is reconnected to the destination party.
We consider here the usage of third party call control just for
playing the mid-call dialog to collect the credit card information.
Rosenberg, et al. Best Current Practice [Page 23]
RFC 3725 SIP 3pcc April 2004
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 | | |
|.......................................| |
Figure 13
We assume the call is set up so that the controller is in the call as
a B2BUA. When the timer fires, we wish to connect the caller to a
media server. The flow for this is shown in Figure 13. When the
timer expires, the controller places the called party with a
connection address of 0.0.0.0 (1). This effectively "disconnects"
the called party. The controller then sends an INVITE without SDP to
Rosenberg, et al. Best Current Practice [Page 24]
RFC 3725 SIP 3pcc April 2004
the pre-paid caller (4). The offer returned from the caller (5) is
used in an INVITE to the media server which will be collecting digits
(6). This is an instantiation of Flow I. This flow can only be used
here because the media server is an automata, and will answer the
INVITE immediately. If the controller was connecting the pre-paid
user with another end user, Flow III would need to be used. The
media server returns an immediate 200 OK (7) with an answer, which is
passed to the caller in an ACK (8). The result is that the media
server and the pre-paid caller have their media streams connected.
The media server plays an announcement, and prompts the user to enter
a credit card number. After collecting the number, the card number
is validated. The media server then passes the card number to the
controller (using some means outside the scope of this
specification), and then hangs up the call (11).
After hanging up with the media server, the controller reconnects the
user to the original called party. To do this, the controller sends
an INVITE without SDP to the called party (13). The 200 OK (14)
contains an offer, offer3. The controller modifies the SDP (as is
done in Flow III), and passes the offer in an INVITE to the pre-paid
user (15). The pre-paid user generates an answer in a 200 OK (16)
which the controller passes to user B in the ACK (17). At this
point, the caller and called party are reconnected.
11. Implementation Recommendations
Most of the work involved in supporting third party call control is
within the controller. A standard SIP UA should be controllable
using the mechanisms described here. However, third party call
control relies on a few features that might not be implemented. As
such, we RECOMMEND that implementors of user agent servers support
the following:
o Offers and answers that contain a connection line with an address
of 0.0.0.0.
o Re-INVITE requests that change the port to which media should be
sent
o Re-INVITEs that change the connection address
o Re-INVITEs that add a media stream
o Re-INVITEs that remove a media stream (setting its port to zero)
o Re-INVITEs that add a codec amongst the set in a media stream
Rosenberg, et al. Best Current Practice [Page 25]
RFC 3725 SIP 3pcc April 2004
o SDP Connection address of zero
o Initial INVITE requests with a connection address of zero
o Initial INVITE requests with no SDP
o Initial INVITE requests with SDP but no media lines
o Re-INVITEs with no SDP
o The UPDATE method [7]
o Reliability of provisional responses [6]
o Integration of resource management and SIP [2].
12. Security Considerations
12.1. Authorization and Authentication
In most uses of SIP INVITE, whether or not a call is accepted is
based on a decision made by a human when presented information about
the call, such as the identity of the caller. In other cases,
automata answer the calls, and whether or not they do so may depend
on the particular application to which SIP is applied. For example,
if a caller makes a SIP call to a voice portal service, the call may
be rejected unless the caller has previously signed up (perhaps via a
web site). In other cases, call handling policies are made based on
automated scripts, such as those described by the Call Processing
Language [11]. Frequently, those decisions are also made based on
the identity of the caller.
These authorization mechanisms would be applied to normal first party
calls and third party calls, as these two are indistinguishable. As
a result, it is important for these authorization policies to
continue to operate correctly for third party calls. Of course,
third party calls introduce a new party - the one initiating the
third party call. Do the authorization policies apply based on the
identity of that third party, or do they apply based on the
participants in the call? Ideally, the participants would be able to
know the identities of both other parties, and have authorization
policies be based on those, as appropriate. However, this is not
possible using existing mechanisms. As a result, the next best thing
is for the INVITE requests to contain the identity of the third
party. Ultimately, this is the user who is requesting communication,
and it makes sense for call authorization policies to be based on
that identity.
Rosenberg, et al. Best Current Practice [Page 26]
RFC 3725 SIP 3pcc April 2004
This requires, in turn, that the controller authenticate itself as
that third party. This can be challenging, and the appropriate
mechanism depends on the specific application scenario.
In one common scenario, the controller is acting on behalf of one of
the participants in the call. A typical example is click-to-dial,
where the controller and the customer service representative are run
by the same administrative domain. Indeed, for the purposes of
identification, the controller can legitimately claim to be the
customer service representative. In this scenario, it would be
appropriate for the INVITE to the end user to contain a From field
identifying the customer service rep, and authenticate the request
using S/MIME (see RFC 3261 [1], Section 23) signed by the key of the
customer service rep (which is held by the controller).
This requires the controller to actually have credentials with which
it can authenticate itself as the customer support representative.
In many other cases, the controller is representing one of the
participants, but does not possess their credentials. Unfortunately,
there are currently no standardized mechanisms that allow a user to
delegate credentials to the controller in a way that limits their
usage to specific third party call control operations. In the
absence of such a mechanisms, the best that can be done is to use the
display name in the From field to indicate the identity of the user
on whose behalf the call is being made. It is RECOMMENDED that the
display name be set to "[controller] on behalf of [user]", where user
and controller are textual identities of the user and controller,
respectively. In this case, the URI in the From field would identify
the controller.
In other situations, there is no real relationship between the
controller and the participants in the call. In these situations,
ideally the controller would have a means to assert that the call is
from a particular identity (which could be one of the participants,
or even a third party, depending on the application), and to validate
that assertion with a signature using the key of the controller.
12.2. End-to-End Encryption and Integrity
With third party call control, the controller is actually one of the
participants as far as the SIP dialog is concerned. Therefore,
encryption and integrity of the SIP messages, as provided by S/MIME,
will occur between participants and the controller, rather than
directly between participants.
However, integrity, authenticity and confidentiality of the media
sessions can be provided through a controller. End-to-end media
security is based on the exchange of keying material within SDP [10].
Rosenberg, et al. Best Current Practice [Page 27]
RFC 3725 SIP 3pcc April 2004
The proper operation of these mechanisms with third party call
control depends on the controller behaving properly. So long as it
is not attempting to explicitly disable these mechanisms, the
protocols will properly operate between the participants, resulting
in a secure media session that even the controller cannot eavesdrop
or modify. Since third party call control is based on a model of
trust between the users and the controller, it is reasonable to
assume it is operating in a well-behaved manner. However, there is
no cryptographic means that can prevent the controller from
interfering with the initial exchanges of keying materials. As a
result, it is trivially possibly for the controller to insert itself
as an intermediary on the media exchange, if it should so desire.
13. Acknowledgements
The authors would like to thank Paul Kyzivat, Rohan Mahy, Eric
Rescorla, Allison Mankin and Sriram Parameswar for their comments.
14. References
14.1. Normative References
[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.
Rosenberg, et al. Best Current Practice [Page 28]
RFC 3725 SIP 3pcc April 2004
14.2. Informative References
[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.
Rosenberg, et al. Best Current Practice [Page 29]
RFC 3725 SIP 3pcc April 2004
15. Authors' Addresses
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
Rosenberg, et al. Best Current Practice [Page 30]
RFC 3725 SIP 3pcc April 2004
16. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rosenberg, et al. Best Current Practice [Page 31]