1 / 12

SIP Events: Open Issues

SIP Events: Open Issues. IETF 52 / SIP Working Group Adam Roach adamr@yahoo.com. 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.

rashida-turan
Télécharger la présentation

SIP Events: Open Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SIP Events:Open Issues IETF 52 / SIP Working Group Adam Roach adamr@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; expires=3599 Subscription-State: active; expires=2107 Subscription-State: terminated; reason=probation; retry-after=3600 Subscription-State: active; expires=300; reason=probation; retry-after=4000

  7. Event Parameters • In drafts to date, “Event” header syntax allows parameters, but doesn’t 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 there’s still “something in it” (would require rewording in bis to clarify that BYE doesn’t 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

More Related