Ю.Ф.Кожанов, Колбанев М.О ИНТЕРФЕЙСЫ И ПРОТОКОЛЫ СЕТЕЙ СЛЕДУЮЩЕГО ПОКОЛЕНИЯ

______________________________________________________________________________

Via: SIP/2.0/UDP server5.alabama.com;branch=z9hG4bK77ef4c2312983.3;received=192.0.2.2 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.3;received=192.0.2.3

Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10;received=192.0.2.4 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf

To: +123456789 <sip:+123456789@alabama.com>;tag=1928301774 Call-ID: a84b4c76e66710

CSeq: 231 BYE

Content-Length: 0

-----------------------------------------------------------------------------------------------------------------------

From: Bob <sip:bob@biloxi.com>;tag=a6c85cf

To: +123456789 <sip:+123456789@alabama.com>;tag=1928301774 Call-ID: a84b4c76e66710

CSeq: 231 BYE

Content-Length: 0

-----------------------------------------------------------------------------------------------------------------------

From: Bob <sip:bob@biloxi.com>;tag=a6c85cf

To: +123456789 <sip:+123456789@alabama.com>;tag=1928301774 Call-ID: a84b4c76e66710

CSeq: 231 BYE

Content-Length: 0

-----------------------------------------------------------------------------------------------------------------------

Обычно адресация вызовов в сети SIP происходит на основе универсального идентификатора ресурсов – Uniform Resource Identifier (SIP URI) вида bob@biloxi.com,

что позволяет определить текущее местоположение абонента через DNS. Для определения SIP URI оконечного устройства, имеющего телефонный номер в формате Рекомендации Е.164, используется процедура ENUM [RFC 2915, PS]. Для этого в системе доменных имен имеется специальный домен “e164.arpa” [RFC 3761, PS] со специальными записями – Naming Authority Pointer, NAPT. Домен имеет записи соответствия только для телефонных номеров в формате Рекомендации Е.164. Например, для определения SIP URI по телефонному номеру +123456789 SIP-сервер осуществляет DNS-запрос (NAPTR RR query: 9.8.7.6.5.4.3.2.1.e164.arpa), на который получает ответ (например, bob@biloxi.com).

2.7.4. Дополнительные виды обслуживания

Многие услуги IP-телефонии, такие как многосторонние вызовы, подача индивидуального акустического тона при поступлении вызова, могут и должны располагаться в оконечных устройствах. С другой стороны, услуги, связанные с местоположением абонентов логично располагать в сетевых устройствах (серверах). Традиционно сетевые услуги создавались провайдерами сети. Абоненты не имели права или имели ограниченное право изменять содержание услуг. Однако глобальность Интернет и его открытые протоколы дают возможность абонентам самим создавать и менять услуги. В [RFC 2824, INF] описывается архитектура сети, в которой сетевые устройства обрабатывают вызовы в соответствии со сценарием, составленным абонентом на простом, легко читаемом языке – языке обработки вызовов (Call Processing Language, CPL).

Дополнительные виды обслуживания предполагается реализовывать на основе скриптов. Скрипт представляет собой базу данных в виде листа соответствия исходные данные – действие. Если принятый запрос соответствует каким-либо исходным

160

Глава 2 ПРОТОКОЛЫ МУЛЬТИМЕДИЙНЫХ ПРИЛОЖЕНИЙ

______________________________________________________________________________

данным, то предпринимается соответствующее действие. Если в результате действия получен результат, который подходит под новые исходные данные, то предпринимается рекурсивная (аналогичная) процедура. Например, когда запрос приходит в CPL-сервер, то он просматривает скрипты источника и получателя. Если в качестве исходных данных используется IP-адрес, то реализуется соответствующее действие, в результате которого может быть получен новый IP-адрес. Если для этого нового адреса в базе данных имеется условие, то процедура повторяется. Один и тот же скрипт может быть использован для одного, нескольких или даже для всех адресов.

Скрипты располагаются в одном из серверов, через которые проходит соединение, обычно на исходящем и/или входящем. Точный метод для транспортировки скрипта в сервер не определен, но в любом случае для его размещения на сервере требуется авторизация. Если скрипт загружен в сервер, то при регистрации абонента на сервере в поле Contact: помещается IP-адрес сервера, где и храниться скрипт. Пользователи также должны иметь возможность модифицировать существующий скрипт. Сервер должен иметь способности обнаруживать ошибки и неточности скрипта. В [RFC 3880, PS] предлагаются типовые шаблоны скриптов для реализации наиболее известных услуг.

При обработке скриптом исходных данных в приоритетном порядке учитываются: адрес назначения, адрес отправителя, предпочтения отправителя, информации отправителя (содержание, организация), описание типа связи (полоса, вид связи). Результатом обработки могут быть отклонение вызова, его перенаправление, его обслуживание.

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

Примером противоречия “услуга с услугой на одном сервере” является попытка одновременного конфигурирования услуги “извещение о поступлении нового вызова”

(Call Waiting) и “переадресация при занятости” (Call Forwarding on Busy). Такие противоречия легко обнаруживаются при наличии хорошего редактора скриптов у пользователя и тестера скриптов на сервере. Примером противоречия “скрипт со скриптом в одном сервере” является ситуация, когда результатом исполнения скрипта получается второй адрес, имеющийся в базе данных. При обработке скрипта второго адреса получается исходный первый адрес, т.е. образовалась петля. Примером противоречия “сервер с сервером” является ситуация, когда у абонента имеется услуга “черный список”, а у другого – “переадресация”. Абонент “черного списка” переадресовывается другим абонентом, который не занесен в “черный список”.

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

При выборе языка написания скриптов должно приниматься во внимание

1.Эффективность, легкость применения, быстрая компиляция.

2.Легкость проверки синтаксиса, обнаружение наличия петель.

3.Малое потребление ресурсов – время процессора, объем памяти.

4.Легкость чтения программы машиной и человеком.

5.Независимость от нижележащих протоколов.

В соответствии с этими требованиями предполагается использовать специальный расширяемый язык разметки – Extensible Markup Language, XML.

161