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