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

Francois Menard <fmenard@xittel.net> Fri, 16 July 2010 12:43 UTC

Return-Path: <fmenard@xittel.net>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD913A69DC for <sipcore@core3.amsl.com>; Fri, 16 Jul 2010 05:43:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSAF5KseLnt0 for <sipcore@core3.amsl.com>; Fri, 16 Jul 2010 05:43:49 -0700 (PDT)
Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 5E52B3A6985 for <sipcore@ietf.org>; Fri, 16 Jul 2010 05:43:49 -0700 (PDT)
Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from <fmenard@xittel.net>) id 1OZkGi-0005xN-BU; Fri, 16 Jul 2010 08:43:56 -0400
Received: from [207.96.236.60] (helo=[192.168.3.252]) by relay.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from <fmenard@xittel.net>) id 1OZkGh-0000zo-Fm; Fri, 16 Jul 2010 08:43:56 -0400
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="windows-1252"
From: Francois Menard <fmenard@xittel.net>
In-Reply-To: <C8655032.41B60%jon.peterson@neustar.biz>
Date: Fri, 16 Jul 2010 08:43:54 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <994F9DFA-A692-4C08-A415-0A0B9F273FB9@xittel.net>
References: <C8655032.41B60%jon.peterson@neustar.biz>
To: "Peterson, Jon" <jon.peterson@neustar.biz>
X-Mailer: Apple Mail (2.1081)
Cc: Roger Marshall <RMarshall@telecomsys.com>, "sipcore@ietf.org" <sipcore@ietf.org>, "Thomson, Martin" <Martin.Thomson@andrew.com>
Subject: Re: [sipcore] location-conveyance-03 just submitted
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Jul 2010 12:43:51 -0000

I've been monitoring this thread and I think too much effort is being made to consider 'location negotiation' inside SIP.

Heck we're not even there with SDP for codec negotiation after 15 years of having VoIP in production.

With SDP, the end-point chooses ultimately what to send over RTP.  It receives advice at the SIP level, but insofar as possibly being rogue, an end-point being told to send-in G.729, will possibly send-out G.711 without saying so.

Now, to build on this analogy, if an end-point chooses to package into its SIP invite, several LbyV and an LbyR to accomodate the requirement that the SIP B2BUA behind the proxy of a PSAP gets an LbyR, to perform verification that the LbyV is really what its supposed to be, then such interpretation of the LbyR is done by the far-end B2BUA at the PSAP.  I am not convinced that the job of the proxy at the PSAP will be to replace an LbyR by a LbyV and that the B2BUA at the PSAP will blindly trust what's coming from its first hop proxy over what's coming from the far-end SIP UA at the customer premise.

The requirements for this chain of trust, i.e.

1) end-user SIP UA trusting acquisition of location by say DHCPLOC
2) first hop VoIP service provider trusting PROXY that the SIP UA is conveying the proper location (if its LbyR, then it can't authenticate), is proper
3) last hop B2BUA at the PSAP, if it sees an LbyV added by its first hop proxy, did this LbyV replaced the far-end LbyV learned by the end-user SIP UA from DHCPLOC ?

This does not appear to be super well documented at this time.

This is why I am asking that PSAPs get together in Canada and start ironing out their NG-911 requirements.

And so far, its being met with some resistance.

But we're getting going, making tis new CRTC CISC working group Task on NG-911 PSAP requirements.

Has anyone else documented what we'd like to see done or are we trying to accommodate all possible requirements ?

F.


On 2010-07-16, at 2:54 AM, Peterson, Jon wrote:

