Web call (uri2dec) open source project home page

Welcome

August 19, 2007

Дайджест VoIP, середина 2006

Filed under: Technical notes — admin @ 7:12 pm

Дайджест VoIP, середина 2006
Содержание
SIP стандарты 3
SDP-Related Documents 3
RTP-Related Documents 3
HTTP-Related Documents 4
MIME-Related Documents 4
SIP Extension and Options 5
SIP Informational RFCs and BCP Documents 6
SIP-Related Documents 7
ENUM Internet-Drafts: 8
ENUM Request For Comments: 8
Directory Services Documents 9
SIP-телефония 9
Вместо вступления… 9
Возможности протокола SIP 9
Архитектура SIP-сети 10
Сообщения SIP 11
Пример 12
Кодеки 13
Методика тестирования 13
Заключение 13
Internet-телефония как двигатель SIP 13
NAT: РЕШЕНИЕ ПРОБЛЕМЫ 15
QOS: БЕРЕГА ПОКА НЕ ВИДНО 15
БЕЗОПАСНОСТЬ: СТАРАЯ ТЕМА НА НОВЫЙ ЛАД 16
Немного о SIP, H.323, IAX2 16
Asterisk 17
IAX trunking 17
Техническая спецификация сервера IP-PBX Asterisk 18
Сетевые услуги 18
Возможности масштабирования сети 18
Поддерживаемые протоколы 18
Поддерживаемые кодеки 18
Поддержка традиционной телефонной сигнализации 19
Поддержка MF и DTMF сигнализации 19
Сравнение IAX2 и SIP 19
Asterisk IAX clients 20
Hardware 20
Hardphones 20
Distributors 20
Software 20
Applications 20
IAXClient - Open Source library to implement the IAX protocol used by The Asterisk Software PBX 21
Kiax 22
What is a softphone? Cubix 22
Technical Specifications 23
Features 23
Sample Config for IAX/IAX2 Client for Asterisk as under 24
SIP-телефоны 25
Cisco IP phone 7940 25
Vontel IP 110 25
QTECH QVI-P2 VoIP 26
D-Link DPH-120S 26
D-Link DPH-140S 27
Samsung OfficeServ SOHO 27
PLANET VIP-153PT 28
PLANET VIP-153T 28
USB-телефоны 29
Telco PH-397 USB 29
SkypeMate USB-P1K 29
SkypeMate USB-P1M 30
SIP-адаптеры 30
Cisco ATA-186 30
LinkSys RT31P2 broadband router 31
Grandstream ATA-486 31
QTECH QVI-G4SO1-1 32
Nateks VoiceCom115 32
Nateks VoiceCom130 32
Nateks VoiceCom110 33
D-Link DVG-2004S 33
Офисная АТС на Asterisk малой кровью или бюджетный способ получить мини АТС с функциями серьезной станции. 33
1. Почему (На правах введения). 33
2. Что. 33
3. Как. 33
3.1 Установка Asterisk 35
3.1.1 Подключение абонентов 35
Подключение аналоговых телефонов 40
3.1.2 Подключение внешних каналов 40
3.1.2.1 Через DialPeer провайдера VoIP используя обычный IP канал 43
3.1.2.2 Через аналоговые карты Digium 43
3.1.2.3 Через цифровые карты E1 потока Digium или аналогичные 43
3.2 Установка RADIUS плагина для Asterisk. Взаимодействие с LANBilling VoIP RADIUS агентом (выполняет функции сервера RADIUS). 43
Установка. 44
Системы статистики звонков и корпоративного биллинга для Asterisk 44
Введение 44
Система статистики Asterisk 45
Mobile Client Software Factory – July 2006 51
Summary 51
Contents 52
Overview 52
Architect Scenarios 56
Benefits 56
Getting Started 60
Community 60
Future Plans 60
Feedback and Support 61
Authors and Contributors 61
Сеть SIPNET 62
ИНТЕГРАЦИЯ СИСТЕМ АДРЕСАЦИИ E.164 И DNS НА ОСНОВЕ ENUM 63

SIP стандарты
RFC 2543 SIP: Session Initiation Protocol (obsolete: see RFC 3261)
RFC 3261 SIP: Session Initiation Protocol

SDP-Related Documents
RFC 2327
Session Description Protocol (SDP) (obsolete)
RFC 4566
An Offer/Answer Model with the Session Description Protocol (SDP)
RFC 3266
Support of IPv6 in SDP
RFC 3388
Grouping Media Lines in SDP
RFC 3407
Session Description Protocol (SDP) Simple Capability Declaration
RFC 3556
SDP Bandwidth Modifiers for RTCP Bandwidth
RFC 3605
Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)
RFC 3890
A Transport Independent Bandwidth Modifier
RFC 4091
An Alternative NAT Semantics for SDP
RFC 4145
TCP-Based Media Transport in the SDP
RFC 4567
Key Management Extensions for SDP and RTSP
RFC 4568
SDP Security Descriptions for Media Streams
RFC 4570
SDP Source Filters
RFC 4572
Connection-Oriented Media Transport over TLS in SDP

RTP-Related Documents
RFC 3550
RTP: Transport Protocol for Real-Time Applications
RFC 3551
RTP Profile for A/V Conferences with Minimal Control
RFC 2198
RTP Payload for Redundant Audio Data
RFC 2733
An RTP Payload Format for Generic Forward Error Correction
RFC 2793
RTP Payload for Text Conversation (obsolete: see RFC 4103)
RFC 2833
RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
RFC 2959
Real-Time Transport Protocol Management Information Base
RFC 3389
RTP Payload for Comfort Noise
RFC 3611
RTP Control Protocol Extended Reports (RTCP XR)
RFC 3711
The Secure Real-time Transport Protocol (SRTP)
RFC 4103
RTP Payload for Text Conversation
RFC 4571
Framing RTP and RTCP Packets over Connection-Oriented Transport
RFC 4585
Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF)
RFC 4586
RTP/AVPF: Results of the Timing Rule Simulations
RFC 4588
RTP Retransmission Payload Format

HTTP-Related Documents
RFC 2616
Hypertext Transfer Protocol — HTTP/1.1
RFC 2617
HTTP Authentication: Basic and Digest Access Authentication
RFC 3310
HTTP Digest Authentication Using Authentication and Key Agreement (AKA)

MIME-Related Documents
RFC 1847
Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
RFC 2045
MIME Part One: Format of Internet Message Bodies
RFC 2046
MIME Part Two: Media Types
RFC 2047
MIME Part Three: Message Header Extensions for Non-ASCII Text
RFC 2048
MIME Part Four: Registration Procedures
RFC 2633
S/MIME Version 3 Message Specification
RFC 3204
MIME media types for ISUP and QSIG Objects
RFC 3420
Internet Media Type message/sipfrag
RFC 3555
MIME Type Registration of RTP Payload Formats

SIP Extension and Options
RFC 2976
The SIP INFO Method
RFC 2848
Extensions for IP Access to Telephone Call Services
RFC 3050
CGI for SIP
RFC 3262
Reliability of Provisional Responses
RFC 3263
Locating SIP Servers
RFC 3265
SIP-Specific Event Notification
RFC 3311
UPDATE Method
RFC 3312
Integration of Resource Management and SIP
RFC 3313
Private SIP Extensions for Media Authorization
RFC 3319
DHCPv6 Options for SIP Servers
RFC 3323
A Privacy Mechanism for SIP
RFC 3324
Short Term Requirements for Network Asserted Identity
RFC 3325
Private Extensions to SIP for Asserted Identity within Trusted Networks
RFC 3326
The Reason Header Field
RFC 3327
Extension Header Field for Registering Non-Adjacent Contacts
RFC 3329
Security Mechanism Agreement
RFC 3361
DHCP-for-IPv4 Option for SIP Servers
RFC 3372
SIP for Telephones (SIP-T): Context and Architectures
RFC 3398
ISUP to SIP Mapping
RFC 3428
SIP Extension for Instant Messaging
RFC 3455
Private Header Extensions for 3GPP
RFC 3515
The Session Initiation Protocol (SIP) Refer Method
RFC 3578
Mapping ISUP Overlapped Signalling to SIP
RFC 3581
Extension to SIP for Symmetric Response Routing
RFC 3608
Extension Header Field for Service Route Discovery During Registration
RFC 3680
SIP Event Package for Registrations
RFC 3840
Indicating User Agent Capabilities in SIP
RFC 3841
Caller Preferences for SIP
RFC 3842
Message Summary and Message Waiting Indication Event Package
RFC 3856
Presence Event Package
RFC 3857
A Watcher Information Event Template-Package
RFC 3891
“Replaces” Header
RFC 3893
SIP Authenticated Identity Body (AIB)
RFC 3903
Event State Publication
RFC 3959
Early Session Disposition Type
RFC 3960
Early Media and Ringing Tone Generation
RFC 4028
Session Timers in the Session Initiation Protocol (SIP)
RFC 4235
An INVITE-Initiated Dialog Event Package for SIP
RFC 4244
Extension for Request History Information
RFC 4320
Actions Addressing Identified Issues with the SIP Non-INVITE Transaction
RFC 4411
Extending the SIP Reason Header for Preemption Events
RFC 4412
Communications Resource Priority for SIP
RFC 4483
A Mechanism for Content Indirection in SIP
RFC 4488
Suppression of SIP REFER Method Implicit Subscription

SIP Informational RFCs and BCP Documents
RFC 3087
Control of Service Context using SIP Request-URI
RFC 3351
User Requirements for SIP in Support of Speech/Hearing Impaired
RFC 3603
Private SIP Proxy-to-Proxy Extensions for PacketCable Distributed Call Signaling
RFC 3702
Authentication, Authorization, and Accounting Requirements for SIP
RFC 3824
Using E.164 numbers with SIP
RFC 3911
The SIP “Join” Header
RFC 3968
IANA Registry for SIP Header Field
RFC 3969
IANA Registry for SIP URI
RFC 3976
Interworking SIP and IN Applications
RFC 4117
Transcoding Services Invocation using 3PCC
RFC 4123
SIP-H.323 Interworking Requirements
RFC 4168
SCTP as a transport for SIP
RFC 4189
Requirements for End-to-Middle Security for SIP
RFC 4240
Basic Network Media Services with SIP
RFC 4245
High-Level Requirements for Tightly Coupled SIP Conferencing
RFC 4317
SDP Offer/Answer Examples
RFC 4321
Problems Identified Associated with the SIP Non-INVITE Transaction
RFC 4353
A Framework for Conferencing with SIP
RFC 4354
SIP Event Package and Data Format for Push-to-Talk over Cellular (PoC) Service
RFC 4453
Requirements for Consent-Based Communications in the SIP
RFC 4457
SIP P-User-Database Private-Header (P-Header)
RFC 4458
SIP URIs for Applications such as Voicemail and Interactive Voice Response (IVR)
RFC 4475
SIP Torture Test Messages
RFC 4504
SIP Telephony Device Requirements and Configuration
RFC 4538
Request Authorization through Dialog Identification in SIP
RFC 4596
Guidelines for Usage of the SIP Caller Preferences Extension

SIP-Related Documents
RFC 3219
Telephony Routing over IP (TRIP) (tutorial)
RFC 3320
Signalling Compression
RFC 3321
Signalling Compression - Extended Operations (informational)
RFC 3322
Signalling Compression - Requirements and Assumptions (informational)
RFC 3486
Compressing the Session Initiation Protocol (SIP)
RFC 3485
SIP and SDP Static Dictionary for Signaling Compression
RFC 3725
Best Current Practices for 3PCC in SIP
RFC 3764
enumservice registration for SIP Addresses-of-Record
RFC 4077
A Negative Acknowledgement Mechanism for Signaling Compression
RFC 4083
3GPP Release 5 Requirements on SIP
RFC 4092
Using SDP Alternative NAT Semantics in SIP
RFC 4465
Signaling Compression (SigComp) Torture Tests
RFC 4497
Interworking between the SIP and QSIG

ENUM Internet-Drafts:
ENUM Implementation Issues and Experiences (76038 bytes)
IANA Registration for Enumservice VOID (29734 bytes)
ENUM Validation Information Mapping for the Extensible Provisioning Protocol (47322 bytes)
ENUM Validation Architecture (33740 bytes)
ENUM Validation Token Format Definition (32332 bytes)
IANA Registration for an Enumservice Containing PSTN Signaling Information (26798 bytes)
IANA Registration for vCard Enumservice (16683 bytes)
Guide and Template for IANA Registrations of Enumervices (26191 bytes)
Infrastrucure ENUM Requirements (14554 bytes)
A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services (9838 bytes)
A Telephone Number Mapping (ENUM) Service Registration for Internet Calendaring Services (11064 bytes)
The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application for Infrastructure ENUM (12146 bytes)
IANA Registration for an Enumservice Calling Name Delivery (CNAM) Information and IANA Registration for Media type ‘application/cnam’ (26827 bytes)
The ENUM Branch Location Record (11345 bytes)
Combined User and Infrastructure ENUM in the e164.arpa tree (21877 bytes)
ENUM Requirement for EDNS0 Support (23491 bytes)
ENUM Request For Comments:
E.164 number and DNS (RFC 2916) (18159 bytes) obsoleted by RFC 3761
Number Portability in the Global Switched Telephone Network (GSTN): An Overview (RFC 3482) (78552 bytes)
enumservice registration for SIP Addresses-of-Record (RFC 3764) (17604 bytes)
ENUM Service Registration for H.323 URL (RFC 3762) (8450 bytes)
The E.164 to URI DDDS Application (ENUM) (RFC 3761) (41559 bytes) obsoletes RFC 2916
Enumservice Registration for Presence Services (RFC 3953) (13875 bytes)
IANA Registration for ENUMservices web and ft (RFC 4002) (18072 bytes)
E.164 Number Mapping for the Extensible Provisioning Protocol (EPP) (RFC 4114) (31490 bytes)
IANA Registration for Enumservices email, fax, mms, ems and sms (RFC 4355) (30218 bytes)
IANA Registration for Enumservice Voice (RFC 4415) (15956 bytes)
An ENUM Registry Type for the Internet Registry Information Service (IRIS) (RFC 4414) (89985 bytes)
Directory Services Documents
H.350
Directory Services Architecture for Multimedia Conferencing
H.350.4
Directory Services Architecture for SIP
SIP-телефония
Ixbt.ru
http://www.sightspeed.com/
Вместо вступления…
В последнее время наблюдается повышенный интерес к технологиям IP-телефонии, использование которой позволяет в значительной мере снизить стоимость телефонной связи. При этом становится возможным использование сети Интернет, что позволяет сразу достичь “глобальных масштабов”, а необходимость прокладки магистральных коммуникаций попросту отпадает.
Целью данной статьи является поверхностное рассмотрение возможностей IP-телефонии, использующей протокол SIP, для ознакомления с общими принципами ее работы.
Протокол SIP (Session Initiat Protocol, протокол установки соединения) не является первопроходцем в области IP-телефонии. Протокол H.323 уже давно используется для целей IP-телефонии, однако изначально он не разрабатывался для IP-сетей, что снижает “оптимальность” их совместной работы. За годы работы с протоколом H.323 накоплен большой опыт использования, который позволил выявить как его положительные черты, так и недостатки, которые были учтены при разработке протокола SIP.
Протокол H.323 использует двоичный формат. Одним из следствий этого является необходимость стандартизации всех возможностей данного протокола, так как в случае если определенная возможность не поддерживается устройством, то такие устройства из-за двоичного формата не смогут работать друг с другом. SIP-протокол использует текстовый формат сообщений, если одному из устройств не знаком определенный тип сообщения или заголовка, то оно просто игнорируется (как и в HTTP, который по своему формату очень похож формат протокола SIP). К тому же сам протокол SIP значительно проще H.323.
Возможности протокола SIP
Основные преимущества протокола SIP:
1. Масштабируемость - возможность увеличения количества клиентов при расширении сети.
2. Мобильность - возможность получения сервиса вне зависимости от местоположения (как например электронная почта), а каждому пользователю выдается персональный идентификатор, по которому он может быть найден.
3. Расширяемость - возможность дополнения протокола новыми функциями (за счет введения новых заголовков и сообщений). Как уже говорилось выше, если устройству встречается неизвестное ему расширение протокола, оно попросту игнорируется. Так как протокол H.323 использует сообщения двоичного формата, то неизвестные функции могут привести к невозможности предоставления сервиса.
Протокол SIP разрабатывался с расчетом на возможность использования любых транспортов, но, тем не менее, наиболее предпочтительным является использование UDP-пакетов (это позволяет повысить производительность по сравнению с использованием протокола TCP, но требует использования дополнительных механизмов проверки доставки сигнальных сообщений).
Так как телефония с использованием протокола SIP позволяет использовать большое количество разнообразных сервисов (помимо передачи голоса, возможна передача видео, текстовых сообщений, факсов и др.), необходим механизм обмена информацией о том, какие сервисы может использовать вызываемая\вызывающая стороны. Для этой цели используется протокол SDP (Session Description Protocol) - протокол описания сессии. Данный протокол позволяет определить какие звуковые (видео и другие) кодеки и иные возможности может использовать удаленная сторона.
Собственно сама передача голоса осуществляется благодаря использованию протокола RTP (Real-time Transport Protocol, протокол транспортировки в реальном времени). Сам протокол SIP непосредственного участия в передаче голосовых, видео и других данных не принимает, он отвечает только за установление связи (по протоколам SDP, RTP и др.), поэтому под SIP-телефонией понимается не передача голоса по протоколу SIP, а передача голоса с использованием протокола SIP. Использование протокола SIP предоставляет новые возможности установления соединений (а также возможность беспроблемного расширения данных возможностей), а не непосредственной передачи голосового и других видов трафика.
Формат адресов используемых протоколом SIP напоминает формат E-Mail-адреса: имя@идентификатор_хоста. В начале адреса ствится приставка “sip:” (пример: sip:user@host.com). В качестве идентификатора хоста может служить его IP-адрес, домен или имя хоста (IP-адрес определяется с использованием DNS, так что в итоге все равно получается обращение по адресу sip: имя@IP-адрес).
Архитектура SIP-сети
Стандартными элементами в SIP-сети являются:
1. User Agent: по протоколу SIP устанавливаются соединения “клиент-сервер”. Клиент устанавливает соединения, а сервер принимает вызовы, но так обычно телефонный аппарат (или программный телефон) может как устанавливать так и принимать звонки, то получается что он одновременно играет роль и клиента и сервера (хотя в реализации протокола это не является обязательным критерием) - в этом случае его называют User Agent (UA) или терминал.
2. Прокси-сервер: прокси сервер принимает запросы и производит с ним некоторые действия (например определяет местоположение клиента, производит переадресацию или перенаправление вызова и др.). Он также может устанавливать собственные соединения. Зачастую прокси-сервер совмещают с сервером определения местоположения (Register-сервер), в таком случае его называют Registrar-сервером.
3. Сервер опредления местоположения или сервер регистрации (Register): данный вид сервера служит для регистрации пользователей. Регистрация пользователя производится для определения его текущего IP-адреса, для того чтобы можно было произвести вызов user@IP-адрес. В случае если пользователь переместится в другое место и/или не имеет определенного IP-адреса, его текущий адрес можно будет определить после того, как он зарегистрируется на сервере регистрации. Таким образом клиент останется доступен по одному и тому же SIP-адресу вне зависимости от того, где на самом деле находится.
4. Сервер переадресации: обращается к серверу регистрации для определения текущего IP-адреса пользователя, но в отличие от прокси сервера только “переадресует” клиента, а не устанавливает собственные соединения.

Прокси-серверы в SIP-сети также могут вносить изменения в передаваемые сообщения - это позволяет беспрепятственно преодолевать NAT в случае если прокси-сервер стоит на NAT-маршрутизаторе (также возможна настройка прокси сервера, находящегося за NAT в случае если на последнем невозможно установить прокси сервер - для этого потребуется задать параметры переадресации так, чтобы получился прокси-сервер стал “виртуальным сервером”). Помимо этого прокси-серверы можно объединять в “цепочки”, которые позволяют использовать телефонию, даже если конечная точка (UA) находится сразу за несколькими NAT-шлюзами.
Сообщения SIP
Сообщения SIP-протокола имеют следующую структуру:
Стартовая строка (start-line)
Заголовки сообщения (*message-header)
Пустая строка (CRLF)
Тело сообщения
Стартовая строка различается в зависимости от того является ли сообщение запросом или ответом (в случае запроса - в ней сообщается тип запроса, адресат и номер версии протокола, а в случае ответа - номер версии протокола, статус и текстовую расшифровку статуса).
В заголовках содержатся сведения об источнике, адресате, пути следования сообщения и др. Этих заголовков может быть достаточно много и это количество может меняться на пути следования пакетов.
В протоколе SIP версии 2.0 существует 6 типов запросов (тип запроса задается в стартовой строке):
INVITE - вызывает адресата для установления связи. С помощью этого сообщения адресату передаются виды поддерживаемых сервисов (которые могут быть использованы инициатором сеанса), а также виды сервисов, которые желает передавать инициатор связи
ACK - сообщение подтверждающее согласие адресата установить соединения. В этом сообщении могут быть переданы окончательные параметры сеанса связи (окончательно выбираются виды сервисов и их параметры которые будут использованы)
Cancel - отмена ранее переданных запросов (используется в случае если необходимости в них больше нет)
BYE - запрос завершения соединения
Register - данным запросом пользователь идентифицирует свое текущее местоположение
OPTIONS - запрос информации о функциональных возможностях терминала (применяется в случае, если эти данные нужно получить до установления соединения, то есть до фактического обмена данной информацией с помощью запросов INVITE и ACK)

На каждый запрос, отправителю направляется ответ, содержащий код результата выполнения запроса. Формат этих ответов унаследован от протокола HTTP. Ответы кодируются 3-хзначным числом, первая цифра которого указывает на класс ответов, а остальные две - идентифицируют конкретный ответ в каждом классе. Устройство может не знать, что означает код ответа, но должно обязательно знать класс ответа. Всего существует 6 классов ответов:
1?? - информационные ответы
2?? - успешное окончание запроса
3?? - информация об изменения местоположения вызываемого абонента
4?? - информация об ошибке
5?? - информация об ошибке сервера
6?? - информация о невозможности вызова абонента (пользователя с таким адресом не существует, или пользователь отказывается принять вызов)
Информационные ответы сообщают о стадии выполнения запроса, они не являются завершением запроса. Остальные же классы ответов завершают выполнение запроса.

Пример
Рассмотрим пример процесса установления соединения с использованием SIP-протокола (пример взят из RFC 3261). Данный пример отражает работу базовых функций телефонии и соответственно не затрагивает такие возможности как видеосвязь передача текстовых сообщений и др. - общий принцип работы протокола остается неизменным.

рис. 1 (RFC 3261)
Пользователь Alice (sip:alice@atlanta.com) вызывает пользователя Bob (sip:bob@biloxi.com).
1. Пользователь Alice посылает сообщение INVITE прокси-серверу по умолчанию (atlanta.com) Если бы пользователю Alice был известен IP-адрес пользователя Bob и он мог к нему обратиться напрямую, то запрос INVITE в этом случае мог быть послан непосредственно вызываемому пользователю.
2. Прокси-сервер посылает запрос INVITE серверу вызываемого абонента (biloxi.com).
3. Далее прокси-сервер пользователя Bob при необходимости определяет его текущий IP-адрес и посылает ему сообщение INVITE - у пользователя начинает звонить телефон, о чем сообщается в ответе 180 (Ringing).
4. Если вызываемый пользователь ответил на звонок, то на запрос INVITE высылается ответ 200 (OK).
5. Вызывающий пользователь отправляет сообщение ACK, сообщающее вызываемому о том, что он получил ответ на свой запрос INVITE, им задаются окончательные параметры соединения. На этом этапе все готово к установлению соединения по протоколу RTP (Real-time Transport Protocol).
6. Устанавливается RTP-соединение с заранее согласованными параметрами.
7. Для завершения соединения, завершающим пользователем (кладет трубку) высылается запрос BYE, на которое высылается ответ 200 (OK)
Пока сообщения установления соединения (INVITE) ходят между прокси-серверами и неизвестно доступен ли вызываемый пользователь, в ответ на INVITE посылается ответ 100 (Trying), сообщающий о попытке установления соединения.
Так как прокси-сервер может устанавливать собственные соединения, его использование позволяет вызовам без проблем преодолевать NAT. Также возможно построение нескольких прокси-серверов в одну цепочку, что позволяет преодолевать сразу несколько NAT.

Кодеки
Для передачи звука и видео используются различные алгоритмы сжатия и кодирования данных. Эти алгоритмы называются кодеками. Различные кодеки используют различную ширину полосы пропускания, а также вносят различные задержки и обеспечивают различное качество сервиса. Для звуковых кодеков бычно ширина полосы пропускания составляет от 4-х до 64 кбит/с.

Методика тестирования
Основное направления тестирования SIP-телефонии заключается в рассмотрении качества передачи голоса при ограничении ширины полосы пропускания. Также будет рассматриваться качество передачи голоса при динамическом изменении числа сеансов IP-телефонии и изменении загруженности канала связи. При тестировании IP-маршрутизаторов будет также рассматриваться поведение потоков трафика при установлении сеансов IP-телефонии.
Более четкая методика будет разрабатываться по мере нарастания основательной базы результатов тестирования SIP-оборудования различных производителей.

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

Internet-телефония как двигатель SIP
Христиан Штредике LAN #08/2005
Osp.ru

