SIP 请求方法（7）- REFER

        RFC3515中定义了REFER方法，UA使用REFER方法请求另一个UA访问一个URI或URL资源。资源内容由Refer-To头域指定，通常是URI或URL，Refer-To头域对REFER请求来说是必须的。这里的URI或URL可以是任何类型的URI：sip, sips, http, pres等等。URI是sip或sips时，REFER可以实现呼叫转移服务。还可以用REFER实现P2P(peer-to-peefr)呼叫控制。

        既可以在dialog内，也可以在dialog外发起REFER请求。下图是一个典型的呼叫流程。在这个例子中，UAC向UAS发一条REFER消息，在执行认证及授权之后，UAS决定接受REFER请求，它回应一条202 Accepted (或 200 OK)消息。请注意，响应是即时的，不需要等待触发的请求完成。这一点很重要，因为REFER使用非INVITE方法状态机，它要求立刻给出最终应答，这和INVITE不同，INVITE可能需要几秒钟(甚至几分钟)才能完成。示例中的Refer-To URI是sip URI，因此它变身UAC，发一条INVITE消息，Request-URI设置为Refer-To URI。这个INVITE最终处理成功，返回200 OK。成功的结果通过NOTIFY方法反馈给REFER事务的UAC。NOTIFY消息的消息体包含所触发请求的最终应答的副本。在本例中，它拷贝了应答消息的起始行：SIP/2.0 200 OK。SIP消息的这一部分在Content-Type头域中描述为message/sipfrag 。请注意，这个隐式订阅可以取消，如果不希望订阅，在REFER请求中携带一个头域：Refer-Sub: false，这样对方就不会发NOTIFY了。REFER消息中存在Require: nosub表示不创建隐式订阅。REFER消息中存在Require: explicitsub表示不创建隐式订阅，而是向Refer-Events-At头域中指定的URI发SUBSCRIBE请求进行显式订阅。

 

REFER 流程图

REFER 消息实例：

 

REFER sip:m.rejewski@biuroszyfrow.example.com SIP/2.0
Via SIP/2.0/UDP lab34.bletchleypark.example.org:5060;branch=z9hG4bK932039
Max-Forwards: 69
To: <sip:m.rejewski@biuroszyfrow.example.com>;tag=ACEBDC
From: Alan Turing <sip:turing@bletchleypark.example.org> ;tag=213424
Call-ID: 3419fak3kFD23s1A9dkl
CSeq: 5412 REFER
Refer-To: <sip:info@scherbius-ritter.example.com>
Content-Length: 0

 

        REFER的另一种用法是“推送”Web页面。下图所示，UAC向UAS发一条REFER消息，Refer-To头域描述一个HTTP URL或Web页面。UAS回应202 Accepted，然后向URL所标识的Web服务器发HTTP GET请求。页面加载之后，UAS发一条NOTIFY反馈消息，消息体内容HTTP/1.0 200 OK。

REFER推送Web页面

        REFER请求及它所触发的SIP请求中可以包含Referred-By头域，说明发起者的信息。

        下图展示了REFER的一种高级用法，实现一种PSTN/PBX的常见业务：咨询转移。这个功能中，转移发起方和被转移方同处一个dialog(会话)中。转移发起方向第三方发起INVITE，我们称这一方为转移目标。转移方与转移目标之间的会话建立之后，转移发起方向被转移方发一条REFER请求，它导致被转移方生成一个新的，发给转移目标方的INVITE (称为触发INVITE)。这条INVITE处理成功之后，取代了原先转移发起方与转移目标之间的会话。被转移方通过NOTIFY消息通知转移发起方转移处理成功，转移发起方发BYE请求结束它与被转移方之间的会话。这个应用在Refer-To URI中使用了转义(escaped)字段。也就是说，在URI中指定并预填充某些特定的SIP头域字段，然后反这些字段复制到触发INVITE消息 中。具体到这个实例中，转移发起方把转移流程及触发INVITE所需要的信息写到Replaces头域字段中。被转移方生成触发INVITE消息时，提取转义字段Replaces的值填充到INVITE消息中。

使用 REFER 与Replaces实现指定转移功能题

 

        通过202 Accepted应答接受REFER请求时，建立了一个隐式的订阅(没有SUBSCRIBE请求的订阅。在发出202 Accepted之后，必须马上发一条NOTIFY消息，内容包含状态信息100 Trying和订阅信息Subscription-State: active;expires=60，说明订阅将在60秒后超时(订阅有效时间由状态通知方选择)。Subscription-State头域描述订阅的超时时限。如果触发请求处理完毕之前超时了，双方终止订阅，状态能和方发一条最终通知。

        当被转移方(授受REFER的一方)发出最后通知(带有Subscription-State: terminated;reason=noresource的NOTIFY消息)后，订阅自然结束。通常这是在收到触发请求的最终应答之后发出来的。但是，有时候被转移方可能不希望建立订阅关系，这时，在给出REFER的最终应答之后，可以马上发一条NOTIFY消息说明订阅已经终止。每次发REFER都会独立建立订阅。如果在一个dialog内发出多个REFER请求，那么结果通知(和订阅)由Event头域中的id参数标识。在触发中NOTIFY中，id参数是可选的，但是如果同时收到多个REFER请求，id参数就是必要参数了。

 

        REFER请求中可以携带可选头域Referred-By。Refer-To头域还可以包含功能标记，它告诉REFER接收者引用资源。

REFER请求的必要头：

 

REFER的必要头域

Via

To

From

Call-ID

CSeq

Max-Forwards

Refer-To