SIP Events: Changes and Open Issues

1
SIP EventsChanges and Open Issues

• IETF 50 / SIP Working Group
• Adam Roach
• adam.roach_at_ericsson.com

2
Excuses

• I intended to release a new events draft for this
  meeting
• but I had more important deliverables.

3
State Agents(née Event Agents)

• Generalization of a presence agent.
• May be aggregation points for state and/or
  surrogates for offline clients.
• Base draft will describe migration of
  subscriptions from state agents to endpoints.
• Package drafts will be required to define
  semantics (if any) for migration.

4
Out-of-band Subscriptions(aka Unsolicited
Notifications)

• Any subscription initiated by mechanism other
  than SUBSCRIBE method.
• Discussion will be reduced to single sentence
  explicitly allowing them. (e.g. Subscriptions
  may be created via mechanisms other than a
  SUBSCRIBE request.)
• Raises need for clarification 481 responses to
  NOTIFY MUST remove all subscriptions, even those
  provisioned out-of-band.

5
PINT Backwards Compatibility

• Addressed in current draft no event header gt
  PINT semantics.
• No open issues.
• Speak now or forever hold your peace.

6
Throttling of events

• Consensus from interim meeting each package will
  define a throttling mechanism appropriate to its
  specific events.
• Next draft will remove this from open issues
  section.
• Next draft will include requirement that packages
  include a discussion of notification throttling.

7
Instant Notification

• A delay in the initial NOTIFY might otherwise
  convey additional information (e.g. user online,
  subscription manually rejected, etc).
• Need to clarify that a NOTIFY with a default
  (innocuous) state will be sent immediately.

8
Authorization Issues(still open)

• We need a general-purpose mechanism by which
  subscription authorization may be performed in a
  way which allows user interaction.
• Is generalization of QAUTH the way to go, or
  should we use a notification of subscription
  attempt which can then result in a manual update
  of policy?
• Proposal subscription authorization issues will
  be handled in a separate draft. (Volunteers?)

9
SUBSCRIBE Response Codes(vaguely open)

• 202 is noncommital wait for a NOTIFY (which
  contains an Expires 0 if youve been
  rejected).
• Is it allowable to return a 403 or 603 to
  mean no way, bubba -- it just aint gonna
  happen dont even wait for a NOTIFY?
• Conversely, is it allowable to return a 200 to
  say your subscription is 100 guaranteed to have
  been accepted, and I will send you a valid,
  successful NOTIFY post haste?

10
Denial of Service Concerns(still open)

• One SUBSCRIBE in, several SUBSCRIBE replies and
  several NOTIFY requests out is a recipe for
  disaster.
• Proposed solution keep no state for
  unauthenticated SUBSCRIBE messages.
• Can be strengthened by allowing each
  userid/password combination to have only one
  pending SUBSCRIBE in each node. (Is this
  reasonable and viable?)

11
Forking(brace yourself)

• Much discussion at interim meeting, but no
  conclusion.
• Main sticking point seems to be concern that
  accepting multiple NOTIFY messages will disrupt
  route setups, since route setup will occur in
  SUBSCRIBE responses, and only one SUBSCRIBE
  response will be returned to subscriber.

12
Forking Problem Diagram
1. SUBSCRIBE 2. Request is forked to Notifier A
(via proxy) 3. and to notifier B 4. Proxy
record-routes and sends to notifier A 5. and
notifier B sends a 202 response 6. Notifier A
replies (202)...
Notifier A
SubscriptionStatefulproxy
7. notifer B sends NOTIFY... 8. and the proxy
sends Bs 202 on. 9. The stateful proxy forwards
As 202... 10. notifier A sends a NOTIFY
Subscriber
ForkingProxy
Notifier B
11. and the subscriber replies (200) to Bs
NOTIFY 12. The stateful proxy sends As NOTIFY to
the subscriber 13. 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 As
202 response to the SUBSCRIBE request. 14. The
stateful proxy forwards the subscribers NOTIFY
response.
13
Forking Solution 1
Send a 481 for message 13 (NOTIFY reply), since
message 8 (SUBSCRIBE 202) is on a different leg.
Notifier A
SubscriptionStatefulproxy
Subscriber
ForkingProxy
Notifier B
Issue message 7 (NOTIFY) can arrive before
message 8 (SUBSCRIBE 202) we must wait before
responding.
14
Forking Solution 2
Send a 200 for message 13 (NOTIFY reply), and
accept both subscriptions.
Notifier A
SubscriptionStatefulproxy
Subscriber
ForkingProxy
Notifier B
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.
15
What?

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

16
Forking Proposal

• Allow subscribers to implement solution 1 or 2
  according to preference and situation.
• Event packages will be encouraged to specify a
  mode that makes the most sense for the state they
  convey.
• Draft will strengthen SHOULD to MUST for
  proxies which intend to track subscription states.

17
Minor Changes

• Next version will probably be draft-ietf-sip-even
  ts-00.txt (pending new WG charter).
• To/From Tag usage will be clarified.
• A-D suggestions
• For greater visibility, move notice of not a
  general purpose event subscription mechanism
  into Abstract.
• Strengthen section about appropriate
  applications generally, those that rely on SIP
  user/terminal location.
• Possibly create template for extension packages.

18
Event Mailing List

• Moving off of Yahoo! Groups (they require too
  much personal information).
• Announcement of new events mailing list will be
  made on the SIP mailing list Real Soon Now.
• Presence should be discussed on the SIMPLE list
  general event topics, on the events list.