Шумиха вокруг недорогих или вовсе бесплатных телефонных разговоров по Internet помогла окончательно утвердиться SIP как протоколу для передачи голоса по IP. Наибольший интерес к нему проявляется в сегменте конечных пользователей и малых/домашних офисов (SOHO), т. е. в случае телефонных звонков по соединениям DSL. Однако и производители телекоммуникационных систем с поддержкой IP не могут более игнорировать SIP. В статье подробно рассказывается о техническом развитии и изменении стандарта SIP.
Изначально считалось, что протокол SIP для передачи голоса по IP разработчикам будет реализовать проще, чем устоявшийся, но сравнительно сложный конкурирующий протокол Н.323. Эти времена давно прошли. Сегодня стандарты, относящиеся к SIP, уже насчитывают более 2 тыс. страниц, а IETF все еще усердно утверждает новые запросы на комментарии (Requests for Comments, RFC). Речь идет не столько об основополагающих темах, сколько об эзотерических: о транспортном уровне, «политике сеансов» или просто-напросто о том, каким образом медиа-сервер должен перехватывать нажатия клавиш и транслировать их на сервер приложений (см. Рисунок 1).

Рисунок 1. Количество посвященных SIP страниц RFC, отсортированных по дате публикации. Маленькие цифры обозначают номер стандарта.
Для конечного пользователя такие нюансы едва ли имеют значение, поскольку используемый в повседневной жизни набор функций должен быть стабильным. Производители из области SIP уже настолько хорошо освоились с существующими стандартами, что продукты разных компаний в основном совместимы друг с другом. В областях, где IETF пока еще не установила окончательного стандарта, часто производители сами находят прагматические решения. К примеру, Broadsoft определила, каким образом должно осуществляться управление светодиодными индикаторами телефонов и как на телефоне можно принять звонок с компьютера.
Однако стандарт SIP не бесспорен, «конкуренция» поджимает со всех сторон: так, производителю Skype удалось чуть ли не за ночь занять рынок бесплатной Internet-телефонии, да и вообще создать его. Вместо того чтобы ввязываться в дискуссии о стандартизации, инженеры Skype предпочли сами творить историю, предложив собственный подход. То обстоятельство, что при использовании этого метода трафик частично проходит через компьютеры, которые никакого отношения к участвующим в разговоре пользователям не имеют, вследствие чего приходится мириться с неустранимым риском вторжения в частную сферу, по всей видимости, никому не мешает. Для дальнейшего успеха очень важно, примут ли эту технологию в качестве стандарта такие игроки, как Cisco и Microsoft, - вопрос пока открыт.
Еще один протокол VoIP, IAX, наделал очень много шума в связи с перспективой принятия нового стандарта. В спецификации IAX меньше 50 страниц, и привлекает она своей простотой. Воодушевленное этим фактом сообщество открытых исходных кодов, организовавшееся вокруг проекта Asterisk ожидает появления недорогого оборудования для передачи голоса по IP. Однако речь в случае IAX идет о полностью самостоятельном протоколе. Стань он разработкой более крупного игрока, возмущению не было бы предела. А теперь, как и в случае со Skype, IAX остается ждать, согласятся ли его принять лидеры рынка.
NAT: РЕШЕНИЕ ПРОБЛЕМЫ
Преобразование сетевых адресов (Network Address Translation, NAT), как и прежде, одна из важнейших проблем при передаче голоса по IP. В последние годы производители маршрутизаторов DSL и брандмауэров занимались в первую очередь HTTP и SMTP. Типичным для этих протоколов является то, что действия всегда инициируются клиентом: электронная почта ему никогда не доставляется - каждые несколько минут он сам вынужден проверять, нет ли на почтовом сервере непрочитанных сообщений.
В случае телефонии этот подход больше не работает. Сервер (в Internet) должен быть в состоянии доставить клиенту (в локальной сети) сообщение, что удается благодаря ограничению срока действия регистрации клиента, когда тому приходится регистрироваться снова и снова. При этом необходимо «отмечаться» в таблице NAT, через которую сервер отправляет входящие сообщения. Возникающий при таком методе «дежурный» трафик не стоит недооценивать — на каждого пользователя за месяц приходится до 100 Мбайт. Многие операторы скорее смирятся с большим количеством трафика, чем станут объяснять своим клиентам, как им следует конфигурировать маршрутизаторы.
Проблема NAT решается путем простого прохождения UDP поверх NAT (Simple Traversal UDP over NAT, STUN). Этот стандарт (RFC 3489) позволяет конечным устройствам в сети «взглянуть на себя в зеркало» при помощи внешнего сервера и таким образом обеспечить правильное соответствие общедоступных и локальных IP-адресов. Однако STUN функционирует не во всех случаях: если брандмауэр использует так называемую симметричную трансляцию NAT, то конечное устройство становится достижимым через Internet только с сервера STUN, а пакеты иного происхождения, к примеру от IP-телефонов, не пропускаются. STUN работает во многих средах, однако успешное применение этого протокола, к сожалению, остается делом случая.
Новый инфраструктурный компонент для операторских сетей, который решает проблему симметричной трансляции NAT, называется пограничным контроллером сеансов (Session Border Controller, SBC). Вначале он был оценен IETF как «неудачный», однако позже стало ясно, что без него, к сожалению, не обойтись. Благодаря SBC подавляющее большинство абонентов Internet-телефонии могут пользоваться своим IP-телефоном без необходимости внесения каких-либо изменений в маршрутизатор или конечное устройство (см. Рисунок 2). Наряду с решением проблемы NAT контроллер SBC позволяет, к примеру, операторам прерывать разговор, когда средства на счету клиента истекли. Кроме того, с его введением решается и проблема фрагментации UDP, когда маршрутизатор не может корректно переправлять очень большие пакеты. Поскольку SBC не дает полной информации о маршрутизации, пакеты обычно столь малы, что трудностей не возникает. Для оператора такая технология привносит интересный побочный эффект: когда клиенты не видят информации о маршрутизации, они не могут напрямую связаться с собеседником и обойти при этом оператора и связанный с этим биллинг.
QOS: БЕРЕГА ПОКА НЕ ВИДНО
Когда речь идет о передаче голоса по IP в пределах корпоративных сетей, должное качество услуг (Quality of Service, QoS) подразумевается само собой. Это утверждение справедливо также применительно к различным предложениям операторов и провайдеров для соответствующих соединений через глобальную сеть. Иначе выглядит ситуация в области SOHO, где у пользователей также есть желание приобщиться к Internet-телефонии по недорогим соединениям DSL. Локальный маршрутизатор DSL в состоянии сортировать покидающие локальную сеть пакеты по исходящим очередям в соответствии с QoS, однако обратное направление контролирует провайдер.
По опыту Германии можно сказать, что ситуация в этой области оставляет желать лучшего, поскольку соответствующе биты QoS, как правило, игнорируются. Гораздо чаще оператор дает пакетам TCP более высокий приоритет, чем UDP. К сожалению, загрузка в большинстве случаев происходит по ТСР, и поэтому они могут заметно мешать параллельным телефонным разговорам по IP. На данный момент существуют два решения этой проблемы. Первое заключается в выборе провайдера, предлагающего QoS. При использовании SBC он способен обеспечит правильную сортировку пакетов, даже если входящие пакеты VoIP не маркированы битами QoS. Второе, скорее прагматическое, решение состоит в том, чтобы арендовать второй канал DSL и физически разделить голос и данные. Этот вариант функционирует очень хорошо, и при коммерческом использовании часто оправдывает себя экономически.
БЕЗОПАСНОСТЬ: СТАРАЯ ТЕМА НА НОВЫЙ ЛАД
С растущей привлекательностью телефонии на базе Internet возникают схожие проблемы, связанные с безопасностью, как и в других областях коммуникаций по IP: речь идет о спаме, хакерских атаках и попытках прослушивания. По аналогии с сорной почтой наблюдается настоящая волна «сорных» звонков: спам по Internet-телефонии (Spam via Internet-Telephony, SPIT). Поисковая машина Google выдает уже более 130 тыс. совпадений по теме «спам и SPIT». Принцип прост: когда телефонные звонки бесплатны, «спитеры» могут запустить из какой-либо части Internet миллионы звонков, и те, кто их принимает, слышат, что выиграли, например, путешествие на юг Тихого океана. Целевые адреса получить достаточно просто, испробовав все номера, предоставляемые провайдером его клиентам.
Меры противодействия известны по борьбе с традиционным спамом. Во-первых, операторы начинают вести так называемые «белые списки». Как правило, они охватывают адресный потенциал партнеров-операторов. В случае звонка из Internet от третьей стороны он отклоняется. Во-вторых, составляются и «черные списки», содержащие данные о клиентах, рассылающих SPIT, что может происходить и автоматически, когда клиент инициирует больше звонков, чем в состоянии это сделать.
По всей видимости, дело дошло до первых вирусных звонков, содержащих манипулируемый пакет данных: хотя он и не приводит к отказу всей системы, но посредством соответствующего программного кода преобразуется в послушного робота, который по команде превращается, к примеру, в подслушивающий жучок. В таких случаях рекомендуется проинформировать как производителя оконечного устройства, так и провайдера. Для предотвращения подобных атак в будущем существует достаточное количество технических возможностей.
Наряду с так называемыми атаками DoS (к ним относится и SPIT) важную роль играет защита частной сферы, для чего используются методы, аналогичные тем, что специфицированы в НТТР. Аналогом HTTPS является SIPS, «защищенный» стандарт SIP. Как и в случае HTTPS, для идентификации участников служат сертификаты, они представляют базис для согласования необходимого ключа. Соответствующим образом SRTP является дополнением протокола передачи данных в реальном времени (Real Time Transport Protocol, RTP), причем используется шифрование AES с длиной ключа 128 бит. Обмен ключами происходит посредством SIPS. На данный момент дискуссия о корректной формулировке стандарта еще не окончена, однако все вопросы должны быть разрешены в ближайшие месяцы, и при помощи SIPS и SRTP будет возможным полноценное шифрование переговоров.

Немного о SIP, H.323, IAX2
ASTERISK.ORG.RU
Каждый раз, при интеграции оборудования, проектировании сети, необходимо определиться с VoIP протоколами, которые мы будем использовать. На сегодняшний день широкое распространение получили протоколы SIP (Session Initiation Protocol) и рекоммендация H.323, но некоторые операторы начинают использовать IAX2 (Inter-Asterisk eXchange) для организации голосовых потоков между удаленными терминалами. Для того, чтобы разобраться в преимуществах и недостатках таких вариантов, предлагается весьма короткая обзорная заметка.
Все протоколы более или менее стандартизованы. Основное отличие заключается в том, что для SIP стандартизована непосредственно сигнализирующая часть – интерфейс, сервисы же могут быть отдельно стандартизованы, H.323 и IAX2 же предполагают полную стандартизацию. То есть сервисы SIP можно развивать и предлагать к использованию любыми группами разработчиков, H.323 и IAX2 - замкнутые системы. Что лучше - вопрос сложный, ответ в выборе – что лучше, гибкость, развитие, но возможные разочарования от неиспользованных функций, или стабильность и совместимость.
Наиболее удачная реализация в смысле экономии трафика у IAX2, особенно при большом количестве звонков с использованием технологии транков. Далее, SIP и H.323 используют по пять портов (три минимум), IAX2 – только один, что увеличивает конроллируемость и гибкость сети. Также IAX2 поддерживает работу через межсетевые экраны полностью, SIP и H.323 – далеко не во всех случаях.
IAX2 и SIP имеют различные способы для адрессации абонентов. H.323 в этом плане ограничен. Также IAX2 полностью отделяет параметры регистрации от идентификации абонента в сети, что безусловно удобно.
На текущий момент наиболее практичен SIP, как наиболее поддерживаемый. H.323 медленно уходит с рынка VoIP услуг, IAX2 же пока поддерживается только на установках с Asterisk
Asterisk
CITKIT.RU
В Asterisk объединяются возможности мультиплексора с разделением времени (TDM - Time Division Multiplexer), телефонной станции без доступа во внешние сети (PBX - Private Branch eXchange) и IVR-платформы с функциональностью автоматического распределения звонков (ACD – Automated Voice Distribution). Выполняет роль промежуточного программного обеспечения между Интернетом (протоколы IAX, SIP, MGCP, Skinny, H.323), телефонными каналами (Zaptel, T1, PRI, E1, FXO, FXS, VoIP, VoFR, ISDN, модемы, Internet Phone Jack и т.д.) и приложениями (голосовая почта, конференции, службы директорий, проигрыватели MP3, интеркомы и т.д.) Имеет множество полезных возможностей, например API для трансляции кодеков. В базовую поставку входят несколько канальных «движков», а также приложения. Однако самым заметным достоинством Asterisk является возможность расширения системы за счет API, динамического загрузчика модулей и интерфейса AGI для скриптов. Конечные пользователи могут писать собственные приложения для системы на C или на любом скриптовом языке.
IAX trunking
http://freeresource.info/
Объединение (trunking) каналов нужно для экономии полосы пропукания канала.
IAX обладает возможностью передавать в одном пакете данные сразу нескольких параллельных каналов, что резко уменьшает накладные расходы.
При большом количестве одновременных каналов увеличение эффективности использования пропускной способности канала может быть по крайней мере в 1.5–3 раза.
Необходимо помнить, что:
IAX trunking требует наличия zaptel-таймера (хотя бы ztdummy);
опция trunk=yes должна быть в конфигурации IAX на обеих сторонах;
Если trunk=yes установлена только на одном узле, то звук будет односторонний.
Самый лучший способ избежать этой проблемы, использовать register для регистрации на узле, с которым будет работать транк.
Техническая спецификация сервера IP-PBX Asterisk
asterisk.org.
Сетевые услуги
база данных пользователей и персональных настроек;
многосторонняя конференц-связь;
интерактивное голосовое меню (IVR);
очередь звонков и маршрутизация их обработки;
переадресация и парковка вызовов;
маршрутизация по критерию Least Cost Routing (LCR);
индивидуальная и принудительная маршрутизация;
услуги Caller ID;
широкий спектр служб VoiceMail:
сообщения голосовой почты на e-mail;
сообщения голосовой почты для групп пользователей;
доступ к сообщениям через Web-интерфейс;
music on hold и music on transfer в формате .mp3;
принудительный набор;
блокировка абонентов;

Возможности масштабирования сети
Технология Voice-over IP телефонии (VoIP)
Интеграция географически разделённых офисов в единое пространство;
Использование традиционного транспорта IP;
Возможность применения единого плана вызовов для всех участвующих в сетевом обмене серверов;
Технология Time Division Multiplex over Ethernet (TDMoE)
Позволяет прямые соединения между несколькими iBox.Asterisk;
Нулевые задержки и дрожание фазы;
Использует традиционное оборудование Ethernet;
Поддерживаемые протоколы
Inter-Asterisk Exchange (IAX);
H.323;
Session Initiation Protocol (SIP);
Media Gateway Control Protocol (MGCP);
Cisco® Skinny® (SCCP);
Поддерживаемые кодеки
ADPCM;
G.711 (A-Law и μ-Law);
G.723.1 (режим “pass through”);
G.726;
G.729 (необходимо приобрести лицензию, см. ниже);
GSM;
iLBC;
Linear;
LPC-10;
Speex;
Поддержка традиционной телефонной сигнализации
Loopstart
FXS
FXO
Groundstart
Kewlstart
E&M
E&M Wink
Feature Group D
GR-303
Поддержка MF и DTMF сигнализации
Robbed-bit Signaling (RBS) Types

Являясь продуктом open-source технологий, IP-PBX Asterisk предполагает использование лицензионного кодека G.729 только после приобретения лицензии. Кодек G.729 доступен на web-сайте Digium.com. Оплата производится на поканальной основе.

Сравнение IAX2 и SIP
http://freeresource.info/
IAX is information-element encoded rather than ASCII encoded. This makes implementations substantially simpler and more robust to buffer overrun attacks since absolutely no text parsing or interpretation is required. The IAXy runs its entire IP stack, IAX stack, TDM interface, echo canceller, and callerid generation in 4k of heap and stack and 64k of flash. Clearly this demonstrates the implementation efficiency of its design. The size of IAX signalling packets is phenomenally smaller than those of SIP, but that is generally not a concern except with large numbers of clients frequently registering. Generally speaking, IAX2 is more efficient in its encoding, decoding and verifying information, and it would be extremely difficult for an author of an IAX implementation to somehow be incompatible with another implementation since so little is left to interpretation.
IAX has a very clear layer2 and layer3 separation, meaning that both signalling and audio have defined states, are robustly transmitted in a consistant fashion, and that when one end of the call abruptly disappears, the call WILL terminate in a timely fashion, even if no more signalling and/or audio is received. SIP does not have such a mechanism, and its reliability from a signalling perspective is obviously very poor and clumsy requiring additional standards beyond the core RF3261.
IAX’s unified signalling and audio paths permit it to transparently navigate NAT’s and provide a firewal administrator only a *single* port to have to open to permit its use. It requires an IAX client to know absolutely nothing about the network that it is on to operate. More clearly stated, there is *never* a situation that can be created with a firewall in which IAX can complete a call and not be able to pass audio (except of course if there was insufficient bandwidth).
5 IAX’s authenticated transfer system allows you to transfer audio and call control off a server-in-the-middle in a robust fashion such that if the two endpoints cannot see one another for any reason, the call continues through the central server.
IAX clearly separates Caller*ID from the authentication mechanism of the user. SIP does not have a clear method to do this unless Remote-Party-ID is used.
SIP is an IETF standard. While there is some fledgling documentation courtesy Frank Miller, IAX is not a published standard at this time.
IAX allows an endpoint to check the validity of a phone number to know whether the number is complete, may be complete, or is complete but could be longer. There is no way to completely support this in SIP.
IAX always sends DTMF out of band so there is never any confusion about what method is used.
IAX support transmission of language and context, which are useful in an Asterisk environment. That’s pretty much all that comes to mind at the moment.

Asterisk IAX clients
Voip-info.org
Hardware
ATAs:
IAXy by Digium
S100-FX by X100P
Virbiage 3010: Available direct from Virbiage, or rebranded (e.g. this Freshtel ATA)

Hardphones
GNET: VP320I phone. PA1688 based VoIP Phone
SNOM: Used to have a IAX1 firmware somehwere in 2003
China Roby: IAX2 Phones and Gateways. Currently no distributors. Must be ordered direct from mfr.
France YoIAX Phone: IAX2 Phones with CE Certification. Looking for resellers.
Vlines Europe: IP-Phone VD160 with IAX2 support

Distributors
American Distributor for ATCOM AG168V Gateway: http://www.iareaphone.com
Australian ATCOM distributor: http://www.ob-wan.com/voip
European reseller of ATCOM AT-320 and ATCOM AG-168V: Upnet Taide
European reseller: for all ATCOM products. IP Phones, ATA’s and USB phones
German / European reseller: for all ATCOM products. AT 320 PD - SIP/IAX-Phone, AU 100 - USB-IAX-Phone, AG168V - SIP/IAX-ATA

Software
Libraries
libiax2: Digium’s base IAX2 protocol library
IAXClient: IAX2 softphone library

Applications
Cubix for Windows
DIAX for Windows
Ephone for Windows
Firefly for Windows
GnoPhone for Linux
IaxClientOcx for Windows
IAXComm for Windows, Linux & MacOSX
iaxLite for Windows
IAX Phone for Windows
Idefisk for Windows, Linux and Mac
JackenIAX for MacOSX
JIAXclient - JAVA applet and library
Kiax for Linux and Windows
LoudHush for MacOSX
MediaX Phone for Windows
MozIAX IAX2 plugin for Firefox (Linux & Windows)
PPCIAX for PocketPC
QtIAX written in Qt3.x with a very (!) stripped down libiax
tel
VoipSurfer for PocketPC (WM 2003/2003SE and WM 5.0) english and german
WebIAX ActiveX
IAXClient - Open Source library to implement the IAX protocol used by The Asterisk Software PBX
http://iaxclient.sourceforge.net/
Although asterisk supports other VOIP protocols (including SIP, and with patches, H.323), IAX’s simple, lightweight nature gives it several advantages, particularly in that it can operate easily through NAT and packet firewalls, and it is easily extensible and simple to understand.
Tools
Some developer information
SourceForge Development Site
Subscribe to the mailing list!
FAQ
You can also catch some of the developers online at irc.freenode.net, #iaxclient, or #asterisk
Projects Using IAXClient
iaxComm: a GPL softphone built using IAXClient and wxWindows.
Runs on Microsoft Windows, Mac OSX, Linux, FreeBSD, Solaris.
DIAX: From the home page:
“This is a full featured and very small (less than 100KB for all the files) IAX based software phone for Microsoft Windows platforms (only).
The application is distributed as a freeware for personal use.”
IaxPhone: another GPL softphone built using IAXClient. Written in VB6.
IaxClientOcx: An OCX control written by Babar Shafiq
ZiaxPhone: A softphone for the Zaurus PDA written by Stephan Kauss
IDEFisk: Another Windows softphone from asteriskguru.com
KIAX: A QT-based softphone
PURtel Softphone: An enhanced softphone written especially for connecting to PURtel’s VOIP network.
Others?
If you’re using IAXClient in your application, let us know so we can spread the word.
Kiax
http://kiax.org/
Kiax is a software phone (soft phone, VoIP client) with a simple and comfortable user interface for making VoIP calls to Asterisk PBX. It depends on the iaxclient library to use Asterisk’s IAX2 protocol for easy call configuration and audio setup.

Download Kiax - an IAX Softphone

Operating System: All 32-bit MS Windows (95/98/NT/2000/XP), FreeBSD, Linux, NetBSD

What is a softphone? Cubix

Cubix is a Softphone - The term softphone is short for software telephone and that’s just a fancy way of saying Internet telephone. Cubix is essentially an Internet telephone that allows you to make free phone calls to other people who are also running the same software on their computers.
Traditional telephones use phone lines that run back to your local telephone exchange to make phone calls. When you call someone, your local phone exchange sends the call to the phone exchange nearest the person you are calling and the phone company charges you for the call. When you make a call using Cubix and VoIP, your voice is first turned into digital packets which can be used by your computer. These packets are then sent over the Internet from your computer to the computer of the person you are calling where the packets are turned back into voice. The wonderful thing about this is that it does not cost you anything beyond your normal ISP costs!
You will of course need to be connected to the Internet to use Cubix and VoIP, but the actual softphone call costs nothing! And it does not matter if the person you are calling is across the road or on the other side of the world, since the call is sent over the Internet.
OEM Licensing
Cubix is available for OEM licensing. The basic version is completely free to take a copy and use for testing or as a once off instance for your personal use.
Technical Specifications
What protocols does Cubix support?
Cubix uses an enhanced version of IAX by default; however standard IAX and SIP are also fully supported.
What codecs does Cubix support?
For carrying voice, the base codec is iLBC, however GSM, and G.711u/a are also included.
What is different between your enhanced IAX and normal IAX?
They are actually the same on the protocol level; however we make heavy use of the IAX message packets in order to communicate with the Cubix server. This is used for checking who is online, sending text messages, and things like that. We are happy to release the full specification if anyone is interested.
How much bandwidth does Cubix require?
A call uses about 3KB/sec (three kilobytes per second) inbound and outbound. This translates to a little over 10MB per hour. This is based on a single call using the standard codec (iLBC).
Features
CURRENT VERSION FEATURES
Instant text messaging capability (Including smilies, custom fonts)
IAX Protocol support
G.711 Ulaw & Alaw codec support
iLBC codec support
G.729 codec support
GSM codec support
Speex codec support
Advanced codec settings
Voicestream Network support
Audio Tuning Wizard
Direct IP to IP calling
Touch tones
Dial/re-dial/hang-up
Caller ID
Call timer
Mute
Microphone and speakers levels
Sound device detection
Inbound call ignore
Powerful theming Engine / Easily Brandable
Contact list filtering on name and number
Support for multiple ringing devices
Per-contact configurable notifications (pop-ups) as well as global overrides
Automatic call answering capability
Multiple language support
Auto-away feature
Adaptive jitter buffer
Voice activity detection
Microphone and speaker device detector
Voicemail URL
Auto-start at OS start feature
Multi-platform support (Windows, Linux, Mac)
Automatic USB Audio device detection feature
Voicemail features
Message Waiting Indicator
Online help desk
Contact import from previous version of Cubix
Intuitive Network Wizard
Drag and drop contact list and call list management
Event logging including calls, messages and notifications
Window resizing and snapping
Website and User Directory integration
FUTURE VERSION FEATURES
SIP protocol support
Outlook Integration
Conference Calls
Video
Microphone and speakers meters
Line transfer
Ban inbound contact
Auto answer
Call forwarding URL
Speakerphone with AEC
Auto-conference
Multi-party conferencing (IP and PSTN)
Acoustic Echo Cancellation - AEC G.168
These future features are made available at no extra charge if the maintenance option is taken.

Sample Config for IAX/IAX2 Client for Asterisk as under

iax.conf file for these phones to be configured is as under:

;This text is for the iax.conf file
; Inter-Asterisk eXchange driver definition
;Register commands to connect to another IAX server has to
;be in the [general] section of iax.conf.
;To set up IAX in trunk mode, add “trunk=yes” to your definition in iax.conf.
;IAX Trunking needs support of a hardware timer. See Asterisk timer for more information.
;Do not use both “host=dynamic” and “defaultip=111.222.333.444″,
; make sure it is just one or the other (see bugs 558 and 673).
;
; General settings, like port number to bind to, and
; an option address (the default is to bind to all
; local addresses).
;
[general]
port=5036
iaxcompat=yes
disallow=all
;
; All of the following codecs are supported by VoicePulse Connect!
;
allow=ulaw
allow=ilbc
allow=gsm
;allow=adpcm
;allow=alaw
;allow=g723.1
;allow=g729
jitterbuffer=no
IAX2 trunks

[voicepulse]
type=friend
context=dialout
username=
secret=
host= gwiaxt01.voicepulse.com

[IareaNet.Net]
type=friend
auth=md5
username=
secret=
context=dialout
host=208.111.0.45
qualify=yes
jitterbuffer=no

[anotherprovider]
type=friend
auth=md5
username=
secret=
context=dialout
host=IAX2.anotherprovider.com
qualify=yes
jitterbuffer=yes
; IAX End User phone extensions

[8101]test
type=friend
username=8101
secret=
context=dialout
host=dynamic
callerid=Joe Useri<8101>

