>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]
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
