ietf 69 sipping wg meeting mohammad vakil microsoft [email protected] an extension to session...
TRANSCRIPT
IETF 69 SIPPING WG Meeting
Mohammad VakilMicrosoft
An Extension to Session Initiation Protocol (SIP) Events for Pausing and Resuming Notifications
draft-vakil-sipping-notify-pause-01.txt
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 2007 2
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 2007 3
Proposed Solution - Call Flow
SubscriberSubscriber NotifierNotifierEvent State GeneratorEvent 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
NOTIFY
200 OK for SIP messages not shownIETF 69 - July 2007
1
2
3
4
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
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
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 2007 7
Next steps?
• WG work item? – If yes, sip or sipping?– What more is needed before WGLC?
IETF 69 - July 2007 8