Управляемое клиентом динамическое перенаправление вызова

Управляемое клиентом динамическое перенаправление вызова

Иллюстрации

Показать все

Реферат

УРОВЕНЬ ТЕХНИКИ

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

В телекоммуникационном контексте клиент-сервер, основанном на IP (например, VoIP - голос по Интернет-протоколу), правила обработки/перенаправления вызова телефона традиционно были реализованы на стороне сервера. Это требует, чтобы сервер обладал предварительными знаниями о правилах, которые были установлены клиентом. Перенаправление стороны сервера работало в прошлом, потому что правила, которые клиент мог бы применить, были простые и легкие для реализации.

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

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

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

Последующее представляет упрощенное краткое изложение, для того чтобы предоставлять базовое понимание некоторых аспектов раскрытого изобретения. Эта Сущность изобретения не является исчерпывающим обзором, и она не имеет намерением идентифицировать его ключевые/критические элементы или установить границы объема. Ее единственной целью является представить в упрощенном виде некоторые концепции в качестве вступления к более подробному описанию, которое представлено позже.

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

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

В одном примерном варианте осуществления, протокол сеанса - SIP и правила маршрутизации вызова, разработанные клиентом, используют ответы SIP. Предварительные сообщения ответа SIP (1xx) и/или переадресация ответов (3xx) в протоколе SIP могут быть использованы, чтобы предоставлять управление стороны клиента маршрутизацией вызова стороны сервера. В более автоматизированной реализации, пользователь клиента может написать скрипт на клиенте, который, будучи преданным серверу вызова, содержит в себе правила перенаправления вызова, которые сервер будет применять к тому конкретному вызову. После того, как сервер посредник принимает такой запрос, например, он останавливает разветвление текущего вызова и применяет правила, которые заданы в ответе 1xx.

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

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

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

Фиг.1 иллюстрирует систему, реализованную на компьютере, которая способствует управлению вызовами в соответствии с раскрытым изобретением.

Фиг.2 иллюстрирует методологию управления вызовами от клиента.

Фиг.3 иллюстрирует более подробно систему, которая способствует управлению вызовами в ответ на сообщения, основанные на клиенте.

Фиг.4 иллюстрирует методологию перенаправления вызовов, в соответствии с управлением стороны клиента.

Фиг.5 иллюстрирует методологию поддержки процессов стороны клиента в течение управляемого клиентом перенаправления вызова сервером вызова.

Фиг.6 иллюстрирует методологию обработки стороны сервера, основанной на правилах клиента.

Фиг.7 иллюстрирует систему SIP перенаправления вызова, основанную на клиенте.

Фиг.8 иллюстрирует методологию управления стороны клиента, использующую сервер посредник SIP.

Фиг.9 иллюстрирует методологию управления стороны клиента, использующую сервер переадресации SIP.

Фиг.10 иллюстрирует примерную блок-схему вызова для управления клиентом посредством посылки вызыва других контактов, которые в настоящий момент на связи.

Фиг.11 иллюстрирует примерную блок-схему вызова, использующую 3xx переадресацию, чтобы изменить маршрут вызова.

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

Фиг.13 иллюстрирует методологию динамического управления вызовами для различных учетных записей, используя управление стороны клиента сервером вызова.

Фиг.14 иллюстрирует методологию управления информацией присутствия на клиенте, используя управление стороны клиента сервером вызова.

Фиг.15 иллюстрирует методологию управления входящими вызовами на занятого (или на связи) клиента, используя управление стороны клиента сервером вызова.

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

Фиг.17 иллюстрирует схематическую блок-схему портативного беспроводного устройства, которое содействует созданию правил стороны клиента и управлению сервером вызова.

Фиг.18 иллюстрирует блок-схему настольного или портативного компьютера, действующего, чтобы выполнять управление перенаправлением вызова стороны клиента сервером вызова в соответствии с раскрытой архитектурой.

