SIP 消息流程，模糊了RLS 和PS 這些節點。原來想和（一）合在一起。還是單獨寫出來吧。後面在繼續一點XCAP部分，描述下RLS,PS 與XDMS 之間的業務和消息流程。

也就貼了下RFC 裡的消息流程。

PUA PA WATCHER

(EPA) (ESC)

| | |

| | <---- M1: SUBSCRIBE --- |

| | |

| | ----- M2: 200 OK -----> |

| | |

| | ----- M3: NOTIFY -----> |

| | |

| | <---- M4: 200 OK ------ |

| | |

| ---- M5: PUBLISH ---> | |

| | |

| <--- M6: 200 OK ---- | |

| | |

| | ----- M7: NOTIFY -----> |

| | |

| | <---- M8: 200 OK ------ |

| | |

| ---- M9: PUBLISH ---> | |

| | |

| <--- M10: 200 OK --- | |

| | |

| --- M11: PUBLISH ---> | |

| | |

| <-- M12: 200 OK ---- | |

| | |

| | ----- M13: NOTIFY ----> |

| | |

| | <---- M14: 200 OK ----- |

| | |

Event State: State information for a resource, associated with an event package and an address-of-record.

Event Publication Agent (EPA): The User Agent Client (UAC) that issues PUBLISH requests to publish event state.

Event State Compositor (ESC): The User Agent Server (UAS) that processes PUBLISH requests, and is responsible for compositing event state into a complete, composite event state of a resource.

A User Agent Client (UAC) that publishes event state is labeled an Event Publication Agent (EPA). For presence, this is the familiar Presence User Agent

(PUA) role. The entity that processes the PUBLISH request is known as an Event State Compositor

M1: The watcher initiates a new subscription to the

[email protected]'s presence agent.

SUBSCRIBE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7

To: <sip:[email protected]>

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

Call-ID: [email protected]

CSeq: 1 SUBSCRIBE

Max-Forwards: 70

Expires: 3600

Event: presence ( 如果是Watcher information 的SUBSCRIBER，Event: present.winfo)

Contact: sip:[email protected]

Content-Length: 0

M2: The presence agent for [email protected] processes the

subscription request and creates a new subscription. A 200 (OK)

response is sent to confirm the subscription.

SIP/2.0 200 OK

Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7

;received=192.0.2.1

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

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

Call-ID: [email protected]

CSeq: 1 SUBSCRIBE

Contact: sip:pa.example.com

Expires: 3600

M3: In order to complete the process, the presence agent sends the

watcher a NOTIFY with the current presence state of the

presentity.

NOTIFY sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2

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

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

Call-ID: [email protected]

CSeq: 1 NOTIFY

Max-Forwards: 70

Event: presence

Subscription-State: active; expires=3599

Contact: sip:pa.example.com

Content-Type: application/pidf+xml

Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="pres:[email protected]">

</status>

</tuple>

</status>

</tuple>

</presence>

M4: The watcher confirms receipt of the NOTIFY request.

SIP/2.0 200 OK

Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2

;received=192.0.2.2

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

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

Call-ID: [email protected]

CSeq: 1 NOTIFY

M5: A presence user agent for the presentity initiates a PUBLISH to

the presentity's presence agent in order to update it with new

presence information. The Expires header indicates the desired

duration of this soft state.

PUBLISH sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge

To: <sip:[email protected]>

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

Call-ID: [email protected]

CSeq: 1 PUBLISH

Max-Forwards: 70

Expires: 3600

Event: presence

Content-Type: application/pidf+xml

Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="pres:[email protected]">

<basic>closed</basic>

</status>

</tuple>

</presence>

M6: The presence agent receives, and accepts the presence

information. The published data is incorporated into the

presentity's presence document. A 200 (OK) response is sent to

confirm the publication. The 200 (OK) response contains an

SIP-ETag header field with an entity-tag. This is used to

identify the published event state in subsequent PUBLISH requests.

SIP/2.0 200 OK

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge

;received=192.0.2.3

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

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

Call-ID: [email protected]

CSeq: 1 PUBLISH

SIP-ETag: dx200xyz

Expires: 1800

M7: The presence agent determines that a reportable change has been

made to the presentity's presence document, and sends another

notification to those watching the presentity to update their

information regarding the presentity's current presence status.

NOTIFY sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a

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

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

Call-ID: [email protected]

CSeq: 2 NOTIFY

Max-Forwards: 70

Event: presence

Subscription-State: active; expires=3400

Contact: sip:pa.example.com

Content-Type: application/pidf+xml

Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="pres:[email protected]">

<basic>closed</basic>

</status>

</tuple>

</status>

</tuple>

</presence>

M8: The watcher confirms receipt of the NOTIFY request.

SIP/2.0 200 OK

Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a

;received=192.0.2.2

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

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

Call-ID: [email protected]

CSeq: 2 NOTIFY

Content-Length: 0

M9: The PUA determines that the event state it previously published

is about to expire, and refreshes that event state.

PUBLISH sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02

To: <sip:[email protected]>

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

Call-ID: [email protected]

CSeq: 1 PUBLISH

Max-Forwards: 70

SIP-If-Match: dx200xyz

Expires: 3600

Event: presence

Content-Length: 0

M10: The presence agent receives, and accepts the publication

refresh. The timers regarding the expiration of the specific

event state identified by the entity-tag are updated. As always,

the ESC returns an entity-tag in the response to a successful

PUBLISH. Note that no actual state change has occured, so the

watchers will receive no NOTIFYs.

SIP/2.0 200 OK

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02

;received=192.0.2.3

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

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

Call-ID: [email protected]

CSeq: 1 PUBLISH

SIP-ETag: kwj449x

Expires: 1800

M11: The PUA of the presentity detects a change in the user's

presence state. It initiates a PUBLISH request to the presence

agent to modify the published presence information with the recent

change.

PUBLISH sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2

To: <sip:[email protected]>

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

Call-ID: [email protected]

CSeq: 1 PUBLISH

Max-Forwards: 70

SIP-If-Match: kwj449x

Expires: 3600

Event: presence

Content-Type: application/pidf+xml

Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="pres:[email protected]">

</status>

</tuple>

</presence>

M12: The presence agent receives, and accepts the publication

modification. The timers regarding the expiration of the specific

event state identified by the entity-tag are updated, and the

published data is incorporated into the presentity's presence

document. Note that the document delivered in this modification

will replace the previous document.

SIP/2.0 200 OK

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2

;received=192.0.2.3

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

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

Call-ID: [email protected]

CSeq: 1 PUBLISH

SIP-ETag: qwi982ks

Expires: 3600

M13: The presence agent determines that a reportable change has been

made to the presentity's presence document, and sends another

notification to those watching the presentity to update their

information regarding the presentity's current presence status.

NOTIFY sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3

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

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

Call-ID: [email protected]

CSeq: 2 NOTIFY

Max-Forwards: 70

Event: presence

Subscription-State: active; expires=3400

Contact: sip:pa.example.com

Content-Type: application/pidf+xml

Content-Length: ...

<?xml version="1.0" encoding="UTF-8"?>

<presence xmlns="urn:ietf:params:xml:ns:pidf"

entity="pres:[email protected]">

</status>

</tuple>

</status>

</tuple>

</presence>

M14: The watcher confirms receipt of the NOTIFY request.

SIP/2.0 200 OK

Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3

;received=192.0.2.3

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

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

Call-ID: [email protected]

CSeq: 2 NOTIFY

Content-Length: 0

RFC 3265 - Session Initiation Protocol (SIP)-Specific Event Notification

在NOTIFY 中，通過Subscription-State header 來決定目前的SUBSCRIBER是否成功。200 OK 隻是在transaction 層面上對于SUBSCRIBER的一個response，并不能說明SUBSCRIBER是否成功，需要後續的NOTIFY消息來告知。

If the "Subscription-State" header value is "active", it means that

the subscription has been accepted and (in general) has been

authorized. If the header also contains an "expires" parameter, the

subscriber SHOULD take it as the authoritative subscription duration

and adjust accordingly. The "retry-after" and "reason" parameters

have no semantics for "active".

If the "Subscription-State" value is "pending", the subscription has

been received by the notifier, but there is insufficient policy

information to grant or deny the subscription yet. If the header

also contains an "expires" parameter, the subscriber SHOULD take it

as the authoritative subscription duration and adjust accordingly.

No further action is necessary on the part of the subscriber. The

"retry-after" and "reason" parameters have no semantics for

"pending".

If the "Subscription-State" value is "terminated", the subscriber

should consider the subscription terminated. The "expires" parameter

has no semantics for "terminated". If a reason code is present, the

client should behave as described below. If no reason code or an

unknown reason code is present, the client MAY attempt to re-

subscribe at any time (unless a "retry-after" parameter is present,

in which case the client SHOULD NOT attempt re-subscription until

after the number of seconds specified by the "retry-after"

parameter). The defined reason codes are:

deactivated: The subscription has been terminated, but the subscriber

SHOULD retry immediately with a new subscription. One primary use

of such a status code is to allow migration of subscriptions

between nodes. The "retry-after" parameter has no semantics for

"deactivated".

probation: The subscription has been terminated, but the client

SHOULD retry at some later time. If a "retry-after" parameter is

also present, the client SHOULD wait at least the number of

seconds specified by that parameter before attempting to re-

subscribe.

rejected: The subscription has been terminated due to change in

authorization policy. Clients SHOULD NOT attempt to re-subscribe.

The "retry-after" parameter has no semantics for "rejected".

timeout: The subscription has been terminated because it was not

refreshed before it expired. Clients MAY re-subscribe

immediately. The "retry-after" parameter has no semantics for

"timeout".

giveup: The subscription has been terminated because the notifier

could not obtain authorization in a timely fashion. If a "retry-

after" parameter is also present, the client SHOULD wait at least

the number of seconds specified by that parameter before

attempting to re-subscribe; otherwise, the client MAY retry

immediately, but will likely get put back into pending state.

noresource: The subscription has been terminated because the resource

state which was being monitored no longer exists. Clients SHOULD

NOT attempt to re-subscribe. The "retry-after" parameter has no

semantics for "noresource".

SIP Presence (二)RFC 3265 - Session Initiation Protocol (SIP)-Specific Event Notification

RFC 3265 - Session Initiation Protocol (SIP)-Specific Event Notification

繼續閱讀

[zz]The Most Important Algorithms (in CS and Math)

OBJ分析代碼

Wireshark的Pcap檔案格式分析及解析源碼【轉】

What are training set, validation set and test set?

穩紮穩打Silverlight(53) - 4.0通信之對WCF NetTcpBinding的支援, 在Socket通信中通過HTTP檢索政策檔案, HTTP請求中的ClientHttp和Browse

壓縮編碼M-JPEG、MPEG4、H.264

invalid byte 1 of 1-byte UTF-8 sequence

出現invalid byte 1 of 1-byte UTF-8 sequence問題

批處理程式設計- -介紹DOS/BAT

解決"T-SQL無法附加到程序"錯誤的補充,T-SQLcan not attach to process

spec檔案詳解

設定某一行背景顔色的CListCtrl

處理PCX檔案

坐标系統和投影變換在桌面産品中的應用

Small tricks

無元件上傳圖檔到資料庫中，最完整解決方案