SIP协议主要消息

《SIP协议主要消息》由会员分享，可在线阅读，更多相关《SIP协议主要消息（14页珍藏版）》请在装配图网上搜索。

1、第一章 SIP合同重要消息1.1 SIP消息分类SIP合同是以层合同的形式构成的，就是说它的行为是以一套相对独立的解决阶段来描述的，每个阶段之间的关系不是很密切。SIP合同将Server和User Agent之间的通讯的消息分为两类：祈求消息和响应消息。祈求消息：客户端为了激活特定操作而发给服务器的SIP消息，涉及INVITE、ACK、BYE、CANCEL、OPTION和UPDATE消息。SIP祈求的6种措施：1、 邀请（INVITE）邀请顾客加入呼喊2、 确认（ACK）确认客户机已经接受到对INVITE的最后响应3、 可选项（OPTIONS）祈求有关服务器能力的信息4、 再会（BYE）终结呼

2、喊上的两个顾客之间的呼喊5、 取消（CANCEL）6、 注册（REGISTER）提供地址解析的映射，让服务器懂得其他顾客的位置响应消息：服务器向客户反馈相应祈求的解决成果的SIP消息，涉及1xx、2xx、3xx、4xx、5xx、6xx响应1.2 SIP消息构造祈求消息和响应消息都涉及SIP消息头字段和SIP消息体字段；SIP消息头重要用来指明本消息是有由谁发起和由谁接受，通过多少跳转等基本信息；SIP消息体重要用来描述本次会话具体实现方式；1.3 消息格式1.3.1 祈求消息格式SIP祈求消息的格式，由SIP消息头和一组参数行构成，如图1-1所示。通过换行符辨别命令行和每一条参数行。命令名称对

3、端URICall-id: 值via: 值合同版本消息头参数行To: 值Contact: 值From: 值Content-Length: 值Max-Forward: 值White SpaceSDPContent-Type: 值Cseq: 值图1-1 SIP祈求消息构造注意：参数行的顺序不是固定的。相应的参数解释见Error! Reference source not found.。消息体定义：Call-ID：头字段是用来将消息分组的唯一性标记From：头字段是批示祈求发起方的逻辑标记，它也许是顾客的注册地址。From头字段涉及一种URI和一种可选的显示名称CSeq：头字段用于标记事务并对事务进行

4、排序。它由一种祈求措施和一种序列号构成，祈求措施必须与相应的祈求消息类型一致Max-Fowords：头字段限定一种祈求消息在达到目的地之前容许通过的最大跳数。它涉及一种整数值，每通过一跳，这个值就被减一。如果在祈求消息达到目的地之前该值变为零，那么祈求将被回绝并返回一种483（跳数过多）错误响应消息。Via：头字段定义SIP事务的下层（传播层）传播合同，并标记响应消息将要被发送的位置。只有当达到下一跳所用的传播合同被选定后，才干在祈求消息中加入Via头字段值。expires：参数指出了该值中涉及的URI地址的有效期。这个参数的值是以秒为单位计算的。如果没有提供该参数，那么URI地址的有效期由E

5、xpires头字段值来拟定。SIP祈求消息实例：INVITE sip:0109127.0.0.1:5060;User=phone SIP/2.0Call-ID:01E00127.0.0.1Via:SIP/2.0/UDP 127.0.0.1:5061From:;tag=B534F610A000To:Contact: sip:010203127.0.0.1:5061CSeq:1 INVITEMax-Forwards:70Content-Type: application/SDPContent-Length:168v=0o=UserA IN IP4 s=Session SDPc=IN IP4 192

6、.0.0.1t=0 0m=audio 49172 RTP/AVP 0 8a=rtpmap:0 PCMU/8000a=rtpmap:8 PCMA/8000a=sendonlyINVITE消息是其中一种SIP祈求消息。第一行由消息头和对端SIP实体的URI（通用资源标记）以及SIP版本号码构成。SIP URI是电话URI，附在IP地址上，表达对端和端点收发SIP消息的端口的域。“From”、“To”和“Contact”这三个SIP消息头属于电话URI。当背靠背顾客代理发出呼喊时，“From”消息头中的URI填写在“Via”消息头里。祈求消息类型填写在CSeq消息头里，并且当该SIP端点发送一种祈求