ПОДРОБНОЕ ОПИСАНИЕ

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

Раскрытая архитектура вносит механизм сигнализации в, например, SIP (протокол инициации сеанса) и/или другие протоколы сеанса, которые позволяют клиенту управлять тем, как вызов перенаправляют на сервер вызова без обязательного изменения существующих правил маршрутизации вызова сервера и добавления дополнительной клиентоподобной функциональности серверу динамически, когда клиент начинает сеанс. Как результат, пользователи могут приобретать готовых более новых клиентов и использовать новые интеллектуальные свойства обработки вызовов, которые могут быть сделаны доступными на клиентах, используя существующую инфраструктуру сервера, которую развернул их администратор. Заметим, что хотя описание подробно останавливается на использовании SIP как протокола сеанса для связи между клиентом и сервером вызовов, должно быть понятно, что раскрытое изобретение применяется также к другим протоколам сеанса (например, H.323).

SIP-протокол, разработанный рабочей группой IETF (целевая группа инженерной поддержки Интернет) MMUSIC (управление групповым мультимедийным сеансом) и предлагаемый стандарт для инициации, модификации и завершения диалогового сеанса пользователя, который использует мультимедийные элементы, такие как вызовы телефона, проведение конференций с помощью средств мультимедиа, мгновенный обмен сообщениями и другой обмен информацией в реальном времени в Интернете (например, онлайн-игры и виртуальная реальность). Это один из ведущих протоколов сигнализации для VoIP (передача голоса по IP), в соответствии с H.323.

Мотивационная цель для SIP была в том, чтобы предоставить сигнализацию и протокол для обмена информацией, основанный на IP, который может поддерживать супермножество функций обработки вызова и свойства, присутствующие в телефонной коммутируемой сети общего пользования (PSTN). Фокус SIP - установка вызова и сигнализация, какие свойства разрешают хорошо известные операции, подобные телефонным (например, набор номера, звонок телефона, тональные сигналы обратного вызова или сигнал «занято»).

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

Конечные точки аппаратного обеспечения, которые предоставляют внешность, ощущение и форму традиционного телефона, используют SIP и RTP для связи и дополнительно могут использовать электронную нумерацию (ENUM) для трансляции существующих телефонных номеров в SIP-адреса (основанные на формате URL (унифицированный указатель ресурса)). Соответственно, вызовы другим пользователям SIP могут обходить телефонную сеть, даже хотя поставщик услуг может нормально действовать как шлюз в сеть PSTN для традиционных телефонных номеров и ассоциативно связанных тарифов.

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

Первоначально обращаясь к чертежам, фиг.1 иллюстрирует систему 100, реализованную на компьютере, которая способствует управлению вызовами в соответствии с раскрытым изобретением. Система 100 включает в себя компонент маршрутизации вызова 102 сервера 104 вызова (например, сервера посредника) для маршрутизации вызова клиента 106 в пункт назначения. Система 100 может также включать в себя компонент 108 управления клиента 106 для управления маршрутизацией вызова на сервере 104. При работе, когда сервер 104 вызова принимает вызов, адресованный клиенту 106, сервер 104 вызова сигнализирует клиенту 106 о том, что вызов является входящим. Находится ли клиент в настоящее время на связи по вызову или отключен, клиент 106 может заставить сервер 104 вызова обрабатывать входящий вызов в соответствии с правилами клиента, отличными от правил на сервере 104 вызова в настоящий момент, для обработки вызовов для клиента 106. Клиент 106 отвечает серверу 104 вызова одним или более сообщениями сеанса (например, SIP), которые указывают серверу 104 вызова, как маршрутизировать вызов.

В одном примере, предварительное сообщение ответа SIP включает в себя правило перенаправления вызова, которое передают от клиента 106 на сервер 104, которое, когда выполняется сервером 104, маршрутизирует вызов соответственно. В другом примере, сообщение ответа переадресации SIP включает в себя правило перенаправления вызова, которое передается от клиента на сервер, и которое, когда выполняется сервером, маршрутизирует вызов. Более точно, раскрытая архитектура использует (1xx, где x - это 1-9) информационные (или предварительные) сообщения ответа и/или (3xx, где x - это 0-9) ответы переадресации в протоколе SIP. Использующий, по меньшей мере, один или более из этих типов ответов, скрипт может быть сгенерирован в клиенте 106 и передан от клиента 106 в сервер 104 вызова, скрипт, содержащий правила перенаправления вызова, которые сервер 104 применяет к тому конкретному вызову. Когда сервер 104 вызова принимает скрипт от клиента 106, он останавливает разветвление текущего вызова для того вызова и применяет одно или более правил в скрипте, которые конкретизируют в ответе 1xx.

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

Традиционно, например, документ SIP RFC (запрос комментария) 3261 предоставляет ответ 380 альтернативной услуги (ответ переадресации в SIP), но оставляет свое определение или цель неопределенной. По меньшей мере, один сценарий требует, чтобы клиент задал поведение посредничества серверу. Например, принимая во внимание, что пользователь имеет входящий вызов от вызывающего и желает направить вызывающего к ее/его мобильному номеру, в этом случае повторная маршрутизация (например, посредником) должна быть сделана посредством LS (сервер местоположения) посредника, таким образом запрещая использование существующего SIP-ответа 302 временно перемещенной переадресации для этих целей.

Фиг.2 иллюстрирует методологию управления вызовами от клиента. Несмотря на то, что, в целях простоты пояснения, одна или более методологий, показанных в материалах настоящей заявки, например, в виде блок-схемы алгоритма или диаграммы последовательности операций, показаны и описаны как последовательность действий, должно быть понятно и принято во внимание, что связанное изобретение не ограничено очередностью действий, так как некоторые действия могут, в соответствии с ним, происходить в ином порядке и/или одновременно с другими действиями из тех, что показаны и описаны в материалах настоящей заявки. Например, специалисты в данной области техники будут понимать и принимать во внимание, что методология, в качестве альтернативы, могла бы быть представлена как последовательность взаимосвязанных состояний или событий, таких как на диаграмме состояний. Более того, не все проиллюстрированные действия могут потребоваться для реализации методологии в соответствии с изобретением.

На этапе 200, телефонный вызов принимают на клиенте для обработки. Это может быть телефонный вызов, основанный на IP (например, VoIP), обработка которого совместима с IP-протоколом сеанса (например, SIP). В одной реализации, сервер вызова сигнализирует клиенту, что вызов является входящим и будет обрабатываться для соединения с клиентом. В другой реализации, вызов перенаправляют клиенту, после которого начинают перенаправление вызова, чтобы повторно маршрутизировать вызов. На этапе 202, клиент отправляет скрипт сообщения SIP (или правила вызова) серверу вызова, который управляет сервером вызова для перенаправления вызова в соответствии со скриптом клиента. На этапе 204, сервер вызова принимает и обрабатывает скрипт клиента, чтобы повторно маршрутизировать вызов.

Фиг.3 иллюстрирует более подробно систему 300, которая способствует управлению вызовами в ответ на сообщения, основанные на клиенте. Система 300 включает в себя компонент 102 маршрутизации вызова сервера 104 вызова для маршрутизации вызова клиента 106 в пункт назначения и компонент 108 управления клиента 106 для генерации, передачи и, в конечном счете, управления маршрутизацией вызова на сервере 104.

В этой реализации, клиент 106 также включает в себя компонент 302 правил клиента для разработки одного или более правил для обмена информацией с сервером 104 через компонент 304 сигнализации клиента. Компонент сигнализации клиента способствует использованию различных протоколов сессии, такого как SIP. Одно или более правила, созданных пользователем клиента через интерфейс пользователя для компонента 302 правил клиента, могут быть обменивающимися информацией через компонент 304 сигнализации клиента с компонентом 306 сигнализации сервера. В одном варианте осуществления, компоненты (304 и 306)сигнализации клиента и сервера обрабатывают SIP, протокол сеанса. В другой реализации, H.323 - протокол сеанса. Альтернативно, другие протоколы сеанса уровня приложения могут быть использованы, такие как HTTP (протокол передачи гипертекстовых файлов) и FTP (протокол передачи файлов), например.

Как указано ранее, правила клиента могут быть переданы от клиента 106 к серверу (или серверу посреднику) в форме скрипта, который выполняется сервером 104, и которые способствуют замещению одного или более правил стороны сервера, выбранных для обработки входящего вызова. Скрипт принимают компонентом 308 правил сервера, который обрабатывает скрипт и ассоциативно связанные правила, чтобы маршрутизировать (или перенаправить) вызов соответственно.

Как описано ранее, находится ли клиент 106 в настоящее время на связи по вызову или отключен, когда другой вызов приходит, клиент 106 может служить причиной, чтобы сервер 104 вызова обрабатывал входящий вызов, в соответствии с правилами клиента, отличными от правил в настоящий момент на сервере 104 вызова для нормальной обработки вызовов для клиента 106.

Фиг.4 иллюстрирует методологию перенаправления вызовов, в соответствии с управлением стороны клиента. На этапе 400, сервер вызова принимает правила вызова для нормальной обработки вызовов клиента на сервере вызова. Сервер вызова будет обрабатывать эти правила для вызовов для или от клиента до иного направления правилами управления стороны клиента. На этапе 402, сервер вызова принимает вызов для клиента. На этапе 404, сервер сигнализирует клиенту о входящем вызове и инициирует обработку правил маршрутизации вызова клиента стороны сервера. На этапе 406, клиент отвечает сообщением(ями), чтобы обработать одно или более альтернативных правил маршрутизации вызова, основанных на клиенте. На этапе 408, сервер принимает и обрабатывает одно или более альтернативных правил маршрутизации вызова клиента.

Фиг.5 иллюстрирует методологию поддержки процессов стороны клиента в течение перенаправления управляемого клиентом вызова сервером вызова. На этапе 500 клиент принимает и соединяется с текущим вызовом. На этапе 502, клиент принимает и обрабатывает сигнал, относящийся к другому входящему вызову. На этапе 504, клиент выбирает одно или более альтернативных правил маршрутизации вызова, основанных на клиенте, для обработки на стороне сервера. На этапе 506, клиент передает одно или более альтернативных правил маршрутизации вызова серверу, используя протокол сеанса. На этапе 508, клиент поддерживает нормальные процессы текущего вызова, пока сервер вызова обрабатывает одно или более альтернативных правил. Другими словами, клиент обрабатывает предупреждения, уведомления (например, звуки, стрекотания, вибрации, мелодии для звонка,...) и сообщения, относящиеся к входящему вызову и другим происходящим параллельно процессам, одновременно с управлением сервером вызова так, что пользователь уведомляется о другом входящем вызове, в ответ на который альтернативные правила могут переданы серверу вызова для перенаправления нового вызова. В другом примере, текущий вызов может быть обработан в соответствии с передающимися правилами стороны клиента, чтобы соединить дополнительных получателей (например, проведение конференции) к текущему вызову.

