1 / 7

Alan Johnston <alan@sipstation> Bill Mertka < bmertka@redskytech >

A Batch Notification Extension for the Session Initiation Protocol (SIP) draft-johnston-sipping-batch-notify-00. Alan Johnston <alan@sipstation.com> Bill Mertka < bmertka@redskytech.com >. Problem Space. Optimization for SIP Events

zena-smith
Download Presentation

Alan Johnston <alan@sipstation> Bill Mertka < bmertka@redskytech >

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. A Batch Notification Extension for the Session Initiation Protocol (SIP)draft-johnston-sipping-batch-notify-00 Alan Johnston <alan@sipstation.com> Bill Mertka <bmertka@redskytech.com> SIPPING WG IETF-74

  2. Problem Space • Optimization for SIP Events • Used for synchronization of bulk SIP event information between two peers both with the ability and authority to act as notifiers for this information • NOTIFYs exchanged for this purpose are batch NOTIFYs • The way in which these batch notifications are generated and delivered needs to be managed carefully, otherwise: 1. The rate of notifications could become excessive (solved by draft-neimi-sipping-event-throttle) 2. The size of individual notification messages could become excessive (not currently solved) 3. The processing of state information by both the subscriber and notifier could become excessive (not currently solved) SIPPING WG IETF-74

  3. Use Cases • Presence state events • Presence Servers sharing data • Registration state events • Registrars sharing data • Conference state events • Conference notification server SIPPING WG IETF-74

  4. Requirements • REQ-1: The mechanism will allow a subscriber to set the maximum number of bodies in a batch notification. • REQ-2: The mechanism must work together with other throttling mechanisms and filtering mechanisms. • REQ-3: The mechanism will not be event package specific. • REQ-4: The mechanism will permit the notifier to indicate to the subscriber that the full event state has been transferred. • List discussion about this requirement (next slide) • REQ-5: The mechanism will minimize the processing of the event state data by both the batch subscriber and batch notifier. SIPPING WG IETF-74

  5. Open Issues • List discussion on REQ-5 • Intent is that the mechanism support this requirement, but is use is not required • This requirement useful if a snapshot is needed • Also useful if a different mechanism (such as publication) is to be used for normal state updates after initial sync is done with batch notifications. • More commonly would just transition to a normal subscription for updates • Discussion about use cases • Presence • Conference SIPPING WG IETF-74

  6. Straw Man Mechanisms • New Event header field parameter “batch” used in SUBSCRIBE • Similar to draft-niemi-sipping-event-throttle • Indicates maximum number of bodies in each NOTIFY • Use of Content-Type:multipart/mixed instead of RLMI if 1. There is no back-end subscription as is the case with a RLS. 2. Each individual body is self-contained and does not need any meta information for processing. 3. Only full state event information is included SIPPING WG IETF-74

  7. Next Steps • Interest in this work? • Requirements make sense? • Relation to draft-niemi-sipping-event-throttle? SIPPING WG IETF-74

More Related