SIP-телефоны
Cisco IP phone 7940
Телефонный аппарат CISCO IP PHONE 7960/7940 предназначен для использования в качестве персонального терминала IP телефонии. Все звонки, совершаемые с помощью данного аппарата, осуществляются с использованием сети Internet. Для нормального функционирования аппарата необходимо постоянное подключение к сети Internet синхронным каналом со скоростью передачи данных не ниже 64 Кбт./с. Вы можете использовать любые реальные IP адреса для работы аппарата. В случае использования NAT необходимо указать безусловную маршрутизацию трафика по порту 5060/UDP на IP адрес телефонного аппарата.
Протокол: SIP, H.323
Codec: G.729, G.711
Порты: 1 Ethernet
Особенности: Конфигурация может устанавливаться автоматически или вручную для поддержки протоколов DHCP, TFTP
Производитель: http://www.cisco.com
Инструкция по настройке
Цена:  450 у.е.

Vontel IP 110
Протокол: SIP, H.323
Codec: G711 + G723.1 или G711 + G729a
Порты: 1 Ethernet
Особенности: Поддержка прохода через NAT
Производитель: VonTel
Инструкция по настройке
Цена:  170 у.е.
QTECH QVI-P2 VoIP
Протокол: SIP, H.323 V4, MGCP
Codec: G.711, G.723, G.729AB
Порты: 2 Ethernet
Особенности: PoE, Web browser management, LCD display
Производитель: http://www.qtech.ru
Инструкция по настройке
Цена:  110 у.е.

D-Link DPH-120S
Протокол: SIP
Codec: G.7.11u-law/a-law, G.723.1, G.729a/b
Порты: 1 Ethernet
Производитель: http://www.d-link.ru
Купить D-Link DPH-120S
Инструкция по настройке
Цена:  110 у.е.
D-Link DPH-140S
Протокол: SIP
Codec: G.7.11u-law/a-law, G.723.1, G.729a/b
Порты: 1 Ethernet
Производитель: http://www.d-link.ru
Купить D-Link DPH-140S
Инструкция по настройке
Цена:  140 у.е.

Samsung OfficeServ SOHO
Протокол: SIP VoIP (G711a/u-law, G729)
Порты: 1 Ethernet
Особенности: два городских порта, один порт для аналогового телефона/факса/модема, до восьми Wi-Fi трубок, беспроводная iEEE 802.11 b/g Wi-Fi точка доступа, WAN маршрутизатор (Ethernet 10/100 T-Base, DHCP, NAT, DMZ, Firewall)
Производитель: http://www.samsung.ru
Цена Wi-Fi трубки — 205 у.е..
Инструкция по настройке
Цена:  499 у.е.

PLANET VIP-153PT
 Протокол: SIP 2.0 (RFC-3261), SIP digest authentication (MD5)
 Codec: G.711 а/µ-law, G.723.1 (5.3/6.3 кбит/с), G.729A
 2 x Ethernet (1 x PC, 1 x LAN)
 Особенности: Интуитивно понятный пользовательский WEB интерфейс, поддержка вызовов типа точка-точка / SIP Прокси, поддержка DDNS, STUN, высококачественный голосовой тракт и подсветка дисплея, имеет встроенный сплиттер PoE (стандарт IEEE802.3af) позволяющий подать питание на телефон через сетевой кабель
 Производитель: http://www.planet.com.ru/
 Купить PLANET VIP-153PT
Инструкция по настройке
Цена:  120 у.е.
PLANET VIP-153T
 Протокол: SIP 2.0 (RFC-3261), SIP digest authentication (MD5)
 Codec: G.711 а/µ-law, G.723.1 (5.3/6.3 кбит/с), G.729A
 2 x Ethernet (1 x PC, 1 x LAN)
 Особенности: Интуитивно понятный пользовательский WEB интерфейс, поддержка вызовов типа точка-точка / SIP Прокси, поддержка DDNS, STUN, высококачественный голосовой тракт и подсветка дисплея
 Производитель: http://www.planet.com.ru/
 Купить PLANET VIP-153T
Инструкция по настройке
Цена:  107 у.е.

USB-телефоны

Telco PH-397 USB
«Компьютер — телефон». Этот вид связи находит все более широкое применение как дома, так и в офисе. Для удобства разговора через интернет можно использовать специальный USB-телефон Telco PH-397 USB, который подключается к компьютеру и с помощью SIPNET приближает технологию IP-связи к традиционной. Простой в использовании, требующий минимального времени для набора или ответа абоненту, Telco PH-397 USB сделает вашу связь через интернет такой же удобной и доступной, как и с обычного телефона.
Производитель: TELCO
Купить Telco PH-397 USB
Цена:  36 у.е.

SkypeMate USB-P1K
Для удобства разговора через интернет можно использовать специальный USB-телефон SkypeMate USB-P1K, который подключается к компьютеру и с помощью SIPNET приближает технологию IP-связи к традиционной. Простой в использовании, требующий минимального времени для набора или ответа абоненту, SkypeMate USB-P1K сделает вашу связь через интернет такой же удобной и доступной, как и с обычного телефона.
Производитель: SkypeMate
Купить SkypeMate USB-P1K
Инструкция по настройке
Цена:  32 у.е.

SkypeMate USB-P1M
USB VoIP Телефон co встроенной 128 MБ памятью. Для удобства разговора через интернет можно использовать специальный USB-телефон SkypeMate USB-P1M, который подключается к компьютеру и с помощью SIPNET приближает технологию IP-связи к традиционной. Простой в использовании, требующий минимального времени для набора или ответа абоненту, SkypeMate USB-P1M сделает вашу связь через интернет такой же удобной и доступной, как и с обычного телефона.
Производитель: SkypeMate
Купить SkypeMate USB-P1M
Инструкция по настройке
Цена:  53 у.е.

SIP-адаптеры
Cisco ATA-186
Протокол: SIP, H.323
Codec: G.723, G.729, G.711
Порты: 2 FXS и 1 Ethernet
Особенности: Начиная с версии 3 поддерживает STUN технологию
Производитель: http://www.cisco.com
Инструкция по настройке
Цена:  180 у.е.

LinkSys RT31P2 broadband router
Протокол: SIP
Codec: G.723, G.729, G.711
Порты: 2 FXS и 1 Ethernet
Особенности: Имеет встроенный маршрутизатор
Производитель: http://www.linksys.com
Инструкция по настройке
Цена:  165 у.е.
Grandstream ATA-486
Протокол: SIP
Codec: G.723, G.729, iLBC, G.711
Порты: 1 FXS, 1 Ethernet, 1 PSTN
Особенности: Поддерживает STUN технологию, АТА-486 может также выполнять роль маршрутизатора с NAT.
Производитель: http://www.grandstream.com
Инструкция по настройке
Цена:  153 у.е.

QTECH QVI-G4SO1-1
Протокол: SIP
Порты: 4 FXS, 1 Ethernet
Особенности: DHCP, PPPoE
Производитель: http://www.qtech.ru
Инструкция по настройке
Цена:  206 у.е.
Nateks VoiceCom115
Протокол: SIP
Порты: 4 FXS, 4 Ethernet, 1 WAN
Codec: G.723.1, G.729A, G.711alaw/ulaw, G726
Особенности: Поддерживает STUN технологию, маршрутизатор с NAT.
Производитель: www.nateks-networks.ru
Купить Nateks VoiceCom115
Инструкция по настройке
Цена:  269 у.е.

Nateks VoiceCom130
Протокол: SIP
Порты: 8 FXS, 4 Ethernet, 1 WAN
Codec: G.723.1, G.729A, G.711alaw/ulaw, G726
Особенности: Поддерживает STUN технологию, маршрутизатор с NAT.
Производитель: www.nateks-networks.ru
Инструкция по настройке
Цена:  635 у.е.

Nateks VoiceCom110
Протокол: SIP
Порты: 2 FXS, 4 Ethernet, 1 WAN
Codec: G.723.1, G.729A, G.711alaw/ulaw, G726
Особенности: Поддерживает STUN технологию, маршрутизатор с NAT.
Производитель: www.nateks-networks.ru
Инструкция по настройке
Цена:  174 у.е.
D-Link DVG-2004S
Протокол: SIP
Порты: 4 FXS, 1 LAN 10/100, T.38
Производитель: www.dlink.ru
Цена:

Офисная АТС на Asterisk малой кровью или бюджетный способ получить мини АТС с функциями серьезной станции.
Lanbilling.ru
1. Почему (На правах введения).
Практика работы на телекоммуникационном рынке показывает существование серьезного интереса к VoIP решениям на базе ПО, реализующего функции некогда доступные только в телефонных станциях уровня Definity и аналогичных. То, что VoIP технология будет идти вперед и если не вытеснит, то существенно подвинет позиции “железных” решений, это так же очевидно как, то, что отсутствие “интернет” - если и не останавливает работу в офисе IT компании, то существенно ее затрудняет . Прогнозы дело не благодарное, кроме того, их на сегодняшний день существует большое кол-во от разных аналитических изданий, в одном они сходятся со стопроцентной уверенностью - очевиден рост темпа внедрений VoIP решений (несмотря на существование пресловутых правил подключения).
2. Что.
В данной статье преследуется “простая” цель - показать возможность реализации функций офисной АТС уровня, например, Panasonic KX-TD 1232 (12 внешних линий, 32 внутренних) при помощи PC сервера, одной или нескольких специализированных плат (Digium) для подключения аналоговых или цифровых внешних линий, программного обеспечения Asterisk (Офисная станция) и LANBilling (тарификация, сбор статистики). Результатом будет являться полноценная IP АТС, в которой могут быть реализованы функции, ранее недоступные, “простому смертному” (компании малого бизнеса с количеством сотрудников около 10-30 человек). Почему Asterisk - потому что это бесплатное, широко распространенное (а значит, по его внедрениям проще найти информацию), и что не менее важно, opensource решение, реализующее большинство необходимых мелкому и среднему офису функций.
3. Как.
Как и любая мини АТС, описанное в статье решение, коммутирует телефонные каналы внутренних абонентов во внешнюю телефонную сеть (как правило, внешних каналов несколько меньше, чем, в общем случае, внутренних). В качестве интерфейса подключения к IP PBX внутренних абонентов используется Ethernet интерфейс сервера, в составе которого мы будем реализовывать решение. Соответственно, транспортом для абонентских телефонных каналов, служит Ethernet среда, по определению, не гарантирующая качества канала (и это является основным камнем преткновения технологии). Поэтому первое, на что стоит обратить внимание при реализации решения, это меры по предотвращению коллизий в Ethernet сегменте. Часто для пакетной телефонии выделяется отдельный Ethernet сегмент в рамках СКС предприятия, что определенным образом гарантирует качество абонентских каналов. Способов же подключить внешние телефонные каналы к АТС существует великое множество, поэтому мы будем рассматривать реализацию решения безотносительно типа подключения АТС к внешней телефонной сети, перечислив лишь способы, которыми могут быть подключены к серверу внешние “линии”.

Во-первых, внешним каналом может служить обычный Интернет канал, с той лишь оговоркой, что он должен быть достаточного для прохождения всех пакетов выбранного протокола VoIP качества и гарантировать минимальность задержки при передаче пакетов. Весьма абстрактное требование. Более точно требования к внешнему каналу в случае использования пакетной телефонии нужно рассчитывать в зависимости от ряда параметров, рассмотрение которых выходит за рамки статьи. Этот способ (при помощи Интернет канала) наименее предпочтителен с точки зрения гарантий качества передачи голоса, по понятным причинам, - у потребителя нет возможности выделения определенной полосы пропускания для голосовых данных. Не стоит строить систему полагаясь только на интернет канал - как известно интернет бывает, что “пропадает”, мало того что неприятно оставваться без интернет, но вдвойне неприятно при этом оставться еще и без телефонной связи, не имея возможности высказать свои претензии провайдеру.

Второй способ это подключение аналоговых линий к IP АТС при помощи плат Digium. Если линий не очень много (до 16), то способ примелем с практической точки зрения, и гарантирует качество переговоров т.к. в данном случае качество может пострадать только из-за перегрузок во внутренней транспортной сети.

Третий способ - это использование плат вышеуказанного производителя (или аналогичных) для стыка E1 и более скоростных. Так же как и способ №2 этот способ гарантирует приемлемое качество телефонных разговоров. Его целесообразно применять при необходимости подключения большего количества внешних линий (более 16, как правило). Существует возможность комбинирования указанных способов подключения внешних линий. Например, когда в нормальной ситуации используется стык канал E1, в случае проблем с основным поставщиком услуг телефонии используется аналоговые каналы, и при их отсутствии диалпир провайдера VoIP, доступный через общий интернет канал. ПО Asterisk позволяет гибко управлять коммутацией при возникновении перегрузок и пр. событий задействуя все внешние каналы безотносительно того, каким способом они подключены к IP АТС.

В практически в любой аппаратной мини АТС имеется COM порт (устаревающие модели) или другой способ (CDR файлы, информация, передаваемая через интерфейс сокетов и т.д.) снятия данных о состоявшихся телефонных разговорах или разговорах находящихся в активном состоянии (начавшихся, но еще не завершившихся). В рассматриваемом нами случае в качестве способа снятия звонковой информации используется интерфейс на базе RADIUS протокола, который не является, к слову, встроенным средством Asterisk, а настраивается в дополнение к основному функционалу при помощи разработанных плагинов (PlugIn - встариваемый код).

До сих пор статья описывает принципы построения решения, т.е. отвечает на вопрос “Что мы получим в результате?”. Резюмируя, можно сказать, что помимо возможностей коммутации телефонных разговоров (основная функция АТС) IP АТС сможет:
работать в качестве карточной платформы
обеспечивать функции виртуального секретаря через IVR (тоновый донабор внутреннего номера внешним абонентом, как пример) Прим: IVR - Interactive Voice Response
обеспечивать функции MailBox - голосового почтового ящика
обеспечить переадресацию вызовов на любой номер (внешний / внутренний)
а также реализовать другие, не характерные для обычных мини АТС функции.
Прежде чем перейти к разделу, в котором подробно описана установка RADIUS клиента для Asterisk - собственно способ интеграции Asterisk и LANBilling, следует отметить что, как и любое свежее решение (не путать с ментос) данное имеет недостатки - например, отсутствие более-менее удобного интерфейса для конфигурирования Asterisk, все настройки приходится применять, редактируя текстовые файлы конфигурации, хотя, что можно придумать неудобнее, чем нажатие кнопок системного телефона при конфигурировании АТС LG-GHX 616, например. Успокаивает то, что не так часто приходится менять настройки станции. По мере внедрения описанного решения статья будет дополняться информацией по новым возможностям как Asterisk, так и всех модулей, участвующих в функционировании предлагаемого решения
3.1 Установка Asterisk
В этом подразделе мы опишем установку asterisk под Linux безотноситильно какого-либо дистрибутива, то есть речь будет идти о сборке из исходников, взять которые можно на asterisk.org. При установке под FreeBSD есть ряд особенностей, на которых сейчас не хотелось бы останавливаться.

В первую очередь распаковываем исходный код:
#tar -zxf asterisk-1.0.9.tar.gz
#cd asterisk-1.0.9/
Для того, чтобы была возможность запускать asterisk от имени непривилегированного пользователя, необходимо отредактировать Makefile, заменив “ASTVARRUNDIR=$(INSTALL_PREFIX)/var/run” (приблизительно строка 123) на “ASTVARRUNDIR=$(INSTALL_PREFIX)/var/run/asterisk”.
Затем:
#make clean
#make
#make install
Если asterisk устанавливается “с нуля”, то рекомендуется установить примеры конфигурационных файлов:
#make samples
Теперь создаем пользователя для asterisk и меняем владельца рабочих директорий:
#groupadd asterisk
#useradd -c “asterisk PBX” -d /var/lib/asterisk -g asterisk asterisk
#chown -R asterisk:asterisk /var/run/asterisk
#chown -R asterisk:asterisk /etc/asterisk
#chown -R asterisk:asterisk /var/lib/asterisk
#chown -R asterisk:asterisk /var/log/asterisk
#chown -R asterisk:asterisk /var/spool/asterisk
Запускать asterisk нужно с ключами -G asterisk -U asterisk. Пример стартового скрипта можно посмотреть здесь.

Основные действия по установке выполнены. В результате имеется практически готовая к использованию IP АТС. Самое время приступать к конфигурированию и подключению абонентов. На данном этапе мы пока не можем использовать протокол H323 и Zaptel (аналоговые POTS lines, цифровые каналы E1/T1/J1). Инструкции по поводу установки и настройки этих модулей смотрите в соответсвующих разделах статьи.
3.1.1 Подключение абонентов
По умолчанию вся конфигурация asterisk хранится в виде текстовых файлов (как правило, в /etc/asterisk/). Разработчиками была проделана большая работа для перенесения конфигурации в базу данных, но это отдельный вопрос… Конфигурационных файлов достаточно много: каждому модулю asterisk соответсвует свой файл. Но это не должно пугать. Скорее всего многие модули Вы просто не будете использовать, поэтому не спешите тонуть в этой куче файлов и непонятных инструкций. На самом деле все конфиги выдержаны в одном стиле, поэтому более-менее разобравшись с основными, не составит труда освоить новый.

Базовая конфигурация (asterisk.conf)

Файл asterisk.conf содержит пути к основным рабочим директориям АТС. Если после установки эти директории никуда не переносились, то файл в исправлении не нуждается.

Настройка протокола SIP/IAX. Подключение SIP/IAX пользователей (sip.conf/iax.conf)

Файлы sip.conf, iax.conf имеет сходную структуру. Эти конфигурационные файлы содержат специфические настройки протокола и определяют профили подключенных пользователей. Рассмотрим для примера sip.conf (взято из asterisk samples):
;
; В этом файле содержится конфигурация, касающаяся протокола SIP
;
; Синтаксис для указания SIP-устройства(это может быть IP телефон, либо
; софтфон, либо VoIP шлюз) в extensions.conf следующий:
; SIP/[имя устройства], где [имя устройства] определяется ниже.
;
; Можно также использовать следущую конструкцию:
; SIP/[имя пользователя]@[домен], чтобы позвонить пользователю
; в сети Итернет
;
; Можно описать узел (peer) для произвольного SIP-прокси (см. ниже),
; тогда вызов пользователя через этот шлюз будет выглядеть так:
; SIP/[SIP-прокси]/[пользователь] или SIP/[пользователь]@[SIP-прокси].
; Что есть SIP-прокси определяется ниже.
;
; Несколько слов об используемой здесь терминалогии:
; user (пользователь) - может звонить на asterisk, либо через него.
; peer (узел) - может только принимать звонки от asterisk.
; friend - объединяет в себе оба вышеупомянутых понятия.
;
; Полезные команды консоли asterisk для контроля SIP узлов/пользователей:
; sip show peers
; Покажет все SIP peer’ы (включая friends)

; sip show users
; Покажет все SIP user’ы (включая friends)

; sip show registry
; Статус установленной регистрации

; sip debug
; Повышенная детализация сообщений в консоли

; reload chan_sip.so

; Перегрузить конфиг. файл
; Конфигурация активных SIP peer’ов изменена не будет

; Раздел общих настроек
[general]
context=default

; Контекст по умолчанию для входящих звонков

;recordhistory=yes

; хранить историю SIP подключений
; (см. sip history / sip no history)

;realm=mydomain.tld

; Realm (атрибут области) для digest аутентификации
; по умолчанию - “asterisk”
; Realms должны быть уникальны в соответсвии с RFC 3261
; Принято указывать здесь свое доменное имя

port=5060

; Прослушиваемый UDP порт (стандартный порт - 5060)

bindaddr=0.0.0.0

; Слушать конкретный IP адрес (0.0.0.0 - слушать на всех)

srvlookup=yes

; Разрешить использование DNS
; Замечание: Asterisk использует только первую запись
; в ответе DNS сервера.
; Если эта опция выключена, вы не сможете установить
; SIP соединение, определяемое именем хоста
; (напр. SIP/user@voip.somewhere.com)

;pedantic=yes

; Разрешить медленную, более точную проверку Pingtel заголовков,
; обеспечивающую строгое соответсвие стандарту SIP.
; (По умолчанию “no”)

;tos=184

; Установить IP QoS. Допускается указать численное значение либо

;tos=lowdelay

; одно из служебных слов: lowdelay,throughput,reliability,mincost,none

;maxexpirey=3600

; Максимальное значение периода входящих регистраций.

;defaultexpirey=120

; Значение периода входящих/исходящих регистраций по умолчанию

;notifymimetype=text/plain

; Явное указание mime типов в MWI NOTIFY

;videosupport=yes

; Поддержка SIP видео

;disallow=all

; Запретить все кодеки (ниже указывается список разрешенных кодеков)

;allow=ulaw

; Разрешаем кодеки в порядке, соответсвующем их приоритету

;allow=ilbc

; Замечание: порядок кодеков имеет смысл задавать только в разделе
; [general]

;musicclass=default

; Установить класс по умолчанию для мелодий во время ожидания.
; Он может задаваться индивидуально для пользователей/узлов

;language=en

; Выбор языка по умолчанию
; Также может задаваться индивидуально для пользователей/узлов.

;relaxdtmf=yes

; “смягченный” режим распознавания dtmf

;rtptimeout=60

; Разрывать соединение, если в течение 60 сек. не было RTP трафика,
; при условии что мы не находимся в режиме ожидания.

;rtpholdtimeout=300

; То же самое, но относится к режиму ожидания
; (rtpholdtimeout > rtptimeout)

;trustrpid = no

; Полагаться на значение поля Remote-Party-ID

;progressinband=no

; Всегда передавать вызывающий сигнал in-band

;useragent=Asterisk PBX

; Задать значение поля user agent

;nat=no

; настройки NAT
; yes = всегда игнорировать информацию в пакетах, предполагая наличие NAT
; no = использовать режим NAT в соответсвие с RFC3581
; never = не использовать NAT режим
; route = использовать режим NAT, не отсылать удаленный порт

;promiscredir = no
; Позволяет разрешить 302 или REDIR (переадресации)
; на нелокальные SIP адреса
; Со включенным promiscredir переадресации на локальные адреса
; приведут к зацикливанию, т.к. протокол SIP неспособен
; осуществлять “петлевые” звонки.

; Если определен regcontext, Asterisk будет динамически создавать
; экстеншн “NoOp” с приоритетом, равным 1, для peer’а,
; который регистрируется у нас и удалять его при снятии
; регистрации. Действительный экстеншн для этого peer’а
; определяется параметром ‘regexten’ либо его именем,
; если ‘regexten’ не указан.
; Может быть задано несколько экстеншенов, разделенных ‘&’.
; Разрешается использовать шаблоны.

;regcontext=iaxregistrations

; Asterisk может регистрироваться как SIP-пользователь
; у своего SIP провайдера
; Соответсвующая инструкция имеет следующий формат:
; register => user[:secret[:authuser]]@host[:port][/extension]

; Необязательные параметры заключены в скобки [].
; Если, не задан экстеншн (extension), используется экстеншн ’s’.
; Соответсвующий экстеншн должен быть определен в extensions.conf,
; чтобы принимать звонки от своего SIP-провайдера
;
; host - это либо DNS имя, либо имя одной из определенных ниже секций.
;
; Пример:
;
;register => 1234:password@mysipprovider.com
; Здесь входящие звонки будут приходить в экстеншн ’s’
;register => 2345:password@sip_proxy/1234
;
; Регистрируем 2345 на SIP-провайдере ’sip_proxy’.
; Входящие звонки от провайдера будут приходить
; в экстеншн 1234, определенном в extensions.conf в default-контексте,
; либо любом другом, если
; вы сконфигурируете раздел [sip_proxy] и зададите там нужный контекст.
; Совет 1: Не используйте DNS имя для названия секций в sip.conf,
; например, [provider.com]
; Совет 2: Используйте раздельно две секции type=peer
; и type=user для SIP-провайдера (вместо одной секции type=friend)
; если звонки идут в обоих направлениях

;externip = 200.201.202.203

; Адрес, который будет помещен в исходящие SIP-пакеты,
; если мы находимся за NAT’ом (наш внешний ip)
; externip и localnet используются при общении
; с SIP-провайдерами, где мы зарегистрированы
; Можно добавить несколько локальных сетей (localnet).
; Ниже перечислены “стандартные” локальные сети:

;localnet=192.168.0.0/255.255.0.0;
;localnet=10.0.0.0/255.0.0.0 ;
;localnet=172.16.0.0/12 ;
;localnet=169.254.0.0/255.255.0.0 ;

;——————————————————————-
; user и peer имеют различные наборы настроек. friend может использовать
; все нижеперечисленные настройки
;
; настройки user: настройки peer:
; ——————– ——————-
; context context
; permit permit
; deny deny
; secret secret
; md5secret md5secret
; dtmfmode dtmfmode
; canreinvite canreinvite
; nat nat
; callgroup callgroup
; pickupgroup pickupgroup
; language language
; allow allow
; disallow disallow
; insecure insecure
; trustrpid trustrpid
; progressinband progressinband
; promiscredir promiscredir
; callerid
; accountcode
; amaflags
; incominglimit
; restrictcid
; mailbox
; username
; template
; fromdomain
; regexten
; fromuser
; host
; mask
; port
; qualify
; defaultip
; rtptimeout
; rtpholdtimeout

; Ниже приведены примеры настроек различных узлов: user, peer, friend
;[sip_proxy]
; Только для входящих звонков
;type=user
;context=from-fwd

;[sip_proxy-out]
;type=peer
; только для исходящих звонков

;secret=guessit
;username=yourusername

; имя пользователя для аутентификации на SIP-прокси

;fromuser=yourusername

; многие SIP-провайдеры требуют наличия этого поля!

;host=box.provider.com

;[grandstream1]
;type=friend

; либо “friend” (peer+user), либо “peer”, либо “user”

;context=from-sip
;fromuser=grandstream1

; если не задан, используется callerid
;callerid=John Doe

;host=192.168.0.23

; у нас статический IP
;nat=no
; между телефоном и Asterisk’ом нет NAT’а