7、，号码就相应递增。SIP合同版本为SIP/2.0。其中SDP被加入到INVITE消息内容里，在消息头里的Content-Length阐明了SDP内容的长度。INVITE祈求消息详解：INVITE sip: SIP/2.0 祈求措施、祈求地址（RequestURI）、SIP版本号（目前都是SIP/2.0）祈求地址一般就是被叫方地址，跟MSN中好友eMail地址类似Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19bSIP版本号（2.0）、传播类型（UDP）、呼喊地址、branch是一随机码，它被看作传播标记Via字段中地址是

8、消息发送方或代理转发方设备地址，一般由主机地址和端标语构成传播类型可觉得UDP、TCP、TLS、SCTPMax-Forwards: 70最大跳跃数，就是通过SIP服务器的跳跃次数，重要是避免循环跳跃每通过代理服务器，该整数减一To: G. Marconi From: Nikola Tesla ;tag=76341表达祈求消息的发送方和目的方如果里面有顾客名标签，地址规定用尖括号包起来对于INVITE消息，可以在From字段中涉及tag，它也是个随机码Call-ID:呼喊ID是由本地设备生成的，全局唯一值。每次呼喊该值唯一不变对于顾客代理发送INVITE消息，本地将生成From tag和Call

9、-ID全局唯一码，被叫方代理则生成To tag全局唯一码。这三个随机码做为整个对话中对话标记（dialog indentifier）在通话双方使用。CSeq: 1 INVITECSeq，又叫命令队列（Command Seqence），每发送一种新的祈求，该数自动加1* 以上几种字段是所有SIP消息体所必须的，其他头字段有些是可选的，有些在特定祈求也是必须Subject: About That Power Outage.Contact: Contact是INVITE消息所必须的，它用来路由到被叫设备地址，也称为顾客代理（UA）Content-Type: application/sdpConten

10、t-Length: 158最后两位附属字段阐明消息体类型以及字段长度v=0 SDP版本号，目前都是0o=Tesla 90844526 INIP4 lab.high-voltage.org 主叫源地址，类型等s=Phone Call1.3.2 响应消息格式SIP响应消息的格式，由SIP响应消息头和一组参数行构成，如0所示。通过换行符辨别命令行和每一行参数。SIP/合同版本响应消息头Call-id: 值via: 值消息头参数行To: 值Contact: 值From: 值Content-Length: 值Max-Forward: 值White SpaceSDPContent-Type: 值Cseq:

11、 值SIP响应消息构造注意：参数行的顺序不是固定的。相应的参数解释见Error! Reference source not found.。 SIP响应消息实例：SIP/2.0 200 OKContent-Type:application/SDPVia:SIP/2.0/UDP 127.0.0.1:5061Call-ID:01EF351F80127.0.0.1CSeq:1 INVITEFrom:;tag=B534F610A000To:;tag=5358336B534F2900CD1B0000Contact:Content-Length:156v=0o=HuaweiSoftX3000 IN IP4

12、127.0.0.1s=Sip Callc=IN IP4 110.111.112.113t=0 0m=audio 5060 RTP/AVP 0a=rtpmap:0 PCMU/8000200 OK消息是SIP响应消息的一种。第一行由SIP版本号和200响应消息构成。SIP URI是电话URI，附在IP地址上，表达对端和端点收发SIP消息的端口的域。“From”、“To”和“Contact”这三个SIP消息头属于电话URI。当背靠背顾客代理发出呼喊时，“From”消息头中的URI填写在“Via”消息头里。祈求消息类型填写在CSeq消息头里，并且当该SIP端点发送一种祈求，号码就相应递增。SIP合同版

