exosip2协议栈原理分析以及总结 下载本文

内容发布更新时间 : 2024/3/29 15:47:07星期一 下面是文章的全部内容请认真阅读。

找出其中的最小值,然后将其与当前时间做差,结果就是最小的超时间隔了。这步是通 过调用接口osip_timers_gettimeout 完成的。主要检查osip 全局结构体上的ict、ist、nict、 nist 以及ixt 上所有事务的事件的超时时间。如果 ict 事务队列上没有事件,则说明没 有有效的数据交互存在,返回值为默认的一年,实际上就是让后面的接收接口死等。如 果有事务队列上的事件的超时时间小于当前值,则说明已经超时了,需要马上处理,此 时将超时时间清为零,并返回。

b. 调用 eXosip_read_message 接口从底层接收消息并处理。如果返回-2,则任务退出。 c. 执行 osip 的状态机。具体为执行osip_timers_ict(ist|nict|nist)_execute 和osip_ict (ist|nict|nist)_execute 这几个函数。最后还检查释放已经终结的call、registrations 以及 publications。

d. 如果 keep_alive 设置了,则调用_eXosip_keep_alive 检查发送keep_alive 消息。 这样,当远端的终端代理发送sip 消息过来时,会被之前创建的监听端口捕获(sip 协议 默认的端口为5060)。在调用eXosip_read_message 接口时会将其接收上来。接收上来的数据存放在buffer 中交给接口_eXosip_handle_incoming_message 来处理。在其中首先调用osip_parse 进行消息的解析,这是osip 的核心功能之一。数据解析后,会生成一个osip_event 类型的事件。接着调用osip_message_fix_last_via_header 将接收到该消息的ip 地址和端口根据需要设置到数据头的via 域中。这在消息返回时有可能发挥作用。为了能够让消息正确的被处理,调用osip_find_transaction_and_add_event 接口将其添加到osip 的事务队列上。处理在这之后发生了分叉,如果osip 接纳了该事件,接口直接返回,因为这说明该事件在osip 上已经有匹配的事务了,或者说该事件是某一个事务过程的一部分。这样在后面执行状态机的接口时,该事件会被正确的处理。如果osip 没有拿走该事件,则说明针对该事件还没有事务与之对应。此时,我们首先检查其类型,如果是request,则说明很可能是一个新的事件到来( 这将触发服务端的状态机的建立), 调用eXosip_process_newrequest 接口进行处理。如果是response , 则调用接口eXosip_process_response_out_of_transaction 处理。在 eXosip_process_newrequest 接口中,如果是合法的事件,则会为其创建一个新的事务。 也就是说这是新事务的第一个事件。经过一大堆的处理后,该事件可能就被osip 消化了, 或者被exosip 消化了。如果需要上报给应用,由应用拿来对一些信息进行存储或者进行图 形显示之类,则会将该事件添加到exosip 的事件队列上。如下图所示:

6

应用程序在exosip 初始化完之后需要调用如下类似的代码,不断从事件队列上读取事件, 并进行处理。

eXosip_event_t *je; for (;;) {

je = eXosip_event_wait (0, 50); eXosip_lock();

eXosip_automatic_action (); eXosip_unlock(); if (je == NULL) break;

if (je->type == EXOSIP_CALL_NEW) { .... .... }

else if (je->type == EXOSIP_CALL_ACK) { .... .... }

else if (je->type == EXOSIP_CALL_ANSWERED) { .... .... }

else ..... .... ....

eXosip_event_free(je); }

读到事件后,判断其类型进行对应的处理。这样整个接收流程就完成了。

5.2 发送过程

要发送数据时,需要根据消息类型,调用exosip 对应模块的api 接口函数来完成。如果 要发送的sip 消息不属于当前已有的任何事务,则类似接收过程,调用osip 的相关接口创建 一个新的事务,同时根据消息生成一个事件,加到事务的事件队列上。最后,唤醒exosip 后台进程,使其驱动osip 状态机,执行刚添加的事件,从而完成数据的状态处理和发送。 当然,也有一些消息并不通过osip 状态机,而是由exosip 直接调用回调函数cb_snd_message 完成发送。

7

6、 exosip 与上层应用以及osip 之间的流程关系

exosip 是对osip 库的扩展,那么它与osip 之间是什么样的关系呢,这可参看下图:

上图为接收过程的示意图。Exosip 后台任务不断从网络另一端读取sip 消息,交给osip 的parser 模块解析,并将其转换为events,添加到事务队列上。同时,exosip 后台任务在不断的驱动osip 的状态机,这样,事务队列上的事件就会被处理。如果需要响应对端,状态机会根据回调函数的设置,直接完成数据的发送。同样,如果要将当前处理反馈给应用,则将其发送到事件队列上(这里是exosip 的事件队列),并通过e-ctl 管道通知应用进行处理。应用需要发送数据时,流程如下图所示:

此时,应用调用exosip 提供的辅助函数(上图中虚线示意此关系),构造osip 事件,将 其添加到osip 的事务队列上。同时,应用通过s-ctl 管道通知exosip 后台任务执行状态机。 在exosip 执行状态机的过程中,sip 消息会被发送到网络另一端的终端。

8

7、linphone与exosip2的关系分析

7.1 linphone功能模块说明

Liblinphone 核心引擎实现了linphone 所有的功能函数,而且能够方便的添加音频和视频的呼叫功能。Liblinphone 也提供高层的API,用来初始化,接收或者终止呼叫。Liblinphone 依赖于下面三个组件: 1 Mediastreamer2

这是一个支持多种平台的轻量级的流技术引擎,主要适合于开发语音和视频电话应用程序。该引擎主要为 linphone 的多媒体流的收发,包括语音和视频的捕获、编码解码以及渲染。 2 ortp2

Ortp 是一个RTP 库。为基于RTP 协议的媒体流传输提供支持。通过mediastream2 编码的数据就是使用ortp 库发送到网络的另一端。 3 eXosip2

Exosip2 为sip 协议的实现。这部分实际上是由exosip2 和osip2 两个库共同完成的。使用sip 协议完成路由、媒体协商以及会话的建立和管理,为直接的媒体流的传输提供基础。

通话双方在通信前使用exosip 进行会话协商。Exosip 后台任务完成数据的接收和发送,并通过事件队列通知linphone 底层的状态变化。filter 的构建在会话协商成功建立后就顺带完成了,并且ticker 任务也跑起来了。此时按照 filter graphics 构建的通道,音视频流不断的从硬件设备上读取,并经过编码压缩送给RTP 会话,之后送到对端,对端到达的音视频流也经过RTP 会话接收送到解码解压缩filter,还原出原始的音视频流交给硬件设备播放。媒体数据在这两路流中源源不断的流动,完成了双方的可视通话。上层linphone 的core 任务也不断的对底层进行迭代检查。所做的基本工作如下:对于sip 协议部分,core 一直等待从事件队列上拿事件。这些事件是exosip 任务在处理sip 消息过程中添加到事件队列上的。每当得到新的事件后,core 就从应用层的角度出发,进行处理。对于视频流:基本上只处理rtcp 数据包到达的事件。stream 上也有一个事件队列,用于保存该流上的相关事件。对于rtcp 数据包事件,core 也只处理sr 类型rtcp 包,即发送端报告,得到jitter 和包丢失率。如果设置了自适应比特率,则调用相关接口进行处理。此过程不断进行,直到当前事件上的包处理完。对于音频流,检查流是否还是活动的。通过比较RTP stats 中接收的数据包数目是否发生变化,如果在超时时间到达后,接收的数据量还没有发生变化,则认为音频没有响应。

7.2 linphone中sal模块完成对exosip的封装

Sal 模块其实应该是最重要的,最核心的模块了。该模块对exosip 进行了简单的封装,间接的对osip 模块进行了封装,使用该模块的接口可以完成sip 协议的处理以及媒体描述的处理。