;canreinvite=yes

; разрешить “проксирование” голосового RTP трафика

;dtmfmode=info

; режим тонального набора

;incominglimit=1

; разрешить только один исх. звонок
; с телефона на Asterisk

;mailbox=1234@default
; голосовая почта 1234 в контексте “default”

;disallow=all
; запрещаем все кодеки, чтобы потом определить разрешенные (allow)

;allow=ulaw
; Замечание: в секции с type=user порядок кодеков
; не учитывается

;allow=alaw
;allow=g723.1
;allow=g729
; …..
Для примера рассмотрим самый простой случай: у нас есть два ip-телефона, и необходимо звонить с одного на другой, используя номера 101 и 102. sip.conf в этом случае может выглядить так:
[general]

port=5060
bindaddr=0.0.0.0
srvlookup=yes
language=en
dtmfmode=RFC2833
promiscredir = no
nat=no

disallow=all
allow=alaw

[101]
host=dynamic
context=default
type=friend
username=101
nat=no
secret=secret101
callerid=phone1 <101>

[102]
host=dynamic
context=default
type=friend
username=102
nat=no
secret=secret102
callerid=phone2 <102>
В настройках телефонов нужно указать точно такие же имя пользователя и пароль. Кроме того, в extensions.conf нужно определить соответсвующие экстеншены в контексте default.
Например, так:
;… skipped …
[default]
exten => 101,1,Dial(SIP/101)
exten => 102,1,Dial(SIP/102)
… skipped …
Теперь, запустив Asterisk и убедившись, что оба телефона успешно зарегистрировались, можно смело набирать номер.
Подключение аналоговых телефонов
(Раздел в разработке)
3.1.2 Подключение внешних каналов
В первую очередь необходимо установить математическое обеспечение (драйверы) той системы сигнализации которую использует Ваш провайдер внешнего телефонного канала.

H.323

Существуют две распространенные реализации H323 драйвера для asterisk: h323, входящий в состав дистрибутива asterisk, и oh323, который разрабатывается InAccess Networks (http://www.inaccessnetworks.com/projects/asterisk-oh323). До сих пор идут споры о том, какой драйвер лучше использовать. Первым появился oh323. Он считается более стабильным в работе, в нем, в отличии от h323, реализован буфер для устранения дрожания. Для передачи используется RTP/RTCP стэк. В то же время h323 гораздо более производительный (загрузка ЦП может быть в 10-15 раз меньше, чем при использовании oh323 на тех же потоках).

Оба модуля имееют подробные интструкции по установке. Единственное, на что следует обратить особое внимание, это требование к библиотекам pwlib и openh323, необходимым для сборки драйвера: они должны быть в точности такими, как указано в инструкции по установке. При установке asterisk’а h323 по умолчанию не собирается. Нужно перейти в директорию asterisk-1.0.9/channels/h323/ и последовательно выполнить все инструкции из README. Если же вы решили использовать oh323, то необходимо предварительно скачать его исходники.

Рассмотрим для примера установку asterisk-oh323-0.6.5. Согласно инструкции нам потребуются библиотеки pwlib (v1.6.6) и openh323 (v1.13.5). Необходимые файлы можно взять здесь.
#tar -zxf pwlib-v1_6_6-src.tar.gz
#tar -zxf openh323-v1_13_5-src.tar.gz
#tar -zxf asterisk-oh323-0.6.5.tar.gz
#export PWLIBDIR=”`pwd`/pwlib”
#export OPENH323DIR=”`pwd`/openh323″
#export LD_LIBRARY_PATH=”$PWLIBDIR/lib:$OPENH323DIR/lib”
#cd pwlib/
#./configure
#make
#cd ../openh323/
#patch -p1 < ../asterisk-oh323-0.6.5/openh323_1.13.5-make.patch
#./configure
#make opt
В этом месте компиляции может случиться конфуз (Fedora Core 3, gcc-3.4.2, glibc-2.3.3):

gkserver.h:434: error: `virtual H323Transaction::Response H323GatekeeperRRQ::OnHandlePDU()’ is protected
gkserver.h:1946: error: within this context

В этом случае нужно отредактировать файл include/gkserver.h, закомментировав строку 433:
H225_RegistrationReject & rrj;

// protected:
virtual Response OnHandlePDU();
};
Далее:
#cd ../asterisk-oh323-0.6.5/
Нужно отредактировать Makefile, указав пути к pwlib, openh323 и asterisk в соответствии с вашими настройками. Например, на демонстрационном стенде это выглядит так:
#…skipped…
PWLIBDIR=/usr/local/src/pwlib
#…skipped…
OPENH323DIR=/usr/local/src/openh323
#…skipped…
ASTERISKINCDIR=/usr/local/src/asterisk-1.0.9/include
Все остальное по умолчанию.
#make
#make install
Проследите, чтобы директория /usr/local/lib была добавлена в /etc/ld.so.conf, и запустите ldconfig. Теперь, после запуска asterisk’а нам будет доступен канал OH323. Конфигурационный файл для него - /etc/asterisk/oh323.conf. Выглядит он, приблизительно, следующим образом:
; Файл конфигурации OpenH323 драйвера
;

;—————————————–
; Основные настройки
; (порты, буфер дрожания, гейткипер, …)
;—————————————–
[general]
;
; Прослушиваемый адрес для входящих подключений.
; По умолчанию - слушать на всех интерфейсах.
;
listenAddress=0.0.0.0
;
; Прослушиваемый порт.
; По умолчанию 1720.
;
listenPort=1720
;
; Порт для удаленного подключения.
; (Используется только при отсутствии гейткипера)
; Значение по умолчанию - 1720.
;
connectPort=1720
;
; Диапазон используемых TCP портов
;
tcpStart=10000
tcpEnd=20000
;
; диапазон используемых UDP портов
; Замечание: диапазон портов, используемых RTP
; настраивается в “rtp.conf”

udpStart=10000
udpEnd=20000
;
; включить “быстрый старт” (yes,no).
;
fastStart=yes
;
; разрешить H.245 туннелирование (yes,no).
;
h245Tunnelling=no
;
; разрешить early H.245 сообщения на этапе инициализации звонка.
;
h245inSetup=no
;
; разрешить in-band-DTMF.
; (замечание: Netmeeting использует именно in-band DTMF)
;
inBandDTMF=no
;
; Не передавать тишину.
;
silenceSuppression=no
;
; Настройки буфера дрожания (в миллисекундах, 20…10000).
;
jitterMin=20
jitterMax=100
;
; Установить флаг “тип сервиса” в ip пакетах для RTP траффика.
; Возможные значения:
; lowdelay, throughput, reliability, mincost, none
;
ipTos=none
;
; Максимальное число входящих/исходящих/одновременных
; H.323 подключений.
;
outboundMax=10
inboundMax=10
simultaneousMax=10
;
; Пропускная способность H.323 соединений.
; Значение задается в Кбит/с.
;
;bandwidthLimit=1024
;
; Настройки лога
; В качестве libTraceFile можно задать либо стандарный вывод ’stdout’,
; либо полный путь к лог-файлу
;
wrapLibTraceLevel=1
libTraceLevel=0
libTraceFile=/var/log/asterisk/oh323.log
;
; Настройки гейткипера.
; Допустимые значения:
; DISABLE - отключен
; DISCOVER - автоопределение
; < DNS имя гейткипера >,
; < ip гейткипера >,
; GKID:<идентификационный номер гейткипера>
;
gatekeeper=DISABLE
;
; Установить пароль для гейткипера
;
;gatekeeperPassword=secret
;
; Таймаут регистрации на ГК
;
gatekeeperTTL=600
;
; Режим отправки ввода пользователя
; Допустимые значения:
; Q931 - Q.931 Keypad Information Element
; STRING - H.245 string
; TONE - H.245 tone
; RFC2833 - RFC2833
;
userInputMode=RFC2833
;
; флаги AMA (автоматический учет стоимости)
; возможные значения: default, omit, billing, documentation
;
amaFlags=billing
;
; Имя для эккаунтинга
;
accountCode=H323
;
; контекст по умолчанию для H.323 звонков.
;
context=h323-incoming

;—————————————–
; Настройки H.323 алиасов (синонимов), префиксов и
; привязка к контекстам ASTERISK
;—————————————–
[register]
;
; алиасы/префиксы, связанные с контекстом по умолчанию,
; определенном в разделе [general].
;
alias=asterisk
alias=123
;
; алиасы/префиксы, попадающие в контекст “all-aliases”.
;
context=all-aliases
alias=ASTERISK
alias=666
;
; алиасы/префиксы, попадающие в контекст “more-aliases”.
;
context=more-aliases
alias=665
;
; алиасы/префиксы, попадающие в контекст “all-prefixes”.
;
context=all-prefixes
gwprefix=00
gwprefix=01
;
; алиасы/префиксы, попадающие в контекст “more-stuff”.
;
context=more-stuff
alias=664
gwprefix=02

;—————————————–
; Настройки, относящиеся к кодекам
;—————————————–
[codecs]
;
; Определение списка доступных кодеков.
; Каждая опция “codec” может иметь связанную с ней настройку “frames”
; Допустимые значения опции “codec”:
; G711U - G.711 u-Law
; G711A - G.711 A-Law
; G7231 - G.723.1(6.3k)
; G72316K3 - G.723.1(6.3k)
; G72315K3 - G.723.1(5.3k)
; G7231A6K3 - G.723.1A(6.3k)
; G7231A6K3 - G.723.1A(6.3k)
; G726 - G.726(32k)
; G72616K - G.726(16k)
; G72624K - G.726(24k)
; G72632K - G.726(32k)
; G72640K - G.726(40k)
; G728 - G.728
; G729 - G.729
; G729A - G.729A
; G729B - G.729B
; G729AB - G.729AB
; GSM0610 - GSM 0610
; MSGSM - Microsoft GSM Audio Capability
; LPC10 - LPC-10
; Количество фреймов в RTP пакете (если не задано явно) равно 1.
;
codec=G711A
frames=20

;codec=GSM0610
;frames=4
;codec=G729
;frames=2
;codec=G7231
;frames=2
3.1.2.1 Через DialPeer провайдера VoIP используя обычный IP канал
(Раздел в разработке)
3.1.2.2 Через аналоговые карты Digium

(Раздел в разработке)

3.1.2.3 Через цифровые карты E1 потока Digium или аналогичные

(Раздел в разработке)
3.2 Установка RADIUS плагина для Asterisk. Взаимодействие с LANBilling VoIP RADIUS агентом (выполняет функции сервера RADIUS).
RADIUS модуль, о котором пойдет речь, основан на клиенте от PortaOne.
Он представляет из себя два perl-скрипта для аутентификации и эккаунтинга и набор патчей для asterisk’а. Все же имеются существенные отличия от оригинальной версии, поэтому есть смысл подробно описать все шаги установки, влючая те, что уже описаны в документе по вышеприведенной ссылке.
Итак, для начала, что позволяет этот модуль.
Аутентификация.
Есть возможность SIP Digest аутентификации (Draft RADIUS digest-auth) и PAP (rfc 2138). Второй метод удобно использовать для организации карточной платформы, либо для аутентификации узлов, не поддерживающих протокол SIP (для примера см. agi-card.agi)
Запрос к RADIUS’у можно послать только при инициации звонка, так как на этапе регистрации телефона(софтфона) на asterisk’е последний не может обратиться к RADIUIS серверу (разработчиками не была предусмотрена такая возможность), поэтому здесь проверку подлинности осуществляет сама PBX.
Имеется возможность задавать индивидуальные настройки RADIUS сервера для различных расширений в dialplan’е (extensions).
По умолчанию происходит разрыв соединения в случае неудачной аутентификации. Если RADIUS возвращает атрибут Session-Timeout или h323-credit-time (cisco VSA), то по истечении указанного времени также происходит автоматический разрыв соединения.
Эккаунтинг.
Отсылаютя стартовый, промежуточные и завершающий эккаунтинг пакеты. Можно настроить интервал отсылки промежуточных (alive) пакетов.
Существенным ограничением является отсутсвие возможности эккаунтинга для неаутентифицированных звонков.
Достоинства.
При общении с RADIUS сервером используются cisco VSA, что гарантирует совместимость со многими биллинговыми системами (в том числе LANBilling)
Модуль целиком написан на языке perl, поэтому он легко может быть расширен и доработан для обеспечения требуемого функционала
Недостатки.
Аутентификация и эккаунтинг осуществляются независимым образом двумя различными процессами. На администратора ложится задача мониторинга этих двух процессов помимо самой PBX для поддержания работоспособности узла.
Интеграция с asterisk ограничена средствами manager API и AGI интерфейса.

Установка.
Для asterisk-1.0.x необходим патч, реализующий dialplan-приложение SIPGetHeader. В asterisk-1.2 соответсвующий код уже включен (следите за changelog’ом, т.к. он неоднократно модифицировался), поэтому если Вы используете версию 1.2, можете пропустить этот пункт.
На момент написания статьи последней стабильной версией asterisk была 1.0.9. Ниже речь будет идти именно о ней.
Необходимый патч можно взять здесь.
Применяем патч и пересобираем asterisk:
#cp patch-chan_sip.c-1.0.9 asterisk-1.0.9
#cd asterisk-1.0.9/
#patch -p0 < patch-chan_sip.c-1.0.9
#make clean && make && make install
Устанавливаем необходимые perl-модули
#perl -MCPAN -e shell

cpan>install Crypt::CBC
cpan>install Crypt::DES
cpan>install Digest::MD5
cpan>install Authen::Radius
cpan>q
Также нам потребуется asterisk-perl, взять который можно здесь или здесь.
#tar -zxf aste
{SKIPPED}
Системы статистики звонков и корпоративного биллинга для Asterisk
Ксения Сергеева, ГК Мототелеком 31/07.2006
www.mototelecom.ru hardawareportal.ru
Введение
Решения на базе open-source VoIP становятся все более конкурентоспособными, выходя на рынок малых и средних предприятий с предложениями в нижнем ценовом сегменте. Большой интерес со стороны специалистов направлен на программный продукт Asterisk, работающий под Linux. Asterisk позволил перенести преимущества открытого кода в сферу телекоммуникаций, оставаясь полностью бесплатным и таким же эффективным, как наиболее дорогие PBX.
Asterisk представляет собой open source приложение марки Digium, позволяющее строить и модифицировать телефонную станцию малых и средних размеров. Open source означает лицензионную программу с исходным текстом, не связанным ограничениями на дальнейшую модификацию. Он осуществляет поддержку три VoIP-протокола (SIP/H323/IAX), обеспечивает функции голосовой почты (VoiceMail), конференций, интерактивного голосового меню, настройки различных режимов приема звонков для рабочих и нерабочих часов, интеграции факса, центра обработки вызовов и многое другое.
Тысячи специалистов во всем мире работают над совершенствованием open source продукта. Так, инженеры компании-интегратора Мототелеком, ключевым направлением которой является построение решений на базе Asterisk IP-PBX, предлагают к рассмотрению свои разработки систем статистики звонков и корпоративного биллинга для Asterisk.
Система статистики Asterisk
Система статистики Asterisk - программа учета звонков, которая позволяет фиксировать и сохранять в базу данных информацию обо всех городских, междугородных, международных и входящих звонках круглосуточно и в реальном режиме времени. С помощью системы статистики Вы получаете следующие сведения: Дата, время, длительность, абонент, набранный номер, статус звонка, отдел, оператор, через которого был сделан звонок, время от окончания набора номера, до состоявшегося соединения. Кроме того, есть возможность экспортировать звонки и формировать детальные и сводные отчеты.
Вы можете формировать следующие отчеты:
междугородные / международные звонки
городские звонки
загрузка внешних / внутренних телефонных линий (Суммарное время, количество звонков, средняя длительность звонка - для анализа эффективности использования)
загрузка менеджеров.
Полученные результаты могут быть использованы:
для сопоставления счетов за телефонные переговоры, выставленные городской АТС
для анализа загруженности офисной станции
для анализа нагрузки на менеджера, отдел
для анализа затрат на отделы и менеджеров
для разделения счетов за переговоры между различными организациями, использующими одну УПАТС
Отчеты предоставляются в графическом виде и состоят из панели управления в верхней части таблицы с данными, согласно примененных фильтров, значков для экспорта информации в pdf или cvs файлы.
Взятая из open source система статистики была усовершенствована специалистами компании Мототелеком, тем самым в системе были устранены недостатки и внесены некоторые коррективы, а именно усовершенствованы:
Возможность ведения учета по отделам.
Возможность редактирования отделов и сотрудников отделов.
Возможность маршрутизации исходящих звонков через одного или другого оператора, полученная путем присвоения служебных кодов.
Система статистики обладает дополнительными функциями, в частности:
Существует возможность горячего отключения оператора и принудительного направление всех звонков через одного из операторов (актуально при аварийном отключении оператора или профилактических работ последнего)
Возможность восстановления первоначальной схемы
Система статистики уже реализована и теперь стала доступна для скачивания.
Правила пользования системой статистики
При входе в систему Вы попадаете на страницу CDR отчетов, где представлена панель для задания дополнительных параметров необходимой информации. Если же не вводя данные, сразу нажать на кнопку «ПУСК», то система выдаст информацию за весь период с момента ее установки.

В данном меню возможно:
Задавать фильтры кратно месяцу. Для этого необходимо отметить поле «Месяц», поставить галочку в поле «от», выбрать месяц, то же самое проделать с полем «до», если нужно ограничиться каким либо конкретным месяцем. Если второе поле не отметить, то данные будут сформированы по текущий месяц.
Задавать фильтры кратно дню. Для более точной выборки, существует следующий фильтр, позволяющий выбрать звонки с точностью до одного дня. При не заполнении поля «до» данные выдаются по текущий день.
Фильтр «Направление» позволяет отфильтровать по исходящим и входящим звонкам. Если телефонный номер известен, то он вводится в поле и отмечается поле «точно». Если известно только начало номера, вводится его первые цифры (если это междугородний, то с кодом выхода на междугороднюю линию и код города) и отмечается поле «в начале». Если известны только последние цифры номера, то они вводятся в поле и отмечается пункт «в конце». И если известно только часть номера, то известная часть вводится в поле и отмечается пункт «содержит».
Задавать фильтры для сбора информации об исходящих звонках с какого-либо внутреннего номера, о входящих звонках с какого-либо внешнего номера. Для этого вводятся данные в поле «Источник» и далее применяются дополнительные фильтры.
Поле «Caller ID» по умолчанию дублирует предыдущее значение. Информация в нем будет отличаться только в случае заполнения таблицы присваивания определенным номерам каких-либо текстовых значений (собственных имен, названия предприятий, городов и т.п.) Программируется для любых IP телефонов и в общих случаях состоит из текстового и цифрового поля. Для традиционной телефонии программируются, в случае необходимости подмены номеров и выдачи в ТФОП необходимого номера. По умолчанию транслирует полученные значения. Данная функция чаще всего востребована при организации корпоративной связи и необходимости передачи информации о звонящем на АТС, способные транслировать данные значения, непосредственно на телефонные аппараты, чаще всего системные (ISDN). В данном случае будет предоставляться информация и возможны фильтрации по заданным текстовым значениям.
Задавать фильтры по отделам. Для получения информации по отделам (количество звонков, общее время, загрузка линий, сравнительная загрузка по месяцам и по дням), в поле вводится наименование отдела, с применением дополнительных фильтров, в зависимости от известной информации об отделе.
Задавать фильтры по операторам. Для получения информации о трафике через какого либо оператора, наименование оператора вводится в поле «Биллинг код», с применением дополнительных фильтров по необходимости.
Задавать фильтры по длительности звонков. В процессе работы возникает потребность в анализе коротких звонков или слишком длинных, для выявлении причин. Для этого в поле «Длительность» вводится минимальное и максимальное искомое значение. При этом возможно задать дополнительные фильтры Больше, меньше или равные введенным значениям.
При необходимости конвертации полученных значений сразу в pdf или cvs файлы, отмечается поле «Показать только статистику». В данном случае графического представлении в виде таблицы не будет. По завершении работы фильтров, данные можно будет конвертировать в выбранный формат.
Графическое предоставление информации

В данном представлении можно увидеть результаты, полученные с применением фильтров.
В таблице представлены следующие значения:
№ п/п - порядковый номер записи.
Дата звонка, представляющая значения в виде - год/месяц/число, часы/минуты/секунды. Данная колонка представляет значения по возрастающей, от первого звонка к последнему, и позволяет менять направление сортировки, нажатием на изображение стрелки, рядом с наименованием колонки.
Источник. Указывает входящий/исходящий номер.
CallerlD. Представляет текстовое представление номера. По умолчанию дублирует данные в колонке «Источник».
Направление. Представляет данные по телефонным номерам, инициаторам звонка. Позволяет сортировать данные по данной колонке.
Статус. Представляет информацию о статусе звонка и может быть:
ANSWERED - соединение произошло;
NO ANSWER - соединение не состоялось по причине отсутствия абонента;
BUSY - соединение не состоялось по причине занятости линии абонента
Длительность. Представляет данные по длительности звонка в формате минуты/секунды (данные по фильтру задаются в секундах);
Отдел. Программируемое поле, задаваемое при программировании Астериска. В данном случае, представляет информацию об отделе по исходящим звонкам, статистику навигации по пунктам IVR при входящих звонках. Наименования отделов задаются заказчиком самостоятельно. Коды представления пунктов меню IVR создаются интегратором, по согласованию с заказчиком.
Биллинг код. Программируемое поле, задаваемое при программировании Астериска. В данном случае, представляет информацию об операторах, через которых были сделаны звонки или через кого они были приняты. Наименование операторов так же может изменяться по желанию заказчика и производятся интегратором. Данные представленные в виде: «invalid-num», говорит о неправильно набранном номере, при попытке соединения.
ВНИМАНИЕ!!! Последние 2 поля в силу программируемости могут быть запрограммированы под необходимые заказчику значения. В данном случае представлены наиболее распространенные параметры. Управление данными полями поставляется отдельным модулем и в данной инструкции не рассматривается.
PDD. Представляет информацию о длительности с момента завершения набора номера и непосредственно самого соединения.

Данная таблица выводит итоговые, посуточные данные по сделанному запросу и состоит:
Дата. Представлены данные о дате в формате год/месяц/число.
Длительность. Представлены данные об общей длительности звонков в секундах, в пределах примененных фильтров.
График. Представлены данные в графическом формате исходя из общей длительности звонков на представленную дату.
Звонков. Представлены данные по количеству сделанных звонков. 1 - попытка соединения, - 1 звонок.
ACD мин - Средняя продолжительность звонков.
ASR % - коэффициент дозвона. Отношение состоявшихся разговора к общему количеству попыток.
PDD сек Среднее время дозвона на данную дату, от окончания ввода номера, до состоявшегося соединения.
Сравнение звонков
Данная категория позволяет проводить анализ звонков за период от 2-х до 4-х дней на предмет загруженности линий, отделов, менеджеров. Информация представляется в виде таблицы для заполнения фильтров:

Здесь задается дата, относительно которой необходимо получить информацию (день и месяц) и диапазон для сравнения от 2-х до 4-х дней. Далее необходимо выбрать параметр построения графика - поминутный или почасовой. При нажатии на кнопку «Поиск» в графическом виде выводится информация за запрашиваемое количество дней, с разделением по цветам (один цвет - 1 сутки).

За конечную точку принимается дата, заданная в фильтре. Все остальные графики строятся относительно заданной даты, за заданное количество предшествующих дней.
Поля Направление, Источник, CallerlD, Отдел (псевдоним), Биллинг код имеют статус дополнительных и описаны Выше.
Трафик
Трафик по месяцам
Данная категория выдает в графическом формате график загруженности по Направлениям, внутренним абонентам, отделам и операторам, за период от 1, до 6-ти предшествующим месяцам, относительно отмеченного в фильтре.
В Идеальном варианте, график загрузки должен быть равномерным.
Трафик по дням
Данная категория выдает в графическом формате график загруженности по Направлениям, внутренним абонентам, отделам и операторам и позволяет выявить часы пиковой нагрузки и проанализировать достаточное количество соединительный линий. Шаг анализа посуточный. Информацию можно получить почасово, в течение заданной даты, по коэффициенту дозвона и одновременно возможна почасовая нагрузка, вместе с коэффициентом дозвона.
Для выявления уровня загруженности линий, делается общий запрос по дате, без применения дополнительных фильтров и выявляются часы пиковой нагрузки.

Так, из приведенного графика видно, что часы пиковой нагрузки пришлись на 10:00, 11:00 и 16:00. Выбираем время с наибольшим значением. Это 10 или 11 часов. Вставляем данные значения в следующую таблицу:

Можно выбрать часовой интервал для подробного отчета.

Согласно данного представления, у клиента, имеющего 25 соединительных линий, наблюдается полная их загрузка в пиковые часы.
Если применить фильтр “Звонки & ASR% по часам”, то мы видим резкое падение коэффициента ASR в 10:00, что, скорее всего, означает то, что попыток соединений было предпринято больше 25, а значит 26 и далее попытка позвонить, отбивалась. Хотя уже в 11:00 наблюдается повышение коэффициента.

Система корпоративного биллинга
Еще одним сервисом для Asterisk, над которым сейчас работает компания Мототелеком, является система корпоративного биллинга. На данный момент система проходит обкатку на рабочих серверах (порядка 5 000 минут ежедневно через 4-х операторов связи).

В систему вводятся тарифы операторов, подключенных к Asterisk, с присвоением каждому из них аккаунт кода.

При осуществлении звонка, система по аккаунт коду выбирает оператора, определяет тарифный план и записывает информацию в базу записи деталей звонков (CDR). В результате у Вас появляется возможность видеть стоимость выполненных звонков как по отдельным абонентам, так и по отделам. При этом ограничения по количеству операторов не существует, а тарифный план каждого оператора закладывается при непосредственном подключении к оператору связи.
К тому же, разработанная система корпоративного биллинга поддерживает разновалютность, что позволяет вести подсчет трафика в наиболее удобных для Вас денежных единицах.
В отличие от традиционных биллинговых систем, предложенное компанией Мототелеком решение для Asterisk не предназначено для выписки счетов и отключения абонентов в случае использования выделенной суммы. Система предназначена для осуществления контроля расходами предприятия, подключившегося к нескольким операторам связи.
Предлагаем всем желающим протестировать рассмотренную выше систему статистики и прислать свои вопросы и предложения на e-mail: market@mototelecom.ru или обсудить на форуме компании Мототелеком.
Аналогичные разработки специалистов этой и других компаний-интеграторов, результаты тестирования VOIP оборудования будут освещаться в сборнике статей Asterisk & NGN. Выпуск первого номера журнала намечен на конец августа текущего года. Получить дополнительную информацию и оформить подписку на издание можно на сайте компании Mototelecom.
О компании:

Компания Mototelecom – системный интегратор, поставщик решений и оборудования для построения корпоративных сетей и телекоммуникационных систем любого класса сложности. Центральный офис компании находится в Москве, успешно работает представительство Урал-Мототелеком в Екатеринбурге, в ближайшем будущем планируется открытие еще ряда филиалов в России и СНГ.
Одно из ключевых направлений - построение решений на базе Asterisk IP-PBX по снижению расходов на междугороднюю и международную связь, по объединению удалённых офисов и созданию общего номерного плана, созданию мобильного офиса, call-центра, contact-центра, факс-сервера, созданию системы записи и прослушивания разговоров, и прочих сервисов современной IP АТС.
С августа 2006 года компания начинает выпуск журнала Asterisk & NGN. Издание будет выходить объемом в 60 полос ежеквартально. Целевая аудитория издания: инженеры–программисты использующие Linux платформу, инженеры-связисты, системные администраторы крупных холдингов, имеющие распределенную структуру предприятий, начинающие пользователи Asterisk, интересующиеся VoIP технологией, операторы IP телефонии, прочие технические специалисты и любители, интересующиеся NGN технологией, Оpen Sourсe (свободно распространяемыми) решениями, программными решениями Asterisk.
Об Asterisk:
Asterisk IP-PBX - Это программный продукт с открытым исходным кодом, работающий на Linux и FreeBSD и предназначенный для создания серверных IP-АТС и построения телефонных систем любой сложности на базе компьютерных технологий VoIP и TMDoE. Сервер IP-PBX Asterisk изначально разрабатывался специально для IP-телефонии, но с помощью специальных плат компьютерных интерфейсов, Asterisk может подключаться к телефонным сетям по интерфейсам E1 PRI или аналоговым линиям связи, или работать совместно с существующей УПАТС в роли шлюза LAN и IP-телефонии.
Asterisk выполняет все функции традиционной PBX (АТС), имеет большой набор дополнительных сервисных функций, обладает практически неограниченными возможностями масштабирования и позволяет построить решения разного уровня для совершенно разных задач и адаптировать их под специфические требования клиентов.
Разработчиком Asterisk и первого в отрасли открытого стандарта межстанционных соединений IAX (Inter-Asterisk eXchange) является компания Digium.
Mobile Client Software Factory – July 2006
patterns & practices Developer Center
July 2006
Summary
The Mobile Client Software Factory provides integrated guidance to help architects and developers create line-of-business Windows Mobile applications that interact with back-end systems over networks such as WiFi and GPRS that might be intermittently available.
A mobile smart client line-of-business application has one or more of the following characteristics:
It has a rich user interface that takes advantage of the power of the Windows Mobile device.
It might use a gateway server and the most cost effective underlying network technology to connect to and exchange data with multiple back-end systems.
It takes advantage of local caching and processing to enable operation during periods of no network connectivity or intermittent network connectivity.
It is easily deployed and configured.
It helps to keep local, potentially confidential information secure.
The Mobile Client Software Factory provides extensive guidance, including patterns, step-by-step instructions (How-to topics), sample application source code (reference implementation), reusable components (Application Blocks), a Guidance Automation Toolkit package that automates common mobile client development tasks in Visual Studio, and architecture documentation.
In addition, the Mobile Client Software Factory builds on and incorporates the following existing patterns & practices assets:
Composite UI Application Block and Data Access Application Block ported into the .NET Compact Framework
Guidance Automation Toolkit
Architects can use the Mobile Client Software Factory to create baseline architectures for their organizations. A baseline architecture is a starting point for implementing instances of similar applications —in this case, a mobile application —that includes the most critical mechanisms and shared elements common to those applications. Developers can use the baseline architecture to create mobile client applications in a predictable and agile way, using the Application Blocks and tools provided.
The patterns & practices team used an agile, community-connected process to develop the Mobile Client Software Factory. Incremental code and milestone releases (called Customer Technology Previews, or CTPs) were made available to the community throughout the development of the Factory. The community feedback influenced both the code and the guidance included in this release.
Downloads Mobile Client Software Factory
To download the toolkit, you have to join the community workspace.
Community Mobile Client Software Factory Community
License End User Licensing Agreement (EULA)
Contents
Overview
Scenarios
Benefits
Contents
Existing patterns & practices Assets
Intended Audience
System Requirements and Installation
Mobile Client Software Factory Features
Getting Started
Community
Future Plans
Feedback and Support
Authors and Contributors
Related Titles
Overview
With the Mobile Client Software Factory, architects and developers can quickly incorporate many of the proven patterns and best practices of mobile client development into their solutions. The factory content guides you through the development of mobile applications, including plug-in-based applications built with the Compact Composite UI Application Block architecture. By using the Mobile Client Software Factory, architects and developers can focus more of their efforts on implementing business requirements, and reduce the risk of creating low-level infrastructure around areas such as connectivity, configuration, or security.
Scenarios
The growing capabilities of mobile devices, such as the Pocket PC, and their increasingly widespread usage within the commercial world, provide an opportunity for business solutions to broaden their reach to include remote and mobile workers. These workers could be sales staff traveling away from the office, goods dispatch workers in a warehouse, or offsite engineers. Any of these workers might require access to the corporate IT system in either a connected or a disconnected scenario.
For example, sales staff may need to check product specifications or delivery schedules while on a customer’s premises. This situation suits an occasionally connected model, where the central system updates the data stored on the mobile device at specific intervals, perhaps when the user is in the office each morning or connected from home or a hotel room in the evening. Alternatively, the application could connect over a wireless cellular network or via a public WiFi when these are available. While the user is connected, the device can push updates, such as new orders, back to the back-end servers, and receive new information for the application to use.
Staff working within the corporation premises may also require a mobile solution: for example, when checking stock in a warehouse or assembling orders for dispatch. A connected (online) model suits this scenario. In this scenario, the mobile device could access back-end systems directly by using a Web UI application or via a Terminal Services client. The application, however would not be available if there is some brief interruption of the connectivity.
Offsite engineers may require live data some or all of the time, but might be out of range of the corporate wireless network. In this case, a cellular telephone connection can provide an online experience for periods when required, while an offline model could be suitable for other tasks.
In addition, many users require several applications to be available, and these applications might be dependent on roles defined within the main system, and they might be integrated with a back-end Enterprise Resource Planning (ERP) or Contact Relationship Management (CRM) platforms. All of these factors combine to require something more than simple, individual remote-capable applications. Instead, as demonstrated by the example application shown in
Figure 1, businesses require comprehensive, extensible, and flexible mobile business solutions. This example application requires access to information even when disconnected, can present the user with multiple task-oriented user interfaces that integrate with each other, and would be manageable and secured with little or no user intervention.

Figure 1. An example of a mobile business solution
Figure 2 shows the common elements of a mobile business solution based on the Microsoft Windows operating system and a range of applications and services. The Microsoft platform provides the core features required for all applications, including the tools and code libraries required to build mobile applications and the services that provide data and integration capabilities to these applications. In most cases, complex mobile solutions will integrate with a back-end ERP or CRM system, or other corporate application.

Figure 2. The base platform, layers, and components of a mobile business solution
The upper section of Figure 2 shows the approach to mobile business solution development that the Mobile Client Software Factory enables. The guidance and application blocks developed by the patterns & practices group, together with code developed by Microsoft partners, implement the services and components for applications running on the mobile client device.
Figure 3 shows the actual architecture of a simple mobile application. The common elements include:
User interface layers that consist of the following:
Views: controls that appear on the device display
Presenters: classes that drive the views
Business logic layers that consisting of the following:
Business entities: classes that represent business concepts, such as Customer, Bank Account, or Address
Business logic components: classes that implement the majority of the business logic within the application
Business workflows: logic that drives the overall flow of control within the application
Resource and data layers that consist of the following:
Data access components, which can fetch data from a local store such as Microsoft SQL Server Mobile Edition, and might use infrastructure components to manage data subscriptions and expirations
Service agents, which act as proxies to external Web services and facilitate working in occasionally connected environments

Figure 3. Common components and layers of a mobile line of business application
Building applications that follow the design and structure shown in Figure 3 requires infrastructure components that implement common tasks. The Mobile Client Software Factory provides many of these infrastructure capabilities, including:
Management tasks, such as logging and storing data about instrumentation events, which can then be collected on the server when the device is connected.
Deployment tasks that make it easier to deploy applications to the device and to update applications as you add new functionality
Configuration tasks that allow allowing the server to push complex data, such as specific configurations per user or per device
Security tasks, such as storing user credentials so that calls to occasionally connected Web Services can be authenticated
Connectivity tasks, such as connection and network management features for assessing the current connectivity of the device and reacting to changes in connectivity
You can also use the container model to simplify application architecture and the development of its internal logic. The Mobile Client Software Factory uses the Compact Composite UI Application Block (CAB) as the basis for this container. The CAB included in the Mobile Client Software Factory is an almost exact replica of the CAB that is available for desktop .NET applications, which means that you can take advantage of existing skills and code across both environments.
Architect Scenarios
As a software architect, you want to make sure that your mobile smart client applications derive from a sound, proven practice-based foundation that:
Provides a standard approach to application development.
Promotes re-usability of common architectural components.
Hides complexity.
Allows developers to focus on business problems instead of infrastructure components.
The Mobile Client Software Factory provides a starting point for creating that foundation. It provides out-of-the-box implementation of a set of features and mechanisms that are common to mobile applications. Additionally, you can customize and extended it to better fit your specific needs. You can add your patterns, How-to topics, and extend the Guidance Automation Toolkit packages to meet specific requirements for your organization.
Developer Scenarios
As an application developer, you want to focus on the business logic and the user experience of your application. You need a baseline that provides you with the necessary infrastructure and the architecture mechanisms that you need. That baseline is the Mobile Client Software Factory modified and extended by the architect.
You should review the patterns, the How-to topics and the reference implementation to understand the proven practices for developing smart clients. After you are ready to build your application, you can use the Guidance Automation Toolkit packages to generate items such as your initial solution, modules, and service agent.
Benefits
The Mobile Client Software Factory provides the following benefits:
Accelerated start. It provides an effective way for architects and developers to create a high-quality starting point (baseline) for their solutions. The baseline includes code and patterns that are typically discovered in Iteration 0, or the inception and elaboration phases, of a project. This means that projects begin with a greater level of maturity than applications developed without source code or guidance.
Reduced risk. It provides you with a proven baseline architecture. The baseline addresses the architecturally significant use cases by exposing design decisions and risks early in the development cycle.
Increased quality. It provides reusable assets, guidance, and examples that address common smart client scenarios and challenges. The code and guidance have been tested for the target scenarios. Tests are supplied as part of the package and they can be extended and used to automatically verify changes and identify problems.
Increased productivity. It includes automation for Visual Studio 2005. With this automation, developers can easily apply guidance in consistent and repeatable ways.
Ease of adoption. It is open and customizable. Architects and development leads can customize the factory to meet specific needs. The factory is fully documented.
Contents
The Mobile Client Software Factory contains the following:
Documentation (provided in Help format):
“Getting Started with the Mobile Client Software Factory.” This provides a vocabulary and framework that the remaining documentation uses to describe the mobile client architecture.
“The Mobile Client Software Factory Project Scope.” This describes the applicable business solutions, purpose, scope, and components included in the Mobile Client Software Factory.
“Developing with the Mobile Client Software Factory.” This provides information on installing and using the software factory, and includes detailed information on testing your applications.
“The Mobile Client Software Factory Application Blocks.” This provides a thorough description of the reusable building blocks included in the software factory. The documentation provides detailed information, instructions, and examples for using each of the application blocks.
“The Automated Guidance Package.” This explains how to install and use the Mobile Client Software Factory automated guidance.
“The C# Hello Mobile World QuickStart.” This provides step-by-step instructions for using the Compact Composite UI Application Block to build a mobile application in C#.
“Visual Basic .NET Hello Mobile World QuickStart.” This provides step-by-step instructions for using the Compact Composite UI Application Block to build a mobile application in Visual Basic .NET.
“AdventureWorks2Go Reference Implementation.” This describes the requirements, architecture, and implementation of the AdventureWorks2Go reference implementation.
Reference implementation. The reference implementation is an executable sample application that demonstrates the mobile client guidance in action. You can use the reference implementation to learn how the factoryÂ’s deliverables are applied, or you can use its concepts and imitate its design in your applications.
Guidance package. The Mobile Client Guidance Package automates development activities that developers would usually have to manually perform frequently by following a series of instructions. It helps developers build smart client solutions in a way consistent with the architecture guidance.
Application Blocks. The Mobile Client Software Factory includes:
The application blocks in the Mobile Client Software Factory are:
a set of Mobile Application Blocks designed specifically to help you build mobile applications
The Mobile CAB and Mobile Object Builder blocks that provide the core features for creating object instances, and instantiating services in a container model.
The fundamental nature of mobile devices, and the kinds of application deployed on them, means that the Mobile Client Software Factory must incorporate several features that are not usually required for desktop or server applications, or that are part of the underlying desktop or server platform. To minimize the memory footprint on the mobile device, the Mobile Client Software Factory exposes these features as separate application blocks that you can install and use in any combination you require. The application blocks provided with the Mobile Client Software Factory are:
The Configuration Block, which provides comprehensive features for managing application configuration, including encrypted configuration, on a mobile device
The Connection Monitor Block, which monitors and exposes connections between the device and networks and services it uses.
The Data Access Block, which provides features to simplify data access code requirements when using the SQL Server 2005 Mobile Edition database
The Data Subscription Block, which provides services that simplify setting up and executing SQL Mobile replication subscriptions.
The Disconnected Service Agent Block, which provides features for storing offline Web Service requests, and executing them when connectivity is available
The Endpoint Catalog Block, which stores and exposes physical address and associated details (including credentials) for remote services to which the device can connect from configuration.
The Orientation Aware Control Block, which implements a control that allows you to design your user interfaces to suit different screen orientations, form factors and resolutions, and culture/localization settings of different devices.
The Password Authentication Block, which provides the features required to authenticate users manage encryption and secure storage for data
Existing patterns & practices Assets
The factory uses a ported version of the Composite UI Application Block to address the core Client UI patterns —such as composite, provider, event broker and layout management. The Composite pattern combines simple user interface parts to create a complex user interface, while allowing the parts to be independently developed, tested, and deployed. For more information, see the Composite UI Application Block.
The factory also uses modified versions of Enterprise Library to address common challenges such as data access.
The factory uses the Guidance Automation Toolkit to automate common development tasks that simplify the development of templates and recipes. The Guidance Automation Toolkit is a lightweight Visual Studio extensibility mechanism. For more information, see the Visual Studio Team System Developer Center.
Many patterns implemented in the Mobile Client Software Factory are also available for desktop Smart Clients in the Smart Client Software Factory.
Intended Audience
This guidance is intended for software architects and software developers. To develop using this guidance, you should have an understanding of the following technologies:
Microsoft Visual C# or Microsoft Visual Basic 2005
Microsoft .NET Framework 2.0 and .NET Compact Framework 2.0
Windows Forms
Windows Mobile 5.0
Applications built using this guidance will require the .NET Framework 2.0 to run.
System Requirements and Installation
The minimum requirements for satisfactory performance when developing Mobile Client applications are:
Using an external device:
Windows XP or Windows Server 2003
1.5GHz processor
512 MB memory (1 GB preferable for best performance)
20MB free disk space
Pocket PC device with 512 MB memory available
Using the Visual Studio Mobile Device Emulator:
Windows XP or Windows Server 2003
1.5GHz processor
1 GB memory (2 GB preferable for best performance)
20MB free disk space
Before using the Mobile Client Software Factory, you must install some tools and utilities. The requirements for developing with and using the Mobile Client Software Factory are:
Visual Studio 2005, available from:
http://msdn.microsoft.com/vstudio/
.NET Compact Framework 2.0, installed with Visual Studio 2005 or available separately from:
http://msdn.microsoft.com/netframework/downloads/updates/default.aspx
http://msdn.microsoft.com/netframework/programming/netcf/default.aspx
SQL Server 2005 Mobile Edition, available with some versions of Visual Studio 2005 and SQL Server 2005, or from:
http://msdn.microsoft.com/sql/mobile/default.aspx
http://www.microsoft.com/sql/editions/sqlmobile/installsdk.mspx
Windows ActiveSync 4.1, available from:
http://www.microsoft.com/windowsmobile/downloads/activesync41.mspx
Windows Mobile 5.0 Pocket PC SDK
http://msdn.microsoft.com/mobility/windowsmobile/downloads/default.aspx
http://www.microsoft.com/downloads/results.aspx?pocId=&freetext=%u2022%09Windows%20Mobile%205.0%20Pocket%20PC%20SDK&DisplayLang=en
Localized emulator images are available from:
http://www.microsoft.com/downloads/details.aspx?familyid=EEC33AE3-C129-4C25-ABAA-18E8E842178F
http://www.microsoft.com/downloads/details.aspx?familyid=52FED581-8F8D-4C46-9966-4832098191B7
Guidance Automation Extensions Technology Preview (June 2006 Release for Visual Studio 2005):
http://go.microsoft.com/fwlink/?LinkId=69210
Guidance Automation Toolkit Technology Preview (June 2006 Release for Visual Studio 2005):
http://go.microsoft.com/fwlink/?LinkId=69211
The factory includes tools that optimize the performance of solutions built on the Compact Framework version of the Composite UI Application Block (CABGen and ObGen). ObGen requires CCI, an improved .NET metadata processing library, which is available here:
CCI http://www.gotdotnet.com/team/fxcop
Additionally, you can download the Windows Mobile 5.0 Developer Resource Kit from http://msdn.microsoft.com/mobility/windowsmobile/howto/resourcekit/default.aspx. This contains:
A 90 day trial version of Visual Studio 2005 Professional Edition
Windows Mobile 5.0 SDKs for Pocket PC and Smartphone
ActiveSync 4.1
.NET Compact Framework 2.0
Localized emulator images and other useful developer tools
SQL Server 2005 Mobile Edition
Notes:
If you install the AdventureWorks Database for the reference implementation, you must have a running instance of SQL Server 2005.
If you install the Web service for the reference implementation, you must have IIS 5.0 or IIS 6.0.
If you want to run the reference implementation, you must install both the AdventureWorks Database and the Web service for the reference implementation.
The mobile devices tested against the Mobile Client Software Factory, based on their capabilities.
Windows Mobile 5 Phone Devices
The Cingular 8125 PocketPC phone is a GSM-capable device that has a quarter VGA screen and a slide-out keyboard. It is useful for testing screen orientation changes, and keyboard support. This phone has features that are hard to test with the emulator.
The T-Mobile MDA is a GSM-capable device.
The Verizon XV6700 (the same as the Sprint PPC-6700) is a CDMA-capable device.
Mobile Devices with a Square Display
The Palm Treo700w is a Windows Mobile 5.0 phone with a square screen, useful for testing with a square screen and keyboard support. You can also use the equivalent emulator for this type of testing.
The HP iPAQ hw6515 phone has a square screen with a keyboard below, but is a Windows Mobile 2003 device.
Mobile Devices with a VGA Screen
The Dell Axim x51v has a VGA screen.
Mobile Client Software Factory Features
Table 1 lists the features the Mobile Client Software Factory provides guidance for.
Table 1: Guidance for Mobile Client Software Factory Features
Mobile client features
Guidance
Automation
Asynchronous communication to Web services, queuing messages, and working offline
Patterns
Reference Implementation
Connection Monitor Application Block
Service Agent Application Block
X
Building complex UIs based on independently developed, tested, and deployed parts (smart parts)
Compact Composite UI Application Block
Quickstarts
Reference Implementation
X
Building UIs that are independent of screen sizes, screen resolutions, and screen orientations.
Orientation Aware Control Application Block
Reference Implementation

Loosely coupled components communicating by way of events
Compact Composite UI Application Block
Reference Implementation

Configuration
Configuration Application Block
Reference Implementation
X
Synchronizing reference data
Reference Implementation

Unit testing components on the device
Reference Implementation
TestRunner for Compact Framework

Getting Started
The following recommendations allow you to quickly use the guidance in the Mobile Client Software Factory.
To learn about proven practices of mobile client development
Install the Mobile Client Software Factory.
Read the documentation for common patterns.
Review the Reference Implementation.
Read and follow the procedures in the Quickstart examples.
To create a mobile client application
Install the Mobile Client Software Factory.
Use the templates and recipes in the guidance package.
Read and follow the procedures in the Quickstart examples.
Review the Reference Implementation. Use it as a starting point for your own application.
Review the Getting Started section in the documentation. Click Start on the taskbar, click All Programs, click Microsoft patterns & practices, click Mobile Client Software Factory – July 2006, and then click Help.
Community
The Mobile Client Software Factory, like other patterns & practices deliverables, is associated with a community site. On this community site, you can post questions, provide feedback, or connect with other users to share ideas. Community members can download additional content such as extensions and training material, and can also help Microsoft plan and test future offerings.
Future Plans
At the time of publication, no new releases of the Mobile Client Software Factory are planned for 2006. The patterns & practices Client team will start collecting customer feedback immediately after the July 2006 release. This feedback will be incorporated into our product planning process and will be broadly communicated in our community site. The team will also evaluate the opportunity to update the Mobile Client Software Factory as new platform technologies are released. patterns & practices plans are driven by community input, so please participate and help us understand what additional guidance you might need.
Feedback and Support
Questions? Comments? Suggestions? To provide feedback about the Mobile Client Software Factory, or to get help with any problems you encounter while using the factory, visit the Mobile Client Software Factory Community. The message board on the community Web site is the preferred feedback and support channel because it allows you to share your ideas, questions, and solutions with the entire community. Alternatively, you can send e-mail directly to the Microsoft patterns & practices team at devfdbck@microsoft.com, although we are unable to respond to every message.
The Mobile Client Software Factory is a guidance offering, designed to be reused, customized, and extended. It is not a Microsoft product. For more information, see Table 2.
Table 2: Mobile Client Software Factory Attributes
Attribute
Description
Support
Code-based guidance is shipped “as is” and without warranties. Customers can obtain support through Microsoft Support Services for a fee, but the code is considered user-written by Microsoft support staff. The patterns & practices team works with product support and will assist them with escalations as needed. Customers are encouraged to support one another through online communities.
Functionality
This guidance provides a flexible and architecturally sound solution to a common enterprise development challenge. The guidance addresses the challenges by using base platform features and adhering to proven practices. The guidance is designed to be extended and customized by users.
Release
Guidance releases are typically developed in a 3–6 month life cycle. Assets are released as they become ready on the currently available platform. New versions of existing assets (possibly revised to run on later versions of the platform) are released if there is sufficient customer demand.
Compatibility
Code-based guidance is designed to help solve problems on specific versions of Microsoft products. As the products change, the guidance issued may change or become obsolete. When possible, the patterns & practices team Microsoft develops guidance with future releases in mind. There are no guarantees about compatibility with earlier releases of guidance or with past or future platform releases. A phased migration strategy is recommended, and coexistence of multiple versions of the guidance is given high priority by the patterns & practices team.
Form factor
This guidance is released as source code. Variability is provided through configuration and defined extensibility points, as well as through direct modification of the source code. Documentation focuses on how to use the asset, how to extend it, and the goals, patterns, and tradeoffs that drive its design.
Authors and Contributors
The Mobile Client Software Factory was produced by the following individuals:
Program and product management: Per Vonge Nielsen and Eugenio Pace (Microsoft Corporation)
Architect: Edward Jezierski (Microsoft Corporation)
Development: Francis Cheung (Microsoft Corporation); John Socha-Leialoha; Daniel Cazzulino, Santiago Blason and Jose Salazar (Clarius Consulting / Q4 Tech)
Test team: Carlos Farre and Mohammad Al-Sabt (Microsoft Corporation); Rohit Sharma, Terrence Cyril Joseph Anthuvan, Lavanya Selvaraj, Saravanan Marappan, Ritesh Chaturvedi and Benjamin Chou (Infosys Technologies Ltd)
Documentation: Alex Homer (Content Master Ltd.); Tina Burden McGrayne (TinaTech, Inc.); Paul Slater (Wadeware LLC); Claudette Siroky (Wadeware LLC)
Release management: Sanjeev Garg (Microsoft Corporation)
The Mobile Client Software Factory was developed in collaboration with Microsoft Dynamics Mobile Application Group:
Erik Dibbern Röser; Ricky Kaare Rasmussen; Laurent Lopez; Bjarne Schøn and the Mobile and Embedded Devices Group in Microsoft Corporation:
Eric Engineer, John Dietz, and Loke Uei Tan
patterns & practices would also like to thank the following expert advisors who provided invaluable assistance throughout the development of the project:
Alex Yakhnin (Infusion Development), Andy Wigley (Andy Wigley Computing Ltd), Dan Fergus (Forest Software Group), Daniel Moth (Microsoft UK), Keni Barwick (Conchango), Leandro Olivestro (Q4Tech S.A.), Maarten Struys (PTS Software bv), Nickolas Landry (Infusion Development), and Peter Nowak (T-Systems Enterprise Services GmbH, Germany)
Related Titles
Composite UI Application Block
Smart Client Software Factory
Enterprise Library
Guidance Automation Extension
Guidance Automation Toolkit
Сеть SIPNET
sipnet.ru
SIPNET — это сеть интернет-телефонии нового поколения, в которой реализованы последние достижения в области инфокоммуникаций, обеспечивающие эффективный обмен голосовой и мультимедийной информацией.
Пользователи сети могут неограниченно и бесплатно общаться через Интернет со всеми участниками сети SIPNET, бесплатно говорить по Интернету из любого города мира с абонентами городских сетей Москвы и Санкт-Петербурга, а так же с абонентами сотовых сетей Москвы, имеющих прямые номера.
Подключение к SIPNET — бесплатное. Более того, после подключения на вашем счёту уже будет находиться 1 у.е.
Чтобы стать пользователем нашей сети, достаточно иметь доступ к Интернету на скорости не ниже 64 Кб/сек, любое стандартное абонентское SIP-устройство или компьютер с гарнитурой (наушники с микрофоном) и установленным программным телефоном.
Самый простой путь — купить гарнитуру, бесплатно установить на свой компьютер один из программных телефонов и пройти регистрацию в SIPNET. Подключение к SIPNET компьютера с программным телефоном минимизирует ваши начальные расходы — сегодня это самый популярный способ подключения.
Чтобы разговаривать без компьютера, можно приобрести любое стандартное SIP-устройство: SIP-телефон или SIP-адаптер (для обычного телефонного аппарата), которые подключаются непосредственно к Интернету. Важно отметить, что в этих устройствах есть специальный Ethernet-разъем, через который ваш компьютер можно подключить к Интернету независимо от SIP-устройства.
Если вы уже все знаете и хотите подключиться немедленно, воспользуйтесь услугой Быстрая регистрация.
Внимание! При регистрации необходимо заполнить регистрационную форму:
Обязательно заполните все поля формы.
В качестве Логина и Пароля указывайте только латинские буквы, цифры, точку или подчеркивание.
Ваш Пароль должен быть не короче 6 символов и одновременно содержать цифры и латинские буквы (обязательно и заглавные — большие, и строчные — маленькие).
Дата вашего рождения вводится в формате дд/мм/гггг.
Обращаем ваше внимание на то, что при регистрации вы можете получить только одну учетную запись для одного IP адреса. Первичная учетная запись имеет статус «Тестовый доступ». Если в течение 30 дней с момента регистрации вы не пользовались услугами голосовой связи, первичная учетная запись автоматически удаляется. Если в течение 30 дней с момента регистрации вы пользовались услугами голосовой связи, но не пополнили свой счет, первичная учетная запись также удаляется.
«Тестовый доступ» позволяет:
Осуществлять соединения по бесплатным направлениям (Москва — стационарные и мобильные сети, Петербург — стационарные).
Общаться с городами России по тарифному плану «Спецсвязь плюс».
Бесплатно разговаривать с другими пользователями SIPNET.
Бесплатно отправлять мгновенные сообщения другим участникам SIPNET.
Внимание! Передача голоса за пределы России и полный доступ к услугам сети SIPNET возможны только для пользователей, пополнивших свой счет. Минимальный платеж для обслуживания по тарифному плану «Спецсвязь» составляет 30 у.е., а для тарифного плана «Спецсвязь Плюс» — 3 у.е.
После пополнения счета учетная запись имеет статус «Абонентский доступ».
Если вы выбираете вариант подключения с абонентским оборудование или с компьютером (программный телефон) вы можете выбрать любой из тарифных планов: без ежемесячной платы — «Спецсвязь Плюс» или «Спецсвязь» — с ежемесячной платой.
Абонентское оборудование вы можете купить у наших партнеров, в том числе и в регионах. За дополнительной информацией обращайтесь по e-mail или по телефонам +7 (495) 974-19-26, +7 (800) 200-99-91.
Если вы не можете самостоятельно установить и настроить SIP-устройство, то к вам приедет специалист технической службы. Настройка платная. Цена настройки одной единицы оборудования 20 у.е. Платеж списывается с Лицевого счета абонента.
Договор на выезд специалиста SIPNET 60 КБ
Заявление на настройку оборудования 32 КБ
Если вы находитесь не в Москве, мы можем помочь выполнить настройку удалённо. Пишите: e-mail, звоните: +7 (495) 974-19-26, +7 (800) 200-99-91.
Любое юридическое лицо может официально стать пользователем сети SIPNET, осуществлять оплату услуг через банк и получать полный комплект документов, необходимых для бухгалтерской отчетности.
Для заключения договора заполните предлагаемую форму и отправьте ее нам по e-mail. Мы подпишем его со своей стороны, выставим счёт на оплату, и направим вам оригиналы договора.
ИНТЕГРАЦИЯ СИСТЕМ АДРЕСАЦИИ E.164 И DNS НА ОСНОВЕ ENUM
Одним из ограничений современной IP-телефонии является невозможность установления соединения, когда инициировавший вызов абонент использует обычный телефонный аппарат, подключенный к традиционной телефонной сети, а вызываемый абонент — ПК или IP-телефон, соединенный с Internet или частной сетью IP.
Хотя востребованность такой услуги пока невелика, с развитием IP-телефонии интерес к ней неизбежно возрастет. Сложность подобного соединения связана с применением в общедоступных телефонных сетях и Internet различных схем адресации — системы телефонных номеров на основе стандарта E.164 и системы имен DNS. И если пользователю ПК или цифрового IP-телефона не составляет труда набрать телефонный номер для вызова абонента, то представить себе набор имени DNS с помощью обычного аналогового аппарата довольно сложно.
Для преодоления пропасти между этими видами общедоступных услуг необходимо либо выбрать общую схему идентификации абонентов, либо разработать метод трансляции одной схемы в другую.
Предложения рабочей группы IETF ENUM решают задачу вторым способом, и пока он наиболее близок к немедленной реализации. Подход ENUM состоит в назначении всем абонентам телефонии, подключенным к Internet или частной сети IP, идентификаторов еще одного типа — телефонных номеров по стандарту E.164.
Однако на конечных узлах и даже сетях, в которых вызов терминируется, эти телефонные номера не используются — они нужны только для идентификации вызываемого абонента стороной-инициатором, применяющей обычный телефон, и маршрутизации вызова в пределах традиционной телефонной сети. Затем телефонные номера преобразуются в имена Internet с помощью хорошо известной и отлично зарекомендовавшей себя службы — системы доменных имен DNS.
Используемый при этом подход подобен тому, который применяется для решения обратной задачи DNS — нахождению имени узла по его IP-адресу. С этой целью предлагается создать новую зону — e164.arpa, куда будут входить территории, соответствующие цифрам телефонного номера: например, зоны верхнего уровня 1, 7, 33, 44 для номеров, принадлежащих абонентам Североамериканского региона, России, Франции и Великобритании соответственно. Домен верхнего уровня arpa традиционно отводится для решения обратной задачи — нахождение имени по адресу с помощью зоны in-addr.arpa.
Для преобразования телефонного номера в имя DNS используется специальный тип записи — Naming Athority Pointer (NAPTR). Изначально данная запись предназначалась для перечисления сервисов, которые поддерживает организация, администрирующая данный домен (RFC 2915). Примером та-кой записи может служить строка sip:Petrov@firma.ru, сообщающая о том, что с абонентом можно связаться, направив ему вызов по протоколу sip на имя Petrov@firma.ru. Очевидно, что такие записи будут находиться только в зонах самого нижнего уровня, где находится номерная емкость, которую провайдер получил для обслуживания конечных абонентов. Зоны же верхнего уровня будут содержать только обычные ссылки на серверы имен зон более низкого уровня. Итак, если имени Petrov@firma.ru соответствует телефонный номер +7 095 758 35 22, то связанная с этим абонентом запись, возможно, содержится в зоне 8.5.7.5.9.0.7.e164.arpa (обратный порядок записи цифр телефонного номера согласуется с принятым в DNS правилом расположения старшей части имени справа, а не слева, как в телефонии). Запись может находиться и в зоне 3.8.5.7.5.9.0.7.e164.arpa — если все номера диапазона +7 095 758 3x.xx переданы еще более мелкому провайдеру (в предыдущем примере предполагалось, что все номера +7 095 758 xx xx принадлежали одному провайдеру). Деление телефонного номера на зоны производится по цифрам в полном соответствии с административной ответственностью каждой конкретной организации за отображение телефонных номеров на имена DNS (точнее, на универсальные идентификаторы ресурсов Internet, URL, которые в дополнение к имени DNS имеют еще префикс, укзывающий тип протокола доступа к ресурсу). Чем больше уровней подчиненности провайдеров IP-телефонии, тем больше составных компонентов в имени зоны.
Если технические моменты в схеме ENUM по организации отображения телефонных номеров на имена DNS сегодня уже вполне ясны (они определены в RFC 2916), то вокруг вопроса об административной подчиненности зон верхнего уровня ведется ожесточенная битва. Дело в том, что некоторые организации, например VerySign, уже начали регистрировать телефонные номера в зоне e164.arpa и хотели бы продолжать свой бизнес, возможно, под общей координацией соответствующего комитета или некоммерческой организации, как это принято в сообществе Internet. Однако распределение старших частей телефонных номеров стандарта E.164 с давних пор координируется ITU и национальными ведомствами, и эту прерогативу ITU хотел бы оставить за собой. Похоже, что чаша весов склоняется к административной опеке со стороны ITU над зоной 164.arpa, во всяком случае недавно к такому решению пришел ряд крупных компаний телекоммуникационной отрасли. Пока переговоры между ITU и IETF продолжаются.
Естественно, общая схема идентификации абонентов может быть создана иначе, например путем введения нового класса адресов IPv6, благо, там имеются соответствующие резервы. Но предложение ENUM можно внедрять уже сегодня, и в этом его привлекательность.

Приложение для обмена голосовыми сообщениями для сетей IP телефонии

Filed under: Technical notes — admin @ 7:06 pm

Разработка программного обеспечения
Приложение для обмена голосовыми сообщениями для сетей IP телефонии

(SIP софтфон)

ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Черновик

Общие сведения
Полное наименование системы и ее условное обозначение

Полное наименование системы: Приложение для обмена голосовыми сообщениями для сетей IP телефонии
Условное обозначение: софтфон SIP

Программное обеспечение «Приложение для обмена голосовыми сообщениями для сетей IP телефонии» разрабатывается.
Заказчик и Исполнители

Заказчик - оператор сети IP телефонии
Исполнитель -

Источник финансирования

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

Договор на выполнение работ по разработке программного обеспечения «Приложение для обмена голосовыми сообщениями для оператора сети IP телефонии»
Документы, описывающие стандарты, используемые в приложениях:
RFC 3261 SIP: Session Initiation Protocol
RFC 2616 Hypertext Transfer Protocol — HTTP/1.1
Плановые сроки начала и окончания работы по созданию софтфона SIP

Начало выполнения работ – 24.12.06.
Окончание работ первой очереди – 24.12.06.
Окончание работ (сопровождение) – 24.12.06.
Назначение и цели создания (развития) системы
Софтфон SIP предназначен для обеспечения обмена голосовыми сообщениями между абонентами SIP и другими пользователями SIP телефонии.
Целями создания софтфона SIP являются:

предоставить абонентам SIP софтфон для бесплатного скачивания с сервера;
интегрировать в софтфон функции, специфические для SIP, как, например, триальное автоматическое подключение к серверу; поиск абонентов в LDAP директории.

Особенностью софтфона SIP является то, что он функционирует, в отличие от аппаратных SIP телефонов, на компьютере с операционной системой Windows XP и обеспечивает интеграцию с выполняемыми приложениями.
Характеристика сети SIP
Сеть SIP ориентирована на сегмент рынка небольших компаний и личного использования, преимущественно с использованием аппаратных SIP телефонов.
Потребители услуг голосовой связи имеют подключение к Интернет, позволяющее им обмениваться голосовыми сообщениями с другими абонентами по более низкой цене в сравнении с услугами стационарной и мобильной связи, но не имеют желания использовать собственные SIP серверы.
Софтфон выполняет вспомогательные функции:
является элементом рекламной деятельности, в частности, используется для формирования имиджа, привлечения потенциальных потребителей из смежных сегментов;
дополняет аппаратный SIP телефон новыми функциями, следующими из интеграции с приложениями Windows.
Требования к софтфону
Требования к софтфону в целом
Софтфон представляет из себя комплекс программ, основанный на современных промышленных стандартах.

Основные требования к функционированию софтофона

Софтфон должен обеспечивать возможность легкой инсталляции на компьютерах с операционной системой Microsoft Windows XP и выше. Основной инсталляционный файл представляет собой выполнимое приложение (PE или MSI). Размер всех инсталляционных файлов, включая недостающие в стандартной поставке целевой платформы библиотеки, не должен превышать 10М.
Софтфон должен в достаточной степени интегрироваться с существующей инфраструктурой предприятия и допускать использование внешних директорий и управлять собственной системой базы данных звонков и контактов.

Перечень подсистем, их назначение и основные характеристики

Win32 приложение (SIP клиент), запускаемое автоматически при старте Windows и располагаемое в системном трее (возле часов). При поступлении вызова информирует Пользователя звуковым и текстовым уведомлением. При нажатии на иконку в трее предлагает ввести номер абонента сети или sip адрес и инициирует звонок;
Плагин к браузеру Internet Explorer собирает sip адреса с посещаемых страниц и при нажатии на ссылку с sip адресом заставляет SIP клиент инициировать вызов; опционально – ищет в тегах JPEG изображений (с логотипом SIP оператора) sip-адрес посещаемых страниц. Данная опция позволяет оператору IP телефонии вместе с адресом (номером) генерировать JPEG иконку (кнопку, банер) с логотипом оператора и включенным в тело (как один из тегов описания) номером телефона.
Кнопка в браузере Internet Explorer позволяет сделать SIP вызов из списка обнаруженных на страницах адресов, кнопка подсвечивается, если страницы содержат SIP адреса. Это позволяет пользователю связаться по контактному телефону без поиска ссылки на страницы, и показывает кнопку SIP оператора непосредственно на панели кнопок браузера IE.
Инсталлятор (или встроенная функция) SIP клиента создает JPEG изображение с логотипом SIP и внедряет в него тег с номером абонента SIP для последующего размещения логотипа на домашней странице Пользователя. Эта функция избавляет Пользователя от необходимости обрамлять изображение тегами ссылки на sip адрес и в некоторой степени усложняет процесс извлечения роботами спамеров (во всяком случае, заставляет робота скачивать изображения).

По требованиям к интеграции софтфон SIP должен обеспечивать:

унифицированный интерфейс пользователя;
SIP софтфон должен иметь возможность подключаться к директориям LDAP и Active Directory для осуществления поиска адресов пользователей внутри локальной сети предприятия. SIP софтфон должен передавать адрес LDAP сервера (Active Directory) по запросу абонента при разрешении Пользователем этой функции.
Дополнительно может включать опции:
встроенный SQL сервер для хранения и последующей обработки осуществленных звонков, запоминания sip адресов;

Требования к квалификации Пользователей, порядку их подготовки и контроля знаний и навыков

Конечный пользователь должен обладать навыками работы на компьютере на уровне пользователя (оператор ЭВМ).
Софтфон SIP должен иметь встроенную справочную систему в формате Compiled HTML (CHM) с описанием возможностей и приемов работы с ним для пользователя. Поставка ПО должна содержать инструкции администратору ЛВС в формате CHM или PDF.

Перспективы развития, модернизации системы

Перспективы развития, модернизации системы предусматривает добавление функций, необходимых для решения специальных задач, по согласованию с Заказчиком. Такими функциями могут быть:

показ рекламных сообщений;

Требования безопасности

По защите и безопасности данных софтфон SIP должнен обеспечивать:
хранить профили и настройки в пользовательских ветках реестра Windows и файлах внутри папки Пользователя;
не иметь скрытых функций, не предусмотренных этим Техническим Заданием;

Требования надежности

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

Требования к эргономике и технической эстетике

Софтфон SIP должен иметь дружественный интерфейс с пользователем, который достигается единообразными стилем форм.
Стиль софтфона SIP включает цветовую схему, типы шрифтов и согласуется с Заказчиком.
Клиент SIP на основной форме может отображать стилизованное изображение телефона, выполненное в Macromedia Fireworks как HTML файл. PNG файл проекта передается Заказчику для последующего изменения внешнего вида.

Требования к функциям системы

Основные функции включают:

Инициация исходящих звонков;
Получение входящих звонков;
Переадресация звонков на фиксированный аппаратный SIP телефон;
Ведение журнала учета времени звонков;
Передача и прием текстовых сообщений;
SIP клиент должен позволять Пользователю вводить http адрес и пытаться определить sip адрес путем поиска тегов в JPEG логотипе на домашней странице Адресата, что избавляет Пользователя запоминать “не родной” домен.
ENUM и DUNDI не используются для преобразования номеров в sip адреса

Требования к системному программному обеспечению

ОС WINDOWS XP SP2 и выше
Microsoft Internet Explorer 4.0 и выше
Microsoft RTC Client API

Состав и содержание работ по созданию системы
В таблице 1 приведен перечень работ по разработке программного обеспечения софтфон SIP.

Таблица 1. - Перечень работ по разработке программного обеспечения софтфон SIP


Наименование работ
1
Анализ, разработка технического задания, согласование технического задания с Заказчиком
2
Разработка рабочего макета софтфона SIP
3
Разработка программного обеспечения Клиент софтфон SIP
4
Сдача в эксплуатацию, доработка ПО софтфон SIP по требованию заказчика в течение срока сопровождения системы. Разработанная система передается в виде выполнимых файлов и библиотек и сценария сборки инсталляционных файлов.
5
Разработка справочной системы
6
Сопровождение системы в течение 2007 гг., включая исправление обнаруживаемых ошибок

В таблице 2 приведен график выполнения работ по перечню работ по разработке программного обеспечения софтфон SIP.

1-1
1-1
1-2
1-3
1-4
1-5
1-6
Начало
01 января 2007 г.
01 февраля 2007 г.
01 марта 2007 г.
01 апреля 2007 г.
15 марта 2007 г.
01 января 2007 г.
Продолжительность
30
60
30
14
5
0
Табл. 2. График выполнения работ по перечню работ

Дата начала работ 1 января. Начало работ 1-4, 1-5 и все последующие может быть передвинуто в соответствии с реальным началом работ по Договору.
Расшифровка работ – 1-1- таблица 1, позиция 1, 1-2 – таблица 1, позиция 2 и т.д.
Пояснения к перечню работ по разработке программного обеспечения:

Технология разработки
Для разработки используется итерационная модель разработки. Порядок взаимодействия Группы Разработчиков с Заказчиком предлагается следующий:
1.Оперативное согласование:
Аналитик из Группы Разработчиков готовит макеты экранных форм и отчетов и передает Представителю Заказчика в виде скриншотов;
Представители Заказчика просматривают их и заполняют лист замечаний
2.Плановое обсуждение:
Аналитик из Группы Разработчиков отправляет несколько черновых экранов и схем;
Представитель Заказчика делает общие замечания по всем представленным черновикам
Генерация отчетов выполняется в виде HTML.
Большая часть кодирования осуществляется в интегрированной среде разработки Borland Turbo Explorer на языке OOP.
Используются системные вызовы, находящиеся в библиотеках подпрограмм в Windows XP, в частности, Microsoft Windows RTC Client API (входит в поставку Windows XP по умолчанию), для интеграции с Microsoft Internet Explorer используются объекты, входящие в браузер.

Порядок контроля и приемки системы
Порядок контроля и приемки софтфона SIP в эксплуатацию производится поэтапно.

Предварительный этап.
Анализ бизнес процессов завершается составлением Технического Задания. Приемка этапа анализа осуществляется подписанием Технического Задания Заказчиком и Исполнителем.

Этап создания клиентской части
Заказчик создает рабочую группу для оперативного согласования экранов и отчетов, выработки замечаний по готовым модулям. Оперативное согласование экранов осуществляется по Листу согласований, Аналитик Исполнителя обсуждает с Представителем Заказчика экраны и отчеты, в них вносятся исправления, при отсутствии замечаний Представитель Заказчика подписывает соответствующий пункт в Листе согласования.
Готовые модули по мере разработки отдельные части модулей предоставляются для испытаний и получения замечаний со стороны специалистов Заказчика рабочей группе. В листе замечаний по мере их исправления рабочая группа делает отметку о приеме исправления.

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

Требования к документированию
Документация должна соответствовать требованиям комплекса стандартов и руководящих документов «Информационная технология» и включать в себя:
Техническая документация (описание БД, описание задач и отчетных форм)
Руководство пользователя софтфон SIP в формате PDF, CHM или текстовом формате
Руководство администратора софтфон SIP в формате PDF, CHM или текстовом формате
Документация должна представлять собой комплекс взаимоувязанных документов, в которых описаны решения по созданию и функционированию системы, подтверждается соответствие системы ТЗ и готовность ее к функционированию.
Вся техническая документация предоставляется в электронном виде.
СОСТАВИЛИ
Наименование организации, предприятия
Должность исполнителя
Фамилия имя, отчество
Подпись
Дата

Инженер-программист
Иванов А.И.

24.12.2006
СОГЛАСОВАНО
Наименование организации, предприятия
Должность исполнителя.
Фамилия имя, отчество
Подпись
Дата

24.12.2006

24.12.2006

Приложение 1
Перечень подлежащих разработке комплектов и видов документов

1.Описание БД
2.Описание процедур по сборке инсталляционных файлов
3.Описание назначения конфигурационных файлов, веток и параметров реестра
4.Реестр отчетных форм
5.Руководство пользователя софтфон SIP в формате PDF, CHM или текстовом формате
6.Руководство администратора софтфон SIP в формате PDF, CHM или текстовом формате

Приложение для обмена голосовыми сообщениями для сетей IP телефонии

Filed under: Technical notes — admin @ 7:04 pm

Разработка программного обеспечения

Приложение для обмена голосовыми сообщениями для сетей IP телефонии

(SIP софтфон)

Пояснительная записка к техническому заданию

Суть

На рисунке показаны ключевые элементы по интеграции sip клиента с браузером Microsoft IE:
1.Pluggable protocol. В строке Адрес встроенный протокол виден по имени ap: ap://isapi. Компонент, реализующий встроенный протокол, также перехватывает скачиваемые страницы Интернет (по протоколу http) и поэтому может собирать ссылки с посещаемых страниц с адресами вида sip:me@commandus.com. В браузер могут подключаться кнопки. На рисунке показана кнопка CALL! Перехват ссылок со страницы позволяет произвести звонок. Преимущества для пользователя – он не связывает инициацию звонка с SIP адресами, с его точки зрения он осуществляет «звонок на сайт». Реализация для Vista требует изучения, так как есть вероятность того, что новые версии IE не позволят загружать COM объекты из за усиления борьбы (возможно, потребуется приобретение сертификата от MS для подписывания COM объектов). В Windows XP, 2000, 2003 все работает. (Пока).
2.Из других (офисных) приложений адреса sip:me@commandus.com могут вызваться, но Office, например, выводит предупреждение об опасности таких ссылок. Вообще из любого места (например, из меню Пуск->Выполнить, из строки Проводника) Есть баг в обработчике (протокол обрабатывается, но не может подгрузить некоторые библиотеки. Это исправимо.
3.Кнопка CALL! в панели инструментов “Обычные кнопки” для быстрого вызова sip клиента (с передачей списка обнаруженных ссылок). Должна бы загораться, если найдет JPEG или sip- адрес. Но из за внутренней архитектуры браузер не передает в потоки COM объектов подключаемых кнопок нужную информацию. В принципе, поток кнопки может самостоятельно анализировать ВСЕ открытые браузеры IE, но это плохо, так как неоправданно нагрузит компьютер. Такой анализ можно сделать, ПОСЛЕ нажатия через посредство COM объекта, анализирующего контент страницы.
4.В веб мастер какого то узла Интернет может разместить банеры с JPEG изображеними с внедренными тегами (/sip.jpg), содержащими sip адреса. Для оператора SIP телефонии это реклама. Чтобы заставить размещать такие веб кнопки, в клиенте реализуется функция «звонок на сайт/домен». С точки зрения пользователя, ему более привлекательно осуществлять звонок не на адрес SIP оператора, а на свой собственный домен (сайт). Большинство пользователей вряд ли пожелают или смогут модифицировать DNS записи для переадресации со своего домена на домен оператора SIP (то есть, осуществить переадресацию средствами записей DNS с MyCorporate.com на ACMESipOperator.com) и без получения «глобальных» E.164 номеров. Нужен для того, чтобы пользователь мог легко добавить ссылку на телефон, без обрамления <a href=”sip: и софттелефон мог взять так же, как берет иконки для адресной строки (favicon.ico) без загрузки главной страницы (которая может и не содержать логотип)

5.В окне браузера показывается отчет о звонках (нарисовано немного не то, но это тоже отчет, из другого приложения (прокси сервер для RSS/ATOM/Blog). В показанном случае данные берутся из РСУБД FireBird 2.0)
6.Так как HTML страница сканируется на наличие <a href=”sip: .., и имеется возможность замены текста, то их можно подменить на более красивые или видимые; например, заменять ссылки конкурентов на свои ;), но это может вызвать опасения со стороны пользователей, что контент подменяется. Но замену части баннеров стандартных размеров на свои можно делать, как опцию банерорезки очень осторожно, так как легко можно потерять доверие, если подмена обнаружится.
7.Так как интерфейс очевидно простой (строка для ввода номера и большая красная кнопка), софтфоны обычно имеют скины, не повышающие удобство пользования, но подсказывающие пользователю назначение программы. Это, видимо, то, что ожидает пользователь. В противном случае получаем IM. Грань между ними очень тонкая, а IM забит монстрами. Поэтому, это фактически единственное отличие, и то чисто внешнее. Можно экран нарисовать в HTML редакторе с javascript, передающим сообщениями Windows нажатия кнопок. На рисунке вверху иконки PDF это как раз делают – и загруженная программа с нужным окном генерирует PDF, Word или Excel. В случае с SIP клиентом- набирает номер, поднимает и кладет трубку.
8.Рисование топовых моделей телефонов – это реклама (телефонов). Не забыть поставить линки на «Купить такой телефон» ;)

Проблемы
1.Если PC подключен к сети через аппаратный SIP телефон, пакеты останутся на телефоне и не пойдут на PC. Прозрачен ли аппаратный SIP телефон? Часть может быть прозрачной, навороченные могут не пропускать (и ни снаружи, и не изнутри). Но остается вероятность что для большинства аппаратных телефонов инициирование с PC произойдет успешно, а зазвонит аппаратный телефон. Это уже фича ;) позволяющая набирать номер на PC а получать звонок на аппаратный телефон.
2.Встроенные протоколы каскадируются, поэтому чтобы заблокировать других клиентов, можно после нахождения <a href=”sip: изменять на <a href=”shut-up:, чтобы вырубить «не своих» клиентов. Порядок вызова обработчиков, скорее всего определяется положением в реестре Windows, потому надо загенерить GUID «помладше».
3.Другие браузеры. Их слишком много… Из трея можно быстро звонить (просто выполнив ShellExecute тем самым передав все это обработчику MSIE и далее в клиент SIP)
4.Большая часть компаний, имеющих веб сайты и SIP аккаунты имеют несовпадающие домены, и часть из них хотела бы иметь SIP адреса в том же домене, что и сайт компании. Однако, хостинг чаще не предоставляет возможность развернуть SIP сервер и, более того, часто не позволяет управлять DNS записями в полном объеме, с тем, чтобы связать какой то из поддоменов (например, sip) на другом IP, чтобы направить звонки на SIP провайдера. Частично эта проблема может разрешаться предлагаемой схемой получения реального SIP адреса с веб сайта (JPEG файлы), что софтфон может легко сделать (попробовать соединиться с sip:alice@atlanta.com, не обнаружив там SIP сервера, запросить по http с http://atlanta.com/sip.jpg и извлечь из тегов alice=sip:12234@siphoster.com). SIP адрес может, конечно, содержать адрес SIP прокси и регистратора, но Инициатор звонка об них не догадывается.
5.В меморандуме перечисляются некоторые существующие другие проблемы, как приземление в зонах, ENUM И DUNDI, связанные, в частности, с проблемами нумерации и ввода sip адресов на sip телефонах, возникающие при передаче звонков от одного SIP сервера другому. Подготовлен черновик RFC для “прямого” преобразования вводимых номеров в SIP адреса с тем, чтобы передавать звонки. Однако эти номера очень длинные- в два раза длиннее sip адреса. В черновике RFC описывается получение обратных адресов, более удобных для запоминания, что немного упрощает задачу запоминания адресов. Идея обсуждалась в IETF, в целом идея не получила поддержки и статус документа не получен. Тем не менее, алгоритм декодирования может быть реализован как модуль к SIP серверу и клиенту, обеспечивая возможность получения звонков для передачи в другие SIP сети с устройств с цифровой клавиатурой без необходимости прописывания маршрутов. Для оператора IP телефонии это может быть привлекательно в случае, если помимо своей нумерации он позволяет и поощряет пользователей адресовать звонки через пользовательские домены (через DNS или как описано выше). Но через шаговую АТС все одно не набрать и не перекинуть… Надо также учитывать, что такие звонки всегда являются эпизодическими, а именно, проблема возникает тогда, когда Пользователь инициирует первый звонок и ему нужно ввести адрес на номеронабирателе, так как не существует другого иного способа. Поскольку sip адреса берутся, скорее всего из веба на PC, эту проблему лучше разрешить путем инициации сессии с PC, где будет указан получатель – аппаратный телефон. Тема совместного использования аппаратного и софтфона требует последующего изучения.
6.Проблема контекста звонков. Более подробно проблемы контекста рассматриваются в документе cFrame Inc. Executive Summary Introducing “Context Messaging”. Там же рассматриваются существующие примеры, как ZapLet. Частично эта проблема может разрешена с использованием журнала звонков, где отмечается тема голосового сообщения. Тема голосового сообщения может быть извлечена из инициирующей программы (почтовой программы, например), но это сопряжено с трудностями реализации. Скорее, лучше реализовывать специализированные клиенты под конкретные предметные области, что и рекомендовано Microsoft. Примерами могут быть – прайс листы, каталоги товаров, аксессуаров, услуг и запчастей, системы заказов, аукционы, голосования, службы поддержки, в том числе – пользователей программ, call центры, где покупка отличается нечеткой формализацией (например, требуется много переговоров) для взаимодействия с клиентами или смежными предприятиями. Проблема контекста, скорее всего, преждевременна.
7.Microsoft RTC Client API предлагает дополнительные функции, как совместно используемые приложения. Похоже, они могут быть реализованы только с SIP сервером от Microsoft Live Communications Server 2003 или Microsoft Office Live 2005 Standard Edition (поставляется с клиентами).
8.Выход на сети стационарной и мобильной голосовой связи. На самом деле, так как современные АТС поддерживают SIP, это становится больше проблемой нумерации и владения зонами и пулами в них, нежели определяется высокой стоимостью аппаратных средств для стыковки с ним по модемам, линиям T1 или IDSN. Это область мини-АТС (имея в виду приземление внутри зон). Некоторые мини-АТС имеют порты для SIP и аналоговых телефонных линий, а также WiFi точки доступа. Многие компании продолжают использовать факсимильную связь, и этим аппаратам не хватает функции fax->email. Для мини-АТС с SIP можно считать характерным сложность инициации сессий в случае, если он расположен за файрволом Интернет провайдера, что дает преимущество ISP и SIP серверам на выделенных серверах. Такие функции могут оказаться востребованными и в клиентах через серверы провайдера IP телефонии (как факс шлюзы).
Заключение
С точки зрения пользователя, на мой взгляд, в Windows клиенте должны быть реализованы утилитарные функции:
1.Большие красные кнопки “Позвонить в офис”, где только возможно (опять же, это всего лишь .lnk файлы – но ими всеми нужно управлять: исправлять адреса, рассыпать в меню и на рабочем столе)
2.Исследовать возможность функции “коротких” звонков, переносящая концепции IM. Например, нажав кнопку абонента, говорим, пока удерживаем ее. Отпускаем кнопку – разрыв соединения. Удобна, например, для внутриофисных переговоров. Но при первом опыте, такая концепция пользователем не воспринимается с ходу.
3.История звонков
4.Интеграция с Active Directory и LDAP
5.Взаимодействие с указанными аппаратными телефонами
6.Проталкивание контента. Например, в момент разговора можно открыть IM сессию и передать абоненту прайс-лист.

Продвинутая или наоборот “облегченная” версия может иметь функции для контроля за звонками сотрудников со стороны менеджмента.
Больше внимания должно быть уделено “красивости” в смысле брэндовости SIP оператора.
Имеется макет приложения, использующего Microsoft RTC Client API через wrapper для Delphi, макеты для интеграции с MSIE.

Примеры кодирования URI десятичными цифрами

Filed under: Technical notes — admin @ 6:58 pm

Примеры кодирования URI десятичными цифрами
Статус документа

Это приложение к документу «Кодирование URI десятичными цифрами» содержит несколько примеров, поясняющих причины выбора тех или иных способов кодирования URI десятичными цифрами.

Авторские права

Copyright (C) Андрей Иванов (2006-2007). Все права зарезервированы.

Реферат

Документ обсуждает реализацию трансляции доменных имен (DNS) и универсальных идентификаторов ресурсов Интернет (URI) в последовательности десятичных цифр для обеспечения простого ввода на номеронабирателях коммуникационных устройств и декодирование этих последовательностей в URI.

Содержание
Содержание 1
1. Хэш 1
1.1 Прямой хэш 1
1.2 Инвертированный хэш 2
1.3 Укорачивание номеров 2
2. Ключ 2
3. Реализации алгоритма 3
1. Хэш
1.1 Прямой хэш
Хэш- это цифры, получаемые при нажатии клавиш номеронабирателя с соответствующими буквами.
Недостающие символы вводятся клавишей «0».

Адрес
Хэш
corwin@amber.ru
267946 0 26237 0 78
corwin@rebma.ru
267946 0 73262 0 78

corwin@amber.com
267946 0 26237 0 266
corwin@rebma.com
267946 0 73262 0 266

random@amber.com
726366 0 73262 0 266

Прямой хэш рекомендуется записывать обязательно с буквенной расшифровкой:
там, где это возможно, в виде графических изображений кнопок;
где это невозможно, указывать только адрес и не указывать хэш;
также в отдельных случаях можно указывать инвертированный хэш с ключом (п. 1.2).
1.2 Инвертированный хэш
Инвертированный хэш используется в случае, когда предпочтительнее не указывать адрес. Такими случаями могут быть:
малая информативность адреса;
отсутствие буквенных надписей на клавиатурах;
отсутствие навыка набора буквами;
Инвертированный хэш рекомендуется для записи в телефонных справочниках.
При передаче адреса абоненту рекомендуется:
при возможности передачи текста передать адрес и ключ;
при передаче голосом рекомендуется передавать инвертированный хэш и ключ.

Адрес
Инвертированный хэш (с «0» начала ключа)
corwin@amber.ru
780 262370 2679460
corwin@rebma.ru
780 732620 2679460

corwin@amber.com
2660 262370 2679460
corwin@rebma.com
2660 732620 2679460

random@amber.com
2660 262370 7263660

В таблице показано, что цифры инвертированного хеша удобно собирать в группы, оканчивающиеся “0”.
Как видно из примеров, инвертированный хеш для домена .ru начинается с 780. Для домена .com начало – 2660.
1.3 Укорачивание номеров
В справочнике номеров для одного домена первые цифры не меняются, и, если дописывается DNS суффикс в пределах сети, где распространяется справочник, то хеш можно укоротить (отбросить 780 для домена .ru и 2602370 для домена amber, например). Соответственно, укорачивается и ключ. При передаче инвертированного хэша с ключом за пределы сети нужно дополнить адрес до полного доменного имени.
2. Ключ
Ключ всегда начинается с «0» или «1». «0» используется в случае, когда указывается инвертированный хеш. Это позволяет сделать инвертированный хеш «более красивым». В случае прямого хэша это не имеет значения, поэтому для него выбрано начала ключа «1».
Ключ не содержит, кроме начала, цифр «1» и «0». Это сделано для того, чтобы ключ заменить на слово (слова), состоящее только из букв – клавиши «1» т «0» на номеронабирателе не имеют букв- эквивалентов.

Адрес
Ключ
corwin@amber.ru
1 724 5348 62623
corwin@rebma.ru
1 724 8468 62623

corwin@amber.com
1 623 3675 42422
corwin@rebma.com
1 623 5345 42422

random@amber.com
1 623 3674 63343
random@rebma.com
1 623 5344 63343

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

На практике не для всех ключей можно подобрать подходящие (желаемые) слова-эквиваленты.

3. Реализации алгоритма

Алгоритм может быть реализован в коде SIP сервера, DNS сервера.

Кодирование URI десятичными цифрами

Filed under: Technical notes — admin @ 6:57 pm

Кодирование URI десятичными цифрами
Статус документа

Этот документ предлагает стандарт Интернет сообществу, и является запросом обсуждения и подачи замечаний. Пожалуйста, обращайтесь к текущей версии “Internet Official Protocol Standards” (STD 1) для получения статуса этого документа.
Документ соответствует требованиям пункта 10 RFC2026 [1].
Распространение этого документа не ограничено.

Авторские права

Copyright (C) Андрей Иванов (2006-2007). Все права зарезервированы.

Реферат

Документ обсуждает трансляцию доменных имен (DNS) и универсальных идентификаторов ресурсов Интернет (URI) в последовательности десятичных цифр для обеспечения простого ввода на номеронабирателях коммуникационных устройств и декодирование этих последовательностей в URI.

Содержание
Содержание 1
1. Введение 2
1.1. Термины 2
2. Проблема 2
3. Назначение 3
3.1. Сценарий 1 3
3.2. Сценарий 2 3
3.3. Сценарий 3 3
3.4. Сценарий 4 4
4. Области применения 4
5. Кодирование 4
5.1. Хеш 4
5.2. Ключ 5
5.3. Процедура инверсии адреса 5
5.4. Кодирование позиции буквы на клавише 6
5.5. Примеры 7
5.6. Замечание для случая нулевого ключа 8
5.7. Расширение 8
5.8. Номер сервиса 8
5.9. Запись 8
6. Предварительно инвертированный адрес 8
7. Декодирование 9
7.1. Определение, является ли число номером сервиса 9
7.2. Удаление расширения 9
7.3. Определение начала ключа 9
8. Кодировки 10
8.1. Регистр букв адреса 10
8.2. Национальные кодировки в адресе 10
8.3. Кодирование специальных символов 10
9. Поиск в адресных книгах 10
9.1. Приложения адресных книг 10
9.2. Иерархия адресных книг 10
9.3. Запоминание новых Хешей и Ключей 11
9.4. Коллизии хеша 11
10. Безопасность 11
11. Благодарности 11
12. Нормирующие документы 11
1. Введение
Документ описывает алгоритм кодирования доменных имен, идентификаторов ресурсов Интернет (URI) десятичными цифрами, который может использоваться для ввода человеком на номеронабирателях телефонов и других устройств.
Данный алгоритм в первую очередь предназначен для использования в VoIP приложениях, в частности, использующих SIP [4].
1.1. Термины
Слова “ДОЛЖНО”, “ТРЕБУЕТСЯ”, “БУДЕТ”, “РЕКОМЕНДОВАНО” и “МОЖЕТ”, встречаемые в этом документе должны интерпретироваться, как описано в RFC 2119 [2].
2. Проблема
Установление соединения, когда Инициатор использует обычный телефонный аппарат, снабженный 10 или 12 клавишным номеронабирателем (рис. 1), в частности, подключенный к традиционной телефонной сети, а вызываемый абонент - компьютер или IP-телефон, соединенный с Internet или частной IP сетью, сопряжено со сложностью, вызванной применением разных схем адресации:
в общедоступных телефонных сетях на основе стандарта E.164;
в Интернет на основе системы имен DNS.
В таком случае Инициатор должен определенным образом транслировать вводимую последовательность цифр с помощью номеронабирателя в адрес с использованием системы имен DNS.
Таким адресом в документе считается универсальный идентификатор ресурсов Интернет, описанный в RFC 3761 [3], хотя в общем случае допускается кодирование любой текстовой или бинарной последовательности.
[...]
Рисунок 1. Номеронабиратель.

В известных решениях – ENUM [5] и DUNDi [6] требуются дополнительные элементы, хранящие информацию для трансляции вводимого номера и адреса, в частности, отдельные системы хранения и поиска номеров телефонов.
Этот документ предлагает способ трансляции последовательности десятичных цифр на номеронабирателях “обычных” и IP телефонов в идентификаторы ресурсов Интернет без необходимости дополнительных элементов, называемый кодированием.
Принципиально кодирование состоит из двух шагов:
ввода адреса на номеронабирателе, Пользователь нажимает клавиши с соответствующими надписями; далее в документе полученная последовательность цифр называется Хешем;
добавлении к хешу последовательности цифр, приблизительно в два раза короче адреса, называемой Ключом.
Ключ должен либо вводиться Пользователем, либо устройство может пытаться восстановить ключ по Хешу, используя словари, называемые в документе Адресными книгами.
Получаемая последовательность цифр называется Интернет кодом сервиса, и она не является ни глобальным номером в стандарте E.164, ни локальным номером.
3. Назначение
В первую очередь кодирование предназначено для набора URL на номеронабирателях телефонов.
В общем же, описываемый алгоритм предназначен для кодирования последовательностей алфавитно-цифровых символов десятичными цифрами и декодирования кода обратно в последовательность алфавитно-цифровых символов.
Представлено несколько сценариев того, как может использоваться описанное кодирование (пункт 5) и декодирование (пункт 7).
3.1. Сценарий 1
Пользователь bob@commandus.com на IP телефоне нажимает кнопки с буквами:

2 5 4 2 3
a l i c e
и соединяется с alice@commandus.com
3.2. Сценарий 2
Пользователь carol@atlanta.com ранее звонила alice@commandus.com и на IP телефоне нажимает кнопки с буквами:

2 5 4 2 3 0 2 6 6 6 2 6 3 8 7 0 2 6 6
a l i c e @ c o m m a n d u s . c o m

и соединяется с alice@commandus.com через свой SIP proxy сервер.
3.3. Сценарий 3
Пользователь carol@atlanta.com нашла в списке адресов bob и первый раз звонит bob@commandus.com, и на IP телефоне нажимает кнопки с буквами:

2 6 2 0 2 6 6 6 2 6 3 8 7 0 2 6 6
b o b @ c o m m a n d u s . c o m
В ответ на запрос телефона, Carol затем вводит ключ:
1 1512622351721
и соединяется с bob@commandus.com через свой SIP proxy.
Последующие звонки Carol делает как в сценарии 3 (пункт 3.3)
2 6 2 0 2 6 6 6 2 6 3 8 7 0 2 6 6
b o b @ c o m m a n d u s . c o m
3.4. Сценарий 4
Пользователь carol@atlanta.com получила по почте другой список:
bob@commandus.com - 26602666263870262 0 1512622351721
alice@commandus.com – 2660266626387025423 0 51262235162333
Спросив Alice, почему ее номер телефона изменился, Carol получила ответ, что оба номера являются одинаково правильными.
4. Области применения
Из-за особенностей описываемого алгоритма, алгоритм наиболее эффективно может применяться в интерактивных системах “человек-машина”, снабженных номеронабирателем
Типичным применением является ввод цифровым кодом URI, в частности:
SIP адресов IP телефонии [4];
адресов почтовых и голосовых ящиков, рассылок и групп пользователей;
адресов других Интернет сервисов и ресурсов, например, веб ресурсов
Пользователем на номеронабирателе (рис. 1).
Типичные реализации алгоритма:
в носимых устройствах мобильной связи;
на коммутаторах мобильной, стационарной и другой связи;
на серверах VoIP телефонии
должны позволять декодировать код в адреса.
Алгоритм оптимизирован для кодирования адресов ресурсов Интернет и также рекомендуется как генератор “глобальных” номеров VoIP телефонов (кодирование).
Обратно, описанный алгоритм делает однозначное преобразование “глобальных” номеров VoIP телефонов (декодирование) в адреса, например, адреса SIP телефонов.
Также алгоритм подходит для штрихового кодирования, где применяются десятичное представление. Алгоритм также позволяет кодировать и декодировать любую информацию, как бинарную, так и представленную в различных кодировках.
5. Кодирование
5.1. Хеш
Для кодирования символов латинского алфавита и цифр от “0″ до “9″, а также нескольких символов пунктуации используется таблица 1, составленная в соответствии с рисунком 1:
Таблица 1. Начальные коды символов латиницы
Символы
Код
“1″
1
“a”, “b”, “c”, “2″
2
“d”, “e”, “f”, “3″
3
“g”, “h”, “i”, “4″
4
“j”, “k”, “l”, “5″
5
“m”, “n”, “o”, “6″
6
“p”, “q”, “r”, “s”, “-”, “/”, “:”, “7″
7
“t”, “u”, “v”, “8″
8
“w”, “x”, “y”, “z”, “_”, “?”, “&”, “9″
9
“.”, “@”, “%”, “0″
0
Например, для адреса:
alice@commandus.com
код начинается с:
2542302666263870266
что называется Хешем адреса.
Синтаксис Хеша определяется в форме Бэкуса-Наура (BNF) в соответствии с RFC-2234 [7]:
hash = {”0″..”9″}
Пользователь на номеронабирателе нажимает клавиши, имеющие соответствующие надписи, а вместо недостающих символов “@” и “.” нажимает клавишу “0″. Делая предположение, что имена запоминаются легче, чем номера, Пользователю не будет слишком сложно ввести последовательность цифр такой длины.
Кроме того, Пользователь может ввести неполный адрес, например:
alice
хеш:
25423
Хеш сам не может быть однозначно преобразован в адрес. Для этого необходима дополнительная информация, называемая Ключом. Ключ может быть введен Пользователем сразу в момент ввода после Хеша, либо устройство, на котором произведен ввод, МОЖЕТ попытаться найти в своей памяти или инициировать поиск в другом месте подходящих адресов. Поиск в адресных книгах описан в пункте 9.
В результате удачного поиска Хеш ДОЛЖЕН дополняться ключом. Если поиск не дал результатов, Пользователь должен самостоятельно ввести ключ.
Допускается и иной порядок формирования Хеша, с предварительно инвертированным адресом, который рассматривается отдельно.
5.2. Ключ
Ключ содержит информацию, необходимую того, чтобы Хеш мог быть однозначно преобразован в адрес.
key:= “1″|”0″ space {”0″..”7″}
Ключ всегда начинается с символа “1″ или “0″. Символ “0″ используется для предварительно инвертированных адресов (см. пункт 6), иначе используется “1″. Назначение инвертированных адресов поясняется ниже. Символ пробела введен для того, чтобы при записи визуально разделить группы цифр.
Далее делается инверсия адреса.
5.3. Процедура инверсии адреса
Для инверсии адреса делается следующее:
В хеше находятся символы “0″, что соответствует символам “.”, “@”, “,”, “0″ в строке адреса
По найденным позициям выделяются слова, не включая символы “.”, “@”, “,”, “0″. Эти символы составляют самостоятельные слова.
Слова копируются в обратном порядке в строку “инвертированного” адреса
Эти шаги описывают инверсию адреса, и для предварительно инвертированного адреса пропускаются.
Например, в
alice@commandus.com
выделяются слова
“alice” “@” “commandus” “.” “com”
и, поменяв порядок следования слов, адрес преобразуется в:
com.commandus@alice
Это называется инвертированным адресом. Для построения ключа используется не инвертированный адрес (так как ключ инвертирует символы).
5.4. Кодирование позиции буквы на клавише
Далее Ключ составляется из цифр “0″..”7″ следующим образом.
Для каждого символа кодируемой последовательности символов в таблице 2 определяется занимаемое число бит. Для разных символов число бит разное. Для символа “1″ число бит равно 0. Для большинства остальных символов число занимаемых бит равно 2, и некоторые требуют 3 бита.
Далее, в той же таблице для каждого символа определяется номер позиции.
Как видно на рисунке 1, номер позиции означает, какая по счету это буква на клавише, но не во всех случаях.
Этот номер кодируется 2 или 3 битами (кроме случая символа “1″, который не требует кодирования). Эти биты копируются в заранее обнуленный битовый вектор достаточного размера так, чтобы первый символ кодируемой последовательности символов занимал младший адрес, а последний – старший адрес. Как минимум, размер вектора для адреса должен быть не меньше 16 октетов.

Например:
alice
хеш:
25423
вектор:
e c i l a
01 00 10 10 01
MSB LSB
Затем битовый вектор будет преобразовываться в его восьмеричное представление.
Определяем самый старший значимый бит – бит 8. Нулевые значения старших разрядов не кодируются. Заметим, что бит 8 также является старшим битом в триаде:
100 101 001
MSB LSB
Затем адрес нужно выровнять на триаду так, чтобы номер старшего значимого бита был кратен 3 (2, 5, 8…). Для этого в вектор в младшие адреса добавляется от 2 до 4 бит. Так как триады уже выровнены, нужно добавить три бита.
Младшие два бита указывают на количество выравнивающих старших битов.
0…0 L L
MSB LSB
Целью выравнивания является сделать так, чтобы выровнять на триаду слово. В примере
выше нужен 1 дополнительный выравнивающий бит, с учетом 2 бит длины, тогда нужно добавить биты 001:
100 101 001 001
MSB LSB
Наконец, каждый триплет преобразуем в восьмеричную цифру (с использованием символов, начиная с «1»: «1»…«9», а не «0»… «7»), получаем:
5622
Таблица 2. Коды позиций символов латиницы
0
1
2
3
4
5
6
7
Число бит
1

0
C
A
B
2

2
D
E
F
3

2
G
H
I
4

2
J
K
L
5

2
O
M
N
6

2
P
Q
R
S
-
7
/
:
3
T
U
V
8

2
W
X
Y
Z
_
9
?
&
3
.
@
%
0

2
5.5. Примеры
Рассмотрим пример с разбиением адреса на слова. Например, для адреса:
alice@commandus.com
хеш:
2542302666263870266
вектор:
m o c . s u d n a m m o c @ e c i l a
01 00 00 00 011 01 00 10 01 01 01 00 00 01 01 00 10 10 01
MSB LSB
Выравнивающие биты:
38 значимых бит в ключе, для выравнивания нужен 1 бит, но число выравнивающих бит должно быть не меньше 2, поэтому нужно 4 бита. Выравнивающие биты:
0010
C учетом выравнивающих бит триплеты:
100 000 001 101 001 001 010 100 000 101 001 010 010 010
Ключ:
1 51262235162333
Хеш с Ключом:
2542302666263870266 1 51262235162333
Другой пример адреса:
bob@commandus.com
Хеш:
26202666263870266
вектор:
c o m . s u d n a m m o c @ b o b
01 00 00 00 011 01 00 10 01 01 01 00 00 01 10 00 10
MSB LSB
Выравнивающие биты:
34 бит в ключе, достаточно 2 бит, следовательно, выравнивающие биты:
001
C учетом выравнивающих бит триплеты:
100 000 001 010 110 000 101 101 100 010 001
MSB LSB
Ключ:
1 1512622351721
хеш с ключом:
26202666263870266 1 1512622351721
Сравнивая теперь ключи
bob@commandus.com - 1 1512622351721
alice@commandus.com – 1 51262235162333
видно, что выравнивание на триаду позволило достичь того, что однодоменные имена имеют одинаковое начало ключа.
5.6. Замечание для случая нулевого ключа
В случае если вычисленный ключ равен 0, он все равно указывается:
8 space 0
или
9 space 0
для инвертированного адреса.
5.7. Расширение
Для некоторых адресов Хеш и Ключ вместе составляют последовательность цифр, короче 16 символов и, чтобы отличать их от “локальных” номеров и от “глобальных” номеров стандарта E.164 [5], в таком случае в конце последовательности должны быть добавлены цифры “9″, так чтобы число цифр стало равно 16.
extension:= {”9″}
Для локальных адресов расширение может выравнивать номер телефона, но общее число цифр может быть меньше 16.
5.8. Номер сервиса
Формат номера сервиса:
service_number:= address|hash space [key] [extension]
5.9. Запись
Хеш и Ключ вместе составляют последовательность цифр, которую Пользователь набирает на номеронабирателе. Эта последовательность записывается в следующем виде:
record:= “ics:” serviceNumber
Например:
ics:bob@commandus.com 8 40126055421
(первая форма записи). ICS – это аббревиатура Internet Code of Service.
Допускается запись и во второй форме:
ics:26202666263870266 8 40126055421
При такой записи, однако, рекомендуется использовать предварительно инвертированный адрес (см. пункт 6).
6. Предварительно инвертированный адрес
Например, для адреса:
alice@commandus.com
инвертированный адрес получается обратной перестановкой слов:
com.commandus@Alice
и хеш его начинается с:
2660266626387025423
Для адреса
bob@commandus.com
Хеш будет:
26602666263870262
В инвертированном адресе Хеш начинается с одной и той же последовательности цифр, где 2660 - .com, 2666263870 – commandus, что делает его удобным для записи во второй форме.
7. Декодирование
7.1. Определение, является ли число номером сервиса
Если длина номера больше или равно 16, введенный номер является номером сервиса. Или устройство, инициирующее вызов (SIP телефон), или коммутатор вызывающей стороны должны декодировать номер сервиса в адрес.
Так как в декодированном адресе может отсутствовать имя протокола, телефон или коммутатор должны назначить протокол в соответствии с собственными правилами. Например, для,
bob@commandus.com
может быть назначен протокол SIP:
sip:bob@commandus.com
Хотя в номере сервиса может быть закодирован протокол, а также другая информация, рекомендуется по возможности сокращать длину строки адреса. Это позволит использовать один номер сервиса для нескольких протоколов:
sip:bob@commandus.com
mailto:bob@commandus.com
http://bob@commandus.com/
ftp://bob@commandus.com/
Соответствующее устройство может предлагать выбирать желаемые протоколы.
По умолчанию РЕКОМЕНДУЕТСЯ использовать протокол SIP.
7.2. Удаление расширения
Если в конце номера сервиса есть символы “9″, они удаляются.
7.3. Определение начала ключа
Декодирование начинается с определения начала ключа. Для этого надо начать искать с конца символ ‘8’ или ‘9’
26202666263870266 8 401511240610
Здесь используется то, что Ключ содержит только символы “0″ .. “7″.
Ключ:
8 401511240610
Символ начала Ключа ‘8’ удаляется.
Так как символ начала ключа был ‘8’, а не ‘9’, адрес не был предварительно инвертирован, поэтому выполняем инверсию адреса.
Выделяем в Хеше:
26202666263870266
символы “0″ (символы 0 также считаются хешами отдельных слов):
262 0 266626387 0 266
и копируем разделяемые ими слова в строку в обратном порядке:
266 0 266626387 0 262
Если бы символ начала ключа был ‘9’, адрес был предварительно инвертирован, и инвертировать адрес не надо было бы.
Определяем по младшим двум битам ключа количество дополнительных выравнивающих бит – 1. Сдвигаем вправо на 3 бита выравнивания ключ, удаляя один дополнительный и два бита длины выравнивания.
Теперь последовательно для каждого символа инвертированного хеша выделяем битовыми масками нужные биты ключа (количество бит дано в таблице 2), и по этой же таблице определяем символ. Получается:
com.commandus@bob
Теперь остается переставить слова еще один раз. Получается:
bob@commandus.com
Так как символ начала ключа был ‘8’, а не “9″, это был не предварительно инвертированный адрес, поэтому была нужна еще одна пересатновка.
8. Кодировки
8.1. Регистр букв адреса
Буквы адреса считаются находящимися в нижнем регистре. Если требуется вводить буквы в верхнем регистре, они должны быть закодированы, как специальные символы (пункт 8.3).
8.2. Национальные кодировки в адресе
Символы в кодировках, отличных от латиницы должны быть закодированы, как специальные символы (пункт 8.3).
8.3. Кодирование специальных символов
Адрес может содержать символы латиницы, не перечисленные в таблице 1, специальные символы и символы в Unicode. Такие символы ДОЛЖНЫ быть закодированы символами латиницы, как требует RFC 2396 [3], например:
%20 - символ пробела
%u20AC - знак евро
9. Поиск в адресных книгах
Поиск в адресных книгах имеет целью:
дополнить адрес (как в примере выше, добавить домен @commandus.com к alice), как показано в сценариях 1 и 2 (пункты 3.1 и 3.2);
устранить неоднозначность Хеша без ввода Ключа.
Поиск в адресных книгах является необязательным.
9.1. Приложения адресных книг
Адресными книгами могут быть процедуры, приложения и сетевые ресурсы, использующие следующие источники адресов:
директории LDAP сервера;
DNS серверы, в том числе реализующие получение доменных имен для телефонных номеров E.164, как регламентировано в RFC 3761 [5];
DNS кэш устройства или заданного компьютера;
Специальные приложения, например, использующие историю посещений веб страниц браузера Интернет, или собранные адреса SIP шлюза, e-mail почтовой клиентской или серверной программ, прокси серверов и шлюзов, или отображаемые в данный момент в приложении (браузере) SIP и другие Интернет адреса.
9.2. Иерархия адресных книг
Адресных книг может быть больше одного. Поиск осуществляется последовательно в адресных книгах в определенном порядке, задаваемым списком адресных книг. Устройство МОЖЕТ хранить у себя или во внешних сервисах несколько списков адресных книг, Пользователь или устройство автоматически условно или, безусловно, могут переключать списки.
Только один список может применяться в каждый данный момент времени.
Если ни в одной из адресных книг, перечисленных в списке, вхождения не найдены, это НЕ является условием переключения списков.
Рекомендуется по умолчанию начинать поиск в адресной книге самого устройства, затем во внешних адресных книгах.
Пользователь или устройство автоматически могут удалять и подключать новые адресные книги, и если нельзя определить иначе, по умолчанию новая адресная книга ДОЛЖНА подключаться к концу текущего списка адресных книг.
Устройство или приложение вычисляет хеш адресов из адресной книги, используя табл. 1, затем ищет вхождения введенного начала кода как подстроки в вычисленных хешах для записей адресной книги.
Если обнаружено одно вхождение введенного хеша с вычисленными хешами в одной адресной книге, Устройство ДОЛЖНО использовать адрес из адресной книги.
Если обнаружено несколько совпадений введенного Хеша с вычисленными хешами для одной адресной книги, Устройство ДОЛЖНО вычислить весовые коэффициенты для вхождений, отсортировать полученные адреса по весу, затем предложить выбрать из полученного списка Пользователю нужный адрес.
9.3. Запоминание новых Хешей и Ключей
Если хеш не найден ни в одной из адресных книг, Пользователь должен продолжить ввод – ввести ключ.
Адресная книга нижнего уровня должна запомнить хеш и ключ с тем, чтобы в следующий раз пользователь мог избежать ввода ключа. При этом должен быть реализован какой либо механизм удаления неиспользуемых Хешей и Ключей.
9.4. Коллизии хеша
В случае если Хеш в адресной книге одинаков для нескольких записей, Пользователю должно быть предложено выбрать из списка нужную запись, если этот список короче 10 записей. Если адресная книга содержит 10 или более записей с таким же Хешем, Пользователю МОЖЕТ быть предложено ввести ключ.
10. Безопасность
Нет требований по безопасности, указанных в пункте 7 RFC 2327.
11. Благодарности
Автор благодарит людей, оказавших помощь в создании документа.
12. Нормирующие документы
1.Bradner, S., “The Internet Standards Process — Revision 3″, BCP 9, RFC 2026, October 1996.
2.Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
3.Berners-Lee, T., Fielding, R.T. and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax”, RFC 2396, August 1998. Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)”, RFC 3761, April 2004.
4.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.
5.Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)”, RFC 3761, April 2004.
6.Marc Spencer. Distributed Universal Number Discovery (DUNDi), October 2004.
7.Crocker, D. and Overell, P.(Editors), “Augmented BNF for Syntax Specifications: ABNF”, RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997.

Адрес автора
Andrei Ivanov
Commandus software development group
Petrovskogo street 2, Yakutsk, Republic Sakha, Russian Federation
email: support@commandus.com
http://commandus.com/

URI to decimal number translation

Filed under: Technical notes — admin @ 6:55 pm

URI to decimal number translation

Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the “Internet Official Protocol Standards” (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2006). All Rights Reserved.

Abstract

This document discusses the translation of the Domain Name System (DNS) names and Unified Resource Locators (URI) into sequence of decimal digits (decimal number) for easy input by user at the numeric keypad.

Table of contents
Table of contents 1
1. Introduction 2
1.1. Terminology 2
2. Problem 2
3. Purpose 3
3.1. Scenario 1 3
3.2. Scenario 2 3
3.3. Scenario 3 3
3.4. Scenario 4 4
4. Intended usage 4
5. Encoding 4
5.1. Hash 4
5.2. Key 5
5.3. Address inversion 5
5.4. Encoding symbol position 5
5.5. Examples 6
5.6. Zero Key case 7
5.8. Extension 7
5.9. Service number 7
5.10. Representation 8
6. Pre-inverted address 8
7. Decoding 8
7.1. Is decimal number a Internet Code of Service 8
7.2. Extension truncation 8
7.3. Key start position 8
8. Special symbols 9
8.1. Lowercase 9
8.2. National codepages 9
8.3. Special symbols encoding 9
9. Searching in address books 9
9.1. Address book applications 9
9.2. Hierarchy of address books 10
9.2. Adding new hashes and keys to the address book 10
9.3. Collisions in hash table 10
10. Full Copyright Statement 10
11. Acknowledgment 10
12. References 10
1. Introduction
This document provides an algorithm of encoding Internet domain names and Uniform Resource Identifiers (URI) [6] into sequence of decimal digits (decimal numbers).
Specifically this document aims to enhance translation of dial numbers to SIP [1] telephone address that allows users to dial URI from numeric keypad directly bypassing referring to the telephone number directories.
1.1. Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 [7].
2. Problem
Users often use telephone devices with numeric keypad shown in Figure 1 and users like use traditional telephone numbers. SIP phone and any other Internet device in contrast use URI addresses and callers must provide more complicated address than telephone number.
To simplify dialing, SIP server uses directory of local telephone numbers and refer to external directory of global telephone numbers therefore dialed numbers translated to other telephone numbers or Internet address.
A lot of addresses can not be found in such directories. Modern communication devices and SIP soft phones are reachable in the Internet but are simply not listed in directories which are in use.
+—–+ +—–+ +—–+
| 1 | | 2 | | 3 |
| | | abc | | def |
+—–+ +—–+ +—–+

+—–+ +—–+ +—–+
| 4 | | 5 | | 6 |
| ghi | | jkl | | mno |
+—–+ +—–+ +—–+

+—–+ +—–+ +—–+
| 7 | | 8 | | 9 |
|pqrs | | tuv | | wxyz|
+—–+ +—–+ +—–+

+—–+
| 0 |
| |
+—–+

Figure 1. Numeric keypad.

Most known solutions are ENUM [2] and DUNDi [3] based on directory concept.
This memo offer direct translation of sequence of decimal numbers into URI without usage of any sort of directories. It means the resulting encoded sequence can be decoded back to the URI without any additional information.
There are two main steps of encoding:
Entering URI. User press buttons with letters and digits figured on face of button; this sequence of digits named a “Hash”;
Adding sequence of decimal digits about two times shorter than Hash, this sequence of digits named a “Key”
Key must be entered by User or, more preferable, device or SIP server can try recovering Key by searching stored keys in hash table stored in the device, SIP server or in other device in the network environment. Hash tables named Address Books.
Combination of Hash and Key sequences named Internet Code of Service (ICS). This code is not global E.164 telephone number or local number because it is not listed in the directory.
3. Purpose
Encoding described in this memo is intended for entering URI using numeric keypads.
It is possible to enter any textual or binary information, not URI only, but this memo is not discusses that.
There are some scenarios of encoding SIP addresses described below in this section.
Section 5 describes encoding, section 7 describes decoding.
3.1. Scenario 1
User bob@commandus.com would like place a call to Alice. He presses buttons:
2 5 4 2 3
a l i c e
Bob’s soft phone found one hash “25423” in the memory thanks Bob placed call to Alice earlier. Soft phone add a key and send combination of them (ICS), to the SIP server. SIP server find out that entered sequence of digits is not a local or global E.164 telephone number and decode ICS to the address: alice. Then SIP server routes a call to the Alice’s telephone.
3.2. Scenario 2
User carol@atlanta.com placed a call to Alice at address alice@commandus.com a week ago. Carol would like place a call again. She presses letters of URI at the numeric keypad:

2 5 4 2 3 0 2 6 6 6 2 6 3 8 7 0 2 6 6
a l i c e @ c o m m a n d u s . c o m

She is outside of commandus.com domain therefore she must add a destination domain at least. She skips entering a Key.
3.3. Scenario 3
User carol@atlanta.com would like to place a call to Bob’s telephone bob@commandus.com first time:

2 6 2 0 2 6 6 6 2 6 3 8 7 0 2 6 6
b o b @ c o m m a n d u s . c o m
Telephone asking her for a Key, Carol enters a key:
1 1512622351721
Later Carol place a call without key requests (as described in Section 3.3)
2 6 2 0 2 6 6 6 2 6 3 8 7 0 2 6 6
b o b @ c o m m a n d u s . c o m
3.4. Scenario 4
User carol@atlanta.com receives from alice@commandus.com a telephone number list by e-mail:
bob@commandus.com - 26602666263870262 0 1512622351721
alice@commandus.com – 2660266626387025423 0 51262235162333
She asks Alice, why Alice’s telephone number was changed. Alice replied that number are valid both.
4. Intended usage
Typical application is telephone or other communication device; algorithm is responsible for coding URI, for instance:
SIP addresses [1] of VoIP telephones or SIP services;
e-mail and voice mail box addresses, user groups and conferences;
web resources.
Decoding algorithm can be implemented in such devices:
SIP servers,
number/address translation servers;
routers.
5. Encoding
Character sequence to be encoded MUST be represented by subset of Latin character set in accordance to RFC 2396 [6] as described in Section 8.3. This memo supposed that address encoded already.
5.1. Hash
Table 1 shows codes of Latin characters, digits from “0” to “9”, and some symbols of punctuation in accordance to the Figure 1:
Table 1. Codes of characters
Character
Code
“1”
1
“a”, “b”, “c”, “2”
2
“d”, “e”, “f”, “3”
3
“g”, “h”, “i”, “4”
4
“j”, “k”, “l”, “5”
5
“m”, “n”, “o”, “6”
6
“p”, “q”, “r”, “s”, “-”, “/”, “:”, “7”
7
“t”, “u”, “v”, “8”
8
“w”, “x”, “y”, “z”, “_”, “?”, “&”, “9”
9
“.”, “@”, “,”, “0”
0
For address:
alice@commandus.com
Hash would be:
2542302666263870266
The syntax of Hash is defined in an Extended Backus-Naur Formalism (EBNF):
hash = digit{digit}
digit = “0″|”1″|”2″|”3″|”4″|”5″|”6″|”7″|”8″|”9″
User MUST press buttons contains image of letter on face of button, and press “0” instead of “@” and “.” characters.
Supposing names is easy to remember in comparison to digits, User can enter Hash without any troubles.
In some cases it is possible to use much shorter addresses, like:
alice
Hash would be:
25423
Of course Hash can not be translated to the URI definitely. Additional information required to do translation clear named a Key. Device receives Hash can waiting for a Key to be entered by User or device can try initiate searching Key in Address Books that keeps addresses that User enter earlier, receives from other person or, for instance, just looking right now in the browser. Address Book searching is described in Section 9.
If Address Book searching gives positive result, device inform User that address is reconstructed and use that address to place a call.
5.2. Key
Key contains information how Hash must be reconstructed to the URI.
key = (“1”|”0”) space {“1”..”9”}
Key starts with “1” or “0”. Character “0” is used in case of pre-inverted addresses (purpose of such addresses discussed in Section 6), else “1” character is used. Space character is used for text formatting purposes only, similar to signs “+”, “-” and spaces are used in telephony numbers.
If address is not pre-inverted, do address inversion.
5.3. Address inversion
Address inversion starting with splitting address into words. Find delimiter characters: “.”, “@”, “,”, “0” (refers to “0” in Hash) in the address. Delimiter characters are words too.
All words (including delimiters) copy in backward order to the string of inverted address.
This procedure named address inversion. If address is pre-inverted, these steps a skipped.
For instance, address:
alice@commandus.com
consists of five words:
“alice” “@” “commandus” “.” “com”
and after reversing words, address would be:
com.commandus@alice
This address named inverted address. Key MUST BE constructed from non-address (key constructed with reversed symbols).
5.4. Encoding symbol position
Then key is constructed with “1” … “9” digits.
For each character of address determine required quantity of bits in the table 2. For different characters quantity of bits varied from 0 to 3.
Then for each character of address determine position code. Note that characters in address usually are lowercase therefore position code for ‘A’ and ‘a’ is the same. Otherwise refer to the Section 8.
Then bits of position code copy to the zero filled bits array. Quantity of bits to be copied is determined earlier. First character of encoded character sequence must occupy higher address. That array must have enough size or memory must be reallocated. At least 16 octets MUST be reserved.

For instance:
alice
Hash would be:
25423
And bit array would be:
e c i l a
01 00 10 10 01
MSB LSB
Non-significant zeroes MUST BE omitted. Now get bit array octal representation. Split array to triads:
100 101 001
MSB LSB
Now time to do a little trick with octal alignment. Alignment means adding from 2 to 5 alignment bits at the lowest address with left shifting.
Most significant bits MUST be bit 2, 5, 8… and occupy most significant bit in triad. Because sequence in example given is octal aligned already, three alignment bits must be added.
In alignment bits last two bits represents quantity of alignment bits, minus 2.
0…0 L L
MSB LSB
Two bits represent quantity of additional bits. These additional bits (if exists) are 0 always.
In shown example one additional bit to two bits of length is required so alignment bits are: 001 and bit array would be:
100 101 001 001
MSB LSB
Finally, each triplet converts to octal digit (plus 1, it means “0” replaced with “1”, “1” with “2” and so ones):
5622
The aim of octal alignment is avoid bit shifting for addresses in the same domain. Therefore Keys of addresses of the same domain starting with same sequence of digits.

Table 2. Symbol position codes
0
1
2
3
4
5
6
7
Quantity of bits
1

0
c
a
B
2

2
d
e
F
3

2
g
h
I
4

2
j
k
L
5

2
o
m
N
6

2
p
q
R
s
-
7
/
:
3
t
u
V
8

2
w
x
Y
z
_
9
?
&
3
.
@
,
0

2
5.5. Examples
Let see more examples. There is address consists of five words:
alice@commandus.com
Hash would be:
2542302666263870266
Bit array would be:
m o c . s u d n a m m o c @ e c i l a
01 00 00 00 011 01 00 10 01 01 01 00 00 01 01 00 10 10 01
MSB LSB
There are four alignment bits must be added:
0010
and bits array would be (rewrite significant bits in triads, starting with from most significant bit):
100 000 001 101 001 001 010 100 000 101 001 010 010 010
Key would be:
1 51262235162333
and ICS would be:
2542302666263870266 1 51262235162333

Another example of address:
bob@commandus.com
Hash would be:
26202666263870266
Bit array would be:
c o m . c o m m a n d u s @ b o b
00 00 01 00 00 00 01 01 01 10 00 01 011 01 10 00 10
MSB LSB
Rewrite significant bits in triads, starting with from most significant bit:
100 000 001 010 110 000 101 101 100 010
There are 3 alignment bits must be added (it is impossible add 0 alignment bits):
001
and bits array would be:
100 000 001 010 110 000 101 101 100 010 001
MSB LSB
Key would be:
1 1512622351721
ICS would be:
26202666263870266 1 1512622351721
Compare keys:
bob@commandus.com - 8 401511240610
alice@commandus.com – 8 40151124051222
Note octal alignment allows Keys starting with same sequence of digits.
5.6. Zero Key case
In case of calculated Key equals zero, this Key MUST represented as:
1 space 1
or
0 space 1
in case of pre-inverted address.
5.8. Extension
Some code sequences can be shorter than 16 characters. Anyway it is possible add any quantity of “0” characters at the end of ICS.
extension = {“0”}
By such alignment it is possible to provide easy way to separate ICS from local telephone numbers and global E.164 telephone numbers both.
5.9. Service number
Numeric format of Internet Code of Service is:
service_number = address|hash space key [extension]
5.10. Representation
Numeric format of Internet Code of Service (ICS) must be represented as:
representation = “ics:” serviceNumber
For instance:
ics:bob@commandus.com 1 1512622351721
It is first representation form.
There is second representation form:
ics:26602666263870262 0 1512622351721
In this form usage of pre-inverted address is recommended (see Section 6).
6. Pre-inverted address
For address:
alice@commandus.com
inverted address would be:
com.commandus@alice
as explained in Section 5.2 and Hash would be:
2660266626387025423
For address
bob@commandus.com
Hash (after inversion of address) would be:
26602666263870262
Hash of inverted address starting with same digits for identical domains:
266 is hash for ‘.com’,
266626387 is hash for ‘commandus’
In case of address is inverted Key must starts with ‘9’ character not ‘8’.
7. Decoding
7.1. Is decimal number a Internet Code of Service
If length of digit sequence is 16 or more, it is ICS. If digit sequence is shorter than 16 characters, SIP server MUST try to search telephone number in his directory first, if no occurrences found, it is ICS. Device such as SIP server must decode ICS to the address.
Decoded address can not contain name of desired protocol. Device can assign default protocol. It is recommended to use ‘sip’ protocol as default. For instance,
bob@commandus.com
would be expanded to:
sip:bob@commandus.com
It is recommended to avoid protocol name from the address.
7.2. Extension truncation
If code sequence contains “9” at the end, they must be removed.
7.3. Key start position
Decoding itself start from finding key start position. From the end of sequence find out first ‘8’ or ‘9’ digits:
26202666263870266 8 40151124051222
Note key consists of “0” … “7″ characters in body of the Key and starts from ‘8’ or ‘9’.
Key is:
8 40151124051222
Remove character ‘8’ from the beginning of Key.
Remember that it was ‘8’ not ‘9’ meaning address is not pre-inverted.
Address was not pre-inverted, so do address inversion.
Find out in Hash “0” characters occurrences
26202666263870266
and split hash into separate words:
262 0 266626387 0 266
Copy separated Hash words to the string in backward order:
266 0 266626387 0 262
Address inversion done.
Looking at two lowest bits in the Key – it represents quantity of additional octal alignment bits – 1.
Shift the Key 3 bits right.
Then for each character in the Hash find out corresponding bits in the Key using Table 2 and recover address:
com.commandus@bob
Then do address inversion again:
bob@commandus.com
Address restored.
8. Special symbols
8.1. Lowercase
Address often is not case sensitive; in most cases address consists of characters in lower case. In case of address contains uppercase characters, such characters MUST be encoded as described in Section 8.3 as special symbols.
8.2. National codepages
Non Latin characters MUST be encoded as described in Section 8.3 as special symbols.
8.3. Special symbols encoding
Address may contain Latin characters not listed in Table 1, special characters, characters of national code pages. Any of these characters MUST be encoded in accordance to RFC 2396 [6].
For instance:
%20 - space character
%u20AC - Euro sign
9. Searching in address books
Searching in address books aims to expand address by adding a Key if address book contain one occurrence of searching Hash.
9.1. Address book applications
Address book applications are procedures or software applications and network resources, using different sources for validation addresses:
LDAP directories;
DNS servers, including translation E.164 telephone numbers as described in RFC 3761 [2]
DNS cache of personal computer;
Special software application plug-ins. For instance, web browser plug-in can search addresses in history of visited web pages or grab URL from the current viewed web page. E-mail client plug-in can search addresses in collected e-mails.
9.2. Hierarchy of address books
User can have more than one address books. Device initiated search MUST organize searching in different address books in assigned order one by one.
Address book application for each record calculates Hash, using Table 1, and then searching Hash compared with them as substring.
If one Hash is matched Address, Address is found and Key can be added automatically.
If no one Hash is matched see Section 9.2.
If more than one Hash is matched see Section 9.3.
9.2. Adding new hashes and keys to the address book
If no Hash is matched, User must provide a Key.
After Key is entered and validated, device must remember Address (or combination of Hash and Key) in Hash table. After some period of time relatively rare in use Addresses must be deleted from the memory.
9.3. Collisions in hash table
If more than one Hash is matched User can choose Address from the list of matched records.
It is recommended in case of matched records quantity is more than 10 occurrences, Device requests a Key to be entered by User.
10. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
11. Acknowledgment
I would like to thank ….
12. 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.Faltstrom, P. and M. Mealling, “The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)”, RFC 3761, April 2004.
3.Marc Spencer. Distributed Universal Number Discovery (DUNDi), Internet-Draft? October 2004.
4.Peterson, J., Liu, H., Yu, J., and B. Campbell, “Using E.164 numbers with the Session Initiation Protocol (SIP)”, RFC 3824, June 2004.
5.Handley, M., Jacobson, V., Perkins, C., Session Description Protocol (SDP), RFC 4566, July 2006.
6.Berners-Lee, T., Fielding, R.T. and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax”, RFC 2396, August 1998.
7.Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

Authors’ Addresses

Andrei Ivanov
email: support@commandus.com
URI: http://commandus.com/

About Us | Site Map | Privacy Policy | Contact Us | Copyright © 2007-2011 Commandus software development group . All rights reserved. Powered by WordPress