Обратимся теперь к фиг.6, там иллюстрируется методология обработки стороны сервера, основанной на правилах стороны клиента. На этапе 600, сервер вызова сохраняет правила маршрутизации вызова клиента для нормальной обработки вызовов клиента. Правила могут быть для обработки входящих вызовов и для обработки вызовов, порожденных клиентом. На этапе 602, сервер принимает вызов, завершенный клиентом, и осуществляет доступ к правилам маршрутизации нормальной обработки для того клиента. На этапе 604, клиент выбирает одно или более альтернативных правил маршрутизации вызова, основанных на клиенте, для обработки на стороне сервера. На этапе 606, сервер принимает альтернативное правило(а), основанное на клиенте, в ответ на сигнализацию о входящем вызове клиента. На этапе 608, сервер вызова прерывает нормальную обработку входящего вызова и обрабатывает альтернативное правило(а). На этапе 610, сервер маршрутизирует текущий вызов в соответствии с альтернативным правилом(ами). Фиг.7 иллюстрирует систему SIP перенаправления вызова 700, основанную на клиенте. Система 700 включает в себя сервер 702 посредник, сервер 704 перенаправления и клиента 706 пользователя SIP клиентского (проводного или беспроводного) устройства 708. Клиент 706 SIP устройства 708 может включать в себя компонент 710 правил клиента для создания правил на клиенте для передачи через интерфейс SIP клиента 712 на сервер посредник и/или сервер 704 переадресации и выполнения сервером 702 посредником и/или сервером 704 переадресации. Как показано, компонент 710 правил клиента и интерфейс 712 SIP клиента являются частью клиента 706 пользователя SIP. Однако это не требование, в котором или оба из компонента 710 правил клиента и/или интерфейса 712 SIP клиента могли бы быть внешними компонентами для клиента 706 пользователя SIP устройства 708.

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

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

Когда код переадресации SIP используют в правиле, созданном в устройстве клиента 708, интерфейс 712 клиента SIP сообщает ответ переадресации SIP интерфейсу 714 SIP сервера 704 переадресации. Сервер 704 переадресации может включать в себя компонент 716 правил переадресации для обработки ответа переадресации и компонента 718 маршрутизации вызова переадресации, который способствует маршрутизации вызова, в соответствии с принятым правилом(ами) клиента.

Когда информационный ответ SIP используется в правиле, созданном клиентом 706, интерфейс SIP клиента сообщает правило интерфейсу SIP сервера 702 посредника. Сервер 702 посредник может включать в себя компонент 722 правил посредника для обработки информационного ответа и компонент 724 маршрутизации вызова посредника, который способствует маршрутизации вызова, в соответствии с принятым правилом(ами) клиента.

Сервера SIP (702 и 704) могут взаимодействовать с другими службами, такими как LDAP (облегченный протокол доступа к каталогам), серверы расположения (например, сервер 726 местоположения), приложение базы данных и приложение XML (расширяемый язык разметки). Эти службы-приложения могут предоставлять внутренние службы, такие как службы каталогов, аутентификации и биллинга. Заметим также, что телефоны могут функционировать как сервер или клиент.

Вызовы могут быть инициированы устройством 708 клиента и маршрутизированы через шлюз 728 SIP в традиционную PBX (телефонную систему для частного использования), например и/или PSTN (телефонную коммутируемую сеть общего пользования). Шлюз 728 предоставляет управление вызовом, преобразование между конечными точками конференций, аудио/видео кодеки, выполняет установку вызова и очистку как на стороне сети IP, так и на стороне коммутируемой линии.

Фиг.8 иллюстрирует методологию управления стороны клиента, использующую сервер посредник SIP. На этапе 800, SIP используют для обработки вызова между сервером посредником вызова и клиентом. На этапе 802 скрипт стороны клиента информационных ответов SIP (1xx) разрабатывают как альтернативные правила для обработки стороной сервера. На этапе 804, инициируют вызов (или порожденный клиентом или завершенный клиентом) и клиент передает скрипт на сервер посредник для выполнения как часть обработки вызова клиента. На этапе 806, сервер посредник останавливает текущее разветвление вызовов для вызова клиента. На этапе 808, сервер посредник применяет правило(а), заданное как сообщение(я) 1xx текущему вызову.

