1. IETF 69 SIPPING WG Meeting Mohammad Vakil Microsoft mvakil@microsoft.com An Extension to Session Initiation Protocol (SIP) Events for Pausing and Resuming Notifications draft-vakil-sipping-notify-pause-01.txt

2. Overview & Usage Scenarios Pausing notification stream on an established subscription dialog, when notifications are not required at the client (e.g. PC idle), provide optimizations: – reduces notification traffic in bandwidth sensitive networks – save on processing to create and send notify from the notifiers – devices receiving notifies will not have to consume processing power to receive and process notifications, thus, saving battery power in mobile devices A fetch subscription (polling of event state) operation during a paused subscription without incurring new subscription processing cost – Helps devices poll for the updated event state, as and when needed (e.g. when buddy list is brought in focus) IETF 69 - July 20072

3. Requirements Be able to pause the notification stream on an established subscription without terminating the subscription (notify=off) Be able to un-pause the notification stream on an established paused subscription (notify=on) Support fetch/poll operation during a paused subscription IETF 69 - July 20073

4. Proposed Solution - Call Flow Subscriber Notifier Event State Generator Initial Subscribe (expires!=0) SUBSCRIBE (Pause notifications) (expires!=0;notify=off) PUBLISH (new event state) NOTIFY PUBLISH (new event state) Paused subscription, no notify sent, except fetch SUBSCRIBE (Fetch during pause) (expires!=0;notify=once) NOTIFY (single) Subscribe (Resume notifications) (expires!=0;notify=on) NOTIFY (full state if no filter defined) PUBLISH (new event state) NOTIFY 200 OK for SIP messages not shown IETF 69 - July 2007 1 2 3 4

5. Does this state diagram capture core cases? 5IETF 69 - July 2007 Incorporated comments from the list discussion – Initial notify is always generated – “notify=once” generates one notify and also transitions the subscription state to paused

6. Feedback? Presence event notification filtering? How does it work with notify=“on”, “off”, “once”? – It should be orthogonal – any subscription can specify filter, but notifier should pay attention to it when notify=“on” OR notify=“once” How useful Subscription-State of “paused” would be, if we were to send a notify. – This means extending subscription-states Do we need “notify-pause” option tag for Supported, Require, and Unsupported header fields? – We should define it, and application may choose to use this option tag 6IETF 69 - July 2007

7. Things to do.. Incorporate comments from today’s discussion and on the list Add state diagram discussed above Add an appendix (?) to describe event package specific filtering scenarios IETF 69 - July 20077

8. Next steps? WG work item? – If yes, sip or sipping? – What more is needed before WGLC? IETF 69 - July 20078