1、Q/CT XXXX.1-2008中国IMS网络SIP协议规范总体技术要求 - 1 -Osip 协议源代码框架详解Prepared by Mao minghua Date 2009.09.25Reviewed by DateApproved by DateQ/CT XXXX.1-2008中国IMS网络SIP协议规范总体技术要求 - 2 -Revision HistoryVersion Author Reviewed By Comments Issued Date0.1 Mao minghua 描述 osip 协议栈的源代码框架Q/CT XXXX.1-2008中国IMS网络SIP协议规范总体技术要
2、求 - 3 -目录1 符号及缩写 42 整体描述 43 OSIP 包的源代码框架解析 53.1 OSIP 的 TRANSACTION 的 EVENT 的产生 .53.1.1 定时器事件的产生过程 63.1.2 报文触发的事件 73.2 OSIP 的 TRANSACTION 的 EVENT 处理流程 73.2.1 ICT 的处理流程 83.2.2 IST 的处理流程 .93.2.3 NICT 的处理流程 .93.2.4 NIST 的处理流程 93.3 OSIP 报文的解析 .103.3.1 sip 协议报文的解析整理流程 103.3.2 Osip 报文头的解析 .123.3.3 uri 的解析
3、143.3.4 添加一个新的协议 header 字段 .153.4 OSIP 的 TRANSACTION 的管理 .163.5 OSIP 中 DIALOG 的管理 .184 EXOSIP 包的源代码框架解析 .194.1 LIB 库的初始化和销毁 .204.2 LIB 库的主处理线程 .234.2.1 2xx 应答的重发处理机制 .244.2.2 Exosip_execute 执行流程 .244.2.2.1 Exosip_read_message 的处理 .264.2.2.2 eXosip_process_response_out_of_transaction 的处理流程： .294.2.3
4、eXosip_automatic_action 处理流程 294.3 CALL 的处理 304.3.1 创建 Call 的第一个 INVITE.304.3.2 INVITE 的 ACK 应答的创建和发送 .324.3.3 dialog 内的请求的创建和发送 .334.3.4 Dialog 内 answer 的创建和发送 334.4 REGISTER 的处理 .344.4.1 向一个服务器第一次注册 354.4.2 调整一个注册的注册超时时间 354.4.3 发送一个 register 注册 35Q/CT XXXX.1-2008中国IMS网络SIP协议规范总体技术要求 - 4 -Osip 源代码
5、框架详解1 符号及缩写缩写 英文全称 中文名称ICT Invite Client Transaction Invite 类型的客户端事务IST Invite Server Transaction Invite 类型的服务端事务NICT Not Invite Client Transaction 非 Invite 类型的客户端事务NIST Not Invite Server Transaction 非 Invite 类型的服务端事务IMS IP Multimedia Subsystem IP 多媒体子系统PSVT Packet service video telephony 分组域可视电话SIP
6、 Session Initiation Protocol 会话初始协议UDP User Datagram Protocol 用户数据报协议URL Uniform Resource Locator 统一资源定位器2 整体描述开源代码的 osip 协议栈分为两个源代码包，整个协议栈采用 lib 库的形式，在内部没有使用到任务，采取与 TCP/IP 协议栈一样的策略，所以在使用上需要上层管理任务直接调用 lib 库提供的接口。因为在 Lib 库内部没有使用到像定时器、发送队列等的任务，而同时需要使用到定时器，所以在 lib 库的内部采用轮训遍历的方式不停的检查是否有定时器超时，这在某种程度上会浪费
7、CPU 的允许时间。同时整个 lib 库实现了对 call, notify 等的管理，为了实现重入，在应用启用多线程的条件下，内部启用的信号量和锁的使用，在下面的分析中不涉及到信号量和锁机制。Lib 库按照 sip 协议栈的层次关系分为两个 lib 包，底层的 osip lib 包实现对单个请求、应答、ACK 的处理，包括 message 的解析、拼装、内容 set 和 get，单个请求形成的transaction 相关操作以及通信两端形成的一个 dialog 的操作。Lib 库上层的 exosip lib 在底层 osip lib 库的实现基础上，实现对 sip 协议整理逻辑上的管理。Exo
8、sip 主要关注的是 sip 协议的业务流程，包括 call 的整体管理，notify 的整体管理，publish 的管理， register 的管理，option 的管理，refer 的管理和 subscription 的管理，其中Q/CT XXXX.1-2008中国IMS网络SIP协议规范总体技术要求 - 5 -最主要的为 call 和 register 的管理，这两个为 sip 协议栈必须实现的部分，另几个功能为 sip协议栈扩展部分。从这几个业务的管理流程出发，在业务的底层它们会使用到相似的一些功能，如注册的认证，发送 message，接收 message，每个请求和应答形成的 tra
9、nsaction，多个 transaction 组合而成的 dialog。在 message 的处理方面，可以分为两类，一类为发送的 message，因为是主动发送，所以上层管理层知道是什么类型的 message，lib 库直接提供各类接口供使用。一类为接收到的 message，因为不知道是哪种类型，所以需要根据解析出来的 message 的信息来进行处理，这部分的处理在 udp.c 文件中。整个 lib 库的初始化在 exOsip 中介绍。3 Osip 包的源代码框架解析在 osip 源代码包中最主要的包括了 message 的相关操作，其中最重要的为 message 的解析，即从获取到的一
10、个 message 中解析生成一个能够被代码直接处理的 message 数据结构osip_message_t。与 message 结构相关的操作包括根据 message 数据结构的信息安装 sip 协议规范组装成一个 message 字符串；message 结构的初始化和释放； message 结构的拷贝操作；以及从 message 结构中获取各种已经解析的成员变量的值和设置各个成员变量的值。在 message 的解析部分，除了 message 的头之外，还包括了 body 的解析，涉及到sdp 协议，包括对每个 sdp 字段的解析。在 osip 源代码包中，设计了一个与同一个请求相关的所有
11、message 的集合transaction，在发送或接收到一个新的请求的时候就会生成一个 transaction，其中 ACK 和CANCEL 请求是比较特殊的，对于非 2xx 应答的 ACK 和初始 INVITE 请求是属于同一个transaction 的，而对于 2xx 的请求是属于单独的 transaction 的，所以其重传操作由 UAC 来控制，而不在 INVITE 的 transaction 内部进行控制。CANCEL 的请求除了本身建立一个transaction 外，根据协议它还会去匹配要 CANCEL 掉的请求的 transaction，如果匹配成功会 CANCEL 掉相应的
12、 transaction。在 osip 包中同样设计了 dialog 相关操作，包括 dialog 的建立， dialog 信息的保存，dialog 的匹配及删除等操作。其它方面，包括多线程中使用到的锁和信号量及信号，内部使用到的链表，用于事件的队列( 需要先进先出策略)，一些平台无关的封装，定时器以及常量等的定义。这部分比较简单，而且都是最底层函数，直接封装了系统调用层。3.1 osip 的 transaction 的 event 的产生transaction 的状态变化是由事件来驱动的，当 transaction 上有事件产生时，根据事件的类型和当前 transaction 的状态来处理该
13、 event。Q/CT XXXX.1-2008中国IMS网络SIP协议规范总体技术要求 - 6 -Transaction 上的事件分为两类：一为定时器事件，在设定的定时器超时时会产生相应的定时器事件；另一类为事件驱动事件，如发送一个请求、应答或接收到一个请求、应答，发送一个 ACK 和接收到一个 ACK，即是由报文产生的事件。3.1.1 定时器事件的产生过程_ _ o s i p _ i c t _ n e e d _ t i m e r _ b _ e v e n ty e so s i p _ t i m e r s _ i c t _ e x e c u t e ( o s i p _
14、t * o s i p )_ _ o s i p _ i c t _ n e e d _ t i m e r _ b _ e v e n t_ _ o s i p _ i c t _ n e e d _ t i m e r _ a _ e v e n tH a v e t i m e r b ?n oy e sH a v e t i m e r a ?n oy e sH a v e t i m e r b ?n o退出添加 e v e n t 到 t r a n s a c t i o n 的t r a n s a c t i o n f f 队列ICT、IST 、NICT 和 NIST 的定
15、时器的事件产生流程都一样，对于每一个 transaction，其定时器是有顺序的，ICT 流程中 TIMEOUT_B 的优先级最高， TIMEOUT_B 定时器触发后，会触发 kill transaction 的操作。当 transactionff 队列中有未处理的事件时，不处理定时器，直接返回，所以在 transactionff 队列中总的事件的数量是不多的。所有的定时器函数调用底层同一个定时器检查函数_osip_transaction_need_timer_x_event。该函数会先检查该定时器是否启动，判断条件为(timer-tv_sec = -1)，如果启动，检查当前时间是否超过定时器
16、中设定的时间，如果是，则产生新的定时器事件。因为定时器没有一个单独的任务，所以是采样轮训的方式检查是否有新的定时器事件产生，而不是根据系统时钟中断进行检测，因此会比较占用系统资源。定时器的启动和修改使用接口 osip_gettimeofday 和 add_gettimeofday。只需要设定定时器的超时时间，即设定了一个新的定时器。取消一个定时器，只需要修改定时器的 timer-tv_sev 为-1。Q/CT XXXX.1-2008中国IMS网络SIP协议规范总体技术要求 - 7 -3.1.2 报文触发的事件_ e X o s i p _ t r a n s a c t i o n _ i n
17、 i to s i p _ n e w _ o u t g o i n g _ s i p m e s s a ge ( i n v i t e )o s i p _ t r a n s a c t i o n _ a d d _ e v e n t ( t ra n s a c t i o n , s i p e v e n t )包括一个新的 invite、response 、ack 的发送或接收，除了对非 2xx 的应答 ack 外，其他的请求和应答都会产生一个新的 transaction，并且产生一个新的 sipevent 事件。3.2 osip 的 transaction 的 eve
18、nt 处理流程在 sip 协议栈中为了更快更好的处理 transaction，根据协议栈的描述，划分为四种不同的 transaction，分别为 ICT、 IST、NICT 和 NIST。四种不同的 transaction 会有不同的处理流程和状态转换表，以及使用到不同的定时器。ICT、IST、NICT 和 NIST 的状态转换采样注册函数处理方式，为便于管理和使用注册函数，源码中使用了四个全局变量管理四种不同类型 transaction 的转换表：ict_fsm、 ist_fsm、nist_fsm 和 nist_fsm。osip 结构如下：struct osipvoid *applicati
19、on_context; /*300 时，client 端发送ACK，当重复接收到该 invite 的 response 时，重发该 ACK，确保 server 端在 kill tranction前能接收到 ACK。3.2.2 IST 的处理流程同 ICT 的处理流程，处理 osip 中的 osip_ist_transaction 链表。 IST 的相关 event 的注册处理函数在 ist_fsm.c 文件和 ist.c 文件。IST 使用了定时器 TIMEOUT_G、TIMEOUT_H 和 TIMEOUT_I。使用方式与 ICTL 类似，详细见协议栈说明。3.2.3 NICT 的处理流程同
20、ICT 的处理流程，处理 osip 中的 osip_nict_transaction 链表。 NICT 的相关 event 的注册处理函数在 nict_fsm.c 文件和 nict.c 文件。NICT 使用了定时器 TIMEOUT_E、TIMEOUT_F 和 TIMEOUT_K。Q/CT XXXX.1-2008中国IMS网络SIP协议规范总体技术要求 - 10 -3.2.4 NIST 的处理流程同 ICT 的处理流程，处理 osip 中的 osip_nist_transaction 链表。 NIST 的相关 event 的注册处理函数在 nist_fsm.c 文件和 nist.c 文件。NIS
21、T 使用了定时器 TIMEOUT_J。3.3 Osip 报文的解析3.3.1 sip 协议报文的解析整理流程当接收到一个 message 的时候，需要解析该 message，生成一个代码能够处理的数据结构，该结构定义为 struct osip_message，该结构定义的一个 message 的全部相关信息，这些信息主要是供 transaction 和 dialog 及 dialog 的更上一层如 call，notify 等的使用。对一个 message 的解析流程如下图所示：o s i p _ m e s s a g e _ p a r s e_ o s i p _ m e s s a g
22、e _ p a r s eo s i p _ u t i l _ r e p l a c e _ a l l _ l w s_ _ o s i p _ m e s s a g e _ s t a r t l i n e _ p a r s em s g _ h e a d e r s _ p a r s em s g _ o s i p _ b o d y _ p a r s e在接收到一个 message 时，调用函数 osip_message_parse 进行 message 的解析。首先调用函数 osip_util_replace_all_lws 替换掉 message 中的连续出现的
23、rnt、 rt、 nt、rn 、 r 、 n 为空格，message 是以0为结束标志的，message 的 headers 和body 之间的分界是以rnrn为标志的，替换只替换到rnrn为止，即只替换 headers 部分出现的t、r、n。由于 sip 协议栈规定，每个 headers 都是起新行，而且新行的头一个字符不为空格或t，所以两个 header 之间的rn 不会被替换掉，替换的只是一个允许 multi 合Q/CT XXXX.1-2008中国IMS网络SIP协议规范总体技术要求 - 11 -并项的 header 的内部多个值之间的“rnt”或“rn ”。举例如下：有两个 heade
24、r，其中 Subject 只允许单个值出现， Route 允许有多个值出现，而且允许分行，但是分行必须以空格或t 开头，而 Subject 和 Route 行必需顶格开始，前面是没有空格或t 的，osip_util_replace_all_lws 函数将 Route header value 中的两行间的rnt 转化为空格，即在逻辑上就成为一行了。Subject: Lunch Route: , 一个 message 由三部分组成，首先是 message 的 startline 部分，该行指明这是一个 sip的 message，包括 sip 标志，请求或应答说明，状态值，然后以rn 做为和 he
25、aders 的分隔符。该rn 不会被 osip_util_replace_all_lws 替换为空格，如请求的 INVITE sip: SIP/2.0 或应答的 SIP/2.0 200 OK，在三个属性之间有且仅有一个空格。起始行的解析由_osip_message_startline_parse 进行解析，解析得到message 的类型，message 的 sipversion 以及 message 的 status_code，当status_code 为初始化值 0 时，该 message 为一个请求，否则为应答。请求的startline 由_osip_message_startline_p
26、arsereq 进行解析，得到请求的request_uri;应答的 startline 由_osip_message_startline_parseresp 进行解析。Startline 部分的解析是严格安装出现的三个属性的顺序进行解析的，并将解析结果保存在osip_message 的结构成员变量中。然后解析 messge 的 headers 部分，调用函数 msg_headers_parse。说明见osip 的 header 报文头解析。如果 message 中在 headers 之后不是结束符 0，则继续解析 message 的负载部分，调Q/CT XXXX.1-2008中国IMS网络SI
27、P协议规范总体技术要求 - 12 -用函数 msg_osip_body_parse 进行解析。Message 的 body 解析首先查询 headers 头解析中保存的 content即 body的属性：content_type，如果 content_type 中的 type 不为multipart，即不支持多种 mime 方式的 content，说明 body 中就一个编码方式，直接将整个body 解析为一个内容；如果 type 为 multitype，说明有多个编码方式的 body 组合在一起形成一个整体的 body，则以”-”为分隔符解析 body，将 body 分为多个 mime 编码
28、方式的字符串，每个解析后的 body 内容保存在 osip_message 结构中的 bodies 结构成员中。3.3.2 Osip 报文头的解析m s g _ h e a d e r s _ p a r s e_ _ o s i p _ f i n d _ n e x t _ c r l fS t a r t _ o f _ h e a d e r 0 为 0Y e sh e a d e r 解析成功 ，b o d y 为 N U L LN o获取下一个 r n ， 保存位置到e n d _ o f _ h e a d e rf a i lS u c c e s s返回 e r r o rS
29、 t a r t _ o f _ h e a d e r 为 r 或 nY e sn o返回成功 , b o d y = s t a r t _ o f _ h ea d e ro s i p _ m e s s a g e _ s e t _ m u l t i p l e _ h e a d e rh e a d e r 解析 s u c c e s s , s t a r t _ o f _ h e a d e r = e n d _ o f _ h e a d e rn oY e s ， 解析下一个 h e a d e rY e s ， 解析下一个 h e a d e r在解析 mes
30、sage 的 header 的时候，因为前面的 osip_util_replace_all_lws 已经转化了单个 header 内部出现的r、n 和 t 为空格，所以每个 header 之间可以使用rn 做为分隔符进行分隔。如果字符串开头 start_of_header 已经到达结束符”0”，则全部 header 解析完毕，返回成功；调用_osip_find_next_crlf 找到这个 header 的结束字符并保存在 end_of_header 中；如果 start_of_header 为r 或n ，则已经解析到rnrn 即 headers 的结束字符串，则返回成功，并且保存 start
31、_of_header 到 body 中，即 body 是从rn 字符串开始解析的，所以在 body 解析时，需要跳过rn 及之后的空格部分；根据 header 内部分隔符 “：” ，取出 header 的Q/CT XXXX.1-2008中国IMS网络SIP协议规范总体技术要求 - 13 -hname 和 hvalue，其中 hvalue 在某些 hname 的情况下是允许为空的，然后调用osip_message_set_multiple_header 来解析该 header 的 hvalue 字符串；解析成功后，置start_of_header 为已经解析完的 header 的 end_of_
32、header，开始解析下一个 header。在 osip_message_set_multiple_header 中，将 headers 分为两类，一类如上面例子中的Subject，只允许一个值，则直接调用 osip_message_set_header 进行解析；一类如上面例子中的 Router，允许多个值，根据 sip 协议，每个值之间以“， ”进行分隔，所以需要查询整个 hvalue 字符串，根据”,”将 hvalue 分隔成多个值，每个值调用 osip_message_set_header进行解析并保存解析结果到 osip_message 的数据成员变量中。因为 hvalue 允许使用
33、引号将值引起来，所以需要特别处理“， ”是否出现在引号内部的问题。只有在引号外部的“， ”才是 header 值的分隔符，而内部的“， ”只是一个 header 值的一部分。osip 源码中 osip_message_set_header 对于 message headers 的解析采用注册函数的方式实现，采用这种方式能够在后继版本很方便的进行新的 header 的添加，并且不会影响到整个源代码的框架流程。Osip_parser_cfg.c 文件中定义了 header 头解析所使用到的全局管理变量： static _osip_message_config_t pconfigNUMBER_OF_
34、HEADERS;_osip_message_config_t 的结构定义如下：typedef struct _osip_message_config_tchar *hname;int (*setheader) (osip_message_t *, const char *);int ignored_when_invalid;_osip_message_config_t;hname 为 sip 协议定义的头字段的字符串，这些字符串定义在 osip_const.h 文件中；函数指针 setheader 为该协议 header 的对应的解析函数；ignored_when_invalid 为是否忽略该
35、header 解析错误的标志，该标志值为 1 时，在解析该协议 header 发送错误时，忽略该错误，除 sip 协议规定的几个必要 header 之外，其他头应该采用忽略方式。为了更快的根据 header 的 hname，找到对应的 setheader 解析函数，采用了 hash 表的查询方式，根据 hname 生成一个 hash 值，并且需要保证没有两个不同的 hname 对应到同一个 hash 值中，以提高查询的速度。调用 _osip_message_is_known_header (hname)获取到Q/CT XXXX.1-2008中国IMS网络SIP协议规范总体技术要求 - 14 -
36、在数组中的 index, 调用_osip_message_call_method (my_index, sip, hvalue)解析协议header，并且解析的结果保存在结构 osip_message_t * dest,中。每一个 header 都包含几个通用的操作：header 字符串的解析函数，即上段讲到的osip_message_set_xxx 解析函数；header 解析后的结构的获取函数，osip_message_get_xxx函数；根据 header 解析后的结构生成字符串的函数：osip_xxx_str；header 解析后的结构的copy 函数 osip_xxx_clone；h
37、eader 解析后的结构的是否函数：osip_xxx_free ；以及 header解析结构的初始化函数：osip_xxx_init。对每个 header 的几个相关操作最终目的是提供协议的整个 header 的整体操作，包括osip_message_init，osip_message_free ，osip_message_clone 和 osip_message_parse。3.3.3 uri 的解析绝大部分的 header 的解析都是相识的，只有其中有参数的部分的 header 的解析会比较复杂，最主要的有 from、to、 contact 等，因为除了本身就有参数之外，其值中的reque
38、st_uri 本身也可以包含有参数，而这两种参数之间是有区别的。Sip 协议栈规定 header 的表示分为 headers name, headers value 和 headers parameter。其中 name 和 value 之间用“：”分隔，value 与 parameter 之间用“；”分隔，parameter 之间也使用“；”相分隔。在结构定义中 header 的 value 根据具体 header 包含的信息进行结构变量的定义，而如果包含 parameter 则直接定义一个 gen_params 的链表，所有的 parameter 都保存在这个链表中。如下面 from 的定
39、义，包含有 from 的名称及一个 url，及相关的 parameter：struct osip_fromQ/CT XXXX.1-2008中国IMS网络SIP协议规范总体技术要求 - 15 -char *displayname; /*”括起来，以表示一个完整 url 部分。所以解析 from 等 header 时需要检查是否包含” o s i p _ i s t _ h a s t a b l e , . . . )T o p _ v i a 中有 b r a n c h _ i dy e sn oI n v i t e o r A C Ky e sn od i c t _ s e a r c
40、 h ( o s i p - o s i p _ n i s t _ h a s t a b l e , . . . )_ _ o s i p _ t r a n s a c t i o n _ m a t ch i n g _ r e q u e s t _ o s i p _ t o _ x is t _ 1 7 _ 2 _ 3H A V E _ D I C T _ D I C T _ HY e sn od i c t _ s e a r c h ( o s i p - o s i p _ i s t _ h a s t a b l e , . . . )T o p _ v i a 中有
41、b r a n c h _ i dy e sn oI n v i t ey e sn od i c t _ s e a r c h ( o s i p - o s i p _ n i s t _ h a s t a b l e , . . . )_ _ o s i p _ t r a n s a c t i o n _ m a t ch i n g _ r e s p o n s e _ o s i p _ t o _x i c t _ 1 7 _ 1 _ 3E V T _ I S _ I N C O M I N G R S Pn oY e s遍历 t r a n s a c t i o n
42、匹配 t r a n s a c t i o n i d3.5 osip 中 dialog 的管理dialog 的相关的管理操作包括 dialog 的初始化建立过程，dialog 的销毁 free 过程，以及dialog 的匹配。此外 dialog 中保存了相关的路由信息和 cseq 信息。Dialog 结构如下，由 call_id、local_tag 和 remote_tag 唯一确定一个 dialog：struct osip_dialogchar *call_id; /*=1 且有 transaction 的 register，r_id 1 或者没有 last transaction 的
43、register 是已经被删除的 register，不需要处理。i. 如果重发时间不为 0，既该 register 需要一直重新发送注册，且注册时间已经超时，该 register 从注册完到现在已经超过 900 秒，则调用函数eXosip_register_send_register 进行重注册。ii. 如果注册时间到现在为止 大于规定的重注册时间间隔 -60 秒，也发起重注册，既如果设置了重注册时间间隔，必需在重注册时间间隔到达之前的 60 秒就开始发起重注册。iii. 或者如果需要重注册，而且离上次注册时间已经超过 120 秒，并且没有接收到注册服务器的应答或者应答不是成功注册的应答，则也
44、发起重注册。iv. 如果还未设置需要重注册，即第一次注册失败，且是因为认证失败而引起的注册失败，则检查注册类型。如果是 WPDIF 注册方式，则检查回复中的认证码 nonce 是否和上一次注册失败时保存的 nonce 值相同，如果相同则发起重注册；如果注册方式不是 WPDIF，则直接发起重注册。为了保证 WPDIF 注册方式的成功，在第一次注册失败时，需要提取当次服务器端的回复中的 nonce 值，以便在确定是否发起重注册的时候判断条件为真。c) Notify、subscription、pub 的处理同 call。4.3 Call 的处理在 exosip lib 库中除了一直在运行的处理对端发
45、送过来的 message 的线程外，还提供了本端做为发送端发送各种 request、ACK。因为所有的 message 最终都属于某个 transaction，而且对 message 的处理最终都放在transaction 的 event 队列中进行处理，所以所有提供的包括call、 notify、publish、register、subscription 、refer 等功能都是通过生成一个 transaction 上的 event 事件与一直运行的处理线程进行联系，当生成 event 之后，处理线程在轮询所有transaction 时会处理到这些 event，当某个 event 需要立即处
46、理的时候，则可以手工启动event 的处理线程，而不需要等到该处理线程处理到该 transaction。Exosip lib 库提供了 call 的 4 类接口：第一次建立一个 call 的 initial invite 创建及发送接口；在 dialog 中创建及发送的其它 request；在 dialog 中创建及发送对从对端发送过来的request 的 response；在 invite 请求中回应对端 response 的 ACK 的创建和发送。4.3.1 创建 Call 的第一个 INVITE在 excall_api.c 文件中的 eXosip_call_build_initial_invite 和
