SIP Events:SIP Events:Changes and Open Changes and Open IssuesIssuesIETF 50 / SIP Working GroupIETF 50 / SIP Working GroupAdam RoachAdam Roachadam.roach@ericsson.comadam.roach@ericsson.com

ExcusesExcuses

I intended to release a new I intended to release a new events draft for this events draft for this meeting…meeting…

……but I had more important but I had more important deliverables.deliverables.

State AgentsState Agents(n(née “Event Agents”)ée “Event Agents”)

Generalization of a “presence agent”.Generalization of a “presence agent”. May be aggregation points for state May be aggregation points for state

and/or surrogates for offline clients.and/or surrogates for offline clients. Base draft will describe migration of Base draft will describe migration of

subscriptions from state agents to subscriptions from state agents to endpoints.endpoints.

Package drafts will be required to Package drafts will be required to define semantics (if any) for migration.define semantics (if any) for migration.

Out-of-band SubscriptionsOut-of-band Subscriptions(aka “Unsolicited Notifications”)(aka “Unsolicited Notifications”)

Any subscription initiated by mechanism Any subscription initiated by mechanism other than “SUBSCRIBE” method.other than “SUBSCRIBE” method.

Discussion will be reduced to single Discussion will be reduced to single sentence explicitly allowing them. (e.g. sentence explicitly allowing them. (e.g. “Subscriptions may be created via “Subscriptions may be created via mechanisms other than a SUBSCRIBE mechanisms other than a SUBSCRIBE request.”)request.”)

Raises need for clarification: 481 responses Raises need for clarification: 481 responses to NOTIFY to NOTIFY MUSTMUST remove remove allall subscriptions, subscriptions, even those provisioned out-of-band.even those provisioned out-of-band.

PINT Backwards PINT Backwards CompatibilityCompatibility

Addressed in current draft: no Addressed in current draft: no event header => PINT semantics.event header => PINT semantics.

No open issues.No open issues. Speak now or forever hold your Speak now or forever hold your

peace.peace.

Throttling of eventsThrottling of events Consensus from interim meeting: Consensus from interim meeting:

each package will define a throttling each package will define a throttling mechanism appropriate to its specific mechanism appropriate to its specific events.events.

Next draft will remove this from “open Next draft will remove this from “open issues” section.issues” section.

Next draft will include requirement Next draft will include requirement that packages include a discussion of that packages include a discussion of notification throttling.notification throttling.

Instant NotificationInstant Notification A delay in the initial NOTIFY might A delay in the initial NOTIFY might

otherwise convey additional otherwise convey additional information (e.g. user online, information (e.g. user online, subscription manually rejected, subscription manually rejected, etc).etc).

Need to clarify that a NOTIFY with Need to clarify that a NOTIFY with a default (innocuous) state will be a default (innocuous) state will be sent immediately.sent immediately.

Authorization IssuesAuthorization Issues(still open)(still open)

We need a general-purpose mechanism by We need a general-purpose mechanism by which subscription authorization may be which subscription authorization may be performed in a way which allows user performed in a way which allows user interaction.interaction.

Is generalization of QAUTH the way to go, or Is generalization of QAUTH the way to go, or should we use a notification of subscription should we use a notification of subscription attempt which can then result in a manual attempt which can then result in a manual update of policy?update of policy?

Proposal: subscription authorization issues will Proposal: subscription authorization issues will be handled in a separate draft. (Volunteers?)be handled in a separate draft. (Volunteers?)

SUBSCRIBE Response SUBSCRIBE Response CodesCodes

(vaguely open)(vaguely open)

202 is noncommital: “wait for a NOTIFY” 202 is noncommital: “wait for a NOTIFY” (which contains an “Expires: 0” if you’ve (which contains an “Expires: 0” if you’ve been rejected).been rejected).

Is it allowable to return a “403” or “603” to Is it allowable to return a “403” or “603” to mean “no way, bubba -- it just ain’t gonna mean “no way, bubba -- it just ain’t gonna happen; don’t even wait for a NOTIFY”?happen; don’t even wait for a NOTIFY”?

Conversely, is it allowable to return a “200” Conversely, is it allowable to return a “200” to say “your subscription is 100% guaranteed to say “your subscription is 100% guaranteed to have been accepted, and I will send you a to have been accepted, and I will send you a valid, successful NOTIFY post haste”?valid, successful NOTIFY post haste”?

Denial of Service ConcernsDenial of Service Concerns(still open)(still open)

One SUBSCRIBE in, several SUBSCRIBE One SUBSCRIBE in, several SUBSCRIBE replies and several NOTIFY requests out replies and several NOTIFY requests out is a recipe for disaster.is a recipe for disaster.

Proposed solution: keep no state for Proposed solution: keep no state for unauthenticated SUBSCRIBE messages.unauthenticated SUBSCRIBE messages.