Фиг.9 иллюстрирует методологию управления стороны клиента, использующую сервер переадресации SIP. На этапе 900, SIP используют для обработки вызова между клиентом и сервером переадресации. На этапе 902, создают скрипт стороны клиента из одного или более ответов переадресации как альтернативные правила маршрутизации вызова. На этапе 904, инициируют вызов (или порожденные клиентом или принимаемые клиентом) и клиент передает скрипт серверу переадресации для обработки вместо нормальных правил обработки, сохраненных на сервере и используемых для вызовов клиента. На этапе 906, сервер переадресации останавливает любое текущее разветвление вызова, относящееся к тому клиенту. На этапе 908, сервер переадресации выполняет скрипт правил и обработку вызова соответственно.

Фиг.10 иллюстрирует примерную блок-схему вызова для управления клиентом посредством посылки вызова других контактов, которые в настоящий момент на связи. Пример имеет место между абонентами Алисой и Бобом, где Алиса вызывает Боба. Алиса обладает SIP-адресом sip:alice@contoso.com, где формат - это sip:userID@gateway.com. Клиент Алисы отправляет запрос SIP INVITE серверу посреднику, сервер посредник определяет путь к вызываемому Бобу, путь является SIP адресом sip:bob@contoso.com и перенаправляет запрос INVITE Бобу. Сервер отправляет сообщение обратно клиенту Алисы, чтобы указать Алисе, что осуществляется попытка вызова. Клиент Боба отвечает ответом 100 TRYING (осуществление попытки) серверу посреднику.

Боб создает и сохраняет набор правил на его клиенте, чтобы звонить другим контактам, которые в настоящее время находятся на связи. Кэрол находится на связи и клиент Боба отправляет предварительный ответ (обозначенный 1xx Rules) серверу посреднику (например, серверу местоположения), указывающему серверу посреднику добавить Кэрол к вызову. Сервер посредник определяет место SIP адреса Кэрол и инициирует SIP INVITE в адрес Кэрол carol@contoso.com. Клиент Кэрол отвечает с ответом 180 RINGING серверу посреднику. Сервер перенаправляет вызывной сигнал обратно клиенту Алисы. Клиент Алисы также отправляет успешный ответ 200 OK серверу посреднику, который перенаправляет его клиенту Алисы. Клиент Алисы отправляет сигнал подтверждения (обозначен ACK) посреднику, который переадресовывает ACK клиенту Кэрол. В некоторый момент, Боб решил выбыть из группового вызова. Соответственно, сообщение CANCEL отправляется от сервера посредника клиенту Боба, и клиент отвечает сообщением SIP 200 OK. Клиент Боба отправляет 487 Request Cancelled (отмена запроса) серверу посреднику, и сервер отвечает ACK.

Предварительный ответ 1xx (например, ответ 199), указанный выше, может иметь гибкий скрипт, например XML скрипт, который содержит детали того, как вызов необходимо маршрутизировать. Ответы 1xx являются полезными в случаях, когда другие пользователи должны быть добавлены к вызову без остановки текущего устройства от вызова. Некоторые примеры представлены ниже. Заметим, что XML имеет место только в иллюстративных целях, могут быть использованы другие языки.

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

SIP/2.0 lxx Rules

To: Bob <sip:bob@contoso.com>;tag=76786

From: Alice <sip:alice@contoso.com>;tag=98908

Call-ID:

Contact:

CSeq: 7778 INVITE

Content-Type: application/ms-callproc-rules+xml

Content-Length: 142

<ms-call-proc>

<add>

<location uri=carol@contoso.com />

</add>

</ms-call-proc>

Последующее - примерный код XML для добавления команды Кэрол и Дэна к существующему вызову.

SIP/2.0 lxx Rules

To: Bob <sip:bob@contoso.com>;tag=76786

From: Alice <sip:alice@contoso.com>;tag=98908

Call-ID:

Contact:

CSeq: 7778 INVITE

Content-Type: application/ms-callproc-rules+xml

