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

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,242评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,769评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,484评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,133评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,007评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,080评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,496评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,190评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,464评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,549评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,330评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,205评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,567评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,889评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,160评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,475评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,650评论 2 335

推荐阅读更多精彩内容