《SIP培训PPT素材》PPT课件 52页

'RFC2543：SIP协议 目录SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 SIP概要1、定义：SIP(SessionInitiationProtocol)是一种用来建立、更新和终止多媒体会话或呼叫的应用层控制协议，可用来初始化会话，然后邀请成员加入这些已建立和广播的会话。SIP明确地支持名字映射和重定向服务，支持ISDN操作和智能网电话(IntelligentNetworktelephony)用户服务。2、SIP支持五种建立和终止多媒体通信的方式：Userlocation:决定通信的终端；Usercapabilities:决定使用的媒体和媒体参数;Useravailability:决定被叫方加入通信的意愿(willingness);Callsetup:"ringing",在被叫方和呼叫方建立呼叫参数;Callhandling:包括传输和中断呼叫.3、名词解释：CallCalllegClientConferenceDownstreamFinalresponseInitiator,callingparty,callerInvitationInvitee,inviteduser,calledparty,calleeIsomorphicrequestorresponseLocationserverLocationserviceParalledsearchProvisionalresponseProxy,proxyserverRedirectserverRegistrarRingbackServerSessionTransactionupstreamURL-encodedUseragentclientUseragentserverUseragent SIP概要--SIPSERVER不同类型的SIPserver的特征总结：propertyredirectserverproxyserveruseragentserverregistrar_______________________________________________________________________alsoactsasaSIPclientnoyesnonoreturns1xxstatusyesyesyesyesreturns2xxstatusnoyesyesyesreturns3xxstatusyesyesyesyesreturns4xxstatusyesyesyesyesreturns5xxstatusyesyesyesyesreturns6xxstatusnoyesyesyesinsertsViaheadernoyesnonoacceptsACKyesyesyesno SIP基本功能和操作主叫方和被叫方由SIP地址标定；当进行一个SIP呼叫时，主叫方首先定位合适的server；然后发送一个SIP请求，最普通的SIP操作是邀请invitation；SIP请求不是直接到达被叫方，而是可以被重定向或者可以在proxy引发一系列新的SIP请求；users可以在SIPservers注册它们的位置。 SIPAddressingSIP地址所标记的是主机上的使用者。SIPURL的格式类似与telnetURL，例如，user@host，user部分是一个用户名或一个电话号码，host部分要么是个域名，要么是个数字形式的网络地址。被叫方在REGISTER时将自己绑定到这个地址上；呼叫方使用SIP地址与被叫方建立实时通信。SIP地址必须包括主机名，可以包括用户名、端口号和参数等。采用与mailto：、http：等类似的格式，是为了扩展在网页、邮件等的应用。 LocatingaSIPServer一个client希望发送请求时，它要么发送请求到一个本地配置好的与Request-URI无关SIPproxyserver上，要么将请求发送到Request-URI中定义的IP地址和端口上。对于后一种情况，client必须决定协议和将请求发送到哪个端口和IP地址。Client可以通过DNS来查找server，除非另外标明，否则client都应该按照Request-URI中列出的端口号来访问server。如果没有提供端口号，则使用默认值5060。如果Request-URI指明了协议（TCP或者UDP），client就使用指定的协议，如果没有提供协议，则使用UDP，如果失败，或者client不支持UDP，则使用TCP。Client应该能够解析明确的网络提示（例如ICMP消息），而不是只能依赖超时信息。例如，如果client发现server不可到达，它应该按照接到请求返回400类的错误来处理。 SIPTransaction一旦SIPserver能够确定，client就可以向其发送SIP请求或收到响应。一个请求（包括重发的请求）和相关的响应合起来称做一个SIP事务。对于一个请求的所有响应都包含相同的Call-ID,CSeq,To,和From头域的值(但可能在to头域中添加了tag参数)，这种机制可以区分出不同的事务。接在INVITE请求后的ACK请求不包括在同一个事务中，因为ACK在传送时可能会经过不同的路径。如果使用TCP协议，同一个事务的请求和响应会在同一个TCP连接中被传送，同一个client发给同一个server的不同SIP请求可以使用同一个TCP连接，也可以使用新的TCP连接。SIP消息体的格式和操作与传输协议无关。 SIPInvitation一个成功的SIP邀请（INVITATION）包括两个请求：INVITE请求和其后的ACK请求。INVITE请求被叫者加入到一个指定的会议中或建立双方通话，被叫方同意加入呼叫后，主叫方发送ACK确认它收到了对方的同意信息。如果主叫方不再希望加入通话，就会不发送ACK，而是发送BYE。一个典型的INVITE请求包含了一个会话描述（sessiondescription），给被叫者提供了加入会话的足够的信息，对于多方通话来说，SD列举了媒体的类型和格式和媒体数据的返回地址。如果被叫方希望加入会话，它就会返回一个包含了同样SD的响应,在多方会话中，被叫者应该只返回一个SD如果它不能接受呼叫者提出的媒体类型或者它希望加入单方呼叫。 图1Figure1:ExampleofSIPproxyservercs.columbia.eduLocationserverWorkLabcs.tu-berlin.decz@cs.tu-berlin.de1:INVITEhenning@cs.col2henninghgs@lab34:INVITE5:ring6:200OK7:200OK8:ACK9:ACKSIPrequestSIPresponsenon-SIPprotocols 图2cs.columbia.eduLocationserverWorkLabcs.tu-berlin.decz@cs.tu-berlin.de1:INVITEhenning@cs.col2henninghgs@lab34:302Movedhgs@lab5:ACKSIPrequestSIPresponsenon-SIPprotocols6:INVITEhgs@lab.cs.columbia.edu7:200OK8:ACKFigure2:ExampleofSIPredirectserver LocatingaUser被叫者可能会有几个不同的终端号码，这些不同的定位可以动态地向SIPserver注册，一个locationserver也可以使用一个或多个协议算法来决定可能会在哪个终端找到被叫用户。因为用户可能同时注册了多个主机信息或者locationserver没有准确的信息，在这些情况下，locationserver可以返回多个定位。对于多个定位的处理方式：SIPredirectserver：返回给client一个Contact头域，包含了定位的列表；SIPproxyserver：连续地或并发地向这些地址发送请求，直到返回了一个2xx响应，表示呼叫成功，或者一个6xx响应，表示被叫者拒绝。如果一个proxyserver向前传递SIP请求，它必须将它自己的地址加入到via头域的最上方，via头域保证了响应能够沿相同的路径返回呼叫方，从而保证了呼叫能够穿透防火墙，并避免了请求环路。在响应回来的路上，每一个主机都必须从via头域中删除自己的地址。一个SIP呼叫请求可能会经过多个SIPproxy，如果一个proxy向多个定位发送了请求，那么UA可能会接到多个相同Call-ID的请求，那么UA必须返回相同状态码的响应。 ChanginganExistingSession在某些环境中，可能会需要改变已存在的会话的参数，这就需要在再次发送相同的Call-ID，单消息体不同或头域不同的INVITE过程中实现。这个重发的INVITE必须有更高的序列号。例如，双方已经在通话，然后希望加入第三方，转换成多方通话，那么已经在通话的一方用新的多播地址邀请第三方，并且同时要用新的多播SD和旧的Call-ID向第二方重新发INVITE消息。 RegistrationServicesREGISTER请求允许client让proxy或redirectserver知道用什么地址可以找到它。在注册时，client就将自己的SIP地址和自己的IP地址绑定到一起。 SIP协议特点最小限度的状态保存一个会议会话或呼叫会涉及到一个或多个SIP请求-响应事务。Proxyservers不需要为呼叫保存状态，然而，它们可以保存SIP事务的状态。为了提高效率，server可以保存locationserver请求的结果。底层协议不限定Lower-Layer-ProtocolNeutralSIP对其下面的传输层和网络层协议只做了最小限度的假定，底层可以提供数据包或者字节流、可靠服务或不可靠服务。在网络传输中，SIP可以用UDP和TCP传输协议。使用UDP的应用程序可以更精确地控制信息和重传定时；可以提供并行的搜索，而不需要使用每一个传出的请求的TCP连接状态；可以使用多播。而TCP使得信息可以更方便地穿透防火墙。当使用TCP时，SIP可以使用一个或多个连接来访问用户或更新现存会议的参数。同一个SIP呼叫的不同SIP请求可以根据需要使用不同的TCP连接或使用一个持久的连接。SIP也可以直接使用ATMAAL5，IPX，framerelay或X.25协议。UA应该SHOULD可以使用UDP和TCP传输，而Proxy,registrar,和redirectservers必须MUST使用UDP和TCP。基于文本SIP是基于文本的，全部使用ISO10646的UTF-8编码，这样就可以很容易地使用Java,Tcl和Perl等语言，调试起来也很方便，而且更重要的是，增强了SIP的灵活性和可扩展性。由于SIP是用来初始化多媒体会议，而不是传输媒体数据的，因此一般认为在基于文本的协议上增加其他的开销是没有什么意义的。 目录SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 SIPURL在SIP消息中SIPURLs可以指明SIP请求的发起者originator(From),，当前目的地址currentdestination(Request-URI)和最终接收者finalrecipient(To)，并且可以指定重定向地址redirectionaddresses(Contact)。SIP-URL="sip:"[userinfo"@"]hostporturl-parameters[headers]userinfo=user[":"password]user=*(unreserved|escaped|"&"|"="|"+"|"$"|",")password=*(unreserved|escaped|"&"|"="|"+"|"$"|",")hostport=host[":"port]host=hostname|IPv4addresshostname=*(domainlabel".")toplabel["."]domainlabel=alphanum|alphanum*(alphanum|"-")alphanumtoplabel=alpha|alpha*(alphanum|"-")alphanumIPv4address=1*digit"."1*digit"."1*digit"."1*digitport=*digiturl-parameters=*(";"url-parameter)url-parameter=transport-param|user-param|method-param|ttl-param|maddr-param|other-paramtransport-param="transport="("udp"|"tcp")ttl-param="ttl="ttlttl=1*3DIGIT;0to255maddr-param="maddr="hostuser-param="user="("phone"|"ip")method-param="method="Methodtag-param="tag="UUIDUUID=1*(hex|"-")other-param=(token|(token"="(token|quoted-string)))headers="?"header*("&"header)header=hname"="hvaluehname=1*urichvalue=*uricuric=reserved|unreserved|escapedreserved=";"|"/"|"?"|":"|"@"|"&"|"="|"+"|"$"|","digits=1*DIGIT SIPURL（续）telephone-subscriber=global-phone-number|local-phone-numberglobal-phone-number="+"1*phonedigit[isdn-subaddress][post-dial]local-phone-number=1*(phonedigit|dtmf-digit|pause-character)[isdn-subaddress][post-dial]isdn-subaddress=";isub="1*phonedigitpost-dial=";postd="1*(phonedigit|dtmf-digit|pause-character)phonedigit=DIGIT|visual-separatorvisual-separator="-"|"."pause-character=one-second-pause|wait-for-dial-toneone-second-pause="p"wait-for-dial-tone="w"dtmf-digit="*"|"#"|"A"|"B"|"C"|"D"SIPURL语法；telephonesubscriber下表总结了SIPURL的用处和默认值。defaultReq.-URIToFromContactexternaluser--xxxxxpassword--xxxxhostmandatoryxxxxxport5060xxxxxuser-paramipxxxxxmethodINVITExxmaddr-param--xxttl-param1xxtransp.-param--xxheaders--xx 目录SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 SIP消息概要与HTTP不同的是,SIP可以使用UDP。当在TCP或UDP上进行传输时，多个SIP事务可以使用同一个TCP连接或UDP包，但是UDP包的长度，包括包头，不能超过最大传输单元（默认为1500字节），这个1500字节是为了适应典型的以太网MTU。SIP消息要么是client到server的请求，要么是server到client的响应：SIP-message=Request|Response不论是请求还是响应消息都使用generic-message格式(RFC822[24])来传输消息体。两种类型的消息都包括一个start-line，一个或多个头域，一行空行(carriage-returnline-feed(CRLF))标志头域的结束，和可选的消息体。为了避免和HTTP相似名称的混淆，SIP使用entity头域来描述消息体。generic-message=start-line*message-headerCRLF[message-body]start-line=Request-Line|Status-Linemessage-header=(general-header|request-header|response-header|entity-header)最前面的空行必须被忽略，换句话说，如果请求或响应消息开始于一个或多个CRLF,CR,或者LFs,，这些字符都必须被忽略。 目录SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 请求Request=Request-Line*(general-header|request-header|entity-header)CRLF[message-body]Request-Line=MethodSPRequest-URISPSIP-VersionCRLFMethod="INVITE"|"ACK"|"OPTIONS"|"BYE"|"CANCEL"|"REGISTER"其中INVITE和ACK用于建立呼叫，完成三次握手，或者用于建立以后改变会话属性；BYE用以结束会话；OPTIONS用于查询服务器能力；CANCEL用于取消已经发出但未最终结束的请求；REGISTER用于客户出向注册服务器注册用户位置等消息。Request-URI指明了请求的目的地址，可能会被proxy改写。Proxy和redirectservers可以根据Request-URI的信息和请求的头域来处理请求，并有可能会重写Request-URI。SIP-Version：SIP/2.0 响应Response=Status-Line*(general-header|response-header|entity-header)CRLF[message-body]Status-Line=SIP-versionSPStatus-CodeSPReason-PhraseCRLFStatus-Code=Informational（1xx）|Success（2xx）|Redirection（3xx）|Client-Error（4xx）|Server-Error（5xx）|Global-Failure（6xx）|extension-codeextension-code=3DIGITReason-Phrase=* 目录SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 头域定义参见SIP协议中的HEADER应用.PPT 目录SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 状态码定义与HTTP/1.1比较：与HTTP一致，是HTTP的扩展，但不包括所有的HTTP状态码；增加了x80响应码；定义了新类6xx；为每一个状态类都定义了默认值（x00）1xx:Informational--收到请求，正在处理请求;2xx:Success--行为已经成功地接收、理解和处理了;3xx:Redirection--完成请求还需要更进一步的操作;4xx:ClientError--请求包含了错误的语法或在这个server上不能完成;5xx:ServerError--server不能完成一个正确的请求;6xx:GlobalFailure--任何server都不能完成这个请求. 状态码定义--1xx1xx：报告信息信息类的响应指明联系的server或者proxy正在进行更深入的操作，还无法返回明确的应答。Client应该等待更进一步的响应，而server也应该在后续时间内主动返回明确的应答信息。如果server预计它需要花费200ms以上的时间来得到最终结果的话，那么它应该先返回1xx响应。server可以发送一条以上的1xx响应，而不必考虑其次序。而client收到此响应也不必回复ACK。eerver可以自由地重传此类响应，而client也可以自由地重发请求，只是为了查询server当前执行的状态。100：Trying正在进行某个没有详细说明的动作，但是还没有定位用户。180：Ringing被叫UA（已注册）已经被定位，正在联系被叫UA。181：CallIsBeingForwardedproxy使用此状态码表示呼叫正在向前传递。182：Queued被叫方暂时不可用，但被叫方决定将呼叫放入队列而不是丢弃，一旦被叫方可用，就会返回最终结果。在返回此状态的响应时，还可以附加一些说明，例如“现在已经有5个队列在排队，大概需要等待15分钟”等等。server也可以发送多个182响应以更新状态报告。 状态码定义--2xx2xx：请求已成功完成，必须终止搜索。200：ok返回此状态码响应对于不同的方法有不同的意义。BYE：呼叫终止，消息体为空；CANCEL：搜索取消，消息体为空；INVITE：被叫同意加入，消息体为被叫的能力特性；OPTIONS：被叫同意提供它的能力特性，这些特性在消息体中提供；REGISTER：注册成功，client根据Content-Type处理消息体内容。 状态码定义--3xx3xx：重定向报告用户的新位置，或者报告可以满足呼叫的可选服务。应该终止目前的搜索，如果需要的话可以让发起者开始新的搜索。任何一个3xx的响应都不能suggest请求中的via字段里的任何地址。为了避免循环，UAC或者proxy必须检查重定向服务器返回的地址是否被更改了。300：多重选择请求中的地址决定了会有几种选择，每种选择都有自己的定位，用户可以选择一个合适的终端通信并将请求重定向到那个定位。响应应该包括一个消息体，其中包含了资源特性列表，那些选择也应该列在contact头域中，SIP响应可以包含几个contact头域或者在一个contact头域中列出几个地址。301：MovedPermanently根据请求URI中列出的地址可能永远也找不到该用户，cilent端应该重试contact头域中列出的新地址。呼叫方应该更新本地的地址本和新的用户定位。302：MovedTemporarilyClient应该根据contact头域中的新地址重发请求。重定向的周期由expires头域指定，如果没有提供明确的时间，就表示这个地址只适用于本次呼叫，不能保存待用。305：UseProxyContact头域中给定的proxy必须可以用请求的资源，希望接收方通过proxy重复这个请求。305响应必须只能由UAS产生。380：AlternativeService呼叫不成功，但是有可选择的服务列在响应的消息体中，此类消息体还没有定义。 状态码定义--4xx4xx：RequestFailure请求失败4xx响应是从特定的server发来的明确的失败响应。Client不应该在修正之前再重试同一个请求。然而发给不同的server的同一个请求可能会成功。400：BadRequest由于错误的语法，请求不能被理解。401：Unauthorized请求需要用户认证。402：PaymentRequired保留以后使用403：ForbiddenServer理解了请求，但是拒绝完成，认证也无济于事，请求不应该再次发送。404：NotFound表示Server有确定的信息表明Request-URI中的用户不存在。如果Request-URI中指明的域和请求的接收者所在的域不匹配时也会产生这种错误状态。405：MethodNotAllowed在Request-Line中列出的方法不被Request-URI指明的对方所接受。响应必须包含一个allow头域，列出对指定的地址可用的方法。406：NotAcceptable请求指定的资源只能产生特殊的响应消息体，其中包含请求的accept头域指明的，但不支持的内容特性。407：ProxyAuthenticationRequired类似401，但是指明client必须先通过proxy认证自己。Proxy必须返回Proxy-Authenticate头域，在此头域中指明可接受的认证的机制和参数。Client可以重复发送包含Proxy-Authorization头域的请求。这个状态码用于通信通道的组件（例如电话网关）的应用程序，而不是需要认证的被叫方。 状态码定义--4xx（续）408：RequestTimeoutServer不能在expires中规定的时间内产生响应，例如用户定位操作。Client可以重复发请求。.409：Conflict由于和资源的现状冲突，请求不能完成。如果REGISTER请求的参数和现存的冲突就会返回这种状态。410：GoneServer上需要的资源不再可用，而且不知道向前传递的地址，这种状况被看作是永久性的。如果server不知道，或者无法决定这种状况是否是永久性的，就应该返回404错误。411：LengthRequiredserver拒绝接受没有定义Content-Length的请求。Client可以加上正确的Content-Length头域再次发送请求。413：RequestEntityTooLargeServer拒绝处理请求，因为请求实体的长度超出server能够接受的程度。Server应该关闭连接，阻止client的后续请求。如果这种状况是临时的，server应该在返回的响应中包含Retry-After头域指出关闭是暂时的，一段时间后client可以再试。414：Request-URITooLongServer拒绝处理请求，因为Request-URI太长，超出server能够解释的范围。415：UnsupportedMediaTypeServer拒绝处理请求，因为被请求的资源不支持请求的消息体的格式。Server应该返回Accept,Accept-Encoding和Accept-Language头域，列出支持的格式。420：BadExtensionServer不理解Require头域中的协议扩展。480：TemporarilyUnavailable被叫终端已经成功联系上，但是被叫方目前不可用（例如，没有登录或者登录方式不能和呼叫方通信）。响应可以指明一个更好的重试时间。user可能对于其它地方方式（例如语音邮件）来说是可用的，因此，这种响应不会终止任何搜索。这种理由应该给出更精确的被叫方不可到达的原因，其值可以由UA设置。486错误可以用于呼叫失败的更精确的理由。如果重定向server发现了Request-URI指定的用户，但是目前没有可到达的向前传输的定位的话，也返回这种错误。 状态码定义--4xx（续）481：CallLeg/TransactionDoesNotExist在两种情况下返回这种错误：server收到一个BYE请求，但此请求不匹配任何已存在的callleg；或者server收到CANCEL请求，但不匹配任何现存的事务（server简单地丢弃未知事务的ACK）。482：LoopDetectedServer收到一个via头域中包含了自己地址的请求。483：TooManyHopsServer收到via入口（跳数）多与Max-Forwards头域中规定的个数的请求。484：AddressIncompleteServer收到请求，其to地址或者Request-URI中地址不完整。485：Ambiguous在请求中提供的被叫方地址不明确。响应可以在Contact中包括一系列可能的明确的地址。但是提供太多的选择可能会破坏用户或组织的私有关系，因此，如果请求地址不明确，必须配置server去响应404状态，或者禁止列出可能的选择。例如请求的URL为lee@example.com，则返回的响应是：485AmbiguousSIP/2.0Contact:CarolLeeContact:PingLeeContact:LeeM.Foote486：BusyHere被叫终端已成功联系上，但被叫方目前不愿或不能接受呼叫。响应可以指明更合适的再次呼叫时间，但不会中断任何搜索。如果client知道没有其它的终端可以接收这次呼叫的话，应该使用600状态(BusyEverywhere)。 状态码定义--5xx5xx：ServerFailure5xxServer端发生不明确的错误，如果有其它未试过的定位，则不能中断搜索。500：ServerInternalErrorServer遇到了意外，阻止它完成请求。Client可以得到详细的错误状态，在几秒钟之后重试。501：NotImplementedServer不支持必须的功能来完成请求。当server不能识别请求的方法并且不支持方法时响应501。502：BadGatewayServer在充当网关或proxy时，由下一步的server收到不可用的响应。503：ServiceUnavailableServer目前不能处理请求，可能是因为暂时的拥塞等。这暗示着这只是临时的情况，经过一段延迟情况会有好转。如果能预测到延迟的时间，可以用Retry-After头域通知对方，如果没有接到这种通知，client必须把此错误当500处理。注意：503状态的存在并不意味着当拥塞发生时，server必须要使用503。一些server可能希望简单地拒绝连接。504：GatewayTime-out作为网关的server在限定时间内没有从locationserver收到需要的响应。505：VersionNotSupportedServer不支持或者拒绝支持请求消息中使用的SIP协议版本。响应应包含一个描述为什么不支持此版本和支持什么版本的消息体。格式未定，留以后扩展。 状态码定义--6xx6xx：GlobalFailures6xx响应表明server对client有了确定的信息，而不是Request-URI中一个指定的地址而已。对这个client的更进一步的搜索注定都要失败，应该终止正在执行的搜索。600：BusyEverywhere已成功到达被叫方，但被叫方忙并且步愿意此时接受呼叫。响应可以指明一个更好的重试时间。如果被叫方不愿意说明拒绝的原因，可以反馈603响应。这种响应只用于client知道没有其它的终端（例如声音邮件）可以应答请求，否则，应该使用486响应。603：Decline被叫方已成功探测到，但是被叫方明确表示不愿意加入通话。响应可以指明更好的呼叫时间。604：DoesNotExistAnywhereServer有确定的信息表明被叫的用户不存在，向别的地方搜索该用户也不会有什么结果。606：NotAcceptableUA已经成功探测到，但是不支持会话的一些方面（例如需要的媒体，带宽或标记地址方式）。606响应意味着用户希望通信但是不能充分支持会话描述。606响应可以在warning头域中包含一系列描述为什么不支持会话描述的原因。双方的沟通并不是频繁发生的，当一个新用户被邀请加入一个已存在的会议，双方沟通可能会不成功，这就需要邀请的发起人决定是否产生606响应。 目录SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 SIP消息体1、消息体内容：请求可以包含消息体。在这个规范中，BYE请求不能包含消息体，ACK、INVITE和OPTIONS中的消息体通常是会话描述，REGISTER请求的消息体使用还需要继续研究。对于响应消息来说，请求的方法和状态码决定了消息体的类型和含义。所有的响应都可以包含消息体，1xx响应的消息体包含了对请求的建议信息，对INVITE方法的2xx响应包含了会话描述，3xx响应的消息体可以包含可选目的地址或服务的描述，对于400和400以上响应的消息体可以包含附加的、可阅读的失败原因信息。建议1xx、300和更大值的响应为text/plain或text/html类型。2、消息体类型由Content-Type头域定义。3、消息体长度由Content-Length头域定义。 紧凑格式紧凑模式当带着认证口令和复杂的会话描述的SIP信令在UDP上传输时，很可能请求或响应的长度超过了MTU，为了解决这个问题，对下列的头域采取了使用缩写的比较紧凑的格式：shortfieldnamelongfieldnamenotecContent-TypeeContent-EncodingfFromiCall-IDmContactfrom"moved"lContent-LengthsSubjecttTovViaClients可以在一个请求中同时使用紧凑格式和正常格式，server必须能接受请求的两种格式，proxy可以在两种格式中相互转换，但不能改变跟在认证后面的域。 目录SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 SIPClients和SIPServer请求：Server对请求做出适当的响应之后，会抛弃以后再来的同样请求的复制品，因此，多个请求的copy并不会影响server的状态。在收到client发来的CANCEL请求后，有状态记录的proxy会向每一个还没得到最终结果的分支发送CANCEL。当一个UA收到请求时，会将Call-ID取出来和正在处理的呼叫相比较，如果有相同的Call-ID，就会进一步比较to头域中的tag参数，如果tag值不同，则表示是同一个SIP地址的两个用户发来的请求，UA就会丢弃后来的请求。如果请求的from头域（包括tag参数值）相同，server就会比较cseq值，如果和已存的序列号相同，则表示是重传的请求，否则表示是新的请求。如果新的请求和以前的请求的callleg不相同，则会新建一个callleg，处理新的呼叫。如果Call-ID不相同，server就会返回一个与请求有相同to头域的响应，不过会在to头域后加上tag标签，但是如果响应只有一个via头域时，tag值会被忽略。响应：Server在发出最终的响应之前可能会给几个临时的响应。如果记录状态的proxy，useragentserver,redirectserver或者registrar不能在200ms内返回最终的结果，那么它应该尽快返回一个临时的1xx响应；但是不记录状态的proxy不能返回临时响应。返回的响应应该与请求有相同的To,From,Call-ID,Cseq头域值和第一个Via头域的branch参数。 UDP和TCP单点传送UDP（Unicast）：响应是按照via头域中的地址传送的，而不是按照from头域中的地址传送。多点传送UDP（Multicast）：请求可以是多点传送的，多点传送的请求的Request-URI可能会跟主机无关。Client收到一个多播的查询时，并不需要将Request-URI的主机名部分和自己所在的域相比较。如果请求是通过多播发来的，那么响应也会用多点传送方式发送出去。收到多播请求后，server必须返回2xx和6xx响应。server不会处理经过多播传来的CANCEL请求，以免会漏掉其它的请求，而proxy和UAC在收到第一个2xx或6xx响应后，就应该向多播点传送CANCEL。TCP：一个TCP连接可以传递一个或多个SIP事务，一个事务包括请求和一个（或多个）最终响应和零个（或多个）临时响应。Client在收到第一个最终响应之前都应该保持TCP通道的连接，如果短于这个时间，对端就会按照收到CANCEL请求来处理；而server在发送完它的最后一个响应之前都应该保持TCP通道的连接，之后就可以根据自己的需要决定TCP通道是否关闭，但是一般来讲，都是由client决定是否关闭TCP通道。 BYE、CANCEL、OPTIONS、REGISTER请求的可靠性UDP：Client对于BYE,CANCEL,OPTIONS,或者REGISTER请求的重传时间是基于指数增长的，开始于T1秒间隔，以后每个包的间隔都乘2，直到间隔达到T2秒为止。这就是说，第一个包发送出去以后，等待T1秒发送第二个重传的包，然后下一个重传要等2*T1秒，再下一个要等4*T1秒，以此类推，直到时间间隔达到T2值，然后以后的重传都要等T2秒间隔；如果client收到临时响应，它还是要重传请求，不过每次都是等待T2秒。当client发了11个包以后，或者收到一个最终的响应，然后就会终止重传。默认的T1和T2值是500ms和4s，Clients也可以使用一个更大的值，但是不能使用更小的值。server收到重传的请求以后也会重传响应，在server发送了最终的响应以后，不知道client是否收到响应，因此它会将最终结果至少保持10*T2秒。在proxy链上的每一个proxy都可以发出CANCEL请求，server收到第一个CANCEL时就会立即做出反应，而不是要等到最终的结果。TCP：使用TCP连接不需要重传机制 INVETE请求的可靠性1.在接到邀请请求后，server可能会花很多的时间，甚至几十秒来决定结果（server可能在忙）；2.如果电话用户界面是模拟的或者需要接到PSTN，那么呼叫者这里就会有振铃音，一旦被叫方摘机，呼叫方就需要知道语音话路已经建立，振铃音停止；3.Client需要终止传递的请求，例如它不再需要等待连接或搜索成功的情况，server就必须等待几个重传间隔时间来确定是终止呼叫还是重传数据丢失。如果在呼叫方放弃呼叫的很短时间内呼叫就成功的话，被叫方仍会做出摘机的反应。TCPUA使用TCP时不能重传请求，但是在收到ACK之前重传响应的算法同UDP。 INVETE请求的可靠性（续） ACK请求的可靠性和ICMP处理ACK请求不会引起响应，ACK只是在INVITE请求的响应到达后产生的通知收到响应的请求，这是和传输协议无关的。注意ACK请求的传输路径可能会和INVITE请求的路径不同，也可能会导致打开一个新的TCP连接。ICMP处理：在使用UDP协议时可能会收到ICMP信息，对于请求来说，主机、网络、端口或协议不能到达的错误会按照400类响应处理；而对于响应，这些错误可能会引起server终止响应的重传。源不能到达（Sourcequench）的ICMP信息被忽略；TTL超时错误被忽略；参数错误被当做400类响应处理。 目录SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 SIPUserAgents呼叫方发出最初的INVITE请求：这个请求的To头域要包括被叫方的地址，Request-URI也包含同样的地址，From包含呼叫方地址，还可以根据情况选择是否包含Contact头域，此头域给出一个返回地址，留给以后的事务使用；被叫方发出响应：被叫方收到INVITE请求后，可以接受、重定向或拒绝呼叫，这些都会返回相应的响应。响应必须从请求中复制To,From,Call-ID,Cseq和Via头域，如果请求包含一个以上的via头域，响应就必须加上tag参数，同样，响应也可以包含Contact头域。Server会保存callleg，标记一个呼叫；呼叫方收到最初请求的响应：呼叫方收到明确的响应后，返回ACK确认，或者返回BYE结束呼叫；呼叫方和被叫方产生后续的请求：通话建立后，双方都可以使用INVITE或BYE更改当前通话的参数。这个请求包的组织要参考以前保留的callleg，To头域设为远端地址，From头域设为本端地址，Contact可以跟以前的值不同，Request-URI可以设为以前从对端接收来的Contact头域的值，或设为远端地址；收到后续的请求：1.如果Call-ID是新的，表示接到新的呼叫；2.如果Call-ID已经存在，而且To,From,Call-ID,和Cseq值完全和以前相匹配，则表示是重传；3.如果不符合前两条，则比较callleg，如果匹配，只是Cseq增加了，则表示请求是本次呼叫的新的事务。 目录SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 RedirectServersRedirectserver：如果用户更改了地址，寻找用户就需要使用重定向服务器。重定向服务器本身不产生任何请求。在收到一个除CANCEL外的请求后，server收集可选的定位列表，返回一个3xx的最终响应，或者干脆拒绝请求；对于CANCEL请求，它返回2xx响应，这种响应终止了SIP事务。redirectserver在整个SIP事务中维持事务的状态，需要在redirectservers之间的client检测是否会造成循环。UserAgentServer：UAserver类似与redirectserver，但它们可以接受请求，返回2xx响应。 SIPProxyServersproxyserver可以是记录状态的也可以是不记录状态的，记录状态的proxy要记录收到的请求和由此产生的发送的响应，不记录状态的proxy在响应产生后就会忘掉所有的信息；能够产生并发（forking）的proxy应该是记录状态的，采用TCP进行通信的proxy必须是记录状态的。记录状态的proxy在发送了最终的响应，或接收到最终响应32秒之后才能转变成不记录状态的proxy，记录状态的proxy更象虚拟的UAC/UAS。代理请求；代理响应；不记录状态proxy：代理响应；记录状态proxy：收到请求；记录状态proxy：收到ACKs；记录状态proxy：收到响应；不记录状态、不产生并发（forking）的proxy；产生并发的proxy 目录SIP介绍SIPURLSIP消息请求和响应头域定义状态码定义SIP消息体与紧凑模式SIPclients和SIPserversSIPUserAgentsSIPproxy和redirectservers安全性 安全考虑保持机密性：加密算法；保持信息的完整性和访问控制：认证；SIP认证算法：Basic和Digest算法；PGP算法'