>The notifier still needs to know how long it has got. Otherwise, it
>might not provide a dispatch-worthy location when it's
>needed. responseTime gives it that. Sure, event-rate-control can
>do this with max-interval, but it would also require that the
>subscription be updated to prevent an excessive rate.
this is why I think guidance can be said here, but no realistic
minimums or maximums.
I also believe fully that phoneBCP must account for the subscribed-to
entity that does not support filters; meaning only having a non-zero
Expire header be what's counted on.
After the PSAP receives location in a request, it'll probably
initiate its own subscription anyway to get updates. This is more
where the filters doc comes into play IMO.
>In particular, the required responseTime might be lower than the
>notifier is willing to accept in max-interval. If you want a
>response in less than 2s, using max-interval is likely to
>fail. This gives the notifier the control it needs without running
>afoul of event-rate constraints.
>
>Further, keep in mind that responseTime has a hidden use - that of
>notifying the LG of how long it has. This helps the LG select the
>appropriate method so the information is available on time. This
>can also be applied to later notifications where the notifier needs
>to go to an LG.
isn't the notifier and the LG the same entity in this case (i.e., in
both cases - this entity is the same LIS)?
The subscriber may (and probably does) change, but always to the same LIS.
>--Martin
>
> > -----Original Message-----
> > From: James M. Polk [mailto:jmpolk@cisco.com]
> > Sent: Tuesday, 28 July 2009 2:03 PM
> > To: Thomson, Martin; Hannes Tschofenig; geopriv@ietf.org
> > Subject: RE: [Geopriv] Another Update to draft-ietf-geopriv-loc-
> > filters-05.txt
> >
> > At 05:56 AM 7/28/2009, Thomson, Martin wrote:
> > >That's a good use case. It's certainly useful. There are some
> > >issues to resolve, but those are minor. I think that this can be
> > >resolved with the responseTime attribute and the event rate control
> > mechanism.
> >
> > or... the subscription can be left open for the subsequent location
> > update in a subsequent NOTIFY, which is easier, and covers non HELD
> > cases - which any mechanism needs to.
> >
> >
> > > > -----Original Message-----
> > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > > Sent: Tuesday, 28 July 2009 12:20 PM
> > > > To: 'James M. Polk'; Thomson, Martin; geopriv@ietf.org
> > > > Subject: RE: [Geopriv] Another Update to draft-ietf-geopriv-loc-
> > > > filters-05.txt
> > > >
> > > > I was more focused on the following scenario:
> > > >
> > > > The SIP proxy gets a location URI via SIP. Now, it wants todo
> > location
> > > > based
> > > > routing for the emergency call. It will dereference the location
> > URI as
> > > > you
> > > > mention in Section 4.5 of your document. The LIS does not know that
> > > > this is
> > > > request is only for location sufficient for routing and it tries to
> > > > determine location at a best possible extend. This takes time.
> > Then,
> > > > when
> > > > location is available the NOTIFY is sent. The SIP proxy can route
> > the
> > > > call
> > > > but had to wait longer (potentially longer than Brian states in
> > Phone
> > > > BCP
> > > > regarding the maximum call setup time).
> > > >
> > > > If I understood the HELD mechanism correctly then there is a way to
> > > > indicate
> > > > what type of reference the URI should point to (this relates a bit
> > to
> > > > the
> > > > HELD context document). And the same stuff is available in HELD
> > deref
> > > > as
> > > > well.
> > > >
> > > > Now, I was wondering whether this would be useful in
> > > > draft-ietf-geopriv-loc-filters-05.txt as well. Namely, to let the
> > SIP
> > > > proxy
> > > > tell the LIS when it sends a SUBSCRIBE that it wants location for
> > > > routing
> > > > (and that typically means faster>
> > > >
> > > > If it does not make sense to anyone then I remove it from
> > > > draft-ietf-geopriv-loc-filters-05.txt.
> > > >
> > > > Ciao
> > > > Hannes
> > > >
> > > >
> > > > >-----Original Message-----
> > > > >From: James M. Polk [mailto:jmpolk@cisco.com]
> > > > >Sent: 28 July, 2009 13:02
> > > > >To: Hannes Tschofenig; 'Thomson, Martin'; geopriv@ietf.org
> > > > >Subject: RE: [Geopriv] Another Update to
> > > > >draft-ietf-geopriv-loc-filters-05.txt
> > > > >
> > > > >At 11:54 AM 7/27/2009, Hannes Tschofenig wrote:
> > > > >>Hi James,
> > > > >>
> > > > >> >> >More seriously: I'm not entirely sure how to interpret
> > > > >> >> >responseTime in the context of a SIP PA. This might work as
> > you
> > > > >> >> >have described, but I would suggest that it complicates
> > things
> > > > >> >considerably. There's
> > > > >> >> >discussion on this point in my draft here:
> > > > >> >> >
> > > > >> >>
> > > > >><http://tools.ietf.org/html/draft-thomson-simple-cont-presence-> >va
> > > > >> >> >l
> > > > >> >> -req-02#section-4.6.1.1>
> > > > >> >> >
> > > > >> >> >I don't know how to solve this problem yet.
> > > > >> >> >
> > > > >> >>
> > > > >> >>I am not sure I see the problems.
> > > > >> >>
> > > > >> >>Imagine a SIP proxy receives a SIP message with an LbyR
> > > > >and wants to
> > > > >> >>retrieve location information for routing. Depending on the
> > > > >> >URI scheme
> > > > >> >>(HTTP vs. SIP) he would either use
> > > > >> >>http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-prot
> > > > >> >ocol-03.t
> > > > >> >>xt
> > > > >> >>Or
> > > > >> >>http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-fil
> > > > >> >ters-04.t
> > > > >> >>xt
> > > > >> >
> > > > >> >I'm confused.
> > > > >> >
> > > > >> >For SIP, why would the filters doc be used when Conveyance
> > already
> > > > >> >has how a server dereferences a location URI for routing?
> > > > >> >
> > > > >> >This isn't a soliciting action requiring filters.
> > > > >>
> > > > >>How does SIP Location Conveyance dereference location URIs?
> > > > >>My reading of draft-ietf-sip-location-conveyance was that it
> > conveys
> > > > >>location by value and/or by reference.
> > > > >
> > > > >I have a section on this. Specifically it is section 4.5
> > > > >
> > > > > "Using sip/sips/pres as a Dereference Scheme"
> > > > >
> > > > >I even have a pretty diagram.
> > > > >
> > > > >
> > > > >>What "indication" is used in a SIP SUBSCRIBE to indicate "Please
> > give
> > > > >>me location information suitable for routing."?
> > > > >
> > > > >err, a proxy routes based on the location information it is
> > > > >given (if it initiates a dereference transaction in the first
> > > > >place, there is no "suitable-ness" to it.
> > > > >
> > > > >The location-based routing process asks for, and receives (or
> > > > >not) the PIDF-LO of the Target, then processes the message
> > > > >(i.e., making routing decisions) as if it were sent the
> > > > >PIDF-LO in the original SIP request. There's no magic to a
> > > > >location URI to get a routable location vs. an unroutable
> > > > >location -- especially since there is no difference in our
> > > > >that same proxy receives location by value.
> > > > >
> > > > >If you believe there needs to be a suitable-ness to location
> > > > >information, then we need a new error code for cases in which
> > > > >the supplied location isn't suitable, with exactly what an
> > > > >inserter is supposed to do with that error code (i.e., in that
> > > > >error code, there needs to be an indication what was missing -
> > > > >other than the whole location - that needs to be in the
> > > > >subsequent SIP request to make is worthy of being routed.
> > > > >
> > > > >Which do you want -
> > > > >
> > > > >#1 - route based on the available location supplied (by-value
> > > > >or by-reference)?
> > > > >or
> > > > >#2 - a new error code and inserter behavior to know what to do
> > > > >when insufficient location was provided in the initial SIP
> > request?
> > > > >
> > > > >#1 is easy, cuz that's the way Conveyance is written now.
> > > > >
> > > > >#2 is much more complicated - both to the routing proxy, and
> > > > >the burden on the location inserter to understand what isn't
> > > > >enough location, and to correct for just that amount - to
> > > > >satisfy the proxy's determination of what it thinks it needs
> > > > >to route the message propoerly.
> > > > >
> > > > >James
> > > > >
> > > > >
> > > > >>Ciao
> > > > >>Hannes
> > > > >
> > > >
> > >
> > >----------------------------------------------------------------------
> > --------------------------
> > >This message is for the designated recipient only and may
> > >contain privileged, proprietary, or otherwise private information.
> > >If you have received it in error, please notify the sender
> > >immediately and delete the original. Any unauthorized use of
> > >this email is prohibited.
> > >----------------------------------------------------------------------
> > --------------------------
> > >[mf2]
> >
>
>------------------------------------------------------------------------------------------------
>This message is for the designated recipient only and may
>contain privileged, proprietary, or otherwise private information.
>If you have received it in error, please notify the sender
>immediately and delete the original. Any unauthorized use of
>this email is prohibited.
>------------------------------------------------------------------------------------------------
>[mf2]
>_______________________________________________
>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
