SIP协议格式详解,视频sip协议详解

('1.SIP1.1.1.SIP格式每条SIP消息由以下三部分组成：（1）起始行（StartLine）：每个SIP消息由起始行开始。起始行传达消息类型（在请求中是方法类型，在响应中是响应代码）与协议版本。起始行可以是一请求行（请求）或状态行（响应）。（2）SIP头：用来传递消息属性和修改消息意义。它们在语法和语义上与HTTP头域相同（实际上有些头就是借自HTTP），并且总是保持格式：<名字>:<值>。（3）消息体：用于描述被初始的会话（例如，在多媒体会话中包括音频和视频编码类型，采样率等）。消息体能够显示在请求与响应中。SIP清晰区别了在SIP起始行和头中传递的信令信息与在SIP范围之外的会话描述信息。可能的体类型就包括本文将要描述的SDP会话描述协议。1.1.2.消息头HeaderfieldwhereproxyACKBYECANINVOPTREGAcceptR-o-omoAccept2xx---omoAccept415-c-cccAccept-EncodingR-o-oooAccept-Encoding2xx---omoAccept-Encoding415-c-cccAccept-LanguageR-o-oooAccept-Language2xx---omoAccept-Language415-c-cccAlert-InfoRar---o--Alter-Info180ar---o--AllowR-o-oooAllow2xx-o-mmoAllowr-o-oooAllow405-m-mmmAuthentication-Info2xx-o-oooAuthorizationRooooooCall-IDcrmmmmmmCall-Infoar---oooContactRo--mooContact1xx---o--Contact2xx---mooContact3xxd-o-oooContact485-o-oooContent-Dispositionoo-oooContent-Encodingoo-oooContent-Languageoo-oooContent-LengtharttttttContent-Type-CseqcrmmmmmmDateaooooooError-Info300-699a-oooooExpires---o-oFromcrmmmmmmIn-Reply-ToR---o--Max-ForwardsRamrmmmmmmMin-Expires423-----mMIME-Versionoo-oooOrganizationar---oooPriorityRar---o--Proxy-Authenticate407ar-m-mmmProxy-Authenticate401ar-oooooProxy-AuthorizationRdroo-oooProxy-RequireRar-o-oooRecord-RouteRarooooooRecord-Route2xx,18xmr-oooo-Reply-To---o--Requirear-c-cccRetry-After404,413,480,486-oooooRetry-After500,503600,603-oooooRouteRadrccccccServerr-oooooSubjectR---o--SupportedR-oomooSupported2xx-oommoTimestampooooooToc(1)rmmmmmmUnsupported420-m-mmmUser-AgentooooooViaRamrmmmmmmViarcdrmmmmmmWarningr-oooooWWW-Authenticate401ar-m-mmmWWW-Authenticate407ar-o-ooo“where”列描述了在头域中能够使用的请求和应答的类型。这列的值是：R:头域只能在请求中出现；r:头域只能在应答中出现；2xx，4xx，等等：一个数字的值区间表示头域能够使用的应答代码。c：头域是从请求拷贝到应答的。如果”where”栏目是空白，表示头域可以在所有的请求和应答中出现。“proxy”列描述了proxy在头域上的操作a：如果头域不存在，proxy可以增加或者连接头域m：proxy可以修改现存的头域值d：proxy可以删除头域值r：proxy必须能读取这个头域，因此这个头域不能加密。接下来6个栏目与在某一个方法中出现的头域有关：c：条件；对头域的要求依赖于消息的内容m：头域是强制要有的。m：头域应当被发送，但是客户端/服务端都需要准备接收没有这个头域的消息。o：头域是可选的。t：头域应当被发送，但是客户端/服务端都需要准备接收没有这个头域的消息。客户端/服务端都需要准备接收没有这个头域的消息。如果通讯的协议是基于面向流的协议（比如TCP），那么头域值必须被发送。：如果消息体不为空，那么头域值就绪要的。（细节请参见20.14,20.15和7.4节）-:这个头域是不适用的。1.1.3.请求格式1.1.4.响应格式1.2.字段Request-URI:呼叫请求发送地址。UA生成初始请求消息时，该域中的信息一般与TO中的地址相同，经过网络服务器后，由于实际路由问题，该值可能发生变化以，另外一个比较特殊的是REGISTER消息，在REGISTER消息中，在REQUEST-URI中将会填充注册服务器的地址（表示消息发往注册服务器），而此时TO域中的地址将会填充客户端实际的地址。From发起请求方的地址。一般采用USERINFO@HOSTPORT形式。该域同时带有一个TAG参数，是随机产生的整数。To接受方地址。同FROM域相同，也采用USERINFO@HOSTPORT的地址形式，当该域存在于最终响应消息中时，将会事有TAG参数。Call－ID用于识别呼叫参数，在同一个DIALOG中，该参数不发生变化。该参数与FROM中的TAG参数、TO域中的TAG参数相结合用以保证呼叫的惟一性。Cseq表征TRANSACEION的参数，由于同一个呼叫中会存在多个TRANSACTION,因此通过该能数来保证同一个USERAGENT发送的不同请求消息间的顺序。Via该参数表征呼叫经过的路径，UA生成SIP消息时，会在该域中填写自己的地址：PROXY在转发请求消息时，将会增加一个填有自己地址的VIA域，表示才叫经过本PROXY。VIA域的存在可以保证响应消息按照原路径返回到主叫方.代理服务器用它检查其内容，如果新端点已出现在via列表中，则表示有环路了。Contact告知对端自己的地址。当对端发送下一个请求消息时，可直接向该地址发送，不需要关心前一个路由信息（除非有特定原则，例如PROXY可以通过RECORD-ROUTE域来保证下一个请求消息必须经过本PROXY,即使CONTACT域中填写对端客户的地址。Expireslimitssearchtime,给出消息内容超期的时间Record-Route由于CONTACT域的存在使得两个用户后续的请求消息可能不经过PROXY,为了运营需要，PROXY在初始INVITE消息中增加了RECORD-ROUTE域，这样可以保证后续请求（例如BYE消息）经过PROXY.通过RECORD-ROUTE与CONTACT的结合，既可避免后续请求旁路网络服务器的行为，又可减少后续请求路径上的环节。CONTENT-TYPE表征消息格式的参数，例如，呼叫采用了SDP进行会话描述，还是采用其他类型的会话描述协议。ExamplesofSIPURIssip:felix.muster@zhwin.chsip:felix.muster@zhwin.ch;transport=sip:muf@dskt6107.zhwin.ch:5678sip:muf@160.85.200.27:3456sip:+41-76-456-9786@sipgate.sip:117@gateway.zhwin.ch;user=sip:zhwin.ch;method=REGISTERDefaults:5060(destinationport)transport=udp(transportparameter)user=ip(userparameter)method=INVITE(SIPmethod)1.2.1.Via格式Via=("Via""v")":"1#(sent-protocolsent-by(";"via-params)[comment])via-params=via-hiddenvia-ttlvia-maddrvia-receivedvia-branchvia-extensionvia-hidden="hidden"via-ttl="ttl""="ttlvia-maddr="maddr""="maddrvia-received="received""="hostvia-branch="branch""="tokenvia-extension=generic-paramVia处理流程hidden处理received/rport处理001INVITEsip:12125551212@211.123.66.222SIP/2.0002Via:SIP/2.0/UDP211.123.66.223:5060;branch=a71b6d57-507c77f2003Via:SIP/2.0/UDP10.0.0.1:5060;received=202.123.211.25;rport=12345004From:;tag=108bcd14005To:sip:12125551212@211.123.66.222006Contact:sip:2125551000@10.0.0.1007Call-ID:4c88fd1e-62bb-4abf-b620-a75659435b76@10.3.19.6008CSeq:703141INVITE009Content-Length:138010Content-Type:application/sdp011User-Agent:HearMeSoftPHONE012…………Intheabovetrace,theIPaddressinline003oftheSIPheaderistheIPaddressthattheclientthinksitis–i.e.theinternalIPaddress(10.0.0.1).ButtheproxyknowsfromwhichIPaddressitactuallyreceivedthepacket,soitaddsthe“received”and“rport”tagswiththeIPaddressandportaftertheNATmapping.ThesetagsallowtheproxytoforwardSIPmessagesbacktotheclientviatheNAT.Branch处理usedtodistinguishbetweenmultipleresponsestothesamerequest.ForkingProxy:Issueasinglerequesttomultipledestinations.1.2.2.Route/Record-Route•Record-Routecanbeused:–ensuresFirewallproxystaysinpath•AFirewallproxyaddsRecord-Routeheader–ClientsandServerscopyRecord-RouteandputinRouteheaderforallmessagesRequestrouting例OnlyProxy3remainsinroute1.UA1isinstructedtoINVITE“sip:UA2@proxy1”2.ThemessageshouldbesenttoProxy13.ThemessageshouldbesenttoProxy24.ThemessageshouldbesenttoProxy35.ThemessageshouldbesenttoUA2.6.UA2sendsa“200OK”,whichshouldbesentbacktoUA1,throughallthreeproxies.7.UA1sendsanACKtoProxy3.8.Proxy3sendstheACKtoUA2.9.UA2sendsaBYEtoproxy3.10.Proxy3sendstheBYEtoUA1.11.UA1sendsa200OKthroughproxy3toUA2.1.2.3.ExpiresTheRFCisreferringtoaREGISTERrequestthatincludesanexpiresparameterontheContactandoneisaseparateheaderfieldlikethis:Contact:;expires=1000Contact:Expires:2000fortheabove,thefoocontactshouldexpireafter1000seconds,andthebarcontactafter2000seconds.ThetestusedtheContactheader:Contact:;EXPIRES=2970whichmeanssomethingelseentirely.The\';expires=1800\'insidetheanglebracketsisapartoftheURI,notafieldparameteroftheContactfield.The\';expires=2970\'outsideisthefieldparameter,soitiscorrecttouseitastheexpirationtimeofthecontact.TheinneroneisusedbytheproxytocontrolforkingtimeoutswhenthisContactisused,andhasnothingtodowiththeregistrationexpiration.BroadBand',)