开源软件架构：洞察与经验

需积分: 10 70 浏览量更新于2024-07-23 收藏 5.84MB PDF 举报

"《开源软件架构》是一本深入探讨开源软件设计和构建的书籍，由Amy Brown和Greg Wilson编辑，2011年由Lulu.com出版。书中涵盖了多个开源项目，旨在提供对软件架构的洞察，让开发者了解并学习历史上的成功案例，避免重复错误，建立在彼此的成功之上。本书分为两卷，涉及众多开源软件，包括：卷1： - Asterisk：一个开源的VoIP通信平台。 - The Bourne-Again Shell (Bash)：Unix和Linux操作系统中的默认shell。 - Berkeley DB：一种嵌入式数据库系统。 - CMake：跨平台的自动化构建系统。 - Eclipse：流行的开源集成开发环境。 - HDFS：Hadoop分布式文件系统，用于大规模数据处理。 - Mercurial：分布式版本控制系统。 - NoSQL生态系统：介绍非关系型数据库。 - Python打包工具：关于Python应用的打包和分发。 - Riak与Erlang/OTP：Riak是一个基于Erlang/OTP构建的分布式键值存储系统。 - Selenium WebDriver：自动化浏览器测试工具。 - SnowFlock：虚拟化技术，用于快速克隆云服务器。 - Violet：图形建模工具。 - VTK：可视化工具包。 - 韦诺之战：游戏开发框架。卷2： - 可扩展Web架构与分布式系统：讨论扩展性和分布式系统的最佳实践。 - Firefox发布工程：Firefox浏览器的构建和发布流程。 - FreeRTOS：小型实时操作系统。 - GDB：GNU调试器，用于程序调试。 - Glasgow Haskell编译器：Haskell编程语言的编译器。 - Git：分布式版本控制系统。 - GPSD：GPS设备服务程序。 - ITK：医学图像处理库。 - Matplotlib：Python的数据可视化库。 - MediaWiki：维基媒体基金会使用的开源wiki引擎。 - Moodle：开源的在线学习平台。 - NginX：高性能的Web服务器和反向代理服务器。 - Open MPI：高性能并行计算的MPI实现。 - Puppet：配置管理工具。 - PyPy：Python解释器的替代实现，注重性能提升。 - SQLAlchemy：Python SQL工具包和ORM框架。 - Twisted：事件驱动的网络编程框架。 - Yesod：基于Haskell的Web应用程序框架。 - ZeroMQ：消息传递库，提供高性能、易用的异步I/O。 - 第二次提到Git，可能是重复内容。这本书适合初级、中级和高级开发者阅读，对于想要了解更资深同行如何解决复杂设计问题的开发者来说，是宝贵的资源。通过学习这些开源软件的架构，读者可以提升自己的编程思维，理解大型项目的组织结构，以及如何设计可扩展、可维护的软件。"

Codec Negotiation

The method used to negotiate which codec will be used for a media stream is specific to

the technology used to connect the call to Asterisk. In some cases, such as a call on the

traditional telephone network (the PSTN), there may not be any negotiation to do.

However, in other cases, especially using IP protocols, there is a negotiation mechanism

used where capabilities and preferences are expressed and a common codec is agreed

upon.

For example, in the case of SIP (the most commonly used VOIP protocol) this is a high

level view of how codec negotiation is performed when a call is sent to Asterisk.

1. An endpoint sends a new call request to Asterisk which includes the list of codecs it

is willing to use.

2. Asterisk consults its configuration provided by the administrator which includes a list

of allowed codecs in preferred order. Asterisk will respond by choosing the most

preferred codec (based on its own configured preferences) that is listed as allowed

in the Asterisk configuration and was also listed as supported in the incoming

request.

One area that Asterisk does not handle very well is that of more complex codecs,

especially video. Codec negotiation demands have gotten more complicated over the last

ten years. We have more work to do to be able to better deal with the newest audio

codecs and to be able to support video much better than we do today. This is one of the

top priorities for new development for the next major release of Asterisk.

Codec translator modules provide one or more implementations of the ast_translator

interface. A translator has source and destination format attributes. It also provides a callback

that will be used to convert a chunk of media from the source to the destination format. It knows

nothing about the concept of a phone call. It only knows how to convert media from one format

to another.

For more detailed information about the translator API, see include/asterisk/translate.h

and main/translate.c. Implementations of the translator abstraction can be found in the

codecs directory.

1.3. Threads

Asterisk is a very heavily multithreaded application. It uses the POSIX threads API to manage

threads and related services such as locking. All of the Asterisk code that interacts with threads

does so by going through a set of wrappers used for debugging purposes. Most threads in

Asterisk can be classified as either a Network Monitor Thread, or a Channel Thread (sometimes

also referred to as a PBX thread, because its primary purpose is to run the PBX for a channel).

1.3.1. Network Monitor Threads

Network monitor threads exist in every major channel driver in Asterisk. They are responsible for

monitoring whatever network they are connected to (whether that is an IP network, the PSTN,

etc.) and monitor for incoming calls or other types of incoming requests. They handle the initial

connection setup steps such as authentication and dialed number validation. Once the call setup

has been completed, the monitor threads will create an instance of an Asterisk channel

(ast_channel), and start a channel thread to handle the call for the rest of its lifetime.