Sal.c 文件主要是对一些sal 相关的结构体的操作,包括SalMediaDescription 和sal_op。处理包括创建这些结构体的实例,获取或者设置其中的一些操作域。

Sal_exosip2_sdp.c 基于osip 库提供的sdp 相关操作的接口,在sal 层实现将其与sal 相关的结构体关联起来操作。比如根据SalMediaDescription 结构体信息将其转换为sdp 结构体,或者反之。

9

Sal_exosip2_presence.c 包括了对in 和out 的subscribe 的操作。Text 数据的发送(基于osip 和exosip)。

Sal_exosip2.c sip 这块比较重要的封装。包含了对sal_op 结构体的创建和基本操作。对exosip 重要结构体的封装,包括初始化和释放。包含了对sal 结构体的创建和基本操作的封装,更重要的是包含了对sal 和sal_op,sal_media_desc,sal_stream_desc 这些上层结构体与底层osip_message,

sip_message,sdp_message 等数据结构之间数据的转换和共享,以及对底层相关接口的调用。这种调用主要包括跟据上层结构体中包含的信息设置底层结构体,并调用底层接口完成具体功能,以及根据底层结构体得到的数据设置上层结构体的相关信息。一个基本的描述就是:sal 作为signal abstract layer 包含了上层所主要理解的交互信息,这些信息对于理解电话操作而言已经足够了,在底层,选择了osip 和exosip 来支持这项操作。所以实际上来说,可以用其他支持sip 的库的接口来替代现有的,保留sal 层接口的功能定义。在linphone 中,虽然大部分使用了sal 层的封装来完成sip 交互过程,但是也调用osip 和exosip 库本身的其他接口,所以这层封装主要还是再次简化协议层的处理,使得功能更具体,而不是更单一。

几个关键数据结构之间的关系:

Sal 一个基本的结构体,通过这个结构体可以搜寻到上层所需的所有sip 协议相关的信息。具体的call,register 等信息保存在sal_op 这个结构体中,多个实体通过链表串接起来,挂在sal 上。Sal_op包含了sal_op_base 结构体,这个结构体保存了一些通用的不变的信息,对多个实体而言,比如路由信息,本地媒体信息,远端媒体信息等。其root 指针由返回指向了sal 这个基础,所以通过sal_op可以找到sal。另外,在媒体信息中包含了所有流的信息,所有这些类似一个树的组织结构,sal 类似树根,通过它可以找到所有的枝叶及其上的信息。

7.3 linphone初始化过程中对sip协议栈的初始化

7.3.1 调用 sal_init 进行sip 协议栈的初始化。该过程将返回一个sal 结构体。 Exosip 全局结构体的创建以及初始化。需要注意,在这里相当于有三层封装调用:一层为sal 层的封装调用,一层为exosip 层的封装调用,最底层为osip 层的基本调用。另外需要注意的是在这里没有创建exosip 任务,而是在后面的读取并配置sip 配置信息时才创建 exosip 任务,并监听特定端口。

将lc->sal 的up 指针指回linphone core 全局结构体 设置sal 上的回调函数,这些回调函数在对应的sip 协议处理完后用于调用来处理外层有关call与media 流的一些处理。如果配置文件中没有设置sip 会话的过期时间,则在这时将其设置为200将所有sip setup 配置串联到registered_sip_setups 全局链表上

7.3.2 读取配置文件中有关sip 协议的相关信息,并以此来配置linphone 的sip 模块。 配置是否在发送数字时使用sip info 信息。 配置是否在发送数字时使用rfc2833 信息 配置是否使用ipv6

配置sip 的传输端口信息。指定是使用随机值还是知名5060 端口 将端口信息设置到linphone core 中,并启动sip 监听。这样,当sip 协议数据到达时即可被处理。

首先调用sal_listen_port 启动监听端口。在这里,协议层被选择和设置,一般情况下都是udp,这里为eXtl_udp。之后创建并启动_eXosip_thread 任务,该任务处理sip 协议数据

10