13、本为SIP/2.0。把SDP加入到INVITE消息内容里，在消息头里阐明内容的长度。第二章 SIP合同重要响应码2.1 响应码分类SIP响应消息用于对祈求消息进行响应，批示呼喊的成功或失败状态。不同类的响应消息由状态码来辨别，状态码涉及三位整数，状态码的第一位用于定义响应类型，此外两位用于进一步对响应进行更加具体的阐明。响应消息的分类如下所示。1）1XX：临时响应，表达祈求消息正在被解决。2）2XX：成功响应，表达祈求已被成功接受，完全理解并被接受。3）3XX：重定向响应，表达需采用进一步以完毕该祈求。4）4XX：客户机错误，表达祈求消息中涉及语法错误信息或服务器无法完毕客户机祈求。5）5XX

14、：服务器错误，表达服务器无法完毕合法祈求。6）6XX：全局故障，表达任何服务器无法完毕该祈求。上述消息中，临时响应用于批示呼喊正在进行，其他最后响应用于结束祈求消息。2.2 1xx类消息（临时响应）1xx消息表达服务器或代理正在进行解决，尚未得到拟定的响应。客户应当继续等待服务器的响应。当服务器预测在200毫秒之内不能得到最后响应时，它应当发送一种1xx响应。服务器可以发送多种1xx响应。下面是常用的1xx类消息列表。表1-1 常用的1xx类消息列表100试呼（Trying）正在进行与呼喊有关的操作（例如：访问数据库），但被叫顾客还没有定位。180被叫振铃（Ringing）被叫顾客代理已经得到

15、被叫的位置，正在提示被叫顾客。该响应也可以再发起一种本地回铃181呼喊前转（Call Is Being Forwarded）代理服务器可以用该状态码表达目前呼喊正被转移到其他目的地。（呼喊正在转发）182呼喊排队（Queued）被叫临时不可访问，目前呼喊被排队而不是被回绝。当服务器有效时，可以继续响应当呼喊。 该响应的reason phrase可以进一步给出排队呼喊的信息，例如：“队列中有5个呼喊，盼望等待时间为15分钟”。服务器可以发出多种182 响应来更新目前排队呼喊的信息。183会话进度（session progress）应答用于提示建立对话的进度信息。Reason-Phrase（体现因

16、素的句子）、头域或者消息体可以用于提示呼喊进度的更新消息的信息。 2.3 2xx类消息（成功响应）2xx消息表达祈求已经被接受、解决并被成功接受；200 ：OK祈求成功。2.4 3xx类消息（重定向响应）3xx消息表达响应给出有关顾客新位置或其他可选服务的信息。下面表1-2是常用的3xx类消息列表。表1-2 常用的3xx类消息列表300多种选择（Multiple Choice）祈求中的地址被解析为多种位置，顾客可以将祈求重定向到一种合适的地址。该响应应当涉及可供顾客或顾客代理选择的位置和资源列表，并且在Contact头域中，列出可供选择的地址。（网络合同不兼容:会话描述中的一种或多种网络合同不

17、可用。）301永久离开（Moved Permanently）在祈求中Request-URI所指的地址找不到顾客，客户应当尝试Contact头域给出的新地址。主叫收到该响应后应当更新所有的本地目录，地址簿，顾客位置缓存并将后来的祈求重定向到新的地址。（网络地址格式不兼容:会话描述中的一种或多种地址格式不可用。）302临时离开（Moved Temporarily）客户应当用Contact头域给出的新地址尝试呼喊。响应中Expire头域指出该次重定向的有效期，如果没有给出有效期，那么重定向只对目前呼喊有效。（传送合同不兼容:会话描述中的一种或多种传送合同不可用。）303带宽单位不兼容:会话描述中的一

18、种或多种带宽度量单位不被理解。304媒体类型不可用:对话描述中的一种或多种媒体类型不可用。305使用代理（Use Proxy）客户所祈求的资源必须通过Contact头域中给出的代理来访问。Contact头域给出代理的URI。该响应只能由顾客代理服务器发出。（媒体格式不兼容:对话描述中的一种或多种媒体格式不可用。）306媒体特性不被理解:对话描述中的一种或多种媒体特性不被支持。307对话描述参数不被理解:除上述几种参数之外的参数不被理解。330组播不可用:顾客站点不支持组播。331单播不可用:顾客站点不支持单播通信(一般是由于防火墙的存在)370带宽局限性:对话描述中定义的或者媒体定义的带宽超过

19、可用带宽。380使用其他服务（Alternate Service）呼喊不成功，但是可选其他的服务（如：电子邮件，语音信箱）。该响应的消息体给出可选服务的描述。399混合告警:该告警表达顾客存在的任意一种错误，收到该告警的系统不可以采用任何自动的动作2.5 4xx类消息(客户机错误)4xx消息表达祈求消息中涉及语法错误或者SIP服务器不能完毕对该祈求消息的解决。下面表1-3是常用的4xx类消息列表。表1-3 常用的4xx类消息列表400无效祈求（Bad Request）祈求语法有误，不能被服务器理解。401未授权（Unauthorized）祈求需要顾客认证。402规定付费（Payment Req

20、uired）该响应为将来使用保存。403严禁（Forbidden）服务器理解祈求，但回绝完毕。客户不应当再次发祈求。404未找到顾客（Not Found）祈求中Request-RUL给出的地址上没有要呼喊的顾客。当Request-RUL给出的地址与服务器管理的域不匹配时，服务器也发送该响应。405措施不容许（Method Not Allowed）祈求行中指定的措施不被容许。该响应必须涉及Allow头域，列出服务器支持的措施。406不可接受（Not Acceptable）根据祈求中的Accpe头域，由祈求给出的资源产生的响应实体里面的内容字符不可接受。407需要代理认证（Proxy Authen

21、tication Required）该响应与401（未授权）类似，但它批示顾客必须一方面向代理认证自己。408祈求超时（Request Timeout）服务器不能在祈求的Expire头域指定的时间内产生响应。客户可以过一段时间重发祈求。409冲突（Conflict）客户的祈求与资源的目前状态冲突，不能完毕祈求。当REGISTER祈求的action参数与现存的注册冲突时返回该响应。410无可用资源（Gone）服务器上没有所祈求的资源，也不懂得进一步联系的地址。这种状况被觉得是永久的。如果服务器不能拟定该状况与否是永久的，它应当发送404（被叫未找到）响应。411需要消息体长度（Length Re

22、quired）服务器回绝接受没有涉及Content-Length头域的祈求。客户何以在加入一种表达消息体长度的Cotent-Length头域后重发祈求。413祈求实体过长（Request Entity Too Large）服务器回绝解决过长的消息实体。如果这种状况是临时的，服务器应当在响应中涉及Retry-After头域批示客户何时重发祈求。414Request-URI过长（Request-URI Too Long）服务器不能解析过长的Request-URI。415媒体类型不支持（Unsupported Media Type）服务器不支持祈求消息体的格式。服务器应当在响应中用Accept，Ac

23、cept-Encoding 和Accept-Language头域列出它支持的格式。416不支持的URI方案（unsupported url scheme）服务器由于不支持Request-URI中的URI方案而终结解决这个祈求。420错误的扩展（Bad Extension）服务器不理解祈求中Require头域指定的合同扩展。421需要扩展支持（extension required）UAS需要特定的扩展来解决这个祈求，但是这个扩展并没有在祈求的Supported头域中列出。具有这个应答码的应答必须涉及一种Require头域列出所需要的扩展。 UAS不应当使用这个应答除非它真的不能给客户端提供有效的

24、服务。相反，如果在Support头域中没有列出需要的扩展，服务器应当根据基准的SIP兼容的措施和客户端支持的扩展来进行解决。 423间隔太短（interval too brief）服务器由于在祈求中设立的资源刷新时间（或者有效时间）过短而回绝祈求。这个应答可以用于注册服务器来回绝那些Contact头域有效期过短的注册祈求。480临时不可访问（Temporarily Unavailable）被叫的终端系统已经成功连接，但顾客临时不可访问（例如：顾客未登录，或登录为免打扰）。服务器可以在Retry-After头域中此外指定一种访问时间。481呼喊支路/事务不存在（Call leg/Transact

25、ion Does Not Exist）在两种状况下服务器返回该响应：服务器收到一种BYE祈求但找不到匹配的呼喊支路；或是收到一种CANCEL祈求但找不到匹配的事务；或是收到与本来TAG标志不同样的INVITE祈求。（对于无匹配的ACK祈求，服务器直接将它丢弃，不响应）。482检测到循环呼喊（Loop Detected）祈求消息的Via头域中涉及接受服务器自身的地址。483跳数过多（Too Many Hop）祈求的Via头域涉及的条目数（跳数）超过Max-Forwards头域指定的值。484地址不全（Address Incomplete）祈求的To或Request-RUL所指的地址不全。485地

26、址不明确（Ambiguous）祈求中提供的被叫地址不明确。该响应可以在Contact头域中列出不明确的地址。486被叫忙（Busy Here）被叫的终端系统已经成功连接，但顾客临时不乐意或不可以接受更多的呼喊。服务器可以在响应的Retry-After头域中此外指定一种访问时间。客户也也许通过其他方式访问，如：语音邮箱，因此该响应并不终结一种查询。如果我们懂得没有其她终端系统可以接听这个呼喊，那么应当返回一种状态码600（Busy Everywhere）。487祈求被回绝（Request Cancelled）本来的祈求消息被一种CANCEL祈求所取消。488此处祈求不接受（not accepta

27、ble here）这个应答和606（Not Acceptable）有相似的含义，但是只是应用于Request-URI所指出的特定资源不能接受，在其她地方祈求也许可以接受。 涉及了媒体兼容性描述的消息体可以出目前应答中，并且根据INVITE祈求中的Accept头域进行规格化（如果没有Accept头域，那么就是application/sdp）。这个应答就像给OPTIONS祈求的200(OK)应答的消息体同样。491未决祈求（request pending）在同一种对话中，UAS接受到的祈求有一种依赖的祈求正在解决。493无法解密（undecipherable）不可辨识，UAS接受到了一种祈求，涉及

28、了一种加密的MIME,并且不懂得或者没有提供合适的解密密钥。这个应答可以涉及单个包体，这个包体涉及了合适的公钥，这个公钥用于给这个UAS通讯中加密包体使用的。2.6 5xx类消息（服务器错误）5xx消息表达SIP服务器故障不能完毕对对的消息的解决。下面表1-4是常用的5xx类消息列表。表1-4 常用的5xx类消息列表500服务器内部错误（Server Internal Error）服务器浮现异常状况，不能解决祈求。501功能未实现（Not Implemented 不可执行）服务器不支持完毕祈求所必需的功能。502网关错误（Bad Gateway）作为网关或代理的服务器在解决祈求时从其他服务器接

29、受到一种无效响应。503服务不可用（Sevice Unavailable）由于临时超载或正在维护，服务器目前不能解决祈求。504网关超时（Gateway Timeout / service Time-out 服务器超时）作为网关的服务器在解决呼喊的过程中没有及时收到其他服务器（例如：定位服务器）的响应。505版本不支持（Version Not Supported）服务器不能或回绝支持祈求消息所用的版本。513消息过大（message too large）2.7 6xx类消息（全局错误）6xx消息表达祈求不能在任何SIP服务器上实现。下面表1-5是常用的5xx类消息列表。表1-5 常用的5xx类

30、消息列表600 全忙（Busy Everywhere）被叫的终端系统已经成功连接，但顾客正忙，不肯够接受目前呼喊。服务器可以在响应的Retry-After头域中此外指定一种访问时间。该响应仅用于客户不能通过其他方式（如：语音邮箱）访问的状况。如果顾客可通过其他方式访问，则应返回486（Busy Here）响应。603回绝（Decline）被叫的终端系统已经成功连接，但顾客明确不肯接受目前呼喊。服务器可以在响应的Retry-After头域中此外指定一种访问时间。604 被叫不存在（Does Not Exist Anywhere）祈求的To头域指定的顾客不存在。606不可接受（Not Acceptable）顾客代理已经成功连接，但某些会话描述如媒体类型、带宽或地址风格不能接受。该响应表达顾客但愿建立通信，但不能充足支持祈求所描述的会话。