>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.
How do you see the event rate mechanism being useful here given that in a
previous mail you argued it is not needed?
Ciao
Hannes
>
>> -----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
