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:[email protected] SIP/2.0 ([email protected] 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:[email protected]>

From: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

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:[email protected]>;tag=zpNctbZq

To: <sip:[email protected]>;tag=ie4hbb8t

Call-ID: [email protected]

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=”<[email protected]>”;

boundary=”50UBfW7LSCVLtggUPe5z”

Content-Length: 1560

–50UBfW7LSCVLtggUPe5z

Content-Transfer-Encoding: binary

Content-ID: <[email protected]>

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:[email protected]”

version=”1″ fullState=”true”>

<name xml:>

<name>Bob Smith</name>

<instance id=”juwigmtboe” state=”active”

cid=”[email protected]”/>

</resource>

<resource uri=”sip:[email protected]”>

<name>Dave Jones</name>

<instance id=”hqzsuxtfyq” state=”active”

cid=”[email protected]”/>

</resource>

<resource uri=”sip:[email protected]”>

<name>Ed at NET</name>

</resource>

<resource uri=”sip:[email protected]”>

<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.