Q: 一个最基本的SIP会话是什么样的?
A:
INVITE
|---------------------------->|
100 Trying
|<----------------------------|
180 Ringing
|<----------------------------|
200 OK
|<----------------------------|
ACK
|---------------------------->|
Q: SIP消息的基本格式 ?
A: SIP消息可以从是client到server的请求，也可以是server到client的应答。其基本格式如下：
*message-header
CRLF
[ message-body ]
start-line = Request-Line / Status-Line
*表示1个或多个， []表示是可选的。
对于请求消息：
Request-Line = Method SP Request-URI SP SIP-Version CRLF
对于应答消息：
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF
Q: 请求的方法有哪些？
A: RFC3261定义了6个基本的方法，分别是REGISTER, INVITE, ACK, CANCEL, BYE, OPTIONS.
REGISTER:注册联系信息，
INVITE, ACK, and CANCEL： 建立会话
BYE：终止会话
OPTIONS：查询server的服务信息.
注：其它RFC文档定义了一些 SIP扩展，其中增加了一些方法。
Q: Staus code有哪些 ?
A: 一个最基本的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 不可辨识
服务器失败(5XX) 500 server internal error 服务器内部错误
501 not implemented 不可执行
502 bad gateway 坏网关
503 service unavailable 服务无效
504 server time-out 服务器超时
505 version not supported 版本不支持
513 message too large 消息太大
全局性错误(6XX) 600 busy everywhere 全忙
603 decline 丢弃
604 does not exist anywhere 不存在
606 not acceptable 不可接受
Q: UA, UAC, UAS ?
A: UA: 一个用户代理,代表了一个终端系统。它包含一个用户代理客户端（UAC）,用来产生请求的;它包含一个用户代理服务端（UAS），用来响应请求的。
Q: 合法的SIP请求必须至少包含哪些头域 ?
A: TO,FROM, Cseq, Call-ID, Max-Forwards, Via。
To头域：请求的”逻辑”接收地，
To: Carol <sip:carol@chicago.com>
From头域：请求发起者的逻辑标志
From: “Bob” <sips:bob@biloxi.com> ; tag=a48s
Call-ID：是区分一组消息的唯一标志。
Cseq头域：用于区分事务，排序事务。由一个方法（method）和号码组成。方法（method）必须和请求的方法一致。
Cseq: 4711 INVITE
Max-Forwards头域：用来限制请求到他的目的地中间的跳转。
Via头域：是标志了用于事务传输的传输设备，并且也标志了应答送回的地址。
注：Contact头域：提供了访问后续请求的特定UA实例的联系方法：SIP或者SIPS URI。
Q: Early Offer, Delay Offer ?
A:
假设John@xx.com向Dave@yy.com发送Invite消息。
在Early Offer中，John在发送Invite时就包含SDP描述，而Dave在发送200 OK时包含SDP描述。
在Delay Offer中，Dave在发送200 OK时包含SDP描述，而John在发送ACK时包含SDP描述。
Q. 带内信令和带外信令
A. 在很久很久以前（long long ago)，那时候人们还处于模拟通信和机械式交换机的时代（纵横或者步进），那时候不存在独立的信令网，交换机之间的“语言交流（信令）”和语音信号在一条传输通道上跑。这就是带内信令。后来发展了，交换机之间的“语言交流（信令）”和语音信号的传输分别走不同的传输通道，建立起独立的信令网，这样信令信号走信令网，语音走语音的传输通道，两者分道扬镳，这就是带外信令！
带内信令是指信号的频率在话音频率范围之内（0.3~3.4kHz）。带内信号是在话音通道内传递的。
带外信令，又叫共路信令，是一种采用在信息传输频率/信道之外的频率/信道传输信令技术。在带内信令可能受到各种网络问题影响的情况下，带外信令经常被用于传输控制命令以报告相关的错误信息。
另外，
SIP协议中我比较care的字段有哪些？
A.
Call-ID 头字段Call-ID 头字段唯一的标识某个客户端的某个特定的邀请或所有的注册请求。一个多媒体会议可
以发起几个 Call-ID不同的呼叫，例如，某用户可以多次邀请某人参与同一个会议。Call-ID 区分大小
写并逐字节比较。缩写形式为 i。例如：
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4
From 头字段
From头字段用于指示请求的发起者。
To 头字段
该头字段指定请求的逻辑接收者。
Cseq 头字段
Cseq 头字段位于请求消息中，包含一个十进制数字序列和一个请求方法。该数字序列必须一个 32
比特的无符号整数来表示。Cseq 头字段的方法部分区分大小写。该头字段用于把某对话中的事务进行
排序且提供了一种唯一标识某事务的方法，并能够区分某请求是新的请求还是重发的请求。如果两个
Cseq的数字序列以及方法都相等那么这两个 Cseq就是等价的。例如:
CSeq: 4711 INVITE
Contact 头字段
Contact 头字段指定一个 SIP 或 SIPS URI，后续请求可以用它来联系到当前 UA。任何能够建立对
话的请求消息中都必须有Contact头字段，并且该头字段中只能含有一个 SIP 或 SIPS URI。在本规范定
义的请求方法中，只有 INVITE 能建立对话。对这些能建立对话的请求，Contact的作用范围是全局的。
也就是说，Contact头字段值中包含的URI是 UA 希望用来接收请求的地址，即使用在任何对话外的后
续请求消息中，该URI也必须有效。
Allow 头字段
该字段列出请求发起 UA所支持的方法。UA 能理解的所有方法就必须列于该头字段中。消息中若无
该头字段，则意味 UA 未提供任何关于它所支持的方法的信息，并不意味着 UA不支持任何方法。
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE
Subject 头字段
Subject头字段包括呼叫的概述或者呼叫的性。举例如下：
Subject: Need more boxes
Retry-After 头字段
Retry-After 头字段用在 500 (服务器内部错误) 或 503 (服务不可用)响应中，可以对请求发起
客户端指示多久以后服务不可用，用于 404 (未找到), 413 (请求过大), 480(暂时不可用), 486 (正
忙), 600 (忙),或者603(下降)响应中表明被叫何时可用。该值用一个十进制的正整数表示，单位为秒，
从响应发出开始计时。
Retry-After: 120
Also 头字段 [ SIP Call Control Services - Internet Draft]
Also字段建议客户端转发INVITE请求到列表中的地址。每一个请求应该包含Requested-By头字段，其内容为
包含Also字段的消息的From字段。
Also = "Also" ":" 1#( SIP-URL | URI ) [ comment ]
Example header:
Also: sip://jones@foo.com, sip://mueller@bar.edu
假设A, B和C是终端结点，下面是一个典型的会话场景:
A -> B: INVITE B SIP/2.0
Call-ID: 19971214T123503.33@A
Also: C
From: A
B -> A: SIP/2.0 200 OK
Call-ID: 19971214T123503.33@A
From: A
B -> C: INVITE C SIP/2.0
Call-ID: 19971214T123503.33@A
From: B
Requested-By: A
C -> B: SIP/2.0 200 OK
Call-ID: 19971214T123503.33@A
From: B
另一个会话场景如下：
A -> G: INVITE G SIP/2.0
From: A
Call-ID: 19971214T124523.00@A
G -> A: SIP/2.0 200 OK
From: A
Call-ID: 19971214T124523.00@A
Also: X, Y, Z
A -> X: INVITE X SIP/2.0
From: A
Call-ID: 19971214T124523.00@A
Requested-By: G
A -> Y: INVITE Y SIP/2.0
From: A
Call-ID: 19971214T124523.00@A
Requested-By: G
SIP协议中我比较care的status code有哪些？
A.
100 (尝试)
尝试响应（100）表明下一跳服务器已经收到该请求，但是对这次呼叫的并未进行具体的处理。和
其他临时响应一样，该响应使 UAC 停止重发 INVITE 请求。与其他的临时性响应不同，该相应不能使用
有状态服务器前转。
该响应表示请求成功。与响应一起返回的信息取决于请求中使用的方法。
302 (暂时移除)
请求发起用户应向 Contact 头字段中的新地址重发请求。新请求中的 Request-URI 是响应中
Contact头字段里的值。Contact头字段中URI 的有效期可以由 Expires 头字段或者Contact 头字段中
的 expires 参数来定义。代理服务器和 UA 可以在有效期内使用 URI。如果没有明确的定义有效期，则
该地址仅可有效递归一次，而以后的事务就不可以再使用该 URI。
500（服务器内部错误）
该响应表示，服务器遇到意外的情况使它不能执行该请求。客户端可以显示这种特定的出错情况，
并且可以几秒钟重发该请求。
如果情况是暂时的，服务器可以在 Retry-After 字段中指定多久之后客户机可以重发该请求。500（服务器内部错误）
参考文献：
1， http://www.iplogos.fr/English-Resources/Focus/sip-early-media-early-offer-en.html
2, http://blog.csdn.net/kukumouse/article/details/2270279
29
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