Content-Length: 142

<ms-call-proc>

<add>

<location uri=carol@contoso.com />

<location uri=dan@contoso.com />

</add>

</ms-call-proc>

Последующее - примерный код XML для отправки команде в течение десяти секунд и затем переадресации на голосовую почту или посыла отсутствия ответа.

SIP/2.0 1xx Rules

To: Bob <sip:bob@contoso.com>;tag=76786

From: Alice <sip:alice@contoso.com>;tag=98908

Call-ID:

Contact:

CSeq: 7778 INVITE

Content-Type: application/ms-callproc-rules+xml

Content-Length: 142

<ms-call-proc>

<add wait=10 no-answer=voicemail>

<location uri=carol@contoso.com />

<location uri=dan@contoso.com />

</add>

</ms-call-proc>

Фиг.11 иллюстрирует примерную блок-схему вызова, использующую 3xx переадресацию, чтобы изменить маршрут вызова. Последующая блок-схема вызова - это пример, где ответ 3xx (например, 399) используют, чтобы изменить маршрут вызова. Ответы 3xx полезны, чтобы указать серверу, чтобы изменить маршрут вызова, основанного на правилах, заданных клиентом. Ответы 3xx, по существу останавливают посылку вызова клиента и применяют заданные правила перенаправления.

В блок-схеме вызова, Боб установил динамическое правило вызова, чтобы сначала перенаправлять вызов к Кэрол в течение пяти секунд, отсоединить Кэрол и затем соединиться с Дэном. Алиса вызывает Боба и вызов звонит сначала Кэрол до посылки вызова Дэна.

Клиент Алисы отправляет запрос SIP INVITE, который включает в себя адрес Боба bob@contoso.com, серверу посреднику, сервер посредник определяет путь к вызываемому Бобу, и перенаправляет запрос INVITE Бобу. Сервер отправляет сообщение обратно клиенту Алисы, чтобы указать Алисе, осуществляется попытка вызова. Клиент Боба отвечает ответом 100 TRYING серверу посреднику. Клиент Боба отправляет правило переадресации (3xx) серверу посреднику. Сервер отвечает клиенту Боба с ACK.

Кэрол находится на связи и сервер посредника отправляет запрос SIP INVITE клиенту Кэрол, чей клиент отвечает серверу сообщением 180 RINGING. Сервер перенаправляет вызов клиенту Алисы. В тот момент, происходит таймаут пять секунд с последующим сообщением CANCEL клиенту Кэрол. Клиент Кэрол отвечает серверу с ACK.

Сервер затем отправляет SIP INVITE клиенту Дэна, который отвечает сообщением 180 RINGING серверу и клиенту Алисы. Клиент Дэна отправляет сообщение 200 OK серверу, которое перенаправляют клиенту Алисы. Клиент Алисы затем отправляет ACK серверу для перенаправления клиенту Дэна. Затем устанавливают двухсторонний голосовой канал между Дэном и Алисой.

Последующее - примерный код XML, где сообщение 3xx используют в переадресации вызова.

SIP/2.0 3xx Apply Rules

To: Bob <sip:bob@contoso.com>;tag=76786

From: Alice <sip:alice@contoso.com>;tag=98908

Call-ID:

Contact:

CSeq: 7778 INVITE

Content-Type: application/ms-callproc-rules+xml

Content-Length: 142

<ms-call-proc>

<retarget wait=5>

<location uri=carol@contoso.com />

<location uri=dan@contoso.com />

</retarget>

<retarget wait=5 noanswer=voicemail>

<location uri=dan@contoso.com/>

</retarget>

</ms-call-proc>

Фиг.12 иллюстрирует примерную блок-схему вызова для переадресации вызова в пункт назначения телефонной коммутируемой сети общего пользования (PSTN). Клиент Алисы отправляет запрос SIP INVITE серверу посреднику, сервер посредник определяет путь к вызыв