> 
> In the corner case (and I do think it is a corner case) where multiple entities are contributing different location information to a single SIP request, I think we face a fundamental architecture choice in this mechanism: either it is SIP’s job to sort out how we understand those different locations, or it is PIDF’s job.  Traditionally, PIDF’s understanding of different sources of presence that provide potentially contradictory information relies on the presence data model (RFC4479), which is designed to reconcile conditions like the one where my mobile phone thinks I am available but my desktop thinks I’m offline. The presence data model moreover differentiates between users, services and devices in a way that is useful and apparently applicable to location information. I am not eager to try to replicate this in SIP headers, including by inserting multiple such headers, putting in markup that tries to explain the “source” of location information in SIP headers, and so on. SIP’s job should be to convey the location object – fundamentally, the further we diverge from “conveyance” and enter into the realm of “integration,” the less comfortable I get.
> 
> I understand that the subsequent use case where there are different sources of location information, some of which are LbrV and some of which are LbyR, looks like a  hairy one. This is, however, a corner case of a corner case. I really do not feel comfortable justifying the allowance of multiple location headers in SIP pointing to different presence objects (as opposed to following the presence data model) to carry the 0, 1 or 2 different locations due to a corner case of a corner case. As I said in my previous mail to Martin, I’m not really sure I even understand the requirements for an intermediary to evaluate and reject LbyR, nor what the best way is for presence from these dynamic sources to be composed. If we were to investigate the right way for presence from those source to be composed, it might very well be that it is the responsibility of the compositor to insert an LbyR into the SIP request (into the Geolocation header), and to poll and compose a coherent PIDF document from its dynamic and static sources – that is probably the approach that most closely parallels the traditional approaches to presence. But we haven’t even begun to explore this yet. No one insisting that there will be “empty” PIDF documents just containing references to external PIDF documents or something. Something along those lines is one approach of many that we would consider if we tried to figure out how to address this in PIDF. The question we need to decide, as I said above, is the architecture one – is SIP’s job to convey PIDF documents, or to compose them?
> 
> Jon Peterson
> NeuStar, Inc.
> 
> On 7/15/10 3:56 PM, "Roger Marshall" <RMarshall@telecomsys.com> wrote:
> 
> All:
> My understanding of what this conveyance-03 draft now allows for is support of location in terms of:
> 
> LbyV if the geolocation header contains a cid URI which points to a PIDF-LO in the body
> Or
> LbyR if the geolocation header contains a location URI
> Or
> Both LbyV & LbyR _only_ if the PIDF-LO that the cid URI points to also includes an "associated" Location URI within.  This is what I assume is the composite case.
> 
> If this is how it's intended to work, how then would routing be accomplished if the intention was to route on location URI, not LbyV?
> 
> The geolocation header parameter value of "routing-allowed" can only be yes or no pointing to the whole PIDF-LO:
> 
> [from -03]
>    The practical implication is that when the "routing-allowed"
>    parameter is set to "no", if a cid:url is present in the SIP
>    request, intermediaries MUST NOT view the location (because it is
>    not for intermediaries to view), and if a location URI is present,
>    intermediaries MUST NOT dereference it.  UAs are allowed to view
>    location in the SIP request even when the "routing-allowed"
>    parameter is set to "no".  An LR MUST by default consider the
>    "routing-allowed" header parameter as set to "no", with no
>    exceptions, unless the header field value is set to "yes".
> 
> It seems to me that a better way is to allow geolocation URIs in numbers of 0, 1, or 2, so that you could elevate the Location URI up to the geolocation header and avoid all the difficulties of not knowing what location form was routable, plus escape the overhead of embedding it into an otherwise empty PIDF-LO when using LbyR exclusively.
> 
> Regards,
> 
> -roger marshall.
> 
> 
> -----Original Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Thomson, Martin
> Sent: Wednesday, July 14, 2010 6:34 PM
> To: Peterson, Jon; James M. Polk; sipcore@ietf.org
> Subject: Re: [sipcore] location-conveyance-03 just submitted
> 
> 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.
> 
> 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.  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.
> 
> The interactions with the intermediary add complexity to the scenario, including some privacy model problems, primarily with retransmission.  I'd like to solve the easier problem first.
> 
> --Martin
> 
> 
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> Sent: Thursday, 15 July 2010 3:09 AM
> To: Thomson, Martin; James M. Polk; sipcore@ietf.org
> 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 intermediary 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 necessarily 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.
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 
> CONFIDENTIALITY NOTICE: The information contained in this message may be privileged and/or confidential. If you are not the intended recipient, or responsible for delivering this message to the intended recipient, any review, forwarding, dissemination, distribution or copying of this communication or any attachment(s) is strictly prohibited. If you have received this message in error, please notify the sender immediately, and delete it and all attachments from your computer and network.
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore