Re: [sipcore] location-conveyance-03 just submitted

["James M. Polk" <[e-mail]>]

At 08:33 PM 7/14/2010, Thomson, Martin wrote:
>Hi Jon,
>
>There’s a number of issues here.  I think that 
>we need to disentangle them.  The role of the 
>intermediary in this dealing with this problem is a secondary concern.
>
>There are two primary reasons for having both 
>value and reference: authorization and dynamism.
>
>Dynamism is the easiest one to pin down.  It's 
>obviously very important to the emergency 
>scenario - the ability of a PSAP to acquire 
>updated location information in a timely fashion 
>is central to many of their use cases.

Martin - how long are you expecting this initial 
INVITE to go from the UAC to the PSAP?

You're giving the impression that a second or two 
matters or the UAC will be in a completely 
different location, meaning the wrong PSAP will be contacted.

Is that really probable here?

If it's an infrequent case of a corner-case 
(calling 911/112 in the first place)...


>draft-ecrit-rough-loc describes a scenario where 
>the UAC is less authorized than the UAS; 
>intermediaries are authorized differently.  In 
>the canonical example, the UAS gets a rubbish 
>location value and a location reference that 
>they can't use.  The rubbish location is enough 
>to get them to a PSAP.  The PSAP uses the 
>reference because they are authorized.
>
>In either case, it's possible to leave the 
>intermediary out of consideration and 
>concentrate on the information that the UAC provides.

but what about environments (or networks) that 
don't trust the UE (or UAC) at all. I'd argue 
that's much more probable -- because that's how 3GPP treats their phones.

>The great thing with the solution that you've 
>proposed is that this is ultimately what happens 
>in any case.  Leaving the b2bua case aside, the 
>UAC is ultimately responsible for what Geolocation is placed in the request.

not true for 3GPP, which in theory, will be a 
fair number of endpoints (as in more than 50% of many countries, right?

How will what you're describing fit their network architecture?


>The interactions with the intermediary add 
>complexity to the scenario, including some 
>privacy model problems, primarily with retransmission.

meaning UDP vs TCP?

James

>  I'd like to solve the easier problem first.
>
>--Martin
>
>
>From: Peterson, Jon [mailto:[e-mail]]
>Sent: Thursday, 15 July 2010 3:09 AM
>To: Thomson, Martin; James M. Polk; [e-mail]
>Subject: Re: [sipcore] location-conveyance-03 just submitted
>
>
>[snip]
> > We mean to have the intermediary do the
> > dereference (if one is needed) and compose in the
> > SIP 424 response a MIME body with both the
> > server's version or both locations of the Target,
> > and for that dual location single presence
> > document to be copied into the next SIP request
> > from that UAC (towards that same intermediary).
>
>Elegant as it is, this just doesn't work. Â The 
>UAS (PSAP, LR, etc...) needs to be the entity 
>that does the dereference. Â They need to do 
>this because they know how (and when) to make 
>this request so that they get the information 
>they need. Â If the intermediary does the 
>dereference, then location information is set in stone from that point onward.
>
><JFP> I see your point, but I think the 
>difficulty is deeper still than this. The whole 
>use case for an intermediary providing different 
>(or supplementary) location information above 
>and beyond the location provided by the UAC is 
>based on the intermediary inspecting, and 
>disliking, the location present in the request. 
>If that location is constantly changing, what 
>would it mean for the intermediary to dislike 
>it? Maybe it likes it one minute and not the 
>next? Would it ­ever- be safe for a picky 
>inttermediary to allow a reference to pass it, 
>given that it couldn’t control what location 
>the LR would ultimately get from it? Moreover, 
>what if the creator of the reference authorizes 
>the end recipient (the PSAP) but not the 
>intermediary that wants to judge location 
>information? I think we’d need to look further 
>into the motivations here to understand the underlying requirement.
>
>Practically speaking, however, there are a 
>number of potential work-arounds to enable this 
>semantic ­ I don’t necessarilyy think that 
>once the intermediary performs the dereference, 
>then the location information must be set in 
>stone. If you seriously want to retain the 
>dynamism of location information, it could 
>become the responsibility of the compositor to 
>deliver a similarly dynamic reference, and every 
>time someone dereferences the composed object, 
>the compositor creates a new PIDF-LO document 
>based on freshly dereferencing any dynamic 
>components of the location information. Another 
>possibility would be to specify external 
>references in PIDF, so we could compose location 
>information from dynamic sources by reference in 
>the PIDF object, rather than by value. One 
>composed object could even have a mix of 
>by-value and by-reference location information 
>in that case. The important thing is that we 
>solve this down in the PIDF level, within the 
>parameters of RFC4479, rather than trying to 
>cobble together some relationship between 
>devices, services and users in the Geolocation header.
>
>Anyway, none of this is to suggest that this is 
>adequately specified in the current draft, or 
>something. We’d need to have a more lengthy 
>discussion about some of the issues above before 
>figuring out what we’d add, though.
>
>Jon Peterson
>NeuStar, Inc.