Wednesday, November 16, 2011

[Geopriv] Diff of changes to loc-filters to align with event-rate-control

3.6.  Rate Control     [RFC6446] extends the SIP events framework by defining the following    three Event header field parameters that allow a subscriber to set a    minimum, a maximum, and an average rate adaptive minimum of event notifications    generated by the notifier.  This allows a subscriber to have overall    control over the stream of notifications, for example to avoid being    flooded.  Two of the parameters, namely "min-interval" "min-rate" (which specifies a    minimum notification time period between two    notifications, in seconds) rate per second) and "max-interval" "max-rate" (which specifies    a maximum notification time period between two notifications, in    seconds) rate per second) are used by this document.    Only the implementation of these two attributes is required from the    attributes defined in [RFC6446].  Whenever the time since the most    recent notification exceeds the value in corresponding to the "max-interval" "max-rate"    parameter, the current state would be sent in its entirety, just like    after a subscription refresh.     A notifier is required to send a NOTIFY request immediately after    creation of a subscription.  If state is not available at that time,    then the NOTIFY request may be sent with no content.  A separate    NOTIFY containing location is subsequently generated some time    between the time included in "min-interval" "min-rate" and the time in "max-    interval". "max-rate".  An important use case for    location-based applications focuses on the behavior of the initial    NOTIFY message(s) and the information it returns, for example in case    of emergency call routing.  When an initial NOTIFY is transmitted, it    might not include complete state.     Subscriber          Notifier        |---SUBSCRIBE(1)--->|     Create subscription (w/small (w/large value        |<-------200--------|         for min-interval min-rate and max-interval) max-rate)        |<-----NOTIFY(2)----|     Return initial notify with no state        |--------200------->|        |<-----NOTIFY(3)----|     Return full state (between min-interval min-rate        |--------200------->|         and max-interval) max-rate)        |---SUBSCRIBE(4)--->|     Update subscription (to update        |<-------200--------|         min-interval         min-rate and max-interval) max-rate)                 Figure 9: SUBSCRIBE/NOTIFY with Rate Control     Figure 9 shows a SUBSCRIBE/NOTIFY exchange.  The initial SUBSCRIBE    message (1) has filters attached and contains a "max-interval" "max-rate" rate    control parameter.  In certain situations, it is important to obtain    some amount of location information within a relatively short and    pre-defined period of time, even if the obtained location information    contains a high amount of uncertainty and location information with    less uncertainty at a later point in time.  An example is emergency    call routing where an emergency services routing proxy may need to    obtain location information suitable for routing rather quickly and    subsequently a Public Safety Answering Point requests location    information for dispatch.     To obtain location information in a timely fashion using the    SUBSCRIBE/NOTIFY mechanism, it is RECOMMENDED that the initial    SUBSCRIBE contain a "max-interval" "max-rate" rate control parameter (with a    small large    value) that is in a later message updated to a more sensible value.    This provides equivalent functionality to the 'responseTime'    attribute in Section 6.1 of [RFC5985].  The "max-interval" "max-rate" for this first    request is therefore much lower larger than thereafter.  Updating the    "max-interval" "max-    rate" for the subscription can be performed in the 200 response (see    message 3) to the NOTIFY that contains state.  Depending on the value    in the "max-interval" "max-rate" parameter, the Notifier may create a NOTIFY message    (see message 2) immediately in response to the SUBSCRIBE that might    be empty in case no location information is available at this point    in time.  The desired location information may then arrive in the    subsequent NOTIFY message (see message 4).