毕业设计论文(于嵌入式linux的voip终端设计

毕业设计论文(于嵌入式linux的voip终端设计内容摘要：

请求可以取消 ACK 和 CANCEL 以外的其他请求类型，但是通常只是用来取消 INVITE 请求。 (e) REGISTER： UAC 利用 REGISTER 请求消息将 To 标题字段的地址登记到定位服务器中。 UAC 在开机启动以后将 REGISTER 请求以组播方式发出。 登记服务器的每个登记记录都有一个对应的有效期，一旦到期，记录就被删除。 (f) OPTIONS： OPTIONS 请求用于查询用户代理服务器（ User Agent Server， UAS）的能力。 UAS 在响应消息的 Allow 标题字段中指明它能支持的方法。 代理服务器和重定向服务器只将该请求消息前转而不是指示它们自己的能力。 其他 SIP 扩展请求方法见 RFC 文档。 2. 响应 SIP 响应开始行也是状态行，其格式包括协议版本，数字状态码（其后有文本短语描述），三者分别通过一个空格分开，结束是 CRLF。 除了一句结束为 CRLF，不允许有 CR 或者 LF。 状态码 StatusCode 是一个三位整数，说明尝试理解和处理请求的结果。 ReasonPhrase 是对状态码的简单的文本描述。 StatusCode 是自动操作的，而 ReasonPhrase 是为用户服务的，客户端不需要检测或者显示 ReasonPhrase。 状态码的 3 位数字的第一位表示响应种类，后两位没有进行分类。 所以状态码100 到 199 用“ 1xx 响应”表示，状态码 200 到 299 用“ 2xx 响应”表示， SIP/ 允许 3 位数字的第一位有六种，如下： 1xx： Provisional表示请求收到，正在处理。 2xx： Success表示行为成功被接收并理解。 3xx： Redirection表示要完成请求需要进一步的行动。 江苏大学本科毕业论文 8 4xx： Client Error表示请求包含坏的语法或者不可以被本服务器接受。 5xx： Server Error表示服务器实现有效的请求失败。 6xx： Global Failure表示请求在任何服务器均不可以实现。 3. 标题字段 SIP 标题字段在语法语义上同 HTTP 类似 [8]。 中详细说明了同一标题字段的多个标题字段，他们以逗号分开。 在 SIP 中一样可以应用，但是不同的语法有不同的规定，特别说明的是任何 SIP 标题均为以下形式： header=headername HCOLON headervalue*（ COMMA headervalue） 其他标题字段见 RFC3261[10]等建议。 4. 消息体 请求可能包含消息体信息，除非特别指出，消息体的解释取决于请求方法。 对于响应消息，请求方法和响应状态码取决于消息体的类型和解释。 所有的响应都有可能包含消息体。 消息体是用来描述将要启动的会话的（如：在多媒体会话中用这种方式可以确定音频和视频的编码类型，抽样率等），或者说是用来包含在会话中所使用的不透明的文本或者二进制信息。 一般的消息主体使用 SDP 协议，其细节见 RFC2327[5]。 本文 对 SDP 进行相当详细的描述。 SIP 呼叫流程 下图展示了两用户 UAC 和 UAS 会话建立和终止 SIP 协议工作的流程： 图 UAC 和 UAS 会话建立和终止 会话建立过程如下： 1. 呼叫者 UAC 发送 INVITE 消息给 UAS 的 SIP 地址： sip： 这个消息也包括 SDP 包（它描述呼叫者终端的媒体通信能力）。 2. UAS 接收到了请求以后马上响应，返回一个 100Trying 响应消息。 第二章 VOIP 的技术原理 9 3. UAS 开始“振铃”，通知 用户 新电话到了，同时 180（ Ringing）消息发给 UAC。 4. 用户 拿起电话然后， UAS 发消息 200（ OK）给呼叫 者 UAC。 这个消息也包括SDP 数据包，描述 UAS 通信终端的媒体通信能力。 5. UAC 发送 ACK 来确认 200（ OK）响应 会话中止，会话终端呼叫流如下： 1. 呼叫者（ UAC）决定中止会话并挂机，这由发送一个 BYE 请求给 UAS 的 SIP地址： sip： 2. 用户 的 UAS 用 200（ OK）消息响应并通知 用户，通话结束。 SDP 媒体协商技术 SDP 协议概述 SDP 在 IETF MMUSIC (Multiparty Multimedia Session Control 多方多媒体会议控制 ) 工作组 的 RFC2327 中定义的一个多媒体会话描述协议 [5]。 在 Inter 组播骨干网 (Mbone)中， SDP 用于描述多媒体会话，以便实现会话公告、会话邀请和其它形式多媒体会话的启动。 Inter 上基于组播 (Multicast)的会话与许多其它会话形式的不同之处在于，用户只需知道该会话的组播地址和用于该会话数据流的 UDP 端口，就能够接收该会话的数据流并加入该会话 (该会话被加密除外 )。 而在这种情况下， SDP 有两个主要的目的 :第一个目的是表明会话的存在，第二个目的是传送足够的信息给接收方，以便能够加入、 参加这个会话。 SDP 必须传达的信息包括：会话名称和目的，该会话活动的时间，组成该会话的媒体种类，接收这些媒体的控制信息 (如地址、端口、格式、带宽以及会议管理人员资料等等 )。 SDP 描述内容及其格式 SDP 会话描述采用 RFC2044 中的 ISO10646 字符集。 SDP 域名和属性名用 UTF28的 US ASCII 子集，但是文本域和属性值完全采用 ISO10646 字符集。 SDP 从真正地意义上讲可以说不是一个“协议”，而是一个文本描述，它的简化格式可表示为： 〈 type〉 =〈 value〉， 〈 type〉 总是只有一个区分大小写的单字符，〈 value〉是结构化文本串，其格式依赖于〈 type〉， 并且也区分大小写。 等号两边不能有空格。 一般〈 value〉是以空格为界的若干项 (fields)或者一个自由格式串。 一个会话描述由一个会话级描述和若干个媒体级描述组成。 会话级部分是以“ v=”开头，直到第一个媒体级，媒体描述是以“ m=”行开始直到下一个媒体描述或者到整个会话描述结束，一般，会话级默认值适合于所有媒体， 除非被一个相同会话 级描述值所覆盖。 一个会话描述中包含有如下各行内容并且固定了顺序，标有 *的是可选项 : 江苏大学本科毕业论文 10 会话 描述 ： v= (protocol version)。 o= (owner/creator and session identifier)。 s= ( session name)。 i= * ( session information)。 u= * (URI of description)。 e= * ( address)。 p= * (phone number)。 c= * (connection information)。 b= * (bandwidth information)。 z= * ( time zone adjustments)。 k= * (encryption key)。 a= * (zero or more session attribute lines). 时间描述 ： t= ( time the session is active)。 r= * (zero or more repeat times). 媒体描述 ： m = (media name and transport address)。 i= * (media title)。 c= * (connection information)。 b= * (bandwidth information)。 k= * (encryption key)。 a= * (zero or more media attribute lines). 在上述会话级部分，如果不被媒体描述中的同名属性或连接信息覆盖，连接(“ c= ” )和属性 (“ a= ” ) 可用于这个会话的所有媒体。 RTP 实时语音传输技术 RTP、 RTCP 协议概述 UDP 无法做到避免分组丢失和确保分组有序传输。 运行在 UDP 之上的 RTP 帮助实现了这些功能。 例如， RTP 分组包括序列号，这样，使用 RTP 应用程序至少能够检测到分组丢失的发生并确保收到的数据以正确的次序提交给用户。 RTP 分组还包含了一个时间戳，这个时间戳对应于分组从源媒体中进行抽样的时间。 目的应用程序可以利用这个时间戳 来确保信息同步地传递给目的用户并计算出时延和抖动。 RTP 本身没有提供任何确保及时传送的机制，也没有提供任何传输质量保证的机制，因而业务质量完全由下层网络的质量来决定。 因此 RTP 通常配套使用 RTCP协议。 RTCP 是 RTP 的控制协议，它用于监视业务质量、与正在进行的会话者 传送信第二章 VOIP 的技术原理 11 息并提供拥塞控制。 RTP 协议 RTP 支持实时传输、包排序、封装数据、有效载荷类型鉴定、多播、鉴定发包来源和同步源等服务。 但是，需要注意的是 RTP 本身不提供任何机制来确保把数据及时递送到接收端和确保其他的服务质量，它也不担保在递送过程中不丢失包或者包的次序不被打乱。 RTP 报头包含有支持这些服务所需要的信息，然后由客户端应用程序根据这些信息提供相应的服务。 图 显示了 RTP 报头的格式。 图 RTP 数据包的报文格式 RTP 报头的简单介绍 : V：版本号 P：间隙，设置时，数据包包含一 个或多个附加间隙位组，其中这部分不属于有效载荷。 X：扩展，表示固定长度的报头是否包含一个报头扩展区。 CC： CSRC 计数器，表示有用源标志符的数量。 M：标记，在传输语音数据时，当传输的这个 RTP 包是静音期间过后的第一 3个包，则 M=l。 否则 M=0。 用于标识静音结束。 PT：净 负荷 类型，表示 RTP 包内 净 负荷 的格式。 序列号：每发送一个 RTP 数据包，序列号增加 1。 接收方可以依次检测数据包的丢失并恢复数据包序列。 时间戳： 记录净负荷 中第一个抽样产生的时间，时间戳的初值是随机的，但是两个相邻 RTP 包的时间戳的差值 应为间隔时间段的抽样点数目。 SSRC(Synchronous Source)：同步源。 该标识符随机选择，旨在确保在同一个 RTP会话中不存在两个同步源具有相同的 SSRC 标识符。 用于鉴定包来源。 CSRC(Contributing Source)：贡献源标识符。 识别该数据包中的有效载荷的贡献江苏大学本科毕业论文 12 源。 RTCP 协议 RTCP 被称为传输控制协议，是用来对实时数据的传输进行监视和控制的。 RTP必须周期性的传送 RTCP 包，监视 RTP 传输的服务质量。 在 RTCP 包中，含有已发送的数据包的数量、丢失的数据包的数量等 统计资料。 因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型，实现流量控制和拥塞控制服务。 RTCP 主要有以下几方面的功能： 1. 提供数据发布的质量反馈，这是 RTCP 最主要的功能。 作为 RTP 传输协议的一部分，与其他传输协议的流和阻塞控制有关。 反馈对自适应编码控制直接起作用。 反馈功能由 RTCP 发送者和接收者报告执行。 2. 发送带有称作规范名字（ CNAME）的 RTP 源持久传输层标识。 如发现冲突或程序重新启动，立即做出相应的处理。 3. 用于控制 RTCP 包数量的数量用语。 前两种功能要求所有参加者发送 RTP 包，因 此，为了 RTP 扩展到大规模数量，速率必须受到控制。 4. 传送最小连接控制信息。 如参加者辨识。 最可能用在“松散控制”连接，那里参加者自由进入或离开，没有成员控制或参数协调， RTCP 充当通往所有参加者的方便通道，但不必支持应用的所有控制通讯要求。 所以说，为了可靠、高效地传送实时数据， RTP 和 RTCP 必须配合使用，通常RTCP 包的数量占所有传输量的 5％。 13 第三章 嵌入式 VoIP 终端系统总体设计方案 系统设计目标与开发方法 系统设计目标 本系统设计的目标是在嵌入式平台上实现一个 VoIP 终端 (用 户代理 ， 如图 中的 UA Hard)，具体来说包括： (l)能够满足 IP 网上语音通信的基本要求 (UA 呼叫控制、 SIP 消息解析、语音编解码、 RTP 传输 )； (2)按照标准 SIP 协议开发，能和其它使用 SIP 协议的 UA 互通； (3)运行稳定； (4)具有良好的开放性和扩展性； (5)系统易于维护，方便后续的研究和开发。 系统的总体结构 根据分层实现的思想， 系统的总体结构如图 所示 : 图 系统的总体结构 系统硬件平台的选择 根据局域网上语音通信的需要，本系统的硬件部分至少应包括以下模块 : (l)嵌入式微处理器 (2)存储器 江苏大学本科毕业论文 14 (3)音频模块 :包括音频的输入 (MIC)和输出 (扬声器 ) (4。