--Richard
On Nov 16, 2011, at 4:42 PM, Rosen, Brian wrote:
> 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).
>
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
