SIP

 +----------------------------------------------------------------------------------------------------------------------------------------------------------------+
 +               SIP协议 RFC3261             +   RFC2327 SDP 我们主要有三类的会话描述：会话描述、时间描述、媒体描述，具体你可以参看RFC 2327
 +----------------------------------------------------------------------------------------------------------------------------------------------------------------+
ICT: 客户端邀请事务，由客户端发起的
 
0d0a == 回车换行CRLF
 每行后面都有这个，最后的消息头有 2个

状态码
 1：临时 2：成功 3：重定向(多个contact) 4：客户端错误 5：服务器错误 6：全局错误

SIP消息
 SUBSCRIBE  方法用于请求随后一个事件或一组事件的异步通知。
 NOTIFY     方法用于通知SIP节点先前由SUBSCRIBE 请求的事件已经发生。该方法也可以提供与该事件有关的更进步的详细信息。  
 INFO       消息的目的是沿着SIP信令通路携带应用层消息。
   并不是用来改变SIP呼叫的状态，或会议SIP的初始化状态参数。它仅是用于发送通常与会议有关的应用层的可选信息。
   传送SIP 会议中生成的 DTMF 数字
   在会议的参加者之间传送影像或其它的非流信息
 re-INVITE   能够用于在一个会一种改变会议的特性。这通常是与会议相关的媒体流量的属性或者更新SIP会议地计时器。
   增加/删除媒体流
   改变地址，端口
   永不分支，因为确定的UA
   
   
 REFER    呼叫转移
 OPTIONS  请求可以作为建立会话的一部分，用来查询对方的能力使用
 MESSAGE  即时消息IM

 拆除当前对话，从而保护服务器自身资源，达到keep-alive的目的。
SIP概念：http://www.cnblogs.com/gordon-gao/articles/2516443.html
 call : 会议中每个UA是同一个call-ID = 随机数字@IP或者主机名 
 事务：
  transaction存在于相邻SIP实体：UAC，UAS
  一个事务包含一个请求消息，0或多个临时响应消息，1或者多个最终响应消息
  请求经过每个有事务状态的proxy时，proxy会生成一个服务器端事务和一个客户端事务，
   并把自己的URI添加到VIA的栈顶，并生成一个全局的branch，所以事务以此来区分。
  INVITE事务：UAC一定要回ACK，用3次握手来保证。其他事务：INFO，OPTIONS
 对话：
  端到端的信令关系。UA之间的，不会与代理间有对话。
  dialog起始于对INVITE（REFER）的一个非失败的响应，如200OK，终止于任意一方发出的BYE
  一个呼叫可能包含多个对话（会议）；用call-ID, from, to来标识
  早对话：1XX 到 2XX 之间，可能会有UPDATE请求
 会话： 
  存在时间，同对话
 VIA：
  最下面的VIA是初始化请求的UA插入的；上面的是经过的每个代理插入的
 cseq :  
  标识事务并对事务排序
  初始化时随机，后续按各自方向+1
  可标识是新的请求，还是重发的请求
 contact
  UA希望接受请求的地址，后续请求可以用这个来联系当前UA
  如果代理没有插入record-route, 则后续请求可以忽略它，直接用contact来请求
  
SIP注册
 为增强安全性，运营商在给你分账号的时候会给你一个用户名和密码，这个呢，是用来鉴权用的，
  当你给软交换发注册报文后，服务器会先回应401，请证明，并会带上加密的方法（一般md5）、随机数，
   你就带上你的用户名以及用随机数加密密码后的字符串再发一个注册包，
    这样服务器也会用同样的算法加密后比较字符串，一样的就回应200 OK，不一样就回应403。
 如果你每次发的报文call-id是一样的，cseq也是一样的，那么服务器会认为重复发包，不理会。如果是鉴权的第二个注册包，那么cseq会+1。
  当发起第一个注册包时，会起一个定时器，一般是0.5，但是这个值可以根据实际的网络条件调整，如果在0.5s内没有收到服务器的响应，
   就重发一遍，协议规定的是0.5、1、2、4、4、4、4、4、4、4s来重发，大概是32s的时间内，前面也说了要是你网络延迟实在厉害，这个值是可以调整的，只要是按照T1、2T1，4T1、8T1，8T1，8T1，8T1，8T1，8T1，8T1就可以了。
 解决了 需要在返回401后 把验证信息保存下来 然后再当心跳发送

 

    

  
  
