SIP Presence SUBSCRIBE-NOTIFY

 

本文分享自: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.