本帖最后由 siyzhang 于 2015-7-16 11:38 编辑 进行SIP呼叫分析时，我们经常会遇到Refer和Notify消息，它们的工作原理和信令结构究竟是怎样的呢？{:2_27:}
思科官方详细的refer介绍:
http://www.cisco.com/c/en/us/td/docs/ios/voice/sip/configuration/guide/15_0/sip_15_0_book/sip_cg-msg_tmr_rspns.html#wp1057413
http://www.cisco.com/c/en/us/td/docs/ios/voice/sip/configuration/guide/15_0/sip_15_0_book/sip_cg-call_x-fer.html
Blind Call-Transfer Process
盲转: A blind, or unattended, transfer is one inwhich the transferring phone connects the caller to a destination line beforeringback begins.
This isdifferent from a consultative, or attended, transfer in which one of thetransferring parties either connects the caller to a ringing phone (ringbackheard) or speaks with the third party before connecting the caller to the thirdparty. Blind transfers are often preferred by automated devices that do nothave the capability to make consultation calls.
1、流程中的角色分配
Referer：transfer（refer）的发起者—Alice
Referee：refer的接收者 –Bob
Notifier：notify的发起者—Bob
Refertarget :transfer流程中目标接收新呼叫者（refer to URI）。 -- Carol
2、普通的订阅流程
普通的订阅流程是用subscribe消息来完成的，在该消息中携带了event头域，针对不同的事件进行订阅。这个订阅方式属于显示的订阅流程。详细的流程说明请参考RFC3265
SUBSCRIBEsip:siyzhang@cisco.test SIP/2.0
Via:SIP/2.0/UDP 192.168.111.127:6060;rport;branch=z9hG-000e
To:
From:;tag=49f09f68
Contact:
Call-ID: ZdmAg19580-ID00000002-H16M028S41@192.168.111.127
CSeq: 5SUBSCRIBE
Route:orig@cisco.test:6060;lr>
Max-Forwards:70
User-Agent:Cisco/version/v3.2.1.71
Expires:1030
Event: reg
Accept:application/reginfo+xml
Content-Length:0
终端订阅成功之后，会马上都到notify消息通知所订阅时间的状态信息。
NOTIFYsip:siyzhang@192.168.111.127:6060;transport=udp SIP/2.0
Via:SIP/2.0/UDP 192.168.110.187:4060;branch=z9hG4bK
To:;tag=49f09f68
From:;tag=499027427f01f9dc47bd8a2d42b63264-ce64
CSeq: 10NOTIFY
Call-ID: ZdmAg19580-ID00000002-H16M028S41@192.168.111.127
Content-Length:350
User-Agent:Sip EXpress router
Contact:
Event: reg
Max-Forwards:16
Subscription-State:active;expires=1030
Content-Type:application/reginfo+xml
sip:siyzhang@192.168.111.127:6060;transport=udp
3、隐式订阅的流程
Agent A Agent B
| |
| F1 REFER |
| -----------------------> |
| F2 202Accepted |
| <----------------------- |
| F3 NOTIFY |
| <----------------------- |
| F4 200 OK |
| -----------------------> |
| |
| |
| |------->
| |(whatever)
| |<------
| |
| F5 NOTIFY |
| <----------------------- |
| F6 200 OK |
| -----------------------> |
| |
| |
MessageOne (F1)
REFERsip:b@cisco.test.example SIP/2.0
Via:SIP/2.0/UDP cisco.test.example.com;branch=z9hG4bK2293940223
To:
From:;tag=193402342
Call-ID: 898234234@cisco.test.example.com
CSeq:93809823 REFER
Max-Forwards:70
Refer-To: (whatever URI)
Contact:sip:a@cisco.test.example
Content-Length:0
MessageTwo (F2)
SIP/2.0202 Accepted
Via:SIP/2.0/UDP cisco.test.example.com;branch=z9hG4bK2...
两种方式的不同点：隐式订阅（refer发起的订阅）没有duration。而该订阅的有效时长是由对端决定 的。Refer的发送方和接受方可以在第一个notify消息中协商duration。如果终端接受了refer消息，但是并不想保持subscribe 的状态，则可以在第一个notify中结束掉订阅。
这个duration 应该比refer请求相关的方法完成的时间要长一点。如一个refer to为SIP INVITE URI，那么订阅的duration应该比invite的完成时间要长一点。还有时间可能需要给需要给subscribe鉴权
取消订阅隐式订阅：终端可用一个refer消息来结束subscribe事物，要么取消订阅要么拒绝notify。
一个发起refer的终端should not产生一个cancel消息来结束refer事物，因为终端发refer消息来结束该事物。
终端可以扩展subscribe的时长，通过订阅刷新扩展
3、Referer的行为-请求Refer的作用： 建立关于event：refer的隐式订阅
Refer的特点： Ⅰ、refer消息也可以会话内的.必须（MUST）遵守record-rout 机制
Ⅱ、refer消息也可以是会话外的，但是可以（MAY）遵守record-rout 机制。因此MUST携带一个contact
头域
Ⅲ、同一个会话内的dialog不能fork。会话外的refer可以fork。如果refer消息被多个终端接受，将产生
多个订阅事件。终端对不同的终端响应的notify消息可以独立管理。
Refer的构造： Header：
Refer-to:refer请求must包含一个具体的refer-to头域值。 refer-to头域只能在refer消息中出现。在该
头域中提供了一个URI供后续流程使用。该头域可以端到端加密
Refer-By：refer请求的发起方
Body： Refer消息可以携带body。refer的接收者可以根据自己的content-type来选择处理这个body
（关于body没有具体的说明）
Referer的行为-接收响应订阅事务的创建通常马上会发起一个notify消息，那么refer的发起方创建完subscribe事物后，must马上准备好接收notify消息
Refer是对唯一可以对event：refer产生订阅的机制。如果终端没有发起refer订阅，但是收到携带了event：refer的subscribe-notify消息的时候应该回403消息。
4、Referee的行为如果终端收到refer消息后并回了2**消息，那么终端MUST根据refer-to URI与Goal（Carol）建立会话。
如果终端收到refer消息中含有0个或者多与1个的refer-to头域，则应该回400消息
终端收到refer消息后，可能返回100、4**~6**的响应消息
当终端没有能力处理非sip uri的refer消息，那么should not 接受refer请求。
如果按照规则，终端一直没有收到refer的响应，那么应该refer事物超时之前回202
如果终端收到2xx响应，则接受方必须创建一个subscribe事物并notify refer事物的状态信息。
对refer-to涉及的资源的访问。在refer-to头域中定义的资源的访问机制为普通的访问机制。举个例子：如果这个URI携带了invite指示，那么终端将按照普通的机制产生一个invite发送出去
5、Notifier的行为Notify的作用： notify机制用于给refer的发起方通知refer事物的状态信息。该notify消息中的from、to、callid必须与refer消息一致，前提是创建了隐式订阅。
Notify的组成： Header：
Ⅰ、每个notify消息中必须包含一个event 头域，并且该头域的值必须为refer。如果需要的话，可能还需要一个id参数
Ⅱ、Notify消息中还可以携带warning头域
Ⅲ、notify消息中must携带Subscription-State 头域，refer最后的notify响应必须将订阅的状态terminated 并携带reason=no resource
Body；
每个notify用户都必须包含一个message/sipfrag的包体。当终端的subscribe事物处于pending状态，此时产生的notify消息至少要包含一个100trying。Notify消息中不同情况携带不同的响应码：
SIP/2.0 100 Trying 订阅状态为 pending
SIP/2.0 200 OK Refer成功
SIP/2.0 503 业务失败或者不支持
SIP/2.0 603 Declined refer事物失败
6、Notifier的行为异常场景： Ⅰ、refer-to 为非sip-uri：notify中body中应该为sip 响应码。
例如：一个终端收到refer-to为HTTP uri，该终端可以获得相关的资源，那么终端可以给
referer的notify消息中包含message/sipfrag 包体 “SIP/2.0 200 OK”.如果notifier想携带
HTTP URI相关的非sip 协议的特殊信息，那么可以在sipfrag消息中携带。
Ⅱ、同一个dialog中的多个refer消息：在一个dialog内发出了第二个refer消息中，那么在
refer消息中必须携带一个id参数在event头域。Id的值为相对应的refer消息的CSeq。
ID参数可能包含在第一个notify消息。如果订阅刷新或者结束订阅则应该携带id参数。
发送速率：
Notify消息的发送速率不能超过1个/s
7、Refer target的行为Carol对transfer的动作一点感觉都没有，她感觉只是收到来自Bob的一个普通呼叫
