ietf 69 sipping wg meeting mohammad vakil microsoft mvakil@microsoft.com an extension to session...

IETF 69 SIPPING WG Meeting

Mohammad VakilMicrosoft

mvakil@microsoft.com

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