CC BY
101
Способ передачи с помощью протокола SIP информации о внутреннем номере терминала PBX при установлении исходящих и входящих соединений
Ключевые слова: VoIP, SIP RFC 3261, URI, RFC 2396, PBX, CID, Caller ID, АТС, УАТС, расширение протокола, внутренний абонент, донабор.
Предлагается способ, позволяющий используя расширение SIP URI передавать в сети общего пользования информацию о внутреннем номере абонента PBX, инициировавшего исходящее соединение и осуществлять прямое входящее соединение из сетей общего пользования с внутренними терминалами PBX без использования специфических функций "донабора". Излагается критический анализ существующего решения, описывается предлагаемое к введению дополнительное поле SIP URI "exl" и процедуры его обработки.
Пантелейчук Р.О.,
Институт Физики Твердого Тела Российской Академии Наук, инженер, ogogon@ogogon.org
Используемая терминология
Во избежание разночтений, автор считает необходимым уточнить понимание употребляемых в данной статье ключевых понятий и терминов:
PBX — корпоративный узел связи, имеющий абонентское поле внутренних терминалов с произвольной внутренней адресацией (нумерацией) и так же имеющий возможность принимать входящие соединения из сети общего пользования и осуществлять исходящие соединения с абонентами сети общего пользования.
Автор полагает, что употребляемый по сей день в зтом качестве советский термин 'УАТС" ('Учрежденческая АТС") различимо утрачивает свою корректность, поскольку в настоящий момент владельцами PBX все более являются не только учреждения, но самые разнообразные собственники, включая частных лиц. (По сути, любая базовая станция, использующая технологию DECT, уже является PBX с внутренним абонентским пространством.)
Внешний абонент — в данном случае, абонент сети общего пользования, находящийся вне абонентского поля PBX.
Сеть общего пользования — совокупность абонентских пространств действующих и взаимодоступных операторов связи, использующих иерархическую адресацию в формате ITU-T E.164 [1].
Описание проблемы и актуальность
С момента начала использования в практике связи PBX, существуют известные проблемы, обусловленные функциональными ограничениями, накладываемыми на возможности внутренних абонентов корпоративных узлов и вытекающие из самой идеологии PBX. В частности, следует упомянуть две весьма значимые и взаимосвязанные между собой:
1. Осуществляя исходящие звонки в сети общего пользования, внутренний абонент PBX лишен возможности сообщить на уровне протокола SIP свой внутренний номер;
2. Возможности протокола SIP не позволяют, производя входящее соединение из сети общего пользования, автоматически указывать номер внутреннего абонента PBX для осуществления прямого доступа к нему.
Несомненно, при использовании для установления соединений доменной адресации и текстовых идентификаторов абонента подобная проблема не возникает в принципе, но в данной статье мы обсуждаем архитектуру иерархической цифровой адресации в формате ITU-T E.164 и вытекающие из нее проблемы.
Поскольку, в настоящий момент, практически все абоненты систем связи, использующих протокол SIP, придерживаются адресации E.164 [1], то обсуждаемая автором проблематика и предлагаемое решение являются весьма актуальными в рамках реально сложившейся практики.
Описание и анализ существующего решения
Представления сведений
о вызывающем номере
В настоящий момент, протокол SIP передает сведения о вызывающем абоненте в поле "From: " в формате:
"From: " Отображаемое_имя_абонента "<" "sip:" номер_вызывающего_абонента "@" адрес_комму-тирующего_узла ">" [";" дополнительное поле [";" дополнительное поле]]
Например:
From: The Beer Drinking Factory<sip:+74951234567@ pbx.example.ru>;tag=abc123
где: "From: " — заголовок поля протокола SIP; "The Beer Drink'ng Factory" — текстовое наименование абонента; "sip:" — наименование используемого протокола или метода; "+74951234567" — номер абонента; "pbx.example.ru" — адрес коммутирующей системы; ";tag=abc123" — дополнительное поле или поля, обусловленные иными служебными задачами (в дальнейших примерах мы будем опускать их, как не имеющие отношения к обсуждаемой теме).
Если внутренний абонент PBX инициирует исходящий звонок во внутренней сети PBX, то в поле "From:" указывается его собственное текстовое наименование и внутренний номер. Например, Виктор Петров с внутренним номером 2215 будет иметь следующее значение:
From: Victor S. Petrov<sip:2215@user15.example.ru>
Если же указанный абонент инициирует исходящий звонок во внешнюю сеть, то выполняющий это PBX, коммутируя соединение в сеть общего пользования, вынужден в сведениях об исходящем номере заменить сведения о внутреннем абоненте на какой-либо принадлежащий ему номер из пространства внешней сети. При этом, информация о реальном внутреннем номере абонента полностью и необратимо утрачивается.
Например, уже упоминавшийся номер 2215, производя звонок на внешний номер +74957654321 будет за пределами внутренней сети иметь в поле "From: " внешний номер своего PBX:
From: The Beer Drinking Factory<sip:+74951234567@ pbx.example.ru>
Таким образом, абонент принявший звонок будет лишен возможности определить реальный номер звонящего во внутреннем абонентском пространстве обслуживающего его PBX.
Это весьма неудобно в случае, если абонент был лишен возможности принять звонок и не может установить из списка пропущенных звонков на своем терминале реального абонента PBX большой организации. Особенно в случае ведения дел с целым рядом ее сотрудников и подразделений.
Система приема набора
внутреннего номера PBX
На сегодняшний момент, прием информации о внутреннем номере абонента у PBX остается одной из наименее автоматизированных и стандартизированных функций.
До сих пор, в значительном числе случаев, для этого используется сотрудник-оператор и фактически, как абонентом устанавливающим соединение, так и принимающим его, это действие выполняется вручную.
Даже при использовании автоматизированного модуля донабора внутреннего номера, выполнение этого действия со стороны устанавливающей соединение весьма затруднительно без участия человека - необходимо прослушать индивидуальное у каждого PBX звуковое приглашение, установить момент с которого возможно осуществление набора внутреннего номера, возможно прослушать дополнительные сведения о правилах такого донабора.
Кроме того, отсутствие жесткой унификации длительности тональных посылок DTMF и интервалов между ними зачастую порождает неправильную интерпретацию системой автоматического приема PBX набранного внутреннего номера, если он вводится в автоматическом режиме.
В частности, по опыту автора, это весьма часто является поводом для обращения за консультациями.
Предлагаемое решение
Предлагаемое решение сводится к введению в используемые при установлении SIP соединений URI дополнительного поля, содержащего сведения о внутреннем номере абонента PBX. Указанное поле предназначено как для распространения сведений о внутреннем номере абонента при исходящих звонках, так и для информирования о внутреннем номере при осуществлении входящих соединений.
Ниже мы рассмотрим собственно предлагаемое поле и его синтаксис, а так же процедуры его обработки при различных, связанных с ним ситуациях.
Введение дополнительного поля "ext" в SIP URI
Автором предлагается введение в SIP URI дополнительного поля "ext", предназначенного для указания сведений о внутреннем номере терминала PBX.
В соответствии с RFC 3261 [2], RFC 2396 [3], RFC 1738 [4], RFC 3261 [5] и RFC 2806 [6], определяющими формат SIP URI, указанное поле в настоящий момент не используется, не зарезервировано и не противоречит установленным синтаксическим правилам.
На основании положений RFC 2396 [3], RFC 1738 [4], дополнительные поля в URI описываются следующим формальным синтаксисом:
fieldspec = ";" fieldname "=" fieldvalue
Предлагаемое поле может быть описано следующими формулировками:
fieldname = "ext"
fieldvalue = [ display_name ] "<" [ ( protocol | method ) ":"] pstn_number [ "@" hostname ] ">"
или например:
;ext=Victor S. Petrov<sip:2215@user15.example.ru>
Формирование поля "From:" при исходящих соединениях При осуществлении внутренним абонентом PBX исходящего соединения в сеть общего пользования, в ходе процедуры замены в поле "From: " внутреннего абонентского номера на внешний, сведения о внутреннем не удаляются, но перемещается в тело создаваемого в URI дополнительного поля "ext". У перемещаемого значения могут быть, по соображениям безопасности, опущены наименование протокола (метода) и сетевой адрес узла.
Так если при существующей реализации, поле
From: Victor S. Petrov<sip:2215@user15.example.ru>
будет заменено на поле
From: The Beer Drinking Factory<sip:+74951234567@ pbx.example.ru>,
то при использовании дополнительного поля "ext", сведения о внутреннем номере будут перемещены в указанное поле, а именно:
From: The Beer Drink'ng Factory<sip:+74951234567@ pbx.example.ru>;ext=Victor S. Petrov<sip:2215@ user15.example.ru>,
или приведем более безопасный вариант, не раскрывающий внутренние технические сведения, совершенно не требуемые для решения описываемой проблемы:
From: The Beer Drink'ng Factory<sip:+74951234567@ pbx.example.ru>;ext=Victor S. Petrov<2215>
Формально возможна ситуация, при которой замена внутреннего номера внешним осуществляется несколько раз последовательно -при подключении PBX в качестве внутреннего абонента другого PBX.
Таким образом, при создании дополнительного поля "exf1, подобные поля могут уже присутствовать в URI. В этом случае, вновь создаваемое поле должно вставляться самым первым, непосредственно после основного значения поля "From: ", не изменяя другие возможные дополнительные поля "ext", но предво-ряя их. Например:
From: The First Moscow Buisiness Center
<sip:+74959876543@pbx.mbc1 .ru>;ext=The Beer Drinking Factory<4321>;ext=Victor S. Petrov<2215>
Индикация параметров входящего
вызова терминалом
Поскольку предлагаемый способ создает возможность уведомления абонента получающего входящий вызов не только о внешнем, но и о внутреннем номере вызывающего абонента, то терминальное оборудование, принимающее соединение должно иметь возможность индицировать (и очевидно сохранять для различных сервисов) поступающую информацию в полном объеме.
В зависимости от конкретной реализации, вместе со сведениями об отображаемом имени вызывающего абонента и его номере из поля "From: ", необходимо отображать и аналогичные сведения из его дополнительного поля (или полей) "exf.
Например:
Вас вызывает Victor S. Petrov (2215) из The Beer Drinking Factory (+74951234567)
или
Пропущенный звонок +74951234567 доб. 2215
Обработка дополнительного поля "exf
при входящих соединениях
При обработке входящего соединения, в случае успешного вхождения во входной кон-
текст, соответствующий основному значению URI используемого в запросе INVITE, при наличии в указанном URI, или в URI поля 'To: " дополнительных полей "ext", должна выполняться дополнительная процедура. Содержимое первого дополнительного поля "ext" URI должно быть перемещено в основное значение поля, а само дополнительное поле удалено. Например:
To: <sip:+74951234567@pbxexample.ru>; ext=<2215>
изменено на To: <sip:2215@localhost>
Затем, новое значение должно быть повторно интерпретировано в текущем контексте, как номер для дальнейшего соединения.
Формирование поля 'То: " инициирующем
соединение терминалом
Терминал, осуществляющий прямое исходящее соединение с внутренним абонентом PBX должен иметь возможность сформировать расширенный URI в поле 'To: ". В соответствии с предлагаемым способом, необходимо добавить в URI дополнительное поле, задающее внутренний номер абонента. Так, если внешний номер PBX в сети общего пользования +74951234567, а внутренний номер абонента 2215, то должен быть сформировано следующее знанчение:
To: <sip:+74951234567@pbxexample.ru>; ext=<2215>
Несомненно, описываемое расширение предъявляет дополнительные требования и к сервисному функционалу терминала.
Например, функционал прямого набора номера должен иметь возможность разделить
набираемые внешний и внутрений номер, если таковой вводится. Так же, в случае использования в терминале сохраненного списка корреспондентов, ("адресной книги"), необходимо предусмотреть возможность сохранения в ней и сведений о внутреннем номере корреспондента для прямого соединения.
Вопросы безопасности
Несомненно, увеличение объема распространяемых сведений о внутренней структуре PBX потенциально понижает его защищенносты перед производимыми атаками.
Формат SIP URI содержит не только информацию о номере (или идентификаторе) абонента, но и данные об IP-адресе его терминала или его доменном имене, использованном протоколе и методе. Это позволяет потенциальному атакующему собирать сведения о реальной инфраструктуре, организации транспортной интернет-сети, доменной политике, протоколах, используемых на различных направлениях, возможных удаленных терминалах за пределами периметра PBX и иную приватную информацию.
Ввиду того, что подобные сведения никаким образом не требуются для реализации предлагаемого метода, автор считает разумным не включать в формат дополнительного поля "ext” информацию о типе протокола, методе и интернет-адресе терминала. (В частности, в п. 5.2 показан пример формирования сокращенного поля, не приводящего указанные сведения.)
Остальные распространяемые сведения не составляют угрозы информационной безопасности, но все же дополнительно могут корректироваться путем создания на уровне реализаций, дополнительных механизмов определения политик формирования сообщаемых в полях "ext" сведений.
Заключение
В целом, поскольку протокол SIP по своей идеологии является расширяемым и построенным в соответствии с моделью совместимости "снизу вверх", то все его концептуально правильно выполненные реализации, встретив неизвестное поле или команду, должны игнорировать таковые, но не переходить в состоянии ошибки.
Следовательно, введение поля "ext" не должно вызывать отказы или сбои в системах не поддерживающих предлагаемое расширение и его реализации могут внедряться в существующих SIP-сетях, не провоцируя каких либо коллизий.
Литература
1. Международный Союз Электросвязи, "E.164: Международныий план нумерации электросвязи общего пользования", Сектор стандартизации электросвязи МСЭ, 02/2005.
2. T. Bernes-Lee, L Masinter and M. McCahill, "Uniform Resource Locators (URL)", RFC 3261, December 1994.
3. Berners-Lee, T., R. Fielding and L Maniste, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
4. T. Berners-Lee, L Masinter, M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
5. J. Rosenberg, H Schulzrinne, G. Camarilo, A. Johnston, J. Peterson, R. Sparks, M. Handley and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
6. A. Vaha-Sipia, "URLs for Telephone Calls", RFC 2806, April 2000.
The transmission method using a SIP extension details PBX terminal when establishing outgoing and incoming connections Richard O. Panteleichuk, Institute ofSolid State Physics (ISSP), engineer, e-mail: ogogon@ogogon.org
Abstract
A novel technique utilizing a SIP URI extension is proposed. It allows for transferring the PBX extension number of the call-initiating subscriber directly to public networks. It also enables making direct inbound connections from public networks to PBX local terminals, eliminating the necessity of using specific "extension dialing" functions. The proposed technique is compared with existing solutions. An additional SIP URI field "ext" and procedures of its handling are described.
Keywords: VoIP, SIP, RFC 3261, URI, RFC 2396, PBX, CID, Caller ID, protocol extension, extension numbers, extension dialing.