1.3.2. Channel Threads

As discussed earlier, a channel is a fundamental concept in Asterisk. Channels are either inbound

or outbound. An inbound channel is created when a call comes in to the Asterisk system. These

channels are the ones that execute the Asterisk dialplan. A thread is created for every inbound

The main loop of the channel thread handles dialplan execution. It goes to the rules defined for the

dialed extension and executes the steps that have been defined. The following is an example

extension expressed in the extensions.conf dialplan syntax. This extension answers the call

and executes the VoicemailMain application when someone dials *123. This application is what a

user would call to be able to check messages left in their mailbox.

exten => *123,1,Answer()

same => n,VoicemailMain()

When the channel thread executes the Answer application, Asterisk will answer the incoming call.

Answering a call requires technology specific processing, so in addition to some generic answer

handling, the answer callback in the associated ast_channel_tech structure is called to handle

answering the call. This may involve sending a special packet over an IP network, taking an analog

line off hook, etc.

The next step is for the channel thread to execute VoicemailMain (

Figure 1.6). This application is

provided by the app_voicemail module. One important thing to note is that while the Voicemail

code handles a lot of call interaction, it knows nothing about the technology that is being used to

deliver the call into the Asterisk system. The Asterisk channel abstraction hides these details from

the Voicemail implementation.

There are many features involved in providing a caller access to their Voicemail. However, all of

them are primarily implemented as reading and writing sound files in response to input from the

caller, primarily in the form of digit presses. DTMF digits can be delivered to Asterisk in many

different ways. Again, these details are handled by the channel drivers. Once a key press has

arrived in Asterisk, it is converted into a generic key press event and passed along to the

Voicemail code.

One of the important interfaces in Asterisk that has been discussed is that of a codec translator.

These codec implementations are very important to this call scenario. When the Voicemail code

would like to play back a sound file to the caller, the format of the audio in the sound file may not

be the same format as the audio being used in the communication between the Asterisk system

and the caller. If it must transcode the audio, it will build a translation path of one or more codec

translators to get from the source to the destination format.

Figure 1.6: A Call to VoicemailMain

At some point, the caller will be done interacting with the Voicemail system and hang up. The

channel driver will detect that this has occurred and convert this into a generic Asterisk channel

signalling event. The Voicemail code will receive this signalling event and will exit, since there is

nothing left to do once the caller hangs up. Control will return back to the main loop in the channel

thread to continue dialplan execution. Since in this example there is no further dialplan processing

to be done, the channel driver will be given an opportunity to handle technology specific hangup

processing and then the ast_channel object will be destroyed.

1.4.2. Bridged Call

Another very common call scenario in Asterisk is a bridged call between two channels. This is the

scenario when one phone calls another through the system. The initial call setup process is

identical to the previous example. The difference in handling begins when the call has been set up

and the channel thread begins executing the dialplan.

The following dialplan is a simple example that results in a bridged call. Using this extension, when

a phone dials 1234, the dialplan will execute the Dial application, which is the main application

used to initiate an outbound call.

exten => 1234,1,Dial(SIP/bob)

The argument specified to the Dial application says that the system should make an outbound

call to the device referred to as SIP/bob. The SIP portion of this argument specifies that the SIP

protocol should be used to deliver the call. bob will be interpreted by the channel driver that

implements the SIP protocol, chan_sip. Assuming the channel driver has been properly

configured with an account called bob, it will know how to reach Bob's phone.

The Dial application will ask the Asterisk core to allocate a new Asterisk channel using the

SIP/bob identifier. The core will request that the SIP channel driver perform technology specific

initialization. The channel driver will also initiate the process of making a call out to the phone. As

the request proceeds, it will pass events back into the Asterisk core, which will be received by the

Dial application. These events may include a response that the call has been answered, the

destination is busy, the network is congested, the call was rejected for some reason, or a number

of other possible responses. In the ideal case, the call will be answered. The fact that the call has

been answered is propagated back to the inbound channel. Asterisk will not answer the part of the

call that came into the system until the outbound call was answered. Once both channels are

answered, the bridging of the channels begins (

Figure 1.7).

Figure 1.7: Block Diagram of a Bridged Call in a Generic Bridge

During a channel bridge, audio and signalling events from one channel are passed to the other

until some event occurs that causes the bridge to end, such as one side of the call hanging up.

The sequence diagram in

Figure 1.8 demonstrates the key operations that are performed for an

audio frame during a bridged call.

剩余344页未读，继续阅读

john213

粉丝: 4
资源: 30

开源软件架构：洞察与经验

开源软件架构深入解析：卷1&2

开源软件架构：探索与学习

开源软件架构探析：以J2EE轻量级框架Spring为例

开源软件架构 软件架构

开源软件架构探秘：提升架构思维

SofAA开源软件架构图形工具介绍

开源软件架构.pdf（作者：Greg Wilson , Amy Brown）

开源软件架构中英文（卷一和卷二高清非打印完整版）

(免费)The Architecture of Open Source Applications 1&2 及中文版 开源软件架构1和2

开源软件架构揭秘：历史经验与设计启示

最新资源

开源软件架构软件架构

(免费)The Architecture of Open Source Applications 1&2 及中文版开源软件架构1和2