您好,欢迎访问三七文档
当前位置:首页 > 临时分类 > Resiprocate注释
1Resiprocate介绍1.前言本文主要内容来自互联网,特此感谢Steven的辛苦撰写和resiprocate开源组织的无私奉献以及sip协议的创造者Schulzrinne教授和Rosenberg大师的辛勤工作。2.从SIP谈起说明:不期待一次就把RFC3261或者其他的协议文档内容及其细节全部记住或者完全理解;把原理性的东西及其脉络厘清也许更重要;在调试程序和看协议栈源码的过程中我的做法是一直把RFC3261(经常的是那份中文文档的文档打开;遇到忘记或者不是太明白的概念和内容就在文档中再搜索相关主题及内容来看看;经常会碰到这样的问题,我发个内容给SIPProxy或者SIPServer,可是并没得到我希望的回复或者与期待的回复内容有出入,这时,我的经常做法是再去研读协议的相关定义,看看是不是我哪个细节并没理解深入或者引起注意,导致我发出去的内容与协议标准有出入或者我的流程与协议定义不吻合。接下来的内容是前人的文档整理,只是个大概,如果没兴趣,完全可以跳过不看;协议栈部分基本上是分成DUM与Stack两部份可以先后看,也可以先看Stack部分。补充说明:文档中的大部分图片都来自网上公开的资料,只有少数几幅是自绘,因此出现内容不清和误导,概不负责特此感谢借鉴资料和图片的原创者们,虽然他们并不知道又误导了一个菜鸟。2.1SIP(SessionInitiationProtocol)简介最先由美国哥伦比亚大学的HenningSchulzrinne教授在1998年初开始发起,1999年3月由IETF的MMUSIC(MultipartMultimediaSessionControl)工作小组制定正式标准成为RFC2543,1999年9月IETF成立新的工作小组,负责SIP新版本2.0的制定,并于2000年7月释出初版RFC2543bis,于2001年发布了RFC3261。RFC3261的发布,标示着SIP的基础已经确立,随后又发布了几个RFC增定版本,充实了安全性及身份认证等几个领域的内容,例如RFC3262对临时响应做了可靠性的规范。RFC3263确立了SIPproxy的定位规则。RFC3264提供了Offer/AnswerModel,RFC3265则是确立了具体的事件通知。如同Internet一样,SIP易于理解、扩充、及实做,作为IETF2的规范,SIP将Internet开放标准的精神延伸至通讯领域,实现了不同计算机、电话、及软件的通讯。SIP的讯息类似于HTTP(RFC2068),其寻址方式,则是重用了SMTP的寻址方式,SIPaddress(如:sip:inaba@ssl.es.ncku.edu.tw)与E-mailaddress的结构相同,SIP甚至利用Web的体系结构,如DNS,而使得SIP的使用者之间的通讯,有更高的扩充性。SIP有下列几点特性利用文字(Text-based)的方式来编码,类似HTTP/1.1Client-Server的架构Clients端初始一个呼叫(caller)Servers端响应呼叫(callee)Signal与media独立,SIP负责signal部分,media传送部分可以使用RTP等,可与其它IETF所制订的协议配合,例如:RFC2327(SDP),RFC2616(HTTP/1.1),RFC2396(URL)…2.2SIP命名方式SIP的地址称做SIPURLs,其格式为user@host:port,使用者利用REGISTER的SIPrequest来结合自己的SIPURLsuser代表使用者名称或是电话号码host代表domainname或是数字型态的IPaddress举例来说sip:inaba@pku.edu.cn或是sip:25643588@140.92.61.552.3SIP组件介绍在SIP是一个ClientandServer的架构,在此环境当中,有三个主要的组件分别为:UserAgents,Servers还有LocationServers。UserAgents在SIP环境中是终端设备,主要负责产生SIPrequests,用来建立多媒体会议(mediasession),并且传送及接收多媒体资料。UserAgents又分成了UserAgentClient(UAC)及UserAgentServer两种模式。UAC负责产生一个Request及处理一个Response,UAS怎是接受一个Request并且产生response。在Session建立过程中,UA通常需要接替着扮演这两个角色。这点并不像其它ClientandServer架构,例如HTTP,PC一直扮演着HTTPclient的角色,而WebServer也一直扮演着HTTPServer的角色。Servers3根据RFC3261中定义,Server主要分成了Proxy,Redirect,以及Registrarserver。SIPproxy:负责接受UA或其它proxy所发送的SIPRequest,并且转送Request到其它地方。RedirectServer:负责接受UA或其它proxy所发送的SIPRequest,并且传回redirectionresponse(3xx),指出这个Request应该送往何方。RegistrarServer:负责接受SIPregistrationrequests,并且更新SIPUA在LocationServer或其它数据库当中的信息。SIPproxy,Redirect还有Registrarservers只有做单纯的signal转送,他们没有传送media及产生SIPRequest的能力。Proxy,Redirect,以及Registrarserver只是逻辑概念定义的不同而物理实现上完全可以在同一物理位置实现。LocationServers:在RFC3261中,通常当作一个数据库来使用。数据库当中可以存放使用者的信息,例如URLs,IPaddress,或是其它资料等等。SIPUA不能直接来存取Locationserver,而是透过proxy,redirect,或是registrarserver。2.4SIPmessageSIPmessage的语意及表头与HTTP/1.1(RFC2616)相同。可以分成两类,一类是Request,另外一类是Response。在RFC3261当中,定义了六个基本的SIPrequest种类,如表2.1所示。方法说明INVITE建立会话SessionACK对INVITE做最后的确认BYE结束一个已经存在的会话CANCEL取消尚未建立联机的会话REGISTER注册使用者的URLOPTIONS查询Server及其功能表2.1、SIPmethodsResponse用status-codes来表示响应的内容,符合且扩展了HTTP/1.1responsecode。分成Provisional(暂时)及Final(最终)两类,Provisional为1xx系列,Final则包括了2xx,3xx,4xx,5xx,6xx等系列,表2.2表示各个不同类别的Response。方法说明41xxInformational2xxSuccessful3xxRedirection4xxClient-Error5xxServer-Error6xxGlobal-Failure表2.2、SIPResponse1xxInformationalresponses指的是server或是proxy正在执行一些未来的动作,并还没有一个定义好的response。2xx代表这个request是成功的,并且必须结束一个搜寻的动作。3xxRedirection会回复欲通讯的使用者目前的位置信息。4xxresponse是Server对于UAC所提出的request回复一个失败的response。5xxresponse是代表Server本身发生了错误。GlobalFailures6xx指的是server有一个关于特定的使用者最终的信息,不仅仅是这个特定的Request-URI,所有未来的对这个使用者的搜寻都应该被终止。表2.3为几个常用的Responsecode范例ResponsecodeReasonPhrase100Trying200OK302Movedtemporarily403Forbidden503ServiceUnavailable600Busy表2.3、SIPResponsecode2.5SDPSIPmessagebody当中,可以携带任何的资料,但通常是给通讯双方用来协商session相关的信息。SIP本身并没有提供多媒体协商的能力,多媒体协商必须仰赖SessionDescriptionProtocol(SDP),SDP本身并不是一个通讯协议,它的描述语言是基于文字的。SIP利用answer/offer的模式来使用SDP。呼叫者送出一个INVITE讯息并携带着SDP,其中SDP包含了呼叫者想使用的多媒体的格式、地址、Port,被呼叫方在响应的时候,便可以针对呼叫者所提出的SDP,做出接受或拒绝的响应,这种双方协商的结果,就可以得知多媒体资料格式及通讯的地址为何。SDP定义在RFC2327当中,后来经过修订及汇集draft之后,发表了RFC3264“AnOffer/AnswerModelwithSDP”,RFC3264明确的描述应该如何将SIP与SDP一起使用。SDP简单地提供一个描述session信息的格式。基本而言,一个session是由数个mediastream所组成,因此,要描述一个session必须要有数个相关的参数。SDP当中有session-level与5media-level的参数,session-level的参数包含了session的名称、session的发起者、session的期限等等。Media-level的信息包含了media的种类,portnumber、传输协议以及media的格式。图2.1为SDP的结构。SessionDescriptionSessionLevelProtocolVersionOriginatorandSessionIDSessionNameSessionTimeMediaNameandTransportConnectionInformationMediaDescription6图2.1SDPsessionDescriptionStructure2.6SIP运作模式SIP的呼叫建立如图2.2所示,开始的时候caller会送出SIPINVITE的讯息给callee,callee收到之后,会马上响应一个100Ringing的讯息通知caller,说明目前callee已经收到INVITE讯息且正在处理中,如果callee愿意与caller通话,便会送出200OK的response,最后caller再送出ACK,此时便可以开始进行会议。当其中一方想结束通讯时,便会送出BYE的讯息来通知对方,对方响应200OK便可以结束目前进行会议。Client(Caller/UA)Server(Callee/UAS)INVITE100:Trying180:Ringing200:OKACKBye200:OKRTP7图2.2SIPcallflow2.6.1SIPproxy模式以图2.3为例,caller(inaba@work.com)先送出一个INVITE讯息呼叫callee(yucho@work.com),proxyserver收到之后便会去做查询,查询完成之后便得知目前callee实际的地址在yucho@home.com,于是proxyserver便会以yucho@home.com为对象发出INVITE讯息。callee在回复200OK的时候,会将200OK的response响应给proxyserver,再由proxyserver转送给caller。2.6.2SIPRedirect模式如图2.4所示,与proxyserver不同的地方,在于redir
本文标题:Resiprocate注释
链接地址:https://www.777doc.com/doc-2855254 .html