SIP协议共定义6 类状态码，其中状态码的第1 位数字用于指示响应类型，后两位数字表示具体响
应。本协议规定状态码为“100—199”之间的响应用“1XX”进行标识，“200—299”之间的响应用
“2XX”进行标识，依此类推。
1）1XX：临时响应，表示请求消息正在被处理。
2）2XX：成功响应，表示请求已被成功接收，完全理解并被接受。
3）3XX：重定向响应，表示需采取进一步以完成该请求。
4）4XX：客户机错误，表示请求消息中包含语法错误信息或服务器无法完成客户机请求。5）5XX：服务器错误，表示服务器无法完成合法请求。
6）6XX：全局故障，表示任何服务器无法完成该请求。
响应代码
SIP 的响应代码在HTTP/1.1 的基础上有所扩展。本规范只涉及到SIP 响应代码，并补充了6xx 响应代码。
1 临时响应1xx
临时性响应即报告性的响应，用来指明所联系的服务器还没有确定性的响应。如果服务器需要
200ms 以上的时间才能发出最终响应，则它就需要首先发送一个1xx 响应。1xx 响应不能进行可靠传输。
它也不能让客户端发送一个ACK 请求。临时响应(1xx)可以包括一些消息体，其中包含会话描述SDP。
1.1 100 (尝试)
尝试响应（100）表明下一跳服务器已经收到该请求，但是对这次呼叫的并未进行具体的处理。和
其他临时响应一样，该响应使UAC 停止重发INVITE 请求。与其他的临时性响应不同，该相应不能使用
有状态服务器前转。
1.2 180 (振铃)
UA 收到INVITE 请求之后用该响应通知用户，该响应也可以在发起一个本地回铃。
1.3 181 (呼叫正在转发)
服务器可以使用该状态码表示该呼叫正被前转到另外一组终点。
1.4 182 (排队)
如果被叫方正忙，服务器可以将本次呼叫放于队列中等待而非拒绝它。当被叫空闲时，将返回适当
的最终响应。该响应中可包含一个关于呼叫状态的原因短语。服务器可以向主叫发出多个182 响应来
更新呼叫等待的状态。
1.5 183 (会话进行)
该响应用来传递关于呼叫进程的信息。其中包括原因短语、头字段、消息体来描述呼叫进程更详细
的信息。
2 2xx(请求成功)
该响应表明请求成功。
2.1 200 (成功)
该响应表示请求成功。与响应一起返回的信息取决于请求中使用的方法。
3 3xx(重定向)
该响应指定用户新位置信息，或者指定可以满足本次呼叫所需要的的其他服务。
3.1 300 (多选择)
请求中的地址可以解析为几个选项，每个选项都有自己特定的位置。用户或者UA 可以确定一个首选的通信端点并且将该请求重定向到该位置。
请求中的消息体可能包含一个资源特征和位置的列表，用户或者UA 可以从中选择一个Accept 头字段中所允许的最合适的资源特征和位置。该消息体不定义MIME 类型。
这些选项可作为Contact 字段列出。SIP 响应可包含几个Contact 字段或者在一个Contact 字段中
有多个地址。UA 可以使用Contact 字段中的值自动重定向，也可以要求用户对选项进行确认。自动选
择的标准定义不再本规范范围之内。如果被叫可以通过多个不同位置到达，且服务器不能代理该请求，则可以使用该状态码。
3.2 301(永久移除)
用当户已经不在Request-URI 头字段的地址中，请求发起用户就应该重发请求至Contact 头字段中
的新地址。请求方应该更新本地姓名地址簿和用户位置并将将来的请求重定向到新地址。
3.3 302 (暂时移除)
请求发起用户应向Contact 头字段中的新地址重发请求。新请求中的Request-URI 是响应中Contact 头字段里的值。Contact 头字段中URI 的有效期可以由Expires 头字段或者Contact 头字段中
的expires 参数来定义。代理服务器和UA 可以在有效期内使用URI。如果没有明确的定义有效期，则
该地址仅可有效递归一次，而以后的事务就不可以再使用该URI。
如果用户向Contact 头字段中的URI 发送请求失败，则应向重定向请求中的URI 尝试发送请求。有
效期过后之后该URI 就不再使用，这时可以使会使用另一个新的暂时性的URI。
3.4 305(用户代理)
用户必须通过Contact 头字段中指定的代理服务器接入到请求的资源。Contact 头字段指定代理服
务器的URI。接收者将通过代理服务器中继该请求。该响应只可由UAS 发出。
3.5 380 (可选择服务)
呼叫不成功但是有另外可供选择的服务。该响应中的消息体中描述了这种另外可以选择的服务。本规范不涉及消息体的格式定义。
4 4xx(请求失败)
该响应由服务器发出表明请求失败。客户机不应（例如增加合适的授权）将原请求不加修改并重新
发送。但将原请求发向不同的服务器也可能成功。
4.1 400(错误请求)
该响应表示请求由于语法错误该而不能被理解。响应的原因短语中应详细指出语法错误. 4.2 401 (未鉴权)
该响应表示请求消息需要用户鉴权。该响应由UAS 和注册服务器发起。407 (代理服务器要
求鉴权)
由代理服务器发起。
4.3 402 (Payment Required)
保留将来使用。
4.4 403 (禁止)
该响应表示服务器能理解但是拒绝执行请求消息。即使该请求已经鉴权也不能进行中继。4.5 404 (未找到)
该响应表示服务器可以确定用户不在Request-URI 头字段指定的域中。如果Request-URI 头字段所
指定的域与请求的接收方所能处理的域不一致时，也应该发送该响应。
4.6 405(方法不允许)
该响应表示在Request-URI 头字段指定的地址上，请求中的方法能够被理解但并不允许使用。该响
应中必须包括一个Allow 头字段来列举指定地址上所允许的方法。
4.7 406(不接受)
该响应表示，根据请求的Accept 头字段，该请求所指定的资源生成响应的消息体中包含的某些内
容特性是不被接受的。。
4.8 407(代理服务器要求鉴权)
该响应类似于401 (未鉴权)，不同的它指定客户机必须首先向代理服务器鉴权自己。该状态码可
用于接入到通信信道中。
4.9 408 (请求超时)
该响应表示服务器不能在适当的时长内产生响应。例如当它不能及时确定用户的位置时。客户端
收到该响应后，可以不加修改便重发原请求。
4.10 410 (Gone)
该响应表示服务器中被请求的资源不可用且服务器不知道转发地址，并且这种情况是永久性的。如
果服务器不知道这种情况是否为永久性的，此时则应该使用404 (未找到)状态码。
4.11 413 (请求过大)
该响应表示，如果请求的消息体超出服务器能够处理范围，服务器将拒绝处理该请求。服务器可以
关闭此连接以防客户端不断发送同一个请求。
如果这种情况是暂时的，服务器应在响应中加入一个Retry-After 头字段用来指定多久以后客户机
可以重发该请求。
4.12 414 Request-URI (过长)
该响应表示，如果Request-URI 超出服务器能够处理的范围，服务器将拒绝处理该请求。4.13 415(不支持媒体类型)
该响应表示服务器不支持某请求方法的消息体格式而拒绝处理该请求。根据具体内容的不同，服务
器必须用响应Accept、Accept-Encoding 或Accept-Language 头字段返回服务器可以接收的格式列表。
关于UAC 如何处理该响应参见本规范8.1.3.5。
4.14 416 (不支持的URI 方案)
该响应表示，由于服务器不理解URI 的方案而不能处理该请求。关于客户端如何处理该响应参见本规范8.1.3.5。
4.15 420(错误扩展)
该响应表示，服务器不理解Proxy-Require 或Require 头字段中协议的扩展规定。服务器必须在响应中的Unsupported 字段中包含一个它不支持的扩展的列表。关于UAC 如何处理该请求参见本规范8.1.3.5。
4.16 421 (扩展要求)
该响应表示，UAS 需要某个特定的扩展才能处理该请求，但是这种扩展没有列在请求中的Supported头字段中。该响应必须包含一个Require 头字段列举所需要的扩展。
除非UAS 不能向客户提供任何其他所需的业务否则不应该使用该响应。如果Supported 字段中没
有所需的扩展，服务器只能用客户端所支持的扩展规定对该请求进行SIP 的基本处理。
4.17 423 (间隔太短)
该响应表示，由于请求更新资源的间隔时间太短，服务器拒绝该请求。注册请求的Contact 字段中
定义的有效期太短，注册服务器可以使用该响应拒绝请求。关于响应的使用以及相关的Min-Expires字段定义参见本规范10.2.8, 10.3,和20.23。
4.18 480 (暂时不可用)
该响应表示，与被叫方成功的联系上，但是被叫目前不可用者。在响应的Retry-After 字段中可以
指定一个合适的呼叫时间，在原因短语应该给出一个详细的原因指明为什么被叫方不可用。这个值可以由UA 来设置。
如果重定向服务器或者代理服务器知道Request-URI 中指定的用户但是目前并没有其有效位置，就可以返回该状态码。
4.19 481 (呼叫/事务不存在)
该响应表示UAS 收到的请求与现有的对话或者事务没有相对应的。
4.20 482(环路检测)
该响应表示服务器检测到有环路。
4.21 483 （跳数太多）
该响应表示，服务器收到的请求中的Max-Forwards 值为零。
4.22 484（地址不完整）
该响应表示，服务器收到的Request-URI 不完整并应在原因短语中提供附加信息。该状态码允许异步拨号（overlapped dialing）。当用户使用异步拨号的方式时并，客户端并不知道拨号字串的的长度。因此它发送的字符串比实际的长，并提示用户输入更多的数字。直到不再收到484 状态码为止。
4.23 485 （不明确）
该响应表示请求中的Request-URI 不明确。该响应中的Contact 字段中可以包含另外一个明确的地址，由于显示替代的Request-URI 可能会破坏用户或者组织的保密性。这种情况下，服务器必须可以做出404(未找到) 响应，或者服务器能够禁止列举可能的URI 选项。
例子如下：
sip:lee@https://www.doczj.com/doc/a53973162.html,:
SIP/2.0 485 Ambiguous
Contact: Carol Lee
Contact: Ping Lee
Contact: Lee M. Foote
有些电子信箱以及语音信箱系统可以提供这种功能。该状态码与3xx 状态码语义不同：对于300响应，假设可以通过所提供的选项到达同一个人或者服务。自动化的选择或者连续的查找只对3xx 有意义，而使用485 (Ambiguous)响应时则需要用户干涉。
4.24 486 （正忙）
该响应表示，已经成功的和被叫终端连接，但是被叫目前不能在该终端系统执行呼叫，响应中的Retry-After 字段可以指定一个合适的呼叫时间。该用户在其他地方可用。如果客户机知道没有别的终端系统可以接受本次呼叫那么应该使用600 (忙)状态码。
4.25 487 （请求终止）
该响应表示，请求被BYE 或者CANCEL 请求终止。CANCEL 请求不可以返回该响应。
17.4.26 488 （此处不接受）
该响应与606 响应的含义相同，但是仅指Request-URI 中指定的资源，如果在别处，该请求可能成功。
该响应中可能存在包含媒体能力描述的消息体，该消息体格式根据INVITE 请求中的Accept 字段
(如果不存在就是application/sdp)规定。21.4.27 491 请求挂起响应
该响应表示，UAS 收到请求但是在同一个对话中该UAS 还有一个等待处理的请求。具体参见本规范14.2。
4.27 493 （无法解密）
该响应表示，UAS 收到的请求包含一个加密的MIME 消息体而接收方没有合适的解码密钥。该响应可以只包含一个消息体，该消息体包含一个公共密钥用来加密发送给UA 的MIME 消息体。关于该响应码参见本规范23.2。
5 5xx（服务器错误）
该响应表示服务器内部出错导致失败。
5.1 500（服务器内部错误）
该响应表示，服务器遇到意外的情况使它不能执行该请求。客户端可以显示这种特定的出错情况，并且可以几秒钟重发该请求。
如果情况是暂时的，服务器可以在Retry-After 字段中指定多久之后客户机可以重发该请求。
5.2 501（不可实现）
该响应表示服务器不支持实现该请求所需要的功能。如果UAS 无法识别该请求的方法并且不支持该方法，就可以发送该响应。如果为代理服务器，它转发请求时都不考虑请求的方法。如果服务器识别了请求中的方法但是并不支持该方法应该发送405 (方法不允许)响应
5.3 502 （错误网关）
当服务器作为网关或者代理服务器时，需要接入到某下行服务器来完成请求，该下行服务器发出该响应表示其为无效网关。
5.4 503 （服务不可用）
该响应表示由于服务器过载或者正在维护而导致服务器暂时不能处理该请求。服务器可以在Retry-After 中指明何时可重发该请求。如果没有Retry-After 则客户端必须按照收到的是500 (服务器内部错误)响应处理。
代理服务器或UAC 收到一个该响应之后应该将该原请求转发到替代的服务器上。如果响应中存在Retry-After 字段，则在该字段定义的时间之内该客户机不能再向原来的服务器发送任何请求。服务器也可以不必发送该响应，而直接拒绝连接或者丢弃原请求。
5.5 504 （服务器超时）
该响应表示，服务器接入到一个外部服务器来处理请求，但是没有及时收到该外部服务器的响应。
如果在Expires 字段中规定的时间之内没有收到上行服务器发来的响应，就应该使用408 (RequestTimeout)响应。
5.6 505 （不支持版本）
该响应表示服务器不支持请求中的协议的版本。
5.7 513(消息过大)
该响应表示，由于消息体的长度超过服务器的处理能力限制，服务器不能处理该请求。
6 6xx(全局失败)
该响应表示服务器对于某一特定用户的确定的信息。
6.1 600 (忙)
该响应表示与被叫终端连接成功，但是被叫因为忙而不能接收呼叫。该响应中的Retry-After 字段指定过多久之后可以重新呼叫。如果被叫不希望给出拒绝本次呼叫的原因则应该使用603 (拒绝)。该响应只用于客户端知道没有别的终端可以接收该请求的情况，否则应该返回486 响应。
6.2 603 (拒绝)
该响应表示，与被叫已经成功连接，被叫用户明确表示不能参与此呼叫。该响应中的Retry-After字段可以指定过多久之后可以重新呼叫。只有客户端知道没有别的终端可以接收该请求才可以使用该响应。
6.3 604 (用户不存在)
该响应通知服务器Request-URI 中的用户根本不存在。
6.4 606 (无法接受)
该响应表示与用户代理已经成功连接，但是会话描述中如请求的媒体、带宽或者地址形式等都不可接受。
该响应可以包含一个Warning 头字段来详细说明不支持该会话描述的原因。关于Warning 参见本规范20.43。
该响应中可以有一个包含媒体能力描述的消息体，它的格式依据INVITE 请求中的Accept 头字段，如果没有该字段，则依据application/sdp。同OPTIONS 请求消息的200 (OK)响应的消息体。
通信中不希望有频繁的协商，但如果一个新用户被邀请参加原有的一个会议根据邀请发起者是否发送606 响应来决定是否需要协商。该响应只用于客户机知道没有别的终端可以响应该请求。
一、SIP协议介绍： 会话发起协议SIP（Session Initiation Protocol）是一个应用层控制信令协议，用于建立、更改和终止多媒体会话或呼叫。SIP作为一个基础，可以在其上提供很多不同的服务。目前已经定义的媒体类型有音频、视频、应用、数据、控制。 二、SIP呼叫流程： 注册流程： （1）用户首次试呼时，终端代理A 向代理服务器发送REGISTER 注册请求； （2）代理服务器通过后端认证/计费中心获知用户信息不在数据库中，便向终端代理回送401Unauthorized 质询信息，其中包含安全认证所需的令牌； （3）终端代理提示用户输入其标识和密码后，根据安全认证令牌将其加密后，再次用REGISTER 消息报告给代理服务器； （4）代理服务器将REGISTER 消息中的用户信息解密，通过认证/计费中心验证其合法后，将该用户信息登记到数据库中，并向终端代理A 返回成功响应消息200 OK。 呼叫流程：
（1）用户摘机发起一路呼叫，终端代理A 向该区域的代理服务器发起Invite 请求；（2）代理服务器通过认证/计费中心确认用户认证已通过后，检查请求消息中的Via 头域中是否已包含其地址。若已包含，说明发生环回，返回指示错误的应答；如果没有问题，代理服务器在请求消息的Via 头域插入自身地址，并向Invite 消息的To 域所指示的被叫终端代理B 转送Invite 请求； （3）代理服务器向终端代理A 送呼叫处理中的应答消息，100 Trying； （4）终端代理B 向代理服务器送呼叫处理中的应答消息，100 Trying; （5）终端代理B 指示被叫用户振铃，用户振铃后，向代理服务器发送180 Ringing 振铃信息； （6）代理服务器向终端代理A 转发被叫用户振铃信息； （7）被叫用户摘机，终端代理B 向代理服务器返回表示连接成功的应答（200 OK）；（8）代理服务器向终端代理A 转发该成功指示（200 OK）； （9）终端代理A 收到消息后，向代理服务器发ACK 消息进行确认； （10）代理服务器将ACK 确认消息转发给终端代理B； （11）主被叫用户之间建立通信连接，开始通话； 结束流程：
ＳIP应答消息状态码与类型状态码状态说明?临时应答(１XＸ）１00 Tｒying 正在处理中 182ｑuｅue 排队 18１ｃall being forwarｄeｒ呼叫正在前向? 180Ringiｎｇ振铃? １81* sessiｏｎproｇｒesｓ会话进行 会话成功（２XＸ）２0０OK 会话成功 重定向（3XＸ）300 ｍultiｐle 多重选择 301 moved pｅｒｍaneｎtｌy 永久移动 302 moveｄteｍporaily 临时移动 ３05 use pｒoxy 用户代理 380 alｔeｒnative seｒvice 替代服务 请求失败(4XX) 40０bad rｅqueｓt 错误请求?４0１unａuthｏrizeｄ未授权 402 ｐayment required 付费要求 403 ｆorbidden禁止 ４04 not found 未发现 40５ｍethod ｎo alｌowed 方法不允许 ４０6 ｎot acceptable 不可接受?4０7 ｐｒoxｙaｕｔhentｉcatｉon reqｕirｅd 代理需要认证?4０8ｒequest timeouｔ请求超时?４１０gｏne离开 41４reqｕest—url too lｏng 请求ＵRL太长?4１5 4１3 request ｅｎtity tｏo large请求实体太大? uｎsupported media typｅ不支持得媒体类型 416unｓｕｐporｔeｄurl scheme 不支持得URL计划? 420ｂａd extｅｎｓｉon 不良扩展?4２1e xｔensｉon ｒｅqｕired需要扩展 481call/ｔran 42３intervａｌtoo ｂrｉｅf间隔太短?4８0 temporａrily uｎavaiｌａble临时失效? 482lｏoｐｄｅtectｅd 发现环路?4８3 too m ｓaｃtiｏｎｄｏes not eｘiｓt 呼叫／事务不存在? 485amｂigｕous 不明朗? 48６busy 484ａｄdrｅss iｎplete 地址不完整? ａnyｈoｐs跳数太多? hｅｒe这里忙 4８7requesｔterｍinateｄ请求终止?4８８nｏt acceptaｂle ｈere 这里请求不可接受 49１request pｅndiｎg 未决请求 ４93unｄecｉｐheｒaｂｌe不可辨识 服务器失败（5ＸＸ）500seｒｖer iｎternal error 服务器内部错误5?０1 noｔimpｌementeｄ不可执行 502 bad gatewａy 坏网关 503 sｅrｖice unａvaｉlable 服务无效? 50５veｒsｉon n 50４ｓeｒｖeｒtiｍe－oｕt 服务器超时? oｔｓupportｅｄ版本不支持 513message toｏｌarge 消息太大 全局性错误（6XＸ) 600 busy everｙwhere 全忙?6０3 declinｅ丢弃?６04 does not exｉｓtａｎy ｗheｒe不存在 ６０6 not aｃceptabｌｅ不可接受 SＩP应答代码(以下就是详细内容） 应答码就是包含了，并且扩展了/1、1应答码。并不就是所有得/1、1应答码都适当应用,只有在折里指出得就是适当得.其她／1、1应答码不应当使用。并且,SIP也定义了新得应答码系列,６xｘ。 1 临时应答１xx?临时应答，也就就是消息性质得应答，标志了对方服务器正在处理请求，并且还没有决定最后得应答。如果服务器处理请求需要花20０ms以上才能产生终结应答得时候，它应当发送一个１xx应
SIP协议学习总结 1、SIP协议定义 SIP（Session Initiation Protocol，即初始会话协议）是IETF提出的基于文本编码的IP电话/多媒体会议协议。用于建立、修改并终止多媒体会话。SIP 协议可用于发起会话，也可以用于邀请成员加入已经用其它方式建立的会话。多媒体会话可以是点到点的话音通信或视频通信，也可以是多点参与的话音或视频会议等。SIP协议透明地支持名字映射和重定向服务，便于实现ISDN，智能网以及个人移动业务。SIP协议可以用多点控制单元（MCU）或全互连的方式代替组播发起多方呼叫。与PSTN相连的IP电话网关也可以用SIP协议来建立普通电话用户之间的呼叫。 SIP协议在IETF多媒体数据及控制体系协议栈结构的位置 H.323SIP RTSP RSVP RTCP H.263 etc. RTP TCP UDP IP PPP Sonet AAL3/4AAL5 ATM Ethernet PPP V.34 SIP协议支持多媒体通信的五个方面： ◆用户定位：确定用于通信的终端系统； ◆用户能力：确定通信媒体和媒体的使用参数； ◆用户有效性：确定被叫加入通信的意愿； ◆会话建立：建立主叫和被叫的呼叫参数； ◆会话管理：包括呼叫转移和呼叫终止； SIP协议的结构 SIP是一个分层的协议，也就是说SIP协议由一组相当无关的处理层次组成，这些层次之间只有松散的关系。 SIP最底层的是它的语法和编码层。编码方式是采用扩展的Backus-Naur Form grammar (BNF范式)。 第二层是传输层。它定义了一个客户端发送请求和接收应答的方式，以及一 个服务器接收请求和发送应答的方式。所有的SIP要素都包含一个通讯层。 第三层是事务层。事务是SIP的基本组成部分。一个事务是UAC向UAS发送的一个请求以及UAS向UAC发送的一系列应答。事务层处理应用服务层的重发，匹配请求的应答，以及应用服务层的超时。任何一个用户代理客户端完成的事情都是
Osip2是一个开放源代码的sip协议栈，是开源代码中不多使用C语言写的协议栈之一，它具有短小简洁的特点，专注于sip底层解析使得它的效率比较高。 eXosip是Osip2的一个扩展协议集，它部分封装了Osip2协议栈，使得它更容易被使用。 一、介绍 Osip2是一个开放源代码的sip协议栈，是开源代码中不多使用C语言写的协议栈之一，它具有短小简洁的特点，专注于sip底层解析使得它的效率比较高。但缺点也专门明显，首先确实是可用性差，没有专门好的api封装，使得上层应用在调用协议栈时专门破裂；其次，只做到了transaction层次的协议过程解析，
缺少call、session、dialog等过程的解析，这也增加了使用的难度；再次，缺少线程并发处理的机制，使得它的处理能力有限。 eXosip是Osip2的一个扩展协议集，它部分封装了Osip2协议栈，使得它更容易被使用。eXosip增加了call、dialog、registration、subscription等过程的解析，使得有用性更强。然而eXosip局限于UA的实现，使得它用于registrar、sip server等应用时极其不容易。另外，它并没有增加线程并发处理的机制。而且只实现了音频支持，缺少对视频和其它数据格式的支持。 综合来讲，Osip2加上eXosip协议栈仍然是个实现Sip协议不错的选择。因此需要依照不同的需求来增加更多的内容。 二、Osip2协议栈的组成 Osip2协议栈大致能够分为三部分：sip协议的语法分析、sip 协议的过程分析和协议栈框架。 1、Sip协议的语法分析：
要紧是osipparser2部分，目前支持RFC3261和RFC3265定义的sip协议消息，包括INVITE、ACK、OPTIONS、CANCEL、BYE、SUBSCRIBE、NOTIFY、MESSAGE、REFER和INFO。不支持RFC3262定义的PRACK。 遵循RFC3264关于SDP的offer/answer模式。带有SDP的语法分析。 支持MD5加解密算法。支持Authorization、www_authenticate 和proxy_authenticate。 2、Sip协议的过程分析： 要紧是osip2部分，基于RFC3261、RFC3264和RFC3265的sip 协议描述过程，围绕transaction这一层来实现sip的解析。 Transaction是指一个发送方和接收方的交互过程，由请求和应答组成。请求分为Invite类型和Non-Invite类型。应答分为响应型的应答和确认型的应答。响应型的应答是指那个应答仅代表
SIP应答消息状态码 与功能 类型状态码状态说明 临时应答(1XX) 100 Trying 正在处理中 180 Ringing 振铃 181 call being forwarder 呼叫正在前向 182 queue 排队 181* session progress 会话进行 会话成功(2XX) 200 OK 会话成功 重定向(3XX) 300 multiple 多重选择 301 moved permanently 永久移动 302 moved temporaily临时移动 305 use proxy 用户代理 380 alternative service 替代服务 请求失败(4XX) 400 bad request 错误请求 401unauthorized 未授权 402 payment required 付费要求 403 forbidden 禁止 404 not found 未发现 405 method no allowed 方法不允许 406 not acceptable 不可接受 407 proxy authentication required 代理需要认证408 request timeout 请求超时 410 gone 离开 413 request entity too large 请求实体太大 414 request-url too long 请求URL太长 415 unsupported media type 不支持的媒体类型416 unsupported url scheme 不支持的URL计划420 bad extension 不良扩展 421 extension required 需要扩展 423 interval too brief 间隔太短 480 temporarily unavailable 临时失效 481 call/transaction does not exist 呼叫/事务不存在482 loop detected 发现环路
SIP消息头域的说明(转) 1 general-header类： 为描述消息基本属性的通用头域，可用于请求消息或响应消息；通用头域的域名只有在协议版本改变时才可有效地扩展。不过，通信中的所有方均认为是“通用头域”的新的头域也可认为是通用头域。不被认可的头域作为实体头域。 1.1 Call-ID Call-ID通用头域唯一标识一个特定的请求或者一个特定客户的所有登记。来自同一个客户的所有的登记应该使用同样的Call-ID头值，至少是在同一个重新启动的循环中。注意到单个的多媒体会议会产生不同Call-ID的几个呼叫，例如，用户多次邀请一个单个的私人加入同一个会议。 对于一个INVITE请求。主叫方用户代理服务器不应该警告用户，如果用户先前已经对INVITE请求中的Call-ID 作出了响应。如果用户已经是会议的一个成员，同时包含在会话描述中的会议参数并未改变，那么主叫方用户代理服务器可以接受此呼叫，而不管Call-ID。对于一个已存在的Call-ID或者会话的邀请可能改变会议的参数。一个客户应用可以决定向用户简单地指示会议参数已经改变，可以自动接受邀请或者可能需要用户的确认。 使用几个不同的Call-ID可以邀请一个用户加入同一个会议或者呼叫。如果需要的话，可以使用在会话描述中的标识来检测此副本。例如，SDP的“o”域中包含了会话标识和版本号。 REGISTER和OPTIONS方式使用Call-ID值来精确匹配请求和响应。一个单个的客户发布的所有的REGISTER请求应该使用同一个Call-ID，至少在同一个有效循环中。 Call-ID = (“Call-ID” | “i”)”:”local-id”@”host Local-id = 1*uric i是Call-ID的缩写形式。 “host”应该是一个真正的域名或者是一个全球性的IP地址。如 此，”local-id”应该是一个由URI字符组成的标识，此标识在”host”中是唯
Sip 响应状态码对照详解 SIP应答消息状态码 与功能 类型状态码状态说明 临时应答(1XX) 100 Trying 正在处理中 180 Ringing 振铃 181 call being forwarder 呼叫正在前向 182 queue 排队 181* session progress 会话进行 会话成功(2XX) 200 OK 会话成功 重定向(3XX) 300 multiple 多重选择 301 moved permanently 永久移动 302 moved temporaily临时移动 305 use proxy 用户代理 380 alternative service 替代服务 请求失败(4XX) 400 bad request 错误请求 401unauthorized 未授权 402 payment required 付费要求 403 forbidden 禁止 404 not found 未发现 405 method no allowed 方法不允许 406 not acceptable 不可接受 407 proxy authentication required 代理需要认证408 request timeout 请求超时 410 gone 离开 413 request entity too large 请求实体太大 414 request-url too long 请求URL太长 415 unsupported media type 不支持的媒体类型416 unsupported url scheme 不支持的URL计划420 bad extension 不良扩展 421 extension required 需要扩展 423 interval too brief 间隔太短 480 temporarily unavailable 临时失效 481 call/transaction does not exist 呼叫/事务不存在482 loop detected 发现环路 483 too many hops 跳数太多 484 address incomplete 地址不完整 485 ambiguous 不明朗 486 busy here 这里忙 487 request terminated 请求终止 488 not acceptable here 这里请求不可接受 491 request pending 未决请求 493 undecipherable 不可辨识
sip代码含义 1xx = 通知性应答 100 正在尝试 180 正在拨打 181 正被转接 182 正在排队 183 通话进展 2xx = 成功应答 200 OK 202 被接受：用于转介 3xx = 转接应答 300 多项选择 301 被永久迁移 302 被暂时迁移 305 使用代理服务器 380 替代服务 4xx = 呼叫失败 400 呼叫不当 401 未经授权：只供注册机构使用，代理服务器应使用代理服务器授权407 402 要求付费（预订为将来使用) 403 被禁止的 404 未发现：未发现用户 405 不允许的方法 406 不可接受 407 需要代理服务器授权 408 呼叫超时：在预定时间无法找到用户 410 已消失：用户曾经存在，但已从此处消失 413 呼叫实体过大 414 呼叫URI过长 415 不支持的媒体类型 416 不支持的URI方案 420 不当扩展：使用了不当SIP协议扩展，服务器无法理解该扩展 421 需要扩展 423 时间间隔过短
480 暂时不可使用 481 通话/事务不存在 482 检测到循环 483 跳数过多 484 地址不全 485 模糊不清 486 此处太忙 487 呼叫被终止 488 此处不可接受 491 呼叫待批 493 无法解读：无法解读S/MIME文体部分 5xx = 服务器失败 500 服务器部错误 501 无法实施：SIP呼叫方法在此处无法实施 502 不当网关 503 服务不可使用 504 服务器超时 505 不支持该版本：服务器不支持SIP协议的这个版本 513 消息过长 6xx = 全局失败 600 各处均忙 603 拒绝 604 无处存在 606 不可使用 SIP协议应答码 应答代码 应答码是包含了，并且扩展了HTTP/1.1应答码。并不是所有的HTTP/1.1应答码都适当应用，只有在折里指出的是适当的。其他HTTP/1.1应答码不应当使用。并且，SIP也定义了新的应答码系列，6xx。 1 临时应答1xx 临时应答，也就是消息性质的应答，标志了对方服务器正在处理请求，并且还没有决定最后
第一章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）——终止呼叫上的两个用户之间的呼叫 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所示。通过换行符区分命令行和每一条参数行。
图1-1 SIP 请求消息结构 注意：参数行的顺序不是固定的。对应的参数解释见错误！未找到引用源。。 消息体定义： Call-ID ：头字段是用来将消息分组的唯一性标识 From ：头字段是指示请求发起方的逻辑标识，它可能是用户的注册地址。From 头字段包含一个URI 和一个可选的显示名称 CSeq ：头字段用于标识事务并对事务进行排序。它由一个请求方法和一个序列号组成，请求方法必须与对应的请求消息类型一致 Max-Fowords ：头字段限定一个请求消息在到达目的地之前允许经过的最大跳数。它包含一个整数值，每经过一跳，这个值就被减一。如果在请求消息到达目的地之前该值变为零，那么请求将被拒绝并返回一个483（跳数过多）错误响应消息。 Via ：头字段定义SIP 事务的下层（传输层）传输协议，并标识响应消息将要被发送的位置。只有当到达下一跳所用的传输协议被选定后，才能在请求消息中加入Via 头字段值。 expires ：参数指出了该值中包含的URI 地址的有效期。这个参数的值是以秒为单位计算的。如果没有提供该参数，那么URI 地址的有效期由Expires 头字段值来确定。 消息头
SIP 协议学习 1初识SIP 1.1 SIP定义 Session Initiation Protocol会话初始协议是基于文本的信令协议。是一个在IP网络上进行多媒体通信的应用层控制协议。用来创建、修改和终结一个或多个参与者参加的会话进程。 SIP协议可用于发起会话，也可用于邀请成员加入已经用其他方式建立的会话。 SIP基于文本编解码。采用事务机制，每一个请求出发Server的操作方法，请求和响应构成一个事务。事务间彼此独立。 SIP独立于底层传输协议。SIP协议承载在IP网，传输层协议可用TCP或UDP，推荐首选UDP。 SIP支持5方面功能： 1.用户定位：确定通信所用的端系统位置 2.用户能力交换：确定所用的媒体类型和媒体参数 3.用户可用性判定：确定被叫方是否空闲和是否愿意加入通信 4.呼叫建立：邀请和提示被叫，在主被叫之间传递呼叫参数 5.呼叫处理：包括呼叫终结和呼叫转移等 1.2 SIP特点 1.一个正在发展和不断研究中的协议。 2.简练、开放、兼容和可扩展等原则。 3.充分注意到因特网开放而复杂的网络环境下的安全问题。 4.充分考虑了对PSTN的各种业务，包括IN（Intelligent Network智能网）业务和ISDN业 务（Integrated Services Digital Network综合业务数字网）的支持。
2SIP协议 2.1 SIP协议结构 1.最底层的是它的语法和编码层。编码方式是采用扩展的Backus-Naur Form grammar(BNF 范式)。 2.第二层是传输层。定义了一个客户端如何发送请求和接收应答，以及一个服务器如何接 收请求和发送应答。所有的SIP要素都包含一个通讯层。 3.第三层是事务层。事务层处理应用服务层的重发，匹配请求的应答，以及应用服务层的 超时。任何一个用户代理客户端（user agent client UAC）完成的事情都是由一组事务构成的。有状态的代理服务器包含一个事务层;无状态的代理服务器不包含事务层。 4.事务层之上是事务用户TU。每个SIP实体，除了无状态代理，都是一个事务用户。TU 可以创建客户事务，也可以取消客户事务。 2.2 SIP网络结构 User Agent Client (UAC) 用户代理客户端：是一个逻辑的概念，是请求的创建方。UAC 角色只在事务中存在。 User Agent Server(UAS) 用户代理服务器：是一个逻辑的实体，对SIP请求做出接受、拒绝或者转发的响应。UAS角色在事务中存在。 注：UAC和UAS，是在串行事务处理的原理上定义的。当主叫方A发出INVITE请求的
1.SIP 1.1.1.SIP格式 每条SIP消息由以下三部分组成： （1）起始行（Start Line）：每个SIP消息由起始行开始。起始行传达消息类型（在请求中是方法类型，在响应中是响应代码）与协议版本。起始行可以是一请求行（请求）或状态行（响应）。 （2）SIP头：用来传递消息属性和修改消息意义。它们在语法和语义上与HTTP头域相同（实际上有些头就是借自HTTP），并且总是保持格式：<名字>:<值>。 （3）消息体：用于描述被初始的会话（例如，在多媒体会话中包括音频和视频编码类型，采样率等）。消息体能够显示在请求与响应中。SIP清晰区别了在SIP起始行和头中传递的信令信息与在SIP 范围之外的会话描述信息。可能的体类型就包括本文将要描述的SDP会话描述协议。
1.1. 2.消息头 Header field where proxy ACK BYE CAN INV OPT REG Accept R - o - o m* o Accept 2xx - - - o m* o Accept 415 - c - c c c Accept-Encoding R - o - o o o Accept-Encoding 2xx - - - o m* o Accept-Encoding 415 - c - c c c Accept-Language R - o - o o o
Accept-Language 2xx - - - o m* o Accept-Language 415 - c - c c c Alert-Info R ar - - - o - - Alter-Info 180 ar - - - o - - Allow R - o - o o o Allow 2xx - o - m* m* o Allow r - o - o o o Allow 405 - m - m m m Authentication-Info 2xx - o - o o o Authorization R o o o o o o Call-ID c r m m m m m m Call-Info ar - - - o o o Contact R o - - m o o Contact 1xx - - - o - - Contact 2xx - - - m o o Contact 3xx d - o - o o o Contact 485 - o - o o o Content-Disposition o o - o o o Content-Encoding o o - o o o Content-Language o o - o o o Content-Length ar t t t t t t Content-Type * * - * * * Cseq c r m m m m m m Date a o o o o o o Error-Info 300-699 a - o o o o o Expires - - - o - o From c r m m m m m m In-Reply-To R - - - o - - Max-Forwards R amr m m m m m m Min-Expires 423 - - - - - m MIME-Version o o - o o o Organization ar - - - o o o Priority R ar - - - o - - Proxy-Authenticate 407 ar - m - m m m Proxy-Authenticate 401 ar - o o o o o Proxy-Authorization R dr o o - o o o Proxy-Require R ar - o - o o o Record-Route R ar o o o o o o Record-Route 2xx,18x mr - o o o o - Reply-To - - - o - - Require ar - c - c c c - o o o o o Retry-After 404, 413,
SIP协议与视频通信 关键字：SIP视频通信H.323 摘要：文章简要概述现有视频通信技术，包括H.320与H.323应用。然后介绍IETF可以用于视频通信的协议：SIP。在SIP介绍中首先描述SIP协议的历史，然后描述SIP的组成部件。明确部件后举例说明了一个SIP呼叫建立的流程。在第四部分通过与H.323协议族比较来说明SIP用于视频通信的优劣。最后指出SIP协议用于视频通信的前景。 引言 沟通是人类生存的基本需求，通信已成为现代生活中必不可少的内容。在任何时间，任何地点与人和人通信是电信发展的目标。通信技术发展到今天，电话网几乎覆盖全球。语音通信(电话)似乎已基本达到上述目标。但是随着技术的发展，人们已不满足仅仅语音通信。大规模视频通信已成为下一阶段信息产业发展方向。虽然电视会议已出现二十多年，当前不但统一的标准而且有成熟的产品；但是由于种种原因一直没有得到象电话那样的普遍应用。视频通信似乎一直是一座未被足量开采的金矿。随着传输技术的发展，带宽资源已不是瓶颈；随着一场SARS的肆虐，视频通信又成为热点。随着SIP协议的出现，视频通信在技术上又有了新的发展动力。 视频通信协议概述 基于H.320的视频应用 传统会议电视利用以电话网2M或者1.544M直联数字线路连接终端会议电视设备进行实时音频、视频和数据信息的传送。通过使用多点控制器，可以在一块控制板具备所有主会场的操作切换功能。最初会议电视厂家以各自专用的压缩和通信算法进行生产，各个会议电视厂家产品无法互联互通。 随着ITU-T推出H.320协议，上述问题得到很大程度的解决。H.320是同步电路交换网(如ISDN)上现频传输的标准。电路交换网适用于实时应用，如长时间和具有确定延迟的音频和视频信号传递。电路的建立依赖于带外信令、集中的路由控制和昂贵的交换设备。使用H.320协议，电话网上中商用会议电视的理想电路是384 kbps。使用384kbps的电路可以以合理的成本提供高质量的音频和视频信号。采用2M或者1.544M的中继直连当然很容易满足上述带宽要求，但是作等于建立专网，价格将令用户难以承受。 由于电话网络中继价格不断下降以及大量既成事实的基于H.320的电视会议应用，虽然H.320通信成本相对于现有的其它方式稍显昂贵，但其市场仍将在未来数年里继续成长——尽管其成长是缓慢的。 基于H.323协议的视频应用 H.323是国际电信联盟制定的局域网上的多媒体通信系列标准。该协议专门为不提供服务质量(QOS)保证的局域网技术制定，例如运行于以太网、快速以太网和令牌环网(Token Ring)上的TCP／IP和IPX。尽管H.323协议特别为局域网制定，只要带宽时延满足要求同样可以应用在更大范围例如城域网和广域网。1997年5月，国际电信联盟第15研究小组重新定义
2017年第2期信息通信2017 (总第170 期）INFORM ATION & COMMUNICATIONS (Sum. No 170) SIP协议介绍及应用前景分析 杜鑫 (中国人民解放军9155〇部队3分队） 摘要:S IP是一种源于互联网的IP语音会话控制协议，具有灵活、易于实现、便于扩展等特点。文章介绍了 S IP协议的发 展历史、网络组成，通过与传统的电信网络协议对比分析了 S IP协议的特点，结合S IP协议特点及现状对其应用前景进 行了分析。 关键词：SIP ;融合通信;VO LTE;互联网 中图分类号:TN913.23 文献标识码:A文章编号：1673-1131(2017)02-0105-02 1S IP协议的发展历史 SIP(Session Initiation Protocal)会话初始化协议的概念在 1996年出现，主要运用在Internet的不同文本类型当中，用于 电子邮件以及文字聊天等各项环节中。1999年由IE T F最初 建立，应用于Internet的相关网络环境结构当中，实现实时性 通讯。二H世纪初，由IE T F当中的S IP工作团队发出 RFC3261建议后才得到了逐渐推广。 S IP协议最初应用于Internet网络中，实现多媒体的会话 建立控制，后来作为IMS(IP M ultim edia Subsystem IP多媒体 子系统）的主要信令应用于电信领域的VOBB(V oiceover Broad Band宽带语音)，近年来随着LT E的推广，SIP成为LTE 的语音最终解决方案V O LTE的主要信令协议，其应用范围从 特定环境逐步扩展至主流多媒体通信环境。 2 S IP网络组成 2.1 S IP协议在IM S中的应用 S IP协议是IM S中的基本协议,应用于M w、U t、ISC、M i、M g、M j、M k、M r等众多接口，整个IM S网络的会话控制功能 都是由S IP协议完成，具体使用情况如图1所示： P-CSCF ATS IM-SSF SIPl 4 M RFC UGC 19 图1S IP协议在IM S网络中应用示意图 2.2 S IP网络架构 S IP使用CS(Client/server客户端/服务器)架构如图2所 示，交互形式为请求、响应的方式。User Agent C lie n t即客户 端，发起S IP请求;User Agent Server即服务器端，进行S IP请 求处理，并进行响应，Request Proxy Server起到消息路由转发的功能。 3.2认证测试标准 系统B模型采用的简表是07B0,根据K N X协议必须满 足如表1所列的功能需求。认证测试将会针对这些基本功能 来设计测试例进行测试。 按照测试规范[6]要求，先通过E TS配置软件配置好K N X 设备后，采用E IT T软件编写好测试例，运行测试序列，所有测 试例均通过，说明该协议栈符合K N X协议规范要求。在软件 开发过程中，可以通过该方式进行各个功能点的验证，从而保 证软件的可靠性，缩短最终的认证周期。 表1系统B的基本功能表 协议栈主要功能 数据链路层数据帧的封装和解析、应答、数据过滤 网络层正确设置路由计数器 传输层支持四种传输模式；支持style3的状态机 配置和管理直接内存访问；用户内存的直接内存访问；验证模式；接口对象处理；下载状态机；运行状态机；重启；授权；设备描述业务；编程模式；K N X序列号；地址表?，关 联表；组对象表；应用相关参数 4结语 本文介绍的系统B模型的K N X设备是基于LPC处理器、L in u x系统来设计和实现的，并采用了 NCN5120芯片作为 K N X总线收发模块。该设备通过了第三方认证测试实验室的 认证测试，符合K N X协议规范。系统B模型K N X具有更丰 富的资源，可应用于复杂的智能家居和楼宇控制系统中，具有 广阔的市场价值和应用前景。 参考文献： [1]夏长凤.基于K N X总线智能家居控制系统的设计[J].电 器自动化，2016, 38⑴. [2]任志勇.基于K N X智能家居的应用[J].重庆电子工程职 业学院学报,2010, 19(4). [3]Jason Richards,Development o f Complex K N X Devices. W EINZIERL ENGINNERING GmbH,2010. [4]Konnex Association.Konnex Standard,Vol3,System Specifications,2013. [5]Konnex Association.Konnex Standard,Vol6,Profiles,2013. [6]Konnex Association.Konnex Standard,Vol8,System Test Specifications,2013. 作者简介:朱莉(1979-)，女，四川省资中县人，电子工程师，硕 士学位，主要研宄方向为智能家居、大数据、LTE。 105
协议分析 协议扩展分析 STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ????STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?
SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK 与传统 Telephony 业务互通的场景 ?Encapsulation –'Transparent' Transit of ISUP Messages –SIP 与ISUP 协议不可能一一映射 –如果为了保证SP1－SP2之间业务的无缝互通，只有SP1发出的ISUP 消息能够透传到SP2–将ISUP 消息封装在SIP 消息体里–Content-Type: application/ISUP
STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?可STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK SIP GW INVITE SIP Proxy PSTN PSTN IAM SIP GW Transaction STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ???准?STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK SIP GW INVITE SIP Proxy PSTN PSTN IAM SIP GW STATE KEY LABORATORY OF SWITCHING TECHNOLOGY AND TELECOMMUNICATION NETWORK ?规则CANCEL ???
SIP各类消息简介 1.消息简介 sip消息类型和消息格式 SIP是一个基于文本的协议,使用的是UTF-8字符集. SIP消息主要分为两大类: 一类是由客户端发往服务器的请求消息(Request); 一类是由服务器发往客户端的应答消息(Response). 一个基本的SIP消息包括起始行、一个或多个头字段、说明头字段结束的空行和一个可选的消息体。 消息=起始行（包括请求行/状态行；请求行规定了请求的类别，而状态行指出了每个请求的状态，比如是成功还是失败。如果是失败的话还要给出失败的原因或类型。） *头字段 CRLF [消息体] （消息首部给出了关于请求或应答的更多信息一般包括消息的来源、规定的消息接收方，另外还包括一些其他方面的重要信息。消息体通常描述将要建立会议的类型包括所交换媒体的描述，但不具体定义消息体的内容或结构，其结构或内容使用另外一个协议来描述，就是会话描述协议SDP。） 2.请求消息 请求行=方法+空格+请求地址+SIP版本号+空行 通过一个请求行作为起始行，请求行包括了方法名、请求的URL、协议版本号、中间用空格分开。 六种请求方法： INVITE 发出呼叫会话请求 ACK INVITE请求被最终请求 BYE 释放一个呼叫会话 CANCEL 取消挂起的呼叫 REGISTER 登记注册用户代理 OPTIONS 查询服务器能力 3.应答消息 状态行=SIP版本+空格+状态码+空格+相关文本短语+空行 SIP应答消息状态码与功能 类型状态码状态说明 临时应答(1XX) 100 Trying 正在处理中 180 Ringing 振铃 181 call being forwarder 呼叫正在前向 182 queue 排队
sip协议解析与实现(c和c++使用osip)11 第八章查询能力 SIP的OPTIONS方法允许一个UA查询另外一个UA或者一个代理服务器的能力。这能让客户端探测关于它们所支持的方法、内容类型、扩展和编码等信息，而不用"呼叫(ringing)"另外一端。例如，在客户端插入了一个Require头域到INVITE 中，并列出了不确定目标UAS是否支持的能力之前，它可以先使用OPTIONS方法查询目标UAS是否要查询的选项被目标UAS在应答的Supported头域中返回。所有UA必须支持OPTIONS方法。 OPTIONS方法的目标使用Request-URI来标识，因为它可以表示不同的UA或者SIP服务器。如果OPTIONS被定位到一个代理服务器，Request-URI不由客户端设置，这类似于REGISTER请求设置Request-URI的方法。 如果服务器接收到一个Max-Forwards头域的值为0的的OPTIONS请求，它要对这个请求进行应答而不用管Request-URI. 这个行为与HTTP/1.1一致。这个行为可以被用于"追踪路由线路(traceroute)"功能，从而使用发送一系列递增的 Max-Forwards值的OPTIONS请求的方法检查消息路由过程中个别服务器的能力。
作为一般UA的行为，如果OPTIONS长时间没有应答，事务层能够返回一个超时错误。这将指出，目标是不可到达的并且查询的能力是不可以使用的。 OPTIONS请求可能由建立一个对话的一端发送，用于查询对端在后面的对话中可能会被使用到的能力。 第一节构造OPTIONS请求 OPTIONS请求使用像RFC3261第8.1.1讨论的标准的构造SIP请求的规则来构造。 OPTIONS可能会有一个Contact头域。 应该包含一个Accept头域用来指出UAC希望接收到的应答中的消息体类型。典型的，这可能被设置成用来描述UA的媒体能力的类型，比如，SDP(application/adp)。OPTIONS请求的应答被认为是有限定范围的，它被限定在原始请求的Request-URI内。只有当OPTIONS被作为建立对话的一部分发送，它保证会话中后继的请求也由应答OPTIONS的服务器所接收时，对OPTIONS请求的应答才是可用的。 OPTIONS请求的例子： OPTIONS sip:carol@https://www.doczj.com/doc/a53973162.html, SIP/2.0 Via: SIP/2.0/UDP https://www.doczj.com/doc/a53973162.html,;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70