当前位置: 首页 > 工具软件 > oSIP > 使用案例 >

osip的一些知识

权韬
2023-12-01

当需要创建新的ICT的transaction时,TIMEOUT_B被启动,时长为64*DEFAULT_T1(DEFAULT_T1为500ms),TIMEOUT_B为整个transaction的生命周期时长,如果超过这个时间,transaction会被结束。

如果传输层是没有传输保证的UDP,则设置TIMEOUT_A、TIMEOUT_D的间隔时间为DEAULT_T1和64*DEFAULT_T1;

如果传输层使用的是面向连接的TCP,则直接使用TCP内部的重传机制,不在SIP层提供传输的保护机制,不启动TIMEOUT_A、TIMEOUT_D

TIMEOUT_A管理Invite的发送,发送时启动TIMEOUT_A,如果超时还没收到response,则重发该Invite;
TIMEOUT_D管理ACK

每个header都是起新行,且新行的头一个字符不为空格或\t
header和body之间的分界为‘\r\n\r\n’ ,message是以‘\0’为结束标志

header内部分割符 ‘:’ 取出header的hname和hvalue

Subject只允许一个值 , 而Router允许多个值,每个值之间以“,”进行分割

osip中对于header的解析采用注册函数的方式实现,能够方便的在后续版本中添加新的header,而不影响整个源代码的框架流程。

SIP协议栈规定header的表示分为header’s name header’s value 和header’s parameter,其中name和value之间用“:”分隔,value与parameter之间用“;”分隔,parameter之间也使用“;”相分隔。

url分为三部分 :url的基本信息,url的header头部分和url的参数部分。开始部分与header头部分用个“?”分隔,
header头之间用“&”进行分割,header头部分与参数部分用“;”分割,参数之间有使用“;”分隔

如果url中包含parameter,则整个url必须使用“<” “>” 括起来,以表示一个完整的url部分。所以解析from等包含url的header时需要检查是否包含“<” 字符

根据sip协议描述 一个transaction由5个必要部分组成:from、 to、 topvia、 call-id 和 cseq,整个5个部分一起识别某一个transaction,缺少然和一部分,该transaction就会设置失败。

每个部分都有一个设置函数,对于发送端topvia为自己的via,对于接收端topvia为将messags转发到自己的最后一个sip-proxy服务器
_osip_transaction_set_call_id用于设置一个dialog的标识值,改值是随机生成的,算法保证很长一段时间内生成的call_id不同;
_osip_transaction_set_cseq用于设置cseq值,该值在同一个dialog内部是一直保持增长的,即同一个dialog的后面的transaction的cseq会比前面的transaction的值大,按照sip协议其初始值可以是随机数,代码实现中如果是register请求,从1开始,如果是非Register请求的dialog,从20开始。

transaction的初始化发生在接收到一个新的请求或者发送一个请求的时候,该请求经过解析成为一个可以直接使用请求信息的结构osip_message_t。初始化在设置完from、 to、 topvia、 call-id 和 cseq5个部分后(都有自己的设置函数),还需要初始化event队列,根据osip_message_t的type初始化用到的定时器结构,入ICT的ict_context. 其他部分的初始化都在exOsip源代码中实现。

transaction匹配是根据topvia的branch_id是否相同,如果相同就是同一个transaction的请求和应答及ACK。同时,为了兼容旧版本,也支持call_id、cseq,from_tag, to_tag 来匹配transaction。

transaction匹配过程中,如果是发出的请求,因为本地的transaction都会分配一个不重复的transaction_id,所以只需要匹配transaction即可;对于incoming的message按照上边的匹配

dialog保存了相关的路由信息和cseq信息;
dialog由call_id、local_tag和remote_tag唯一确定一个dialog

exOsip
为支持多线程间的通信,在两个线程间采用pipe的方式进行实现

message中的状态码,如果是0说明是一个请求,如果不为0,则是一个response

在处理接收到的message时可能会创建新的call、新的transaction、生成新的transaction的event,还有exosip的event。

匹配dialog比匹配transaction条件简单,多个transaction可以属于同一个dialog。

eXosip_automatic_action用于处理那些认证失败的call、register、notify、publish等,

所有的message最终都属于某一个transaction,而且对message的处理最终都放在transaction的event队列中进行处理,所以所有提供的包括call、notify、publish、register、subscription、refer等功能都是通过生成一个transaction上的event事件与一直运行的处理线程进行呢联系,当生成event之后,处理线程在轮询所有transaction时会处理到这些event,当某个event需要立即处理的时候,则可以手工启动event的处理线程,而不需要等到该处理线程处理到该transaction。

在dialog创建之前构建INVITE请求,调用的接口为out_of_dialog,即不需要从dialog中获取信息;
如果是在dialog中构造新的请求,其新的request的local cseq number必须大于dialog中的local cseq number,并且因为属于同一个dialog,所以其call_id,from_tag,to_tag必须与dialog相同。

initial invite用于创建一个新call时,在发送initial Invite时,创建一个new call,并且为该Invite创建一个新的transaction,应为整个call是由该transaction创建的,当该transaction到complete状态时该call就建立起来了,但此时并不建立dialog,因为dialog是两段通信协商后的结果,只有收到对端的非100的1xx应答或>200的应答才会建立一个dialog。
在创建完call和transaction之后,根据要发送的INVITE生成一个transaction上的event,将该event添加到该transaction的event队列中,并将call添加到exosip管理的call链表中,然后给call分配一个call_id,最后唤醒处理线程对transaction上的event进行处理。
两个线程的交互式通过transaction的event队列来完成的,eXosip_call_send_initial_invite只是将要发送的invite生成一个event添加到event队列中,真正的发送在处理线程处理该event时才会进行。。

对request的应答时sip协议栈自动完成的,同时对非2xx的应答也自动完成。

ACK只会出现在INVITE的请求transaction中。
eXosip_call_send_ack,直接发送该ack,不作为一个event添加到transaction是防止中间的消耗时间过长,导致对端的2xx应答重发。 保存该ACK,在对端重发2xx应答时重发该ACK。

dialog内的请求的创建和发送:
如果dialog已经建立完成,创建新的dialog内的请求只需要知道request的类型即可,其他的信息在dialog内部已经保存;
在创建一个新的请求的时候,需要检查是否有未处理的请求存在,应为一个call’内的请求是按照顺序进行处理的,即上一个请求没有处理完,下一个请求不应该发送出去。 其中INVITE请求比较特殊,只要没有INVITE请求没有处理完,就可以发送下一个INVITE请求,而不需要等待像notify、option等的请求。

根据transaction id查询得到call、dialog、transaction的结构

只保存最近一个register的transaction,因为注册必须是串行的,再上一个注册还没有处理完毕的情况下,不允许在同一个注册服务器上发送新的注册请求。

 类似资料: