SIP Events: Open Issues

1
SIP EventsOpen Issues

• IETF 52 / SIP Working Group
• Adam Roach
• adamr_at_yahoo.com

2
Version of SIP to reference

• Current version of draft refers to RFC 2543, but
  uses many bis-05 concepts.
• Could simplify draft by referencing bis-05, but
  then become dependent on it.
• Proposal in the interest of simplifying SIP
  Events, reference bis-05 draft, and go to RFC at
  roughly the same time.

3
Forking

• Consensus Forking is okay for SUBSCRIBE in
  general, but undesirable for some packages.
• Base spec should define mechanism by which
  subscriber can decline all but one dialog.
• Current proposal accept first dialog-establishing
  message (NOTIFY request or 2xx response to
  SUBSCRIBE), and send 481 to all other NOTIFY
  messages.

4
Immediate Notifies

• Previous drafts were inconsistent in describing
  whether NOTIFY was sent immediately for all
  SUBSCRIBE messages.
• Newest version cleans this up immediate NOTIFY.
• Pro Immediate NOTIFY message simplifies
  implementation of the forking case.
• Con Immediate NOTIFY requires definition of
  neutral state for all packages, but any useful
  authentication scheme requires this, too.
• Proposal keep language in latest draft (e.g.
  require immediate NOTIFY for all subscriptions).

5
Subscription State Indication

• Several discussions about how to convey
  subscription state in notifications current
  draft has incomplete solution.
• Watcherinfo contains similar types of
  information, and should be synced up.
• Proposal new Subscription-State header with
  values of pending, active, and terminated.
  Header has parameters reason, (synced with
  watcherinfo) expires, (in seconds), and
  retry-after (in seconds).

6
Subscription State Examples

• Subscription-State pending expires3599
• Subscription-State active expires2107
• Subscription-State terminated reasonprobation
  retry-after3600
• Subscription-State active expires300
  reasonprobation retry-after4000

7
Event Parameters

• In drafts to date, Event header syntax allows
  parameters, but doesnt say what they mean.
• Proposal event packages can define semantics for
  event parameters which serve a similar purpose as
  bodies, but are much more lightweight.

8
(Suggested) IANA Policy

• Current draft suggests first-come-first-served
  for packages, RFC for sub-packages.
• Some discussion on the list suggests SIP or
  SIPPING RFC mandatory for packages and
  sub-packages.
• Not worth too much debate, since our decision is
  input to the process, not the final answer.
• Suggestion leave as-is, and let the IANA review
  set the actual policy.

9
Subscriptions and Dialogs

• In general, SUBSCRIBE creates a dialog and a
  subscription. The dialog terminates when the
  subscription does (and vice versa).
• Current draft allows SUBSCRIBE requests to share
  a dialog with existing INVITE sessions.
• This is necessary to allow SUBSCRIBE requests to
  reach a particular end point with which a current
  dialog is already established. (Other solutions?)
• Issue 1 What if you want to set up two different
  subscriptions with that client? Do they both go
  on the same dialog? How do you differentiate the
  NOTIFYs?

10
Subscriptions and Dialogs (cont.)

• Issue 2 When this dialog sharing occurs, when
  does the dialog end?
• Dialog terminates when first dialog-creating
  conversation ends (in this case, BYE terminates
  SUBSCRIBE dialog, but subscription expiration
  terminates INVITE dialog if SUBSCRIBE dialog
  existed first)
• Dialog lasts as long as theres still something
  in it (would require rewording in bis to clarify
  that BYE doesnt necessarily terminate the
  dialog)
• Solution needs to be future-proof for other
  dialog-creating methods, not SUBSCRIBE specific.

11
Event header in NOTIFY

• Since NOTIFY must be in the same dialog as
  SUBSCRIBE, the Event header may not be
  necessary.
• Event header parameters might be used to convey
  some state information
• Event header names might be used as a (partial)
  solution to the problem of demultiplexing
  multiple subscriptions in a single dialog.
• If neither of the above reasons are compelling,
  should we just remove Event from NOTIFY?

12
Other expected changes in -02

• Rename sub-package to template-package to
  stem rapidly-spreading confusion
• New section on creation and lifetime of dialogs
• Consolidated definitions section
• Better description of subscription migration
• Moving PINT considerations to own section to make
  them easier to find
• Update ABNF to match bis syntax and LWS
• Reordering of sections for clarity