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

"Thomson, Martin" <Martin.Thomson@andrew.com> Sun, 25 July 2010 14:15 UTC

Return-Path: <Martin.Thomson@andrew.com>
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 5ABDB3A694E for <sipcore@core3.amsl.com>; Sun, 25 Jul 2010 07:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.454
X-Spam-Level:
X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_00=-2.599]
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 kgYVIgMrg0PV for <sipcore@core3.amsl.com>; Sun, 25 Jul 2010 07:15:33 -0700 (PDT)
Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 1CAF93A68A0 for <sipcore@ietf.org>; Sun, 25 Jul 2010 07:15:33 -0700 (PDT)
Received: from [10.86.20.103] ([10.86.20.103]:50790 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S336571Ab0GYOPx (ORCPT <rfc822; sipcore@ietf.org>); Sun, 25 Jul 2010 09:15:53 -0500
Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 25 Jul 2010 09:15:53 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sun, 25 Jul 2010 22:15:50 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: "James M. Polk" <jmpolk@cisco.com>, "Peterson, Jon" <jon.peterson@neustar.biz>, "sipcore@ietf.org" <sipcore@ietf.org>
Date: Sun, 25 Jul 2010 22:18:01 +0800
Thread-Topic: [sipcore] location-conveyance-03 just submitted
Thread-Index: Acsr/fvTuzQQGZrERcyHtbpGyEFTUwABLyxg
Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB77350A@SISPE7MB1.commscope.com>
References: <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.commscope.com> <C8633D20.41A01%jon.peterson@neustar.biz> <8B0A9FCBB9832F43971E38010638454F03E9DCD24A@SISPE7MB1.commscope.com> <201007251333.o6PDXURr019180@rtp-core-1.cisco.com>
In-Reply-To: <201007251333.o6PDXURr019180@rtp-core-1.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com
X-BCN-Sender: 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: Sun, 25 Jul 2010 14:15:35 -0000

I feel like some of this is old ground, but I chalk that up to you doing all these replies while you were offline.

 (I'll note that some of your recent responses are in response to emails that you have already responded to.)

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

It's not the transit time that is the problem, it’s the uses of location after that.  The call can certainly last longer than a few seconds.

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

Then they have some reconsidering to do in how they deploy this spec.  There are methods for dealing with this that might be more practical in those environments, but less so on the wider Internet.  Digital signatures, for example.

... 
> >The interactions with the intermediary add
> >complexity to the scenario, including some
> >privacy model problems, primarily with retransmission.
> 
> meaning UDP vs TCP?
 
Meaning <retransmission-allowed>.  I would hope that people know how to use UDP and TCP by now.