Subject: [sipcore] Inequalities for filters

From: Brian Rosen <[email-masked]>
Date: Fri, 13 Nov 2009 14:28:50 -0500

The current filter specs allow "changed by" semantics, a delta on the last
value.  In location, we ran across the need to know when speed was exceeded
by some value.  This is not a delta, it's a comparison against a fixed
quantity.  

What is the appetite of the work group to add a generalized inequality,
based on the basic "changed by" syntax, that covers the obvious greater
than, less than, equals, not equals, greater than or equal to...?  You get a
notify when the condition is met.

This would be a short draft.

Brian

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 13 Nov 2009 14:10:45 -0600

Along this topic, and what was discussed in my review of the 
loc-filters-07 ID, is what happens if a target moves by a fixed 
amount (i.e., it has changed locations by the preset number of 
meters).  The example is if a target moves by 3 meters since the last 
notification, send a new notification of this movement.

This lead to the idea of a target moving much more than 3m, but by, 
say, 100m.  Does a notification now get sent at 3m. 6m, 9m, 12m ... 
99m, but not the last 1m, because it hasn't reacted the threshold of 
3m increments.

This lead to the idea that perhaps this target is accelerating. Is 
this of value, and should this be determined by the target (which 
senses or is told which increment is has moved) or determined by 
calculation by the recipient that the target is moving at a faster or 
slower pace or speed.

This is not exactly a slippery slope of new things to track, but it 
isn't a single value IMO either.

James

At 01:28 PM 11/13/2009, Brian Rosen wrote:
>_______________________________________________
>sipcore mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sipcore

---

From: Brian Rosen <[email-masked]>
Date: Fri, 13 Nov 2009 15:26:17 -0500

I believe one has to be reasonable.

If the target is moving slowly, and the filter doesn't get changed, then
yes.

If the mechanisms in the device don't react fast, and the target is moving
quickly, you may not get intermediate reports.  You certainly shouldn't get
more than one outstanding NOTIFY over this kind of filter.

The recipient can control the rate of notification with the rate control
filters, so if it doesn't want to be inundated, it can control it.

While we have speed, we don't have acceleration, and I'm not interested in
adding it.

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 24 Nov 2009 10:50:43 +0800

I don't think that James' understanding is quite correct.

The last notification seen by the watcher determines the baseline for notifications.  So, if the 3m, 6m, 9m and 99m notifications were suppressed, the subsequent 100m notification wont be.

--Martin

p.s. Was this the correct group to discuss this topic?  SIMPLE or GEOPRIV seem more appropriate.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Brian Rosen
> Sent: Saturday, 14 November 2009 7:26 AM
> To: James Polk; [email-masked]
> Subject: Re: [sipcore] Inequalities for filters
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 24 Nov 2009 10:52:22 +0800

I'd be interested in seeing this work go ahead.

Would SIMPLE be a better forum than SIPCORE?

--Martin

> Sent: Saturday, 14 November 2009 6:29 AM
> To: [email-masked]
> Subject: [sipcore] Inequalities for filters
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 24 Nov 2009 00:38:44 -0600

>I don't think that James' understanding is quite correct.

although I'm missing a few question marks at the end of obvious 
questions - I was probing for answers, not stating anything.

>The last notification seen by the watcher determines the baseline 
>for notifications.  So, if the 3m, 6m, 9m and 99m notifications were 
>suppressed, the subsequent 100m notification wont be.

Let me try this again -- if the changed-by is set to look for 
increments of 3m, and a target is moving a 3mps, then there should be 
a NOFITY sent every second by the notifier, right?

However, there is something to this -- the subscriber will get 
inundated  with NOTIFYs.

What if the notifier is accelerating?

This is useful information to have IMO (i.e., that the delta is 
occurring more frequent). This will lead to more inundation.

Is it important for the notifier to determine this, or the subscriber?

Is there a timestamp of when each NOTIFY is sent for a subscriber to 
accurately determine this information?

>GEOPRIV seem more appropriate.

I do not believe Geopriv has the expertise for this, as they do not 
regularly deal with SIP signaling (save for a few in the WG).

This is tied to SIPCORE's Location Conveyance ID, as it's primary use 
case is for dereferencing a location URI.

James

---

From: Brian Rosen <[email-masked]>
Date: Tue, 24 Nov 2009 09:00:49 -0500

You use rate control to adjust the rate of notifies if you want to have a
very small changed-by in a device that moves fast.

Brian

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 25 Nov 2009 07:15:08 +0800

That's right, the changed@by might indicate the need for notification, but min-interval can suppress that notification anyhow.

> From: Brian Rosen [mailto:[email-masked]]
> Sent: Wednesday, 25 November 2009 1:01 AM
> To: James Polk; Thomson, Martin; [email-masked]
> >>> quickly, you may not get intermediate reports.  You certainly
> shouldn't
> >>> get
> >>> While we have speed, we don't have acceleration, and I'm not
> interested
> >>> in
> >>> adding it.
> >>>
> >>> Brian
> >>>
> >>>
> >>>>> value.  In location, we ran across the need to know when speed
> was
> >>> exceeded