RE: RE: [Geopriv] Consensus on changes to location-conveyance

At 08:28 PM 7/26/2006 -0500, Winterbottom, James wrote:
>In the case you mention below the reality is that if the target has
>moved during the course of routing, the target will either be at place B
>by the time dispatch occurs, or at point C which may be further away
>still.

Henning mentioned above that this is a routing timeframe (of maybe 1 
second), not a dispatch timeframe - and that it seems unlikely that routing 
would be different during that one second.  Regardless, the call get 
completed where the request was sent.

>At least in the case of a reference you have the possibility of getting
>the current location, which is not possible through any of the
>"by-value" means described thus far unless the caller is stationary!

Henning and Brian have discussed this already, and that is where SUB/NOT 
are useful for the ability to subscribe to that calling endpoint to find 
out where they are at any time during the call.  I mentioned that if the UA 
detects it has moved, it should send a SIP agreed upon UPDATE request (with 
a new l-by-v) to the PSAP informing it that the caller has moved.  This is 
something that belongs in the ECRIT phonebcp, and perhaps a more general 
non-emergency sipping doc.



>-----Original Message-----
>From: Henning Schulzrinne [mailto:[email protected]]
>Sent: Thursday, 27 July 2006 3:14 AM
>To: Andrew Newton
>Cc: [email protected]; IETF SIP List
>Subject: Re: [Sip] RE: [Geopriv] Consensus on changes to
>location-conveyance
>
>For location-based routing case, the likelihood of significant updates
>in the roughly one second that a call might take from caller to callee
>seems unlikely. UAS subscription and polling is clearly more valuable,
>so maybe we need to distinguish these cases. (As discussed earlier,
>mid-routing updates may lead to bad outcomes since the call might have
>been sent to a place A that doesn't know what to do with location update
>
>n+1 since that new location is really handled by place B.)
>
>Andrew Newton wrote:
> > Henning Schulzrinne wrote:
> >>> I believe there are two technical arguments: one is legacy equipment
>
> >>> (the issue that I'll be facing for quite some time), and
>environments
> >>> where the location is generated by the network.  For the latter,
> >>> insertion of the Location header only in emergency situations still
> >>> puts the user in control for non-emergency situations.
> >>>
> >>>
> >>
> >> For the latter, the combination of the in-progress L7 protocols, DHCP
>
> >> and LLDP should presumably allow the UAC to obtain location and
>insert
> >> it by value. Is there a use case not covered by that?
> >
> > As I said, where location comes from the network.  In this scenario,
> > there are two possibilities, both up to the user: 1) the UAC
>subscribes
> > to the location from the network and puts it by value in the call
> > flow... meaning all location updates go through the UAC, or 2) the UAC
>
> > hands out a reference so updates can be independent of the UAC or
> > updates based on subscription come from the UAC but are independent of
>
> > the call.
> >
> > -andy
>
>_______________________________________________
>Geopriv mailing list
>[email protected]
>https://www1.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
>[email protected]
>https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip