sip refer 研究.doc

1、流程中的角色分配Referer：transfer（refer）的发起者AliceReferee：refer的接收者 BobNotifier：notify的发起者BobRefer target :transfer流程中目标接收新呼叫者（refer to URI）。 - Carol2、普通的订阅流程普通的订阅流程是用subscribe消息来完成的，在该消息中携带了event头域，针对不同的事件进行订阅。这个订阅方式属于显示的订阅流程。详细的流程说明请参考RFC3265SUBSCRIBE sip:cuixhopen-ims.test SIP/2.0Via: SIP/2.0/UDP 27:6060;rport;branch=z9hG-000eTo: From: ;tag=49f09f68Contact: Call-ID: ZdmAg19580-ID00000002-H16M028S4127CSeq: 5 SUBSCRIBERoute: Max-Forwards: 70User-Agent: Chinamobile-Ucommunicator/version/v1Expires: 1030Event: regAccept: application/reginfo+xmlContent-Length: 0终端订阅成功之后，会马上都到notify消息通知所订阅时间的状态信息。NOTIFY sip:cuixh27:6060;transport=udp SIP/2.0Via: SIP/2.0/UDP 87:4060;branch=z9hG4bKTo: ;tag=49f09f68From: ;tag=499027427f01f9dc47bd8a2d42b63264-ce64CSeq: 10 NOTIFYCall-ID: ZdmAg19580-ID00000002-H16M028S4127Content-Length: 350User-Agent: Sip EXpress router(2.1.0-dev1 OpenIMSCore (i386/linux)Contact: Event: regMax-Forwards: 16Subscription-State: active;expires=1030Content-Type: application/reginfo+xmlsip:cuixh27:6060;transport=udpMessage One (F1)REFER sip: SIP/2.0Via: SIP/2.0/UDP ;branch=z9hG4bK2293940223To: From: ;tag=193402342Call-ID: 898234234CSeq: 93809823 REFERMax-Forwards: 70Refer-To: (whatever URI)Contact: sip:Content-Length: 0Message Two (F2)SIP/2.0 202 AcceptedVia: SIP/2.0/UDP ;branch=z9hG4bK2293940223To: ;tag=4992881234From: ;tag=193402342Call-ID: 898234234CSeq: 93809823 REFERContact: sip:Content-Length: 0Message Three (F3)NOTIFY sip: SIP/2.0Via: SIP/2.0/UDP ;branch=z9hG4bK9922ef992-25To: ;tag=193402342From: ;tag=4992881234Call-ID: 898234234CSeq: 1993402 NOTIFYMax-Forwards: 70Event: referSubscription-State: active;expires=(depends on Refer-To URI)Contact: sip:Content-Type: message/sipfrag;version=2.0Content-Length: 20SIP/2.0 100 TryingMessage Four (F4)SIP/2.0 200 OKVia: SIP/2.0/UDP ;branch=z9hG4bK9922ef992-25To: ;tag=193402342From: ;tag=4992881234Call-ID: 898234234CSeq: 1993402 NOTIFYContact: sip:Content-Length: 0Message Five (F5)NOTIFY sip: SIP/2.0Via: SIP/2.0/UDP ;branch=z9hG4bK9323394234To: ;tag=193402342From: ;tag=4992881234Call-ID: 898234234CSeq: 1993403 NOTIFYMax-Forwards: 70Event: referSubscription-State: terminated;reason=noresourceContact: sip:Content-Type: message/sipfrag;version=2.0Content-Length: 16SIP/2.0 200 OKMessage Six (F6)SIP/2.0 200 OKVia: SIP/2.0/UDP ;branch=z9hG4bK9323394234To: ;tag=193402342From: ;tag=4992881234Call-ID: 898234234CSeq: 1993403 NOTIFYContact: sip:Content-Length: 0两种方式的不同点：隐式订阅（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想携带 HTT