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 можно внедрять уже сегодня, и в этом его привлекательность.

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

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