resiprocate阅读心得

**Address-of-Record****:Address-of-Record(AOR)是一个SIP或SIPS URI,它指向带位置服务的一个域,位置服务可以将一个URI与另一个URI(可能找到用户的URI)映射。典型的,通过注册来填写位置服务。通常认为AOR是用户的“公开地址”。(sip proxy中查找用户用的)

**ome Domain****:此域为SIP用户提供服务。典型的,它通常是注册的记录地址中URI中出现的域。

**Registrar****:注册员是服务器,它接收REGISTER请求,并把从请求中接收的信息放入其所在的域的位置服务中

**SIPTransaction****:SIP事务在客户端和服务器之间发生,包含从客户端向服务器端发送的第一个请求到服务器端向客户端发送的最后一个响应(非1xx)间的所有消息。如果请求是INVITE而最后的响应不是2xx,那么事务也包含响应的ACK。INVITE请求的2xx响应的ACK是一个独立的事务。

**Transaction User(TU)****:传输层上的协议处理层。事务用户包括UAC核心、UAS核心和代理核心。

**Call-ID** Call-ID头字段作为集合一系列消息的唯一标识符。在对话中,每个UA 发送的所有请求和响应中,Call-ID 必须是一样的。UA 的每个注册中,它应该是一样的。

在UAC 创建的对话外的新请求中,如果不是特定方法行为覆盖的,UAC选择的Call-ID头字段必须是在时间和空间上全球唯一的标识符。所有的SIPUA必须有一种方法来保证其他UA 不会产生它们产生的Call-ID头字段。注意,当在特定的失效响应后,重发请求以修正请求时(如,认证挑战),重的请求将不作为新的请求,因此不需要新的Call-ID 头字段;

推荐在生成Call-ID 时,使用密码学上的随机标识符(RFC 1750 [11])。执行时可以使用这种格式“localid@host”。Call-ID 是区分大小写的,并且逐字节比较的。

使用密码学上的随机标识符提供了会话截获保护,并减少了Call-ID 冲突的可能性。

对于选择请求的Call-ID 头字段的值,不需要规章界面或用户界面

**CSeq** CSeq头字段是用作识别和指示事务的。它由序列号和方法组成。此方法必须和请求相匹配。对于对话外的非REGISTER 请求,此序列号是任意的。此序列号的值必须是值小于2~31 的32 位的无符号整数。只要遵循上述原则,客户端就可以随意地使用一种机制来选择CSeq 头字段值。

refer:访问一个URL或者URL资源,URL可以是另外一个UA,可以是个网页。如果返回2xx,之后要发送Notify,来发送访问url或者url资源的结果

target指的是Contact

---

DUM模块

---

EncryptionManager:应该是给发送/接收的消息的消息体进行加解密的,保证sip body的安全性,暂时不用管.

HandleManager用来管理Handled,Handled和handle id是松耦合关系。

AppDialog:将一个Dialog和一个handle绑定到一起,注意,handle和dialog id不一样,handle是自动生成,递增的,dialog id是可以设置改变的。

AppDialogSet:生成一个AppDialog,其他的好像没啥卵用。

AppDialogSetFactory:生成一个AppDialogSet,更没什么卵用,搞得那么复杂。

BaseCreator:生成一个sip request message.

BaseUsage:继承于Handled,有一个DialogUsageManager成员变量,从这个类继承出来的类有了handle和处理消息的能力,所以,这个类称为BaseUsage(基本有用,不再是废柴类)

DialogUsage:继承自BaseUsage,Dialog作为成员变量,所以可以获取到dialog的各种信息,并且这个类中有一个内嵌内DialogUsageSendCommand,所可以发送DialogUsageSendCommand消息,可以同时发送SipMessage和DialogUsageSendCommand,

Message:有一个TransactionUser成员变量

TransactionUser:一个sip事务,有一个Fifo队列和一个拥堵算法CongestionManager,一个RuleList,一个DomainMatcher。有了Fifo,就可以post,get sip message了!!!

CertMessage:继承自Message,好像用处不大,加密消息的时候有用到

ChallengeInfo:间接继承自Message,成员变量有Failed,ChallengeRequired和transactionId,应该是server向client Challenge的时候用到

ClientAuthExtension:客户端接受Challenge时候的处理,但是奇怪的是这个类没有实现,导致这个类现在貌似没什么卵用,在ClientAuthManager通过ClientAuthDecorator类中调用了此类

ClientAuthManager:处理服务端发送过来的Challenge,作为客户端向服务起发起请求,接收Challange时候用到。(关注此类)

InviteSession:继承自DialogUsage,包含了本地和远端的sdp,对端支持的sip方法,编码,语言,mime type,user agent,发送reinvite(比如,在音频会话建立成功之后又想加入视频),这个类就是发送invite session相关的消息,和处理invite session相关的回应

包含的方法:

requestOffer:向远端发送一个reinvite,来请求一个sdp

provideOffer:向远端发送一个包含sdp的invite请求,或者包含sdp的ack(看InviteSession现在的状态)

provideAnswer:向远端发送一个ack

end:发送一个bye

reject:发送一个status code的response

sessionRefresh和targetRefresh:优先发送Update,如果自己或者对端不支持此方法,则发送一个reinvite

refer:发送一个refer

info:发送一个info(比如通话过程中发送用户的拨号)

message:用户间的短消息通信(比如IM消息)

dispatch:处理sip消息

dispatchConnected:调用dum的mInviteSessionHandler, dum的mInviteSessionHandler可以有上层开发者实现,通过这种办法就实现了对sip消息请求的处理

ClientInviteSession:继承自InviteSession,

dispatch一方面可以dispatch消息,另外一方面可以dispatch timer

ServerInviteSession:继承自InviteSession

ClientOutOfDialogReq:非dialog消息(register, publish, pager消息)

ApplicationMessage:应用层的message,非sip message

Dialog:有两种情况有dialog,invite和subscribe,Dialog用来记录对话的信息(call ID, contact, remoteTarget, local name等,并把各种消息分发到各个地方InvisionSession, ServerSubscription,ClientSubscription等),在Dialog中创建了InviteSession

DialogEventStateManager:管理DialogEventState,这个类最重要的用途应该是回调了DialogEventHandler,让应用层用户有机会处理trying, eraly, processeding, confirmed等dialog消息

DialogSet:管理Dialog,除此之外,好像也做了很多东西,分发各种消息(register,subscribe等 ),不过貌似都没被调用

DialogUsage:里面有个Dialog的成员变量,没咋搞明白这个类的意义,难道XXUsage这种类都是提供给上层用户用的吗?

DialogUsageManager:大名鼎鼎的DUM,从fifo中取出消息,发给各个处理的handle,DialogUsageManager调用SipStack的send从而向SipStack的fifo中传数据,同时 DialogUsageManager又向SipStack注册了自己(因为DialogUsageManager继承自TransactionUser),所以SipStack可以向DialogUsageManager 的fifo中发送数据,从而实现了DialogUsageManager和SipStack之间的数据传递!!!

DumThread:不停的从dum的fifo中取出消息,调用dum的internalProcess来进行处理,

UserProfile和MasterProfile:传入协议栈的配置,决定了协议栈的能力

DumTimeout:是一个application message,表明各种(register,subscribe,cancel等)超时

KeepAliveManager:用来定时发送心跳sip消息的,不过发送的是option,不是register,28181要求发送register

ServerAuthManager:貌似是服务端处理challage的(待确定)

ServerRegistration:继承自NonDialogUsage,server用来处理客户端注册的类

UserAuthInfo:貌似存储了签名时候用到的一些信息

BaseCreator:最重要的功能:用来生成一个initial request

---

Sip Stack模块

---

Aor:从一个url中解析出来scheme,user,host,port的

BasicNonceHelper:生成/解析nonce

Contents:sip message的body

SipStack:核心类,

setEnumDomains:设置domain

TransactionControllerThread:接收sip 网络消息的线程

StackThread:sip协议栈的线程

ConnectionManager:管理这tcp,udp的接收,发送

Transport

pushRxMsgUp方法:把接收到的sip消息放入fifo

你可能感兴趣的:(resiprocate阅读心得)