>With responseTime, the subscription should be open for long enough
>for a real notification to get through. That's probably whatever
>value emergencyDispatch has in the jurisdiction, which might be 15
>seconds, or something else.
I fully agree with this (i.e., that it needs to be confirugurable
- because it will depend on the local <everything> - and can't
really, accurately be be defined in one of our docs, at least not yet).
> > -----Original Message-----
> > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> > Behalf Of James M. Polk
> > Sent: Tuesday, 28 July 2009 2:01 PM
> > To: Hannes Tschofenig; geopriv@ietf.org
> > Subject: Re: [Geopriv] Another Update to draft-ietf-geopriv-loc-
> > filters-05.txt
> >
> > Current SIP rules for SUBSCRIBE are that when the subscription is
> > accepted, a NOTIFY is sent immediately (containing the current state
> > of what the subscribed-to entity knows about the subscription event).
> > If the subscription is to last "over time", then additional NOTIFYs
> > are sent when new changes to the "event" occur.
> >
> > This, I don't believe, is something Conveyance has to account for,
> > but PhoneBCP certainly does. If can be as simple as having text
> > saying that subscriptions for dereferences need to last for 15 or
> > more seconds (i.e., enough to get that second location update from
> > "the system"), but it cannot be completely open ended. This should
> > cover the concept.
> >
> > Do you agree?
> >
> > James
> >
> > At 05:20 AM 7/28/2009, Hannes Tschofenig wrote:
> > >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
> > > >
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.ietf.org/mailman/listinfo/geopriv
>
>------------------------------------------------------------------------------------------------
>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