RFC3261中定义了两个基准定时器T1＝500ms和T2＝4s。
客户端：
 T1:500ms, 超时重传INVITE
 TB: 64T1, 超时终结事务 （超时还未收到ACK，状态转为确认，但应当用BYE来终止）
服务端：
 Th：64T1，超时终结事务
 T2:8T1=4s，重传，T1超时后，加到T2后以T2重传
非INVITE：
 Tf: 64T1=32s，超时终结事务,F（TCP）and E (UDP)
 
   
8. 对话
 对话ID = call-id + 本地标签 + 远端标签
 对话的创建时机：发送2XX或1XX等非失败响应时，进入初始对话状态
 UAS：   响应中包含
  请求中的Record-Route, 保持顺序
  Contact : 后续对话的地址, SIPS ore SIP要与其他消息保持一致
  路由集：    
  远端目的：   请求中contact URI
  远端序列号： 请求中的Cseq
  本地序列号： 空
  呼叫标识符： 请求中的call-id
  本地标签/URI：   请求To tag/URI
  远端标签/URI：   请求From tag/URI
 对话中的请求 发往第一个Route 或者 requestURI
  Request-URI : 远端目的 or 。。。
  Route:        路由集，lr 等参数确定（不含lr，表示本代理服务器不理解此路由机制，）
  目标刷新请求消息 只修改远端URI？ INVITE 由 reINVITE 来刷新
  收到含To tag的请求
  收到的序列号问题：远端序列号为空，大于请求序列号  
  
9. 会话发起过程
 发送INVITE，收到2XX后，发送ACK；
  请求可能被分叉，所以可能收到多个2XX，每个都是属于同个呼叫的一个对话，通过TO中的TAG区别，对每个都要回ACK
 UAC： 
  Supported: 支持的扩展功能  
   INVITE sdp 请求， 2XX sdp 响应
   2XX            ,  ACK   
 UAS：   发送2XX, 未收到ACK时，间隔T1后重发，间隔时间加倍，直到T2，仍未收到，发送BYE 
10. 会话更改过程
 通过在已经建立的Dialog中发送reINVITE来修改媒体流，媒体接受地址等
  UAC：reINVITE中携带新的SDP，过程不能重叠
  UAS：更改是否有效，是就修改，发送2XX，等ACK，等不到发送BYE；否就发送488.
11. 会话结束过程
 通过BYE，或者拒绝
  UAC：发送BYE
  UAS：收到BYE，检查相应的对话，不存在，发送481；存在，发送2XX；正在处理，发送487
12. 代理服务器
 将请求和应答分别路由到UAS，UAC的SIP实体。也可作应答：错误响应，鉴权，此时相当于UAS
  无状态：转发后即丢失信息
  有状态：事物状态，可能分叉请求，即把一个请求分到多个服务器。
   采用TCP传输（有状态传输）时可以不用记录事物状态？两种类型可以随时转换
13. SIP事务
 非2XX响应，其事务包括ACK消息；2XX，不包括ACK
  非INVITE事务： 不使用ACK
 响应与客户端事务匹配:  即判断是否为重传的
  1. via branch 一致
  2. Cseq的方法 一致 （cancel请求与原请求属于不同事务，但branch一致）
  多播请求下，只处理第一个响应。（To tag不同）
 服务器端事务
  100响应，避免重传产生的网络拥塞
  请求与服务端事务的匹配
   1. via branch "z9hG4bk..."
   2. via sendby ,防止不同客户端产生的branch相同
   3. via method
14. 传输
 面向连接的传输 : TCP（处理大块消息？） SCTP TLS。 两个对等的代理服务器使用面向连接传输协议时，会使用2个连接用于各自方向上的连接？？？
 客户端传输层：
  UDP 改 TCP，用于 处理大消息 或者 使用拥塞控制协议（MTU最大传输单元）
  组播时，via 中添加 maddr == 目的地组播地址, ttl = 1
  add via: sendby ==
  UDP default port == 5060   TLS == 5061
  接受响应 检查sendby
 服务器传输成
  sendby 中的地址同包的来源不同，添加via received == 所收数据包的源地址 ？？？
  响应处理：IP: received or sendby中的地址     port : sendby中的端口
 数据帧 content-length
  面向消息的传输 UDP 。。。超长，丢弃；短了，错误
  面向流  的传输 TCP 消息体的大小
      
15. 普通的消息成分
 SIP:user:passwd@host:port;uri-param?heads  (可能没用户部分)
  参数：transport, maddr, ttl(UDP组播数据包的生存时间), lr
 转义 ： a == %61 (% HEX)
 URI比较
18. HTTP鉴权的使用
 质询鉴权，分类digest鉴权机制，用401、407来要求UAC鉴权
 UAC：
  收到401后，重新发请求，Cseq 加 1
  有证书，在Authorization中提供证书；无，用anonymous重试
  407:  proxy-authorization
 UAS：
  401中www-authenticate携带质询参数：realm,
  407中的proxy-autherticate

  
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 read from UDP:10.50.144.100:8578 --->
INVITE sip:90002@10.50.146.14 SIP/2.0
Via: SIP/2.0/UDP 10.50.144.100:8578;rport;branch=z9hG4bK1433206046
From: <sip:90001@10.50.146.14>;tag=1898566852
To: <sip:90002@10.50.146.14>
Call-ID: 1125968959
CSeq: 21 INVITE
Contact: <sip:90001@10.50.144.100:8578>
Authorization: Digest username="90001", realm="asterisk", nonce="628e2fa5", uri="sip:90002@10.50.146.14", response="58cf8d7ee6328ec232c9788b10816ca0", algorithm=MD5
Content-Type: application/sdp                                                       //  用于媒体协商
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO   // Allow: 支持的请求方法
Max-Forwards: 70
User-Agent: Linphone/3.4.0 (eXosip2/unknown)
Subject: Phone call
Content-Length: 376

v=0
o=90001 3239 3239 IN IP4 10.50.144.100            //origin  所有者/创建者 和会话标识
s=Talk                                            //subject 会话的主题
c=IN IP4 10.50.144.100                            //connect 连接信息 多播地址
b=AS:256
t=0 0                                              //time 会话时间，SIP用外部信令的方式建立媒体流，所以为0
m=audio 7076 RTP/AVP 111 110 100 104 3 0 8 101     //media 每个媒体流，可以有0个或者多个  通常，0 端口号指示不期望该媒体流，下面的格式按照优先级排列
a=rtpmap:111 speex/16000                          // 指示从RTP 载荷类型到编码的映射
a=fmtp:111 vbr=on                                 // 提供媒体格式的其他参数
a=rtpmap:110 speex/8000
a=fmtp:110 vbr=on
a=rtpmap:100 iLBC/8000
a=fmtp:100 mode=30
a=rtpmap:104 AMR/8000
a=fmtp:104 octet-align=1
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-11
<-------------> 

 

<--- SIP read from UDP:10.50.146.30:39842 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.50.146.14:5060;branch=z9hG4bK216c45cc;rport=5060
Contact: <sip:90002@10.50.146.30:39842;rinstance=cbe06931a28eb1a2>
To: <sip:90002@10.50.146.30:39842;rinstance=cbe06931a28eb1a2>;tag=a31f2211
From: "90001"<sip:90001@10.50.146.14>;tag=as12dbc590
Call-ID: 510ea8f5478874b773eaa4e943708402@10.50.146.14:5060
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
User-Agent: eyeBeam release 1102q stamp 51814
Content-Length: 184

v=0
o=- 3 2 IN IP4 10.50.146.30
s=CounterPath eyeBeam 1.5
c=IN IP4 10.50.146.30
t=0 0
m=audio 48000 RTP/AVP 0 101
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=sendrecv                                    // 媒体流的方向，收发是默认的，inactive只通信
<------------->