Sunday, July 19, 2009

Re: [Geopriv] Another Update to draft-ietf-geopriv-loc-filters-05.txt

Hi Martin,

>-----Original Message-----
>From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]
>Sent: 20 July, 2009 03:18
>To: Hannes Tschofenig; geopriv@ietf.org
>Subject: RE: [Geopriv] Another Update to
>draft-ietf-geopriv-loc-filters-05.txt
>
>> 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-protocol-
>> 03.txt
>> Or
>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-
>> 04.txt
>>
>> For
>> http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-protocol-
>> 03.txt he
>> could use the 'responseTime' attribute set to "emergencyRouting".
>>
>> When a 'responseTime' attribute is used with
>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-loc-filters-
>> 04.txt
>> then hopefully the semantic would be the same. Instead of returning
>> location information that is good for dispatch location information
>> usable for routing would be returned.
>
>This doesn't necessarily work out this way. Imagine that
>emergencyRouting translates to 30 seconds, worst case.
>Imagine that your SIP stack considers the "immediately" from
>RFC 3265 to be in the order of 5 seconds.

An initial NOTIFY to the SUBSCRIBE is generated immediately. That's fine. It
might even come with an empty body.

>
>The SUBSCRIBE is sent and a 200 response is returned. The
>stack waits its 5 seconds and then gives up on the
>subscription. When the NOTIFY arrives 25 seconds later, it
>doesn't know what to do with it.

I don't understand why the stack would decide on it's own when to give up
the subscription.

Ciao
Hannes

>
>>
>> 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