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
presentity@example.com's presence agent.
SUBSCRIBE sip:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7
To: <sip:presentity@example.com>
From: <sip:watcher@example.com>;tag=12341234
Call-ID: 12345678@host.example.com
CSeq: 1 SUBSCRIBE
Max-Forwards: 70
Expires: 3600
Event: presence ( 如果是Watcher information 的SUBSCRIBER,Event: present.winfo)
Contact: sip:user@host.example.com
Content-Length: 0
M2: The presence agent for presentity@example.com 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:presentity@example.com>;tag=abcd1234
From: <sip:watcher@example.com>;tag=12341234
Call-ID: 12345678@host.example.com
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:user@host.example.com SIP/2.0
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
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:presentity@example.com">
<tuple id="mobile-phone">
<status>
<basic>open</basic>
</status>
<timestamp>2003-02-01T16:49:29Z</timestamp>
</tuple>
<tuple id="gwewg991">
<status>
<basic>open</basic>
</status>
<timestamp>2003-02-01T12:21:29Z</timestamp>
</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:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
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:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
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:presentity@example.com">
<tuple id="efeef223">
<status>
<basic>closed</basic>
</status>
<timestamp>2003-02-01T17:00:19Z</timestamp>
</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:presentity@example.com>;tag=1a2b3c4d
From: <sip:presentity@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com
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:user@host.example.com SIP/2.0
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
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:presentity@example.com">
<tuple id="efeef223">
<status>
<basic>closed</basic>
</status>
<timestamp>2003-02-01T17:00:19Z</timestamp>
</tuple>
<tuple id="gwewg991">
<status>
<basic>open</basic>
</status>
<timestamp>2003-02-01T12:21:29Z</timestamp>
</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:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
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:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK771ash02
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=1234kljk
Call-ID: 98798798@pua.example.com
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:presentity@example.com>;tag=2affde434
From: <sip:presentity@example.com>;tag=1234kljk
Call-ID: 98798798@pua.example.com
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:presentity@example.com SIP/2.0
Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bKcdad2
To: <sip:presentity@example.com>
From: <sip:presentity@example.com>;tag=54321mm
Call-ID: 5566778@pua.example.com
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:presentity@example.com">
<tuple id="efeef223">
<status>
<basic>open</basic>
</status>
<timestamp>2003-02-01T19:15:15Z</timestamp>
</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:presentity@example.com>;tag=effe22aa
From: <sip:presentity@example.com>;tag=54321mm
Call-ID: 5566778@pua.example.com
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:user@host.example.com SIP/2.0
Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK32defd3
To: <sip:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
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:presentity@example.com">
<tuple id="efeef223">
<status>
<basic>open</basic>
</status>
<timestamp>2003-02-01T19:15:15Z</timestamp>
</tuple>
<tuple id="gwewg991">
<status>
<basic>open</basic>
</status>
<timestamp>2003-02-01T12:21:29Z</timestamp>
</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:watcher@example.com>;tag=12341234
From: <sip:presentity@example.com>;tag=abcd1234
Call-ID: 12345678@host.example.com
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".