Can be strengthened by allowing each Can be strengthened by allowing each userid/password combination to have userid/password combination to have only one pending SUBSCRIBE in each only one pending SUBSCRIBE in each node. (Is this reasonable and viable?)node. (Is this reasonable and viable?)

ForkingForking(brace yourself)(brace yourself)

Much discussion at interim meeting, Much discussion at interim meeting, but no conclusion.but no conclusion.

Main sticking point seems to be Main sticking point seems to be concern that accepting multiple concern that accepting multiple NOTIFY messages will disrupt route NOTIFY messages will disrupt route setups, since route setup will occur in setups, since route setup will occur in SUBSCRIBE responses, and only one SUBSCRIBE responses, and only one SUBSCRIBE response will be returned SUBSCRIBE response will be returned to subscriber.to subscriber.

Forking: Problem DiagramForking: Problem Diagram

SubscriberForkingProxy

Notifier B

Notifier ASubscription

Statefulproxy

12

3

4

5

6

7

8

1213

10

11

9

14

1. SUBSCRIBE2. Request is forked to Notifier A (via proxy)…3. … and to notifier B4. Proxy record-routes and sends to notifier A…5. …and notifier B sends a 202 response6. Notifier A replies (202)...

7. …notifer B sends NOTIFY...8. …and the proxy sends B’s 202 on.9. The stateful proxy forwards A’s 202...10. …notifier A sends a NOTIFY…

11. …and the subscriber replies (200) to B’s NOTIFY12. The stateful proxy sends A’s NOTIFY to the subscriber13. This is where the problem occurs: how do we reply? If we accept, refreshes might not go through the stateful proxy, since the subscriber never saw A’s 202 response to the SUBSCRIBE request.14. The stateful proxy forwards the subscriber’s NOTIFY response.

Forking: Solution 1Forking: Solution 1

SubscriberForkingProxy

Notifier B

Notifier ASubscription

Statefulproxy

12

3

4

5

6

7

8

1213

10

11

9

14

Send a 481 for message 13 (NOTIFY reply), since message 8 (SUBSCRIBE 202) is on a different leg.

Issue: message 7 (NOTIFY) can arrive before message 8 (SUBSCRIBE 202); we must wait before responding.

Forking: Solution 2Forking: Solution 2

SubscriberForkingProxy

Notifier B

Notifier ASubscription

Statefulproxy

12

3

4

5

6

7

8

1213

10

11

9

14

Send a 200 for message 13 (NOTIFY reply), and accept both subscriptions.

I believe that we can count on the stateful proxy to include a “Record-Route” header in message 12 (NOTIFY), since the bis draft says it SHOULD.

This will allow the subscriber to route refreshes.

What?What?““6.35.1 Operation6.35.1 Operation

The Record-Route request and response header field is The Record-Route request and response header field is added to a request by any proxy that insists on being in added to a request by any proxy that insists on being in the path of subsequent requests for the same call leg. the path of subsequent requests for the same call leg. A proxy SHOULD add it to any request for A proxy SHOULD add it to any request for robustnessrobustness, but a request route, once established, , but a request route, once established, persists until the end of the call leg, regardless of persists until the end of the call leg, regardless of whether the Record-Route header is present in whether the Record-Route header is present in subsequent requests.”subsequent requests.”

Forking ProposalForking Proposal Allow subscribers to implement Allow subscribers to implement

solution 1 or 2 according to preference solution 1 or 2 according to preference and situation.and situation.

Event packages will be encouraged to Event packages will be encouraged to specify a mode that makes the most specify a mode that makes the most sense for the state they convey.sense for the state they convey.

Draft will strengthen “SHOULD” to Draft will strengthen “SHOULD” to “MUST” for proxies which intend to “MUST” for proxies which intend to track subscription states.track subscription states.

Minor ChangesMinor Changes Next version will probably be “draft-ietf-sip-Next version will probably be “draft-ietf-sip-

events-00.txt” (pending new WG charter).events-00.txt” (pending new WG charter). To/From Tag usage will be clarified.To/From Tag usage will be clarified. A-D suggestionsA-D suggestions

– For greater visibility, move notice of “not a For greater visibility, move notice of “not a general purpose event subscription mechanism” general purpose event subscription mechanism” into Abstract.into Abstract.

– Strengthen section about “appropriate” Strengthen section about “appropriate” applications: generally, those that rely on SIP applications: generally, those that rely on SIP user/terminal location.user/terminal location.

– Possibly create template for extension packages.Possibly create template for extension packages.

Event Mailing ListEvent Mailing List Moving off of Yahoo! Groups (they Moving off of Yahoo! Groups (they

require too much personal require too much personal information).information).

Announcement of new events mailing Announcement of new events mailing list will be made on the SIP mailing list list will be made on the SIP mailing list Real Soon Now.Real Soon Now.

Presence should be discussed on the Presence should be discussed on the SIMPLE list; general event topics, on SIMPLE list; general event topics, on the events list.the events list.