SIP Presence SUBSCRIBE-NOTIFY
来源:互联网 发布:十大淘客软件 编辑:程序博客网 时间:2024/04/24 21:04
本文分享自:http://www.ucunleashed.com/?p=189
Share from:http://www.ucunleashed.com/?p=189
SUBSCRIBE message is send by Subscriber that intends to receive notification of the state change on certain resource.
NOTIFY message is send by Notifier which is mostly the one that receives the subscribe request and sends NOTIFY message to the subscriber at state change of the requested resource.
When subscriber sends SUBCRIBE request to notifier node, a subscription is created at notifier. This subscription remains valid for the time specified in the subscribe request. Subscription can be refreshed by sending another SUBSCRIBE request before the subscription expires. In response to successful subscription creation/updation, the notifier sends back 200 OK.
If notifier feels that subscription duration is too small then it will respond with ‘423 Interval too small’.
SUBSCRIBE message contains event package that denotes the kind of state information needed by the subscriber. For example, presence package as in example below means subscriber is interested in presence related information such as user unavailable, user available from the notifier.
SUBSCRIBE sip:adam-buddies@pres.vancouver.example.com SIP/2.0 (adam-buddies@pres.vancouver.example.com maps to list of URIs on which effective subscriptions are created)
Via: SIP/2.0/TCP terminal.vancouver.example.com;
branch=z9hG4bKwYb6QREiCL
Max-Forwards: 70
To: <sip:adam-buddies@pres.vancouver.example.com>
From: <sip:cmm@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 322723822 SUBSCRIBE
Contact: <sip:cmm.vancouver.example.com>
Event: presence (Refers to event package presence)
Expires: 7200 (Refers to expiration duration before which subscription must be refreshed by AS)
Supported: eventlist (Refers to the fact that AS supports eventlist returned in NOTIFY)
Accept: application/pidf+xml (Refers to PIDF format for presence event representation)
Accept: application/rlmi+xml(Refers to Resource list meta-info format of list of events send in Notify)
Accept: multipart/related(Refers to support of MIME contents in event state information)
Content-Length: 0
NOTIFY message from the notifier contains state information of the all the subscriber mentioned in the corresponding SUBSCRIBE request. The response contains xml payload in SIP message. Call-id field present in NOTIFY is used by subscriber to correlated it with SUBSCRIBE request.
NOTIFY sip:cmm.vancouver.example.com SIP/2.0
Via: SIP/2.0/TCP pres.vancouver.example.com;
branch=z9hG4bKMgRenTETmm
Max-Forwards: 70
From: <sip:adam-buddies@pres.vancouver.example.com>;tag=zpNctbZq
To: <sip:cmm@vancouver.example.com>;tag=ie4hbb8t
Call-ID: cdB34qLToC@terminal.vancouver.example.com
CSeq: 997935768 NOTIFY
Contact: <sip:pres.vancouver.example.com>
Event: presence
Subscription-State: active;expires=7200
Require: eventlist
Content-Type: multipart/related;type=”application/rlmi+xml”;
start=”<nXYxAE@pres.vancouver.example.com>”;
boundary=”50UBfW7LSCVLtggUPe5z”
Content-Length: 1560–50UBfW7LSCVLtggUPe5z
Content-Transfer-Encoding: binary
Content-ID: <nXYxAE@pres.vancouver.example.com>
Content-Type: application/rlmi+xml;charset=”UTF-8″<?xml version=”1.0″ encoding=”UTF-8″?>
<list xmlns=”urn:ietf:params:xml:ns:rlmi”
uri=”sip:adam-friends@pres.vancouver.example.com”
version=”1″ fullState=”true”>
<name xml:lang=”en”>Buddy List at COM</name>
<name xml:lang=”de”>Liste der Freunde an COM</name>
<resource uri=”sip:bob@vancouver.example.com”">
<name>Bob Smith</name>
<instance id=”juwigmtboe” state=”active”
cid=”bUZBsM@pres.vancouver.example.com”/>
</resource>
<resource uri=”sip:dave@vancouver.example.com”>
<name>Dave Jones</name>
<instance id=”hqzsuxtfyq” state=”active”
cid=”ZvSvkz@pres.vancouver.example.com”/>
</resource>
<resource uri=”sip:ed@dallas.example.net”>
<name>Ed at NET</name>
</resource>
<resource uri=”sip:adam-friends@stockholm.example.org”>
<name xml:lang=”en”>My Friends at ORG</name>
<name xml:lang=”de”>Meine Freunde an ORG</name>
</resource>
</list>
It may always happen that if notifer understands the SUBSCRIBE request then subscription will be created. Sometimes, the request may be understood but not authorized so ‘202 Accepted’ response is send back to the subscriber.
Proxies don’t assume any other role than routing SUBSCRIBE, NOTIFY request based on SIP headers present in the request. If subscriber and notifier choose to not disclose the bodies to proxies then they may choose S/MIME type bodies from transamitting encrypted payloads.
- SIP Presence SUBSCRIBE-NOTIFY
- sip presence , subscribe 和 notify 中文
- sip中的subscribe和notify扩展应用技术
- sip中的subscribe和notify扩展应用
- sip中的subscribe和notify扩展应用技术
- sip中的subscribe和notify扩展应用
- sip中的subscribe和notify扩展应用技术
- sip中的subscribe和notify扩展应用技术
- SIP Presence
- SIP Presence
- SIP Presence (二)
- SIP Presence相关...
- 基于P2P-SIP的Presence业务
- SIP Presence and Instant Message Example
- Presence
- 基于会话启动协议的事件通告机制 SUBSCRIBE NOTIFY
- dubbo Ignore empty notify urls for subscribe url
- SIP常用消息实例参考 4、SUBSCRIBE消息
- 自定义组合控件
- 5.Builder-建造者模式
- 框架之初识Struts2 概念及工作原理
- SIP Presence相关...
- Backbone基础-01
- SIP Presence SUBSCRIBE-NOTIFY
- Forking in SIP
- debian进入单用户模式更改密码
- Why only SIP INVITE can be CANCELed ?
- SIP MESSAGE Delivered
- super位置
- 基于RSTP协议的流媒体播放
- dev C++ windows程序 undefine reference to
- TEC1304.值集和弹性域相关技术总结 - 第四章 弹性域安全性详解