From rbarnes@bbn.com Thu Nov 3 02:26:17 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B584211E80DC for ; Thu, 3 Nov 2011 02:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWkYH-39-574 for ; Thu, 3 Nov 2011 02:26:17 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4AD11E80D5 for ; Thu, 3 Nov 2011 02:26:17 -0700 (PDT) Received: from [128.89.254.150] (port=52081) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RLtYu-0005pb-Dy for ecrit@ietf.org; Thu, 03 Nov 2011 05:26:16 -0400 From: Richard Barnes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 3 Nov 2011 10:26:16 +0100 Message-Id: To: ECRIT Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [Ecrit] IETF 82 Agenda X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2011 09:26:17 -0000 Dear ECRIT, The agenda for the ECRIT meeting at IETF 82 has been posted: Please reply ASAP in this thread if you have any agenda bashes. Thanks, --Richard From hannes.tschofenig@gmx.net Mon Nov 7 10:57:06 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBAF11E8085 for ; Mon, 7 Nov 2011 10:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+wYBcmJkORH for ; Mon, 7 Nov 2011 10:57:05 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9F36D21F8AB9 for ; Mon, 7 Nov 2011 10:57:04 -0800 (PST) Received: (qmail invoked by alias); 07 Nov 2011 18:57:02 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.216.191] by mail.gmx.net (mp026) with SMTP; 07 Nov 2011 19:57:02 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18Wk5UadWAWD2XEB5LJ97YVu68Krp5ZTX9/yOE7VA HisUMJH7f5CQN7 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Nov 2011 20:56:55 +0200 Message-Id: To: ECRIT Org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] Updated IETF Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 18:57:06 -0000 Hi all,=20 you may have noticed that a new version of the "additional data" draft = has been submitted for the upcoming IETF meeting in Taipei.=20 Here is the document:=20 http://tools.ietf.org/html/draft-ietf-ecrit-additional-data-02 I would like to highlight the following changes: * The introduction section was re-written to provide more background.=20 * The previous XML schema had been replaced with several reflecting the = different style of communicating the different data blocks. * The IANA consideration section has been updated.=20 * Roger joined us as a co-author. =20 There are many more other changes throughout the document. You can = easily spot them on the diff: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-additional-data-02.t= xt I would like to thank the members of the NENA additional data working = group. I got a better understanding of how the different elements can be = used by PSAPs for better decision making.=20 Ciao Hannes= From mlinsner@cisco.com Tue Nov 8 10:23:00 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1B111E80BD for ; Tue, 8 Nov 2011 10:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDiJaxzzfnzR for ; Tue, 8 Nov 2011 10:22:59 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCB821F8B38 for ; Tue, 8 Nov 2011 10:22:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=1903; q=dns/txt; s=iport; t=1320776579; x=1321986179; h=date:subject:from:to:message-id:mime-version; bh=pSu7MuRbjEimdQOxAEz6pqO3EXRoaweemLEOUi1UC3Q=; b=cP9Hh+OmogVw2U6JwOGOWwQ9ScUVBnhnRAl628jxNVHHYm8o0DKptc4k 3vqpEPdAxCeiZkVkotrMYJwqNG9H+iWHFbH0mxID4H9Mt/DO0fF99z3s8 sXp3nZiG6JMlbom8721xiooiJsX2Q1rJBhvoXRoEPHv9Tz+/ShlbJ+jEX c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAENzuU6tJV2c/2dsb2JhbABEgk2mXHiBBYFpBQsSASpPCwGBAxw1hSaCMpczgSYBnwuJLQSIC4wWhTGMWw X-IronPort-AV: E=Sophos;i="4.69,477,1315180800"; d="scan'208,217";a="34247374" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 08 Nov 2011 18:22:58 +0000 Received: from [10.116.195.123] (rtp-mlinsner-87110.cisco.com [10.116.195.123]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pA8IMuGJ001326 for ; Tue, 8 Nov 2011 18:22:57 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Tue, 08 Nov 2011 13:22:54 -0500 From: Marc Linsner To: "ecrit@ietf.org Org" Message-ID: Thread-Topic: Taipei Agenda Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3403603376_942626" Subject: [Ecrit] Taipei Agenda X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 18:23:00 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3403603376_942626 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit All, So there are no surprises, you may have noticed the agenda for the Taipei meeting is only 90 minutes of a 2.5 hour meeting slot. This is due to ECRIT & BFCPBIS sharing the time slot. This was agreed to by the wg chairs to run these meetings consecutively vs. concurrent as there are folks wanting to attend both. So ECRIT will use the first 90 min. and BFCPBIS will use the last 60 min. of the meeting slot. Marc, Richard, & Roger --B_3403603376_942626 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
All,

So there are no surprises, you may have noticed the agenda for the Taipei = meeting is only 90 minutes of a 2.5 hour meeting slot.  This is due to = ECRIT & BFCPBIS sharing the time slot.  This was agreed t= o by the wg chairs to run these meetings consecutively vs. concurrent as the= re are folks wanting to attend both.  So ECRIT will use the first 90 mi= n. and BFCPBIS will use the last 60 min. of the meeting slot.
Marc, Richard, & Roger
--B_3403603376_942626-- From mlinsner@cisco.com Wed Nov 9 12:17:13 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D05651F0C64 for ; Wed, 9 Nov 2011 12:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmLCZV4KUhTl for ; Wed, 9 Nov 2011 12:17:13 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 510EB1F0C5F for ; Wed, 9 Nov 2011 12:17:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=3883; q=dns/txt; s=iport; t=1320869833; x=1322079433; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=KHGTDb8q7HRhB/8j6x5OLIonCu07l8/dfJPTJi4gcks=; b=DeKAhPD+vYRrkyZDLjqEwjgFeJl7+B2gaeVbIahifyHwF555u7t+0iso mgulcAIA3zdQtAo7fDrM7fA4ttct6sTTkMFoP8Xhl7vuMVoy8nrfYJow+ ORdRp1nYMPu9VHUsKkUem0i180UYdZCnveo8fh0b4McuTK/GIBw/gkTV8 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFABvfuk6tJXG//2dsb2JhbABDgk2mXnmBBYFyAQEBAwEBAQEPASoxEA4IBA0DAQJWKAgGEyKHYAiXToEmAZ8XBIl/BIgMjBmFNYxb X-IronPort-AV: E=Sophos;i="4.69,485,1315180800"; d="scan'208,217";a="34591298" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 09 Nov 2011 20:17:13 +0000 Received: from [10.116.195.123] (rtp-mlinsner-87110.cisco.com [10.116.195.123]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA9KHBZa008026 for ; Wed, 9 Nov 2011 20:17:12 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 09 Nov 2011 15:17:09 -0500 From: Marc Linsner To: "ecrit@ietf.org Org" Message-ID: Thread-Topic: [Ecrit] Taipei Agenda In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3403696632_1387956" Subject: Re: [Ecrit] Taipei Agenda X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:17:13 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3403696632_1387956 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Correction: BFCBIS will be first and ECRIT the last 90min. of the time slot. Marc, Richard, & Roger From: Marc Linsner Date: Tue, 08 Nov 2011 13:22:54 -0500 To: "ecrit@ietf.org Org" Subject: [Ecrit] Taipei Agenda > All, > > So there are no surprises, you may have noticed the agenda for the Taipei > meeting is only 90 minutes of a 2.5 hour meeting slot. This is due to ECRIT & > BFCPBIS sharing the time slot. This was agreed to by the wg chairs to run > these meetings consecutively vs. concurrent as there are folks wanting to > attend both. So ECRIT will use the first 90 min. and BFCPBIS will use the > last 60 min. of the meeting slot. > > Marc, Richard, & Roger > _______________________________________________ Ecrit mailing list > Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --B_3403696632_1387956 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Correction: BFCBIS will be f= irst and ECRIT the last 90min. of the time slot.

Ma= rc, Richard, & Roger

Fro= m: Marc Linsner <mlinsner@cis= co.com>
Date: Tue, 08 Nov 2= 011 13:22:54 -0500
To: "ecrit@ietf.org Org" <ecrit@ietf.org>
Subject: [Ecrit] Taipei Agenda

All,

So there are no surprises, you may have noticed the agenda for the Ta= ipei meeting is only 90 minutes of a 2.5 hour meeting slot.  This is du= e to ECRIT & BFCPBIS sharing the time slot.  This was agr= eed to by the wg chairs to run these meetings consecutively vs. concurrent a= s there are folks wanting to attend both.  So ECRIT will use the first = 90 min. and BFCPBIS will use the last 60 min. of the meeting slot.

Marc, Richard, & Roger
_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/= mailman/listinfo/ecrit
--B_3403696632_1387956-- From hannes.tschofenig@gmx.net Tue Nov 15 04:45:53 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F03F1F0C5B for ; Tue, 15 Nov 2011 04:45:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pChsTLZUuTJb for ; Tue, 15 Nov 2011 04:45:49 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 0114C1F0C51 for ; Tue, 15 Nov 2011 04:45:48 -0800 (PST) Received: (qmail invoked by alias); 15 Nov 2011 12:45:47 -0000 Received: from 203-69-99-17.HINET-IP.hinet.net (EHLO [172.20.2.222]) [203.69.99.17] by mail.gmx.net (mp068) with SMTP; 15 Nov 2011 13:45:47 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/AOF4tVqPA9MP3iaQwXICLMvcl4ISfPnlid3qIEH YoJTKDk6xxKd19 From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2011 20:45:41 +0800 Message-Id: To: ECRIT Org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] Ambulance service disrupted by computer virus X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 12:45:53 -0000 FYI: Interesting security challenging emergency services organizations = are dealing with.=20 = http://nakedsecurity.sophos.com/2011/11/14/ambulance-service-disrupted-by-= computer-virus-infection From pkyzivat@alum.mit.edu Tue Nov 15 22:03:57 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0EC1F0D29 for ; Tue, 15 Nov 2011 22:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFQ7Uj1jTApy for ; Tue, 15 Nov 2011 22:03:56 -0800 (PST) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by ietfa.amsl.com (Postfix) with ESMTP id 2912E1F0D28 for ; Tue, 15 Nov 2011 22:03:56 -0800 (PST) Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta09.emeryville.ca.mail.comcast.net with comcast id xi091h0011zF43QA9i3pD4; Wed, 16 Nov 2011 06:03:49 +0000 Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta24.emeryville.ca.mail.comcast.net with comcast id xiLd1h00a5EhBnE8kiLgGX; Wed, 16 Nov 2011 06:20:45 +0000 Message-ID: <4EC35240.9010209@alum.mit.edu> Date: Wed, 16 Nov 2011 14:03:44 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 16 Nov 2011 06:13:22 -0800 Subject: Re: [Ecrit] draft-holmberg-ecrit-emergency-callback-id X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 06:03:57 -0000 After the meeting this morning I read the document. Here are a bunch of comments to start some discussion. Section 4: - An eGRUU MUST be constructed following the same principles and rules that apply for constructing a public GRUU. Section 6.2 If the Call-ID changes in a register refresh, the server will invalidate all eGRUUs associated with that UA instance; the only valid one will be the new one returned in that REGISTER response. This language is analogous to that for temp gruus, not permanent gruus. Yet the stated intent is that the egruu be like a public gruu. Section 6.4: A UA MUST NOT construct a self-made eGRUU. There may be a reason for this in IMS, but I see no general reason for this. A UA that assigns a gruu for itself to use in emergency calls can then recognize emergency callbacks and process them in a special way. The requirement for a registrar assigned egruu seems to be predicated on emergency services provided by the registrar, or proxies and application servers in the routing path from the home proxy. The presence of such things, and how they work, is environment dependent. Section 6.6 NOTE: If the Contact header field of an initial SIP INVITE request for an emergency call did not contain a "psabcb" parameter, a UA, representing a PSAP, can insert the "psapcb" parameter in the Request-URI of the initial SIP INVITE request for an PSAP callback call. This is dubious. Modifying a URI you received is in general a bad idea. If a UA does not represent a PSAP, making a PSAP callback call, it MUST NOT insert an eGRUU and a "psapcb" parameter in the Request-URI of the intial SIP INVITE request for the call. This makes little sense, and its not enforceable because UAs that don't implement this spec need not comply with it. In general, a UA that wants to send an out of dialog request to some UA it has a dialog with will simply use the remote Contact URI. Then finally, I can find *no* explanation of what happens differently for a request containing the psapcb parameter, vs. one that does not. This is apparently very important, but totally opaque. Also, when the callback is generated with the egruu and its psapcb parameter, the UA does not get the parameter, except possibly via H-I. So its difficult for it to give special treatment for the callback call. Is there an assumption that it will use H-I for this? I also reviewed draft-ietf-ecrit-psap-callback-03 and didn't find any further enlightenment over this. ISTM that there are several requirements: - the callback should be addressed to the UA that initiated the emergency call, not to the AOR of that UA. Existing GRUU technology (either permanent, temporary, or self assigned satisfy this.) - the signaling network that routes the callback should avoid special treatments to callback calls that prevent the callback from reaching the intended UA. This requires that it be possible to identify callback calls. - the UA should give special priority to callback calls. For instance, drop other calls in order to take this one. This requires that it be possible to identify callback calls. - callback calls should be restricted to a limited set of callers, and no others. The allowed set is not well defined, but includes the recipient of the precipitating emergency call, plus some "friends". The reason for this is to prevent others from getting the special treatment. Defining this set is hard. Enforcing this limitation is also hard. Thanks, Paul From hannes.tschofenig@gmx.net Wed Nov 16 06:54:25 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E74911E8102 for ; Wed, 16 Nov 2011 06:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KKriXFAu2Vl for ; Wed, 16 Nov 2011 06:54:25 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 7533021F963D for ; Wed, 16 Nov 2011 06:54:24 -0800 (PST) Received: (qmail invoked by alias); 16 Nov 2011 14:54:23 -0000 Received: from 203-69-99-17.HINET-IP.hinet.net (EHLO [172.20.2.22]) [203.69.99.17] by mail.gmx.net (mp070) with SMTP; 16 Nov 2011 15:54:23 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/VVtwESgLVhhZyYteXzqeWQY8s25xUGusacBUmUF tWPoZ/D5TAtrnR From: Hannes Tschofenig Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 22:54:16 +0800 Message-Id: To: ECRIT Org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] Data Only Emergency Call X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 14:54:25 -0000 Hi all, we had a fairly good discussion today and here are my impressions from = the discussions.=20 First, we had the question about what SIP messages to use for conveying = the CAP payloads.=20 There, we had suggested to focus on the INVITE and on the MESSAGE = method.=20 Brian proposed that we use MESSAGE for a one-shot message that does not = require any session semantic.=20 For those cases where either additionally voice/video is conveyed then = the INVITE is used.=20 Do I miss something? Then, there was the question where to put the CAP? We suggested that we = need to put the CAP in the body of the MESSAGE and the INVITE.=20 We also said that we would not need a CID in the header to point to the = CAP payload in the body.=20 Finally, we had a discussion about the integration of the =93additional = data=94 with =93data-only=94. When we send a SIP INVITE or SIP MESSAGE = then we=20 - MUST attach the additional data structure, and - MAY add a CAP payload (as described in this document if needed). Then, there is also the PIDF-LO for the location.=20 Comments appreciated! Ciao Hannes From hannes.tschofenig@gmx.net Wed Nov 16 07:00:53 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BC91F0C76 for ; Wed, 16 Nov 2011 07:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01KDmryC1wxx for ; Wed, 16 Nov 2011 07:00:52 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id EED171F0C7C for ; Wed, 16 Nov 2011 07:00:51 -0800 (PST) Received: (qmail invoked by alias); 16 Nov 2011 15:00:50 -0000 Received: from 203-69-99-17.HINET-IP.hinet.net (EHLO [172.20.2.22]) [203.69.99.17] by mail.gmx.net (mp071) with SMTP; 16 Nov 2011 16:00:50 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/pkGtx6UfpxMezl7Cgz1x7xHKr26Og2lDVDU9KN7 be+Ph0izY3J21p From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 23:00:43 +0800 Message-Id: To: ECRIT Org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: Adam Roach , Hadriel Kaplan Subject: [Ecrit] PSAP Callback X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 15:00:53 -0000 Hi all,=20 at today's ECRIT meeting I noticed that at least one person (let's call = him H. K.) had not read the latest version of the PSAP callback draft. = It was updated in time before the submission deadline.=20 Please have a look at updated introduction and scenario section at http://datatracker.ietf.org/doc/draft-ietf-ecrit-psap-callback/ The introduction provides a description of the problem being solved and = the scenario section illustrates (with figures) when the currently = specified solution (which is in PhoneBCP) does not work.=20 I have done my best to improve the readability of the draft and would = appreciate feedback on the text.=20 Cullen mentioned an important design requirement: He said that we should = design the solution in such a way that it is as closely to an ordinary = call as possible. He argued that the code required by these special = cases only gets executed very rarely leading to all sorts of problems.=20= Adam had some questions regarding the solution scope and prior solution = approaches investigated by the group are documented in the appendix.=20 Ciao Hannes From hannes.tschofenig@gmx.net Wed Nov 16 07:01:22 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06141F0C7F for ; Wed, 16 Nov 2011 07:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnNjHBSz62hz for ; Wed, 16 Nov 2011 07:01:22 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id EDCF81F0C7D for ; Wed, 16 Nov 2011 07:01:21 -0800 (PST) Received: (qmail invoked by alias); 16 Nov 2011 15:01:20 -0000 Received: from 203-69-99-17.HINET-IP.hinet.net (EHLO [172.20.2.22]) [203.69.99.17] by mail.gmx.net (mp071) with SMTP; 16 Nov 2011 16:01:20 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+lzzdFH2Wl0wq3fvnwPWD4V+aj1CVy9dDF5ifbtO rxk4RQhmwb/9mv From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 23:01:18 +0800 Message-Id: <58EF06B3-2C98-4FD6-91F0-A9A15820A909@gmx.net> To: ECRIT Org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [Ecrit] draft-ietf-ecrit-unauthenticated-access-03 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 15:01:22 -0000 Hi all,=20 in today's ECRIT meeting there was not enough time to discuss the = details of the open issues. We also spent a lot of time on justifying = the draft even though we had made that decision already a long time ago.=20= In any case, here are the open issues:=20 1) No Access Authentication (NAA) I suggested to address the fraud problem that results from a host that = attaches to a network using some special link layer authentication = procedure without actually having credentials for that specific network = by not routing the emergency calls via the VSP but instead contacting = the PSAP directly.=20 =46rom the feedback during the meeting I believe folks are fine with = that approach but are looking forward to see the details.=20 2) Deployment Reality Bernard and Martin had some comments about the current deployment = limitations of many access networks. For example, many hotspots require = user interactions prior to get network access granted. There is not = really anything we can do about it other than mentioning the challenges = in a limitation section. I suggested to introduce such a section.=20 3) Lack of authorization to perform network access The document currently considers the Zero-Balance ASP where an emergency = caller is not authorized to make the emergency call. This lack of = authorization is visible at the application layer. Bernard suggested to = add a discussion about lack of authorization at the network layer as = well.=20 I am OK with adding such text.=20 4) Writing Style Martin suggested to restructure the document, i.e. to change the writing = style. I would like to leave the structure at the moment as is. Ciao Hannes= From hgs@cs.columbia.edu Wed Nov 16 07:17:44 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1AFA21F9014 for ; Wed, 16 Nov 2011 07:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ+YsWSNAQvx for ; Wed, 16 Nov 2011 07:17:44 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id 28E9A21F90A8 for ; Wed, 16 Nov 2011 07:17:44 -0800 (PST) Received: from upstairs-3.home (pool-96-242-116-37.nwrknj.fios.verizon.net [96.242.116.37]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pAGFHdkX021186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Nov 2011 10:17:40 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <58EF06B3-2C98-4FD6-91F0-A9A15820A909@gmx.net> Date: Wed, 16 Nov 2011 10:17:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <896B3758-85FC-4E99-B8CC-B32608567AFB@cs.columbia.edu> References: <58EF06B3-2C98-4FD6-91F0-A9A15820A909@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: ECRIT Org Subject: Re: [Ecrit] draft-ietf-ecrit-unauthenticated-access-03 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 15:17:44 -0000 2) HotSpot 2.0 should help with that problem in the longer run. (Indeed, = our requirements might shape the evolution of that effort, particularly = if we can reach out to that group.) On Nov 16, 2011, at 10:01 AM, Hannes Tschofenig wrote: > Hi all,=20 >=20 > in today's ECRIT meeting there was not enough time to discuss the = details of the open issues. We also spent a lot of time on justifying = the draft even though we had made that decision already a long time ago.=20= >=20 > In any case, here are the open issues:=20 >=20 > 1) No Access Authentication (NAA) >=20 > I suggested to address the fraud problem that results from a host that = attaches to a network using some special link layer authentication = procedure without actually having credentials for that specific network = by not routing the emergency calls via the VSP but instead contacting = the PSAP directly.=20 >=20 > =46rom the feedback during the meeting I believe folks are fine with = that approach but are looking forward to see the details.=20 >=20 > 2) Deployment Reality >=20 > Bernard and Martin had some comments about the current deployment = limitations of many access networks. For example, many hotspots require = user interactions prior to get network access granted. There is not = really anything we can do about it other than mentioning the challenges = in a limitation section. I suggested to introduce such a section.=20 >=20 > 3) Lack of authorization to perform network access >=20 > The document currently considers the Zero-Balance ASP where an = emergency caller is not authorized to make the emergency call. This lack = of authorization is visible at the application layer. Bernard suggested = to add a discussion about lack of authorization at the network layer as = well.=20 > I am OK with adding such text.=20 >=20 > 4) Writing Style >=20 > Martin suggested to restructure the document, i.e. to change the = writing style. I would like to leave the structure at the moment as is. >=20 > Ciao > Hannes > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From randy@qualcomm.com Sun Nov 20 14:44:34 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC25721F8AD2 for ; Sun, 20 Nov 2011 14:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YK0AWZFMSTH for ; Sun, 20 Nov 2011 14:44:30 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC8D21F8AD1 for ; Sun, 20 Nov 2011 14:44:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=randy@qualcomm.com; q=dns/txt; s=qcdkim; t=1321829070; x=1353365070; h=message-id:x-mailer:date:to:from:subject:mime-version: content-type:x-random-sig-tag:x-originating-ip; z=Message-ID:=20 |X-Mailer:=20Eudora=20for=20Mac=20OS=20X|Date:=20Sun,=202 0=20Nov=202011=2014:31:31=20-0800|To:=20, =20Brian=20Rosen=20,=20Hannes=20Tschof enig=0D=0A=09,=20Roger=20Marsh all=20|From:=20Randall=20Gellen s=20|Subject:=20draft-ietf-ecrit-addi tional-data-02|MIME-Version:=201.0|Content-Type:=20multip art/mixed=3B=0D=0A=09boundary=3D"=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D_-890293485=3D=3D_=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D"|X-Random-Sig-Tag:=201.0b28|X-Originating-IP: =20[172.30.48.1]; bh=NeXpL+7EHMpGI2VJaGjMgNNrHJRas2zWe0KnxbPWACI=; b=I4x00sBPkgWleMk7N2vb0QsizH8sINnmHb3wPQpvIefsLV+5X/eE6Wpp +mEackQKaYR5UBnjzxouCCtbcOvm2cwS4tPAFP/uwqKy9/gCoEaTARUvQ jmO9PnANgseeOo5B6WiVQsYLaEbbNrTMbzaOrmSJNo+jcEhZ3wTncjJIF c=; X-IronPort-AV: E=McAfee;i="5400,1158,6536"; a="139404137" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 20 Nov 2011 14:44:28 -0800 X-IronPort-AV: E=Sophos;i="4.69,542,1315206000"; d="txt'?scan'208";a="159103360" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 20 Nov 2011 14:44:28 -0800 Received: from [172.21.1.9] (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.339.1; Sun, 20 Nov 2011 14:43:33 -0800 Message-ID: X-Mailer: Eudora for Mac OS X Date: Sun, 20 Nov 2011 14:31:31 -0800 To: , Brian Rosen , Hannes Tschofenig , Roger Marshall From: Randall Gellens MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-890293485==_============" X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.48.1] Subject: [Ecrit] draft-ietf-ecrit-additional-data-02 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2011 22:44:35 -0000 --============_-890293485==_============ Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Brian, Hannes, Roger, and fellow ecrit-ers, I think this document needs at least another revision before it is ready for WGLC. Attached is a version of the draft with my suggested text changes, identified by "RG " in the left margin (where "^" means insertion at that point in the line above, and "X" means delete the character above). In a number of places I was unable to suggest specific text changes because I was unclear of the intent or for other reasons; those places have my questions or comments on the text, identified by "RG >>>>>" in the left margin. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The most likely way for the world to be destroyed, most experts agree, is by accident. That's where we come in; we're computer professionals. We cause accidents. --Nathaniel Borenstein --============_-890293485==_============ Content-ID: Content-Type: text/plain; name="draft-ietf-ecrit-additional-data-02[rg].txt"; charset="us-ascii"; format=flowed Content-Disposition: attachment; filename="draft-ietf-ecrit-additional-data-02[rg].txt"; modification-date="Sun, 20 Nov 2011 14:21:38 -0800"; x-mac-type=54455854; x-mac-creator=522A6368 Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= ECRIT B.=20 Rosen=0A= Internet-Draft=20 NeuStar=0A= Intended status: Standards Track H.=20 Tschofenig=0A= Expires: May 3, 2012 Nokia=20 Siemens Networks=0A= =20 R. Marshall=0A= =20 TeleCommunication Systems, Inc.=0A= =20 October 31, 2011=0A= =0A= =0A= Additional Data related to an=20 Emergency Call=0A= =20 draft-ietf-ecrit-additional-data-02.txt=0A= =0A= Abstract=0A= =0A= When an=20 emergency call is sent to a Public Safety Answering Point=0A= (PSAP),=20 the device that sends it, as well as any service provider in=0A= the=20 path of the call, or access network may have information about=0A= RG=20 ^=0A= RG through which the call originated,=0A= =20 the call which the PSAP may be able to use. This document=20 describes=0A= RG=0A= RG an XML data structure to contain such data, and a=20 Uniform Resource=0A= RG Identifier (URI) for conveying the data to the=20 PSAP. The URI may=0A= RG point to either an external resource, or the=20 body of the SIP=0A= RG message.=0A= RG >>>>DELETE FOLLOWING FOUR LINES<<<<<=0A= =20 an XML data structure that contains this kind of information in a=0A= =20 standardized form. A Uniform Resource Identifier (URI) that points=0A= =20 to the structure can be included in the SIP signaling with the call,=0A= =20 or the data may be included in the body of a SIP message.=0A= =0A= Status of=20 this Memo=0A= =0A= This Internet-Draft is submitted in full conformance=20 with the=0A= provisions of BCP 78 and BCP 79.=0A= =0A= Internet-Drafts are=20 working documents of the Internet Engineering=0A= Task Force (IETF).=20 Note that other groups may also distribute=0A= working documents as=20 Internet-Drafts. The list of current Internet-=0A= Drafts is at=20 http://datatracker.ietf.org/drafts/current/.=0A= =0A= Internet-Drafts are=20 draft documents valid for a maximum of six months=0A= and may be=20 updated, replaced, or obsoleted by other documents at any=0A= time.=20 It is inappropriate to use Internet-Drafts as reference=0A= material=20 or to cite them other than as "work in progress."=0A= =0A= This=20 Internet-Draft will expire on May 3, 2012.=0A= =0A= Copyright Notice=0A= =0A= =20 Copyright (c) 2011 IETF Trust and the persons identified as the=0A= =20 document authors. All rights reserved.=0A= =0A= This document is subject=20 to BCP 78 and the IETF Trust's Legal=0A= Provisions Relating to IETF=20 Documents=0A= (http://trustee.ietf.org/license-info) in effect on the=20 date of=0A= =0A= =0A= =0A= Rosen, et al. Expires May 3, 2012=20 [Page 1]=0A= =0C=0A= Internet-Draft Additional Call Data=20 October 2011=0A= =0A= =0A= publication of this document. Please review these=20 documents=0A= carefully, as they describe your rights and restrictions=20 with respect=0A= to this document. Code Components extracted from=20 this document must=0A= include Simplified BSD License text as=20 described in Section 4.e of=0A= the Trust Legal Provisions and are=20 provided without warranty as=0A= described in the Simplified BSD=20 License.=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . .=20 . . . . . . . . . . . . . . . 4=0A= 2. Terminology . . . . . . . .=20 . . . . . . . . . . . . . . . . . 6=0A= 3. Call-Info Specification=20 . . . . . . . . . . . . . . . . . . . 7=0A= 4. Data Provider=20 Information . . . . . . . . . . . . . . . . . . 8=0A= 4.1. Data=20 Provider String . . . . . . . . . . . . . . . . . . . 8=0A= 4.2.=20 Data Provider ID . . . . . . . . . . . . . . . . . . . . . 8=0A= =20 4.3. Data Provider Contact URI . . . . . . . . . . . . . . . . 9=0A= =20 4.4. Data Provider Languages(s) Supported . . . . . . . . . . . 9=0A= =20 4.5. vCARD of Data Provider . . . . . . . . . . . . . . . . . . 10=0A= =20 4.6. addDataProviderInfo XML Schema . . . . . . . . . . . . . . 11=0A= =20 5. Service Information . . . . . . . . . . . . . . . . . . . . .=20 12=0A= 5.1. Service Environment . . . . . . . . . . . . . . . . .=20 . . 12=0A= 5.2. Service Delivered by Provider to End User . . . .=20 . . . . 12=0A= 5.3. addCallSvcInfo XML Schema . . . . . . . . . .=20 . . . . . . 13=0A= 6. Device Information . . . . . . . . . . . . . .=20 . . . . . . . . 15=0A= 6.1. Device Classification . . . . . . . .=20 . . . . . . . . . . 15=0A= 6.2. Device Manufacturer . . . . . . .=20 . . . . . . . . . . . . 17=0A= 6.3. Device Model Number . . . . .=20 . . . . . . . . . . . . . . 17=0A= 6.4. Unique Device Identifier .=20 . . . . . . . . . . . . . . . . 17=0A= 6.5. Type of Device=20 Identifier . . . . . . . . . . . . . . . . 18=0A= 6.6.=20 Device/Service Specific Additional Data Structure Type . . 19=0A= =20 6.7. Device/Service Specific Additional Data Structure . . . . 20=0A= =20 6.8. addDataDevInfo XML Schema . . . . . . . . . . . . . . . . 21=0A= =20 7. Owner/Subscriber Information . . . . . . . . . . . . . . . . .=20 22=0A= 7.1. vCARD for Subscriber's Data . . . . . . . . . . . . .=20 . . 22=0A= 7.2. addCallSub XML Schema . . . . . . . . . . . . . .=20 . . . . 22=0A= 8. Example . . . . . . . . . . . . . . . . . . . . .=20 . . . . . . 24=0A= 9. Security Considerations . . . . . . . . . . .=20 . . . . . . . . 25=0A= 10. Privacy Considerations . . . . . . . . . .=20 . . . . . . . . . . 26=0A= 11. IANA Considerations . . . . . . . . .=20 . . . . . . . . . . . . 27=0A= 11.1. 'emergencyCallData' Purpose=20 Parameter Value . . . . . . . 27=0A= 11.2. URN Sub-Namespace=20 Registration for provided-by=0A= Registry Entry . . . . . . .=20 . . . . . . . . . . . . . . . 27=0A= 11.3. MIME Registrations . . .=20 . . . . . . . . . . . . . . . . . 27=0A= 11.3.1. MIME=20 Content-type Registration for=0A= =20 'application/addDataProviderInfo+xml' . . . . . . . . 27=0A= =20 11.3.2. MIME Content-type Registration for=0A= =20 'application/addCallSvcInfo+xml' . . . . . . . . . . 28=0A= =0A= =0A= =0A= Rosen, et=20 al. Expires May 3, 2012 [Page=20 2]=0A= =0C=0A= Internet-Draft Additional Call Data=20 October 2011=0A= =0A= =0A= 11.3.3. MIME Content-type Registration for=0A= =20 'application/addDataDevInfo+xml' . . . . . . . . . . 30=0A= =20 11.3.4. MIME Content-type Registration for=0A= =20 'application/addCallSub+xml' . . . . . . . . . . . . 31=0A= 11.4.=20 URN Sub-Namespace Registration . . . . . . . . . . . . . . 32=0A= =20 11.4.1. Registration for=0A= =20 urn:ietf:params:xml:ns:addDataProviderInfo . . . . . 32=0A= =20 11.4.2. Registration for=0A= =20 urn:ietf:params:xml:ns:addCallSvcInfo . . . . . . . . 33=0A= =20 11.4.3. Registration for=0A= =20 urn:ietf:params:xml:ns:addDataDevInfo . . . . . . . . 34=0A= =20 11.4.4. Registration for urn:ietf:params:xml:ns:addCallSub . 35=0A= =20 11.5. Schema Registrations . . . . . . . . . . . . . . . . . . . 36=0A= =20 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .=20 38=0A= 13. References . . . . . . . . . . . . . . . . . . . . . . . .=20 . . 39=0A= 13.1. Normative References . . . . . . . . . . . . . . .=20 . . . . 39=0A= 13.2. Informational References . . . . . . . . . . .=20 . . . . . . 39=0A= Authors' Addresses . . . . . . . . . . . . . . . .=20 . . . . . . . . 41=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 3]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= 1.=20 Introduction=0A= =0A= RG >>>>> I don't think we need the justification below=20 -- I think=0A= RG >>>>> by now the benefits of IP-based emergency calls=20 are =0A= RG >>>>> understood and accepted. Rather, we should introduce=20 what=0A= RG >>>>> this document does and why it's needed. I'd suggest=20 replacing=0A= RG >>>>> the below paragraph with the following=20 text:=0A= RG >>>>>=0A= RG This document extends the basic signaling of an=20 emergency call in=0A= RG order to carry additional data which may be=20 useful to an entity=0A= RG handling the call. This data is "additional"=20 to the basic=0A= RG signaling used in processing the call. Four general=20 categories of=0A= RG such data are defined, for the caller, the location,=20 the call, and=0A= RG the PSAP. An XML data structure is defined for such=20 data, and a=0A= RG means of conveying the data by including a Uniform=20 Resource=0A= RG Identifier (URI) in the SIP signaling which resolves to=20 the data.=0A= RG The data itself may reside on an external resource, or=20 may be=0A= RG contained within the BODY of the SIP=20 message.=0A= RG >>>>>=0A= RG >>>>> DELETE FOLLOWING PARAGRAPH=0A= As=20 communications devices increasingly utilize the Internet to=0A= =20 interconnect and communicate, users will expect to use such devices=0A= =20 to request help. The Internet Protocol suite provides many=0A= =20 advantages but also requires re-thinking of the traditional=20 emergency=0A= calling architecture. The IETF emergency services=20 architecture, as=0A= described in [I-D.ietf-ecrit-framework] and=0A= =20 [I-D.ietf-ecrit-phonebcp], offers a much richer communication=0A= =20 exchange and thereby better situational awareness for call takers.=0A= =20 The richness comes in various forms, including the multi-media=0A= =20 communication capabilities (via voice, video, instant messaging, and=0A= =20 real-time text), but also via more extensive flow of information.=0A= =20 Sharing information between various actors will enable more=0A= =20 intelligent decision making and therefore better response in case of=0A= =20 an emergency. A pre-requisite is to offer the technical=20 capabilities=0A= to let call takers to gain access to this information=20 stored=0A= elsewhere (granted that they are authorized to access=20 it).=0A= =0A= In general, there are four types of data exchanged:=0A= =0A= Data=20 Associated with a Call: A lot of information is carried in the=0A= =20 call setup procedure itself (as part of the SIP headers as well as=0A= =20 in the body of the SIP message, e.g., for example supported=0A= =20 capabilities of the device). This also includes information about=0A= =20 the emergency caller's identity.=0A= RG >>>>>> the text above is=20 confusing and I'm not sure what it is=0A= RG >>>>>> trying to say, so I=20 can't offer suggested replacement.=0A= RG >>>>>> The text above does not=20 seem to be talking about data pointed=0A= RG >>>>>> to be a Call-Info=20 header.=0A= =0A= Data Associated with a Location: Location information is=20 available=0A= via the PIDF-LO element, which includes civic and=20 geospatial=0A= location, information about the entity that provided=20 the data,=0A= information about how the location was obtained (as=20 expressed by=0A= the element, see Section 2.2.3 of=20 [RFC4119], and the=0A= values registered in=0A= =20 http://www.iana.org/assignments/method-tokens/method-tokens.xml),=0A= =20 and which entity or organization supplied location information=0A= =20 (beyond the domain information that can be inferred from a signing=0A= =20 certificate) available via the element.=0A= RG >>>>>>> I=20 thought data associated with a location would be a pointer=0A= RG >>>>>>>=20 to floorplans, hazardous materials located on-site,=20 building=0A= RG >>>>>>> management contact information, that sort of=20 thing. The text=0A= RG >>>>>>> above seems to be just describing a=20 PIDF-LO.=0A= =0A= Data Associated with a Caller: This is personal data=20 about a caller,=0A= including medical information.=0A= RG ^^^^^^^^^=20 such as=0A= =0A= Data associated with a PSAP: When a PSAP handles a call=20 it develops=0A= information about the call, which must be passed to=20 subsequent=0A= PSAPs, dispatchers and/or responders.=0A= =0A= When an=20 emergency call is sent to a PSAP, there is a rich set of data=0A= in=20 the SIP message used for the call setup, but the device, as well=0A= =20 as any other service provider in the path may have even more=0A= RG=20 XXXXXXXX=0A= =0A= =0A= =0A= Rosen, et al. Expires May 3, 2012=20 [Page 4]=0A= =0C=0A= Internet-Draft Additional Call Data=20 October 2011=0A= =0A= =0A= information useful for a PSAP. This information=20 may include the=0A= RG ^ that may be=0A= identity and contact=20 information of the service provider, subscriber=0A= identity and=20 contact information, the type of service the provider=0A= offers, what=20 kind of device the user has, etc. Some data is device=0A= or service=20 dependent data. For example, a car telematics system or=0A= service=20 may have crash information. A medical monitoring device may=0A= have=20 sensor data. While the details of the information may vary by=0A= =20 device or service, there needs to be a common way to send such data=0A= =20 to a PSAP.=0A= =0A= This document focuses on the data that can be obtained=20 about a call=0A= RG ^=20 ^^^^^^^^^^^^^^^^=0A= RG ^=20 associated with an emergency=0A= RG ^ four=20 types of additional=0A= and a mechanism for transporting it in an=20 existing SIP header field,=0A= the Call-Info header, which is=20 specified in Section 20.9 of=0A= [RFC3261]. For this purpose a new=20 token, namely 'emergencyCallData'=0A= is defined to be carried in the=20 "purpose" parameter. If the=0A= "purpose" parameter is set to=20 'emergencyCallData' then the Call-Info=0A= header contains a HTTPS URL=20 that points to a data structure with=0A= information about the call or=20 a CID that allows the data structure to=0A= be placed in the body of=20 the message. Section 8 shows a SIP INVITE=0A= example containing such=20 a Call-Info header.=0A= =0A= Besides a service provider in the path of a=20 call, the access network=0A= (which in the IETF emergency call=20 architecture provides location in=0A= the form of a PIDF-LO [RFC4119])=20 also has similar information that=0A= would be valuable to the PSAP.=20 This information is not specific to=0A= RG ^^^^^ may=0A= the location=20 itsef, but rather to the immmediate circumstances about=0A= the=20 provision of the location (who the access network is, how to=0A= =20 contact that entity, what kind of service the access network=0A= =20 provides, possibly subscriber data, etc.). This data is in nearly=0A= =20 every respect similar to the data known by services providers in the=0A= =20 path of the call. For this reason, this document describes a=0A= =20 "provided-by" namespace per [RFC4119] for passing information known=0A= =20 to the access network.=0A= =0A= The data is defined as a series of=20 "blocks" that represent a class of=0A= information. Each of the=20 blocks is a MIME type, and an extensible=0A= set of these types=20 constitute the data structure. A registry is=0A= defined to list the=20 block types that may be included.=0A= =0A= The data structure contains an=20 element which itself is a URI that has=0A= device or service dependent=20 data. Thus the common Additional Data=0A= about a Call defined by=20 this document contains a 'hook', in the form=0A= of a URI, for a=20 device or service dependent data structure.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 5]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= 2. Terminology=0A= =0A= =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= =20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= =20 document are to be interpreted as described in RFC 2119=20 [RFC2119].=0A= =0A= RG >>>>> I suggest adding text to this section or=20 elsewhere, describing=0A= RG >>>>> the meaning of the "Use: " items=20 below. What does "Required"=0A= RG >>>>> mean, e.g.? (I assume it means=20 that if the block in which the=0A= RG >>>>> element is defined is=20 included, then the element MUST be part=0A= RG >>>>> of the block, but=20 this just an=20 assumption.)=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et=20 al. Expires May 3, 2012 [Page=20 6]=0A= =0C=0A= Internet-Draft Additional Call Data=20 October 2011=0A= =0A= =0A= 3. Call-Info Specification=0A= =0A= The Additional Data=20 about a Call is information specific to a call=0A= known by the device=20 that sends it or a service provider in the path=0A= of a call or in=20 the access network the call originates in. The=0A= Additional Data=20 about a Call is a set of information blocks. Each=0A= block is a MIME=20 type, and any set of blocks may be included in the=0A= set.=0A= =0A= Two=20 mechanisms are provided to transport the data set, namely=0A= =0A= 1. A=20 URI to the data set MAY be inserted in a SIP INVITE or MESSAGE=0A= =20 transaction with a Call-Info header containing a purpose of=0A= =20 "emergenyCallData". If the data is provided by reference, it may=0A= =20 be retrieved with an HTTPS Get from the URI. The URI MUST=0A= =20 specify an HTTPS scheme, and TLS protection for the data MUST be=0A= =20 negotiated.=0A= =0A= 2. The data may be supplied by value in a SIP INVITE=20 or MESSAGE=0A= message. In this case, Content Indirection (CID)=20 [RFC2392] is=0A= used, with the CID URL pointing to the body of=20 the message.=0A= =0A= More than one Call-Info header with an=20 emergencyCallData purpose can=0A= be expected. The device MAY insert=20 one, and any intermediary service=0A= provider MAY insert its own.=20 When there are multiple intermediaries,=0A= each intermediary MAY each=20 insert one. For example, a device may=0A= provide one, a telematics=20 service provider may provide one and the=0A= mobile carrier handling=20 the call may provide one.=0A= =0A= Note: The access network MAY supply=20 additional data as well. For=0A= this purpose, this document defines=20 a namespace and adds the=0A= namespace to the "provided-by" registry=20 defined by PIDF-LO [RFC4119].=0A= =0A= Additional data about a call is=20 defined as a series of MIME objects,=0A= each with an XML data=20 structure contained inside. MIME-multipart is=0A= used to enclose the=20 XML documents and the sections below define=20 them.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al. Expires May 3, 2012=20 [Page 7]=0A= =0C=0A= Internet-Draft Additional Call Data=20 October 2011=0A= =0A= =0A= 4. Data Provider Information=0A= =0A= =0A= This block is=20 intended to be provided by any service provider in the=0A= path of the=20 call or the access network provider. It includes=0A= identification=20 and contact information. This block SHOULD be=0A= provided for every=20 service provider in the path of the call, and the=0A= access network=20 provider. Devices also use this block to provide=0A= RG=20 ^ MAY ^^^=0A= identifying information. The MIME type is=20 "addDataProviderInfo+xml".=0A= =0A= 4.1. Data Provider String=0A= =0A= Data=20 Element: Data Provider String=0A= =0A= =0A= Use: Required=0A= =0A= =0A= XML Element:=20 =0A= =0A= =0A= Description: This is a plain language=20 string suitable for displaying=0A= the name of the service provider=20 that created the additional data=0A= structure. If the device=20 created the structure the value is=0A= identical to the contact=20 header in the SIP INVITE.=0A= =0A= =0A= Reason for Need: Inform the call=20 taker about the identity of the=0A= RG=20 ^^^^^ of=0A= entity providing the additional call data structure.=0A= =0A= =20 How Used by Call Taker: Allows the call taker to interpret the data=0A= =20 in this structure. The source of the information often influences=0A= =20 how the information is used, believed or verified.=0A= RG >>>>> The "How=20 Used by the Call Taker" text implies a small number=0A= RG >>>>> of=20 service providers that PSAPs are familiar with, and for=0A= RG >>>>>=20 which PSAP call takers have been trained in interpreting the=0A= RG >>>>>=20 data they send. This makes sense when service providers are=0A= RG >>>>>=20 limited to landline and cellular, but how does this work=20 when=0A= RG >>>>> there are an unlimited number of service=20 providers?=0A= =0A= 4.2. Data Provider ID=0A= =0A= Data Element: Data Provider=20 ID=0A= =0A= =0A= Use: Conditional=0A= =0A= =0A= XML Element: =0A= =0A= =0A= =20 Description: A jurisdiction specific code for the provider shown in=0A= =20 the element that created the structure of the=0A= =20 call. This data SHOULD be provided if the local jurisdiction=0A= =20 maintains such an ID list. For example, in North America,=20 this=0A= =0A= =0A= =0A= Rosen, et al. Expires May 3, 2012=20 [Page 8]=0A= =0C=0A= Internet-Draft Additional Call Data=20 October 2011=0A= =0A= =0A= would be a "NENA Company ID". Devices would not=20 typically use=0A= RG=20 ^^^^^^^^^^^^^^^^^^^=0A= RG >>>>> should this be SHOULD NOT?=0A= this=20 element.=0A= =0A= =0A= Reason for Need: Inform the call taker about the=20 identity of the=0A= RG ^^^^^ of=0A= =20 entity providing the additional call data structure.=0A= =0A= =0A= How Used by=20 Call Taker: Where jurisdictions have lists of providers=0A= the=20 Data Provider ID can lead to a wealth of information.=0A= RG=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=0A= RG >>>>> like what? Maybe better to=20 just say "be useful."=0A= =0A= 4.3. Data Provider Contact URI=0A= =0A= Data=20 Element: Data Provider Contact URI=0A= =0A= =0A= Use: Required=0A= =0A= =0A= XML=20 Element: =0A= =0A= =0A= Description: For a service provider the=20 contact SHOULD be a contact=0A= URI. This must be a SIP URI. If a=20 telephone number is the=0A= RG ^^^^ MUST=0A= contact=20 address it should be provided in the form of=0A= =20 sip:telephonenumber@serviceprovider:user=3Dphone. If the call is=0A= =20 from a device, this data is required and should reflect the=0A= RG=20 ^^^^^^^^ REQUIRED=0A= contact information of the owner of the=20 device. This should be a=0A= URI to a 24/7 support organization=20 tasked to provide PSAP support=0A= for this emergency=20 call.=0A= RG >>>>> Need to better explain "device." This reads as a=20 requirement=0A= RG >>>>> that every end-user device MUST provide=20 Call-Info with =0A= RG >>>>> contact information for the user.=0A= =0A= =0A= =20 Reason for Need: Additional data providers may need to be contacted=0A= =20 for error or other unusual circumstances.=0A= =0A= =0A= How Used by Call=20 Taker: To contact the supplier of the additional=0A= data provider=20 structure.=0A= =0A= 4.4. Data Provider Languages(s) Supported=0A= =0A= Data=20 Element: Data Provider Language(s) supported=0A= =0A= =0A= Use:=20 Conditional=0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al. Expires May 3, 2012=20 [Page 9]=0A= =0C=0A= Internet-Draft Additional Call Data=20 October 2011=0A= =0A= =0A= XML Element: =0A= =0A= =0A= Description:=20 Provided by's alpha 2-character code as defined in ISO=0A= RG=20 ^^^^^^^^^^^^^ The language used by the entity in=0A= RG=20 Provided-By, as an=0A= 639-1:2002=0A= =20 (http://www.iso.org/iso/catalogue_detail?csnumber=3D22109) Codes for=0A= =20 the representation of names of languages -- Part 1: Alpha-2 code=0A= =20 Multiple instances of this element may occur. Order is=0A= =20 significant; preferred language should appear first. This data is=0A= =20 required if a Data Provider Contact URI is provided. The content=0A= =20 must reflect the languages supported at the contact URI.=0A= =0A= =0A= Reason=20 for Need: Information needed to determine if emergency=0A= service=20 authority can communicate with the service provider or if=0A= =20 language line will be needed.=0A= =0A= =0A= How Used by Call Taker: If call=20 taker cannot speak language(s)=0A= supported by the service=20 provider, at translation service will=0A= RG=20 X=0A= need to be added in to the conversation.=0A= =0A= 4.5. vCARD of Data=20 Provider=0A= =0A= Data Element: vCARD of Data Provider=0A= =0A= =0A= Use:=20 Optional=0A= =0A= =0A= XML Element: =0A= =0A= =0A= Description:=20 There are many fields in the vCARD and the creator of=0A= the data=20 structure is encouraged to provide as much information as=0A= they=20 have available. For encoding of the vCard this specification=0A= =20 uses the XML-based encoding specified in [RFC6351].=0A= =0A= =0A= Reason for=20 Need: Information needed to determine additional contact=0A= =20 information.=0A= =0A= =0A= How Used by Call Taker: Assists call taker by=20 providing additional=0A= contact information that may not be=20 included in the SIP invite or=0A= the PIDF-LO.=0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 10]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= 4.6.=20 addDataProviderInfo XML Schema=0A= =0A= =0A= =0A= =0A= =0A= =20 =0A= =0A= =20 =0A= =0A= =0A= =20 =0A= =0A= =0A= =0A= =0A= =20 =0A= =0A= =20 =0A= =20 =0A= =0A= =0A= =0A= =20 =0A= =0A= =0A= =0A= =20 Figure 1: addDataProviderInfo XML Schema=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 11]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= 5. Service=20 Information=0A= =0A= This block describes the service that the service=20 provider provides=0A= to the caller. It SHOULD be included by all SPs=20 in the path of the=0A= call. The mime type is=20 "addCallSvcInfo+xml".=0A= =0A= 5.1. Service Environment=0A= =0A= Data Element:=20 Service Environment=0A= =0A= =0A= Use: Required=0A= =0A= =0A= XML Element:=20 =0A= =0A= =0A= Description: This element defines whether a=20 call is from a business=0A= or residence caller. Currently, the=20 only valid entries are=0A= 'Business' or 'Residence'.=0A= =0A= =0A= Reason=20 for Need: To assist in determining equipment and manpower=0A= =20 requirements.=0A= =0A= =0A= How Used by Call Taker: Information may be used=20 to determine=0A= equipment and manpower requirements for emergency=20 responders.=0A= =0A= 5.2. Service Delivered by Provider to End User=0A= =0A= Data=20 Element: Service Delivered by Provider to End User=0A= =0A= =0A= Use:=20 Required=0A= =0A= =0A= XML Element: =0A= =0A= =0A= Description:=20 This defines the type of service the end user has=0A= subscribed=20 to. The implied mobility of this service can not be=0A= relied=20 upon. A registry will reflect the following initial valid=0A= =20 entries:=0A= RG >>>> Where is this registry? This needs to be=20 identified.=0A= =0A= * Mobile Telephone Service: Includes Satellite,=20 CDMA, GSM, Wi-Fi,=0A= WiMAX, LTE (Long Term Evolution)=0A= RG >>>>=20 Do you want to add UMTS/WCDMA?=0A= =0A= =0A= =0A= =0A= Rosen, et al. Expires=20 May 3, 2012 [Page 12]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= * Fixed=20 Public Pay/Coin telephones: Any coin or credit card=0A= operated=20 device.=0A= =0A= * One way outbound service=0A= =0A= * Inmate=20 call/service=0A= =0A= * Soft dialtone/quick service/warm=20 disconnect/suspended=0A= =0A= * Multi-line telephone system (MLTS):=20 Includes all PBX, Centrex,=0A= key systems, Shared Tenant=20 Service.=0A= =0A= * Sensor, unattended: Includes devices that generate=20 DATA ONLY.=0A= This is one-way information exchange and there=20 will be no other=0A= form of communication.=0A= =0A= * Sensor,=20 attended: Includes devices that are supported by a=0A= =20 monitoring service provider or automatically open a two-way=0A= =20 communication path.=0A= =0A= * Wireline: Plain Old Telephone Service=20 (POTS).=0A= =0A= * VoIP Telephone Service: A type of service that=20 offers=0A= communication over internet protocol, such as Fixed,=20 Nomadic,=0A= Mobile, Unknown=0A= =0A= There can be more than one=20 value returned. For example, a VoIP=0A= prison telephone service=20 is a reasonable conbination.=0A= RG >>>>> How is it a combination?=20 Prison isn't listed.=0A= =0A= =0A= Reason for Need: Knowing the type of=20 service may assist the PSAP=0A= with the handling of the call.=0A= =0A= =0A= =20 How Used by Call Taker: Calltakers often use this information to=0A= =20 determine what kinds of questions to ask callers, and how much to=0A= =20 rely on supportive information. An emergency call from a prison=0A= =20 is treated differently that a call from a sensor device.=0A= =0A= 5.3.=20 addCallSvcInfo XML Schema=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 13]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= =0A= =0A= =0A= =20 =0A= =0A= =0A= =0A= =20 =0A= =0A= =20 =0A= =20 =0A= =0A= =0A= =20 =0A= =0A= Figure 2: addCallSvcInfo XML=20 Schema=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al. Expires=20 May 3, 2012 [Page 14]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= 6. Device=20 Information=0A= =0A= This block provides information about the device used=20 to place the=0A= call. It should be provided by any service provider=20 that knows what=0A= device is being used, and by the device itself.=20 The mime type is=0A= "addDataDevInfo+xml".=0A= =0A= 6.1. Device=20 Classification=0A= =0A= Data Element: Device Classification=0A= =0A= =0A= Use:=20 Optional=0A= =0A= =0A= XML Element: =0A= =0A= =0A= Description:=20 If the device provides the data structure, the device=0A= =20 information should be provided. If the service provider provides=0A= RG=20 ^^^^^^ SHOULD =0A= the structure and it knows what the device=20 is, the service=0A= provider should provide the device information.=20 Often the carrier=0A= RG ^^^^^^ SHOULD =0A= does not=20 know what the device is. It is possible to receive 2=0A= RG=20 ^ two=0A= data structures, one created by the device and one=20 created by the=0A= service provider. Information about the device,=20 not how it is=0A= being used. This data element defines the kind=20 of device making=0A= RG >>>>> This ("Information about....") isn't a=20 complete sentence.=0A= the emergency call. A registry will reflect=20 the following valid=0A= entries:=0A= RG >>>>> Where is this registry?=20 It needs to be identified.=0A= =0A= * Cordless handset=0A= =0A= * Fixed=20 phone=0A= =0A= * Mobile handset=0A= =0A= * ATA - analog terminal=20 adapter=0A= RG ^ ":" "--" =0A= =0A= * Satellite phone=0A= =0A= * Stationary computing=20 device (alarm system, data sensor)=0A= =0A= * Guardian devices=0A= =0A= =20 * Desktop PC=0A= =0A= * Laptop computing device=0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 15]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= * Tablet=20 computing device=0A= =0A= * Alarm system=0A= =0A= * Data sensor=0A= =0A= =20 * Personal beacons (spot)=0A= =0A= * Auto telematics (indicates VEDS=20 data set)=0A= =0A= * Trucking telematics=0A= =0A= * Farm equipment=20 telematics=0A= =0A= * Marine telematics=0A= =0A= * PDA (personal=20 digital assistant)=0A= =0A= * PND (personal navigation device)=0A= =0A= =20 * Smart phone=0A= =0A= * Internet tablet=0A= =0A= * Gaming console=0A= =0A= =20 * Video phone=0A= =0A= * Other text device=0A= =0A= * Not Available=0A= =0A= =0A= =20 Reason for Need: The device classification describes the=20 capability=0A= RG ^^^^^^^^^=20 implies=0A= of the calling device. For example, does the device=20 require human=0A= intervention to initiate a call or is this call=20 the result of=0A= programmed instructions. Does the calling device=20 have the ability=0A= to rebid for location or condition changes?=20 Is this device=0A= interactive or a one-way reporting device?=0A= =0A= =0A= =20 How Used by Call Taker: May assist with location of caller. For=0A= =20 example, a cordless handset may be outside or next door. May=0A= =20 provide calltaker some context about the caller.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 16]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= 6.2. Device=20 Manufacturer=0A= =0A= Data Element: Device Manufacturer=0A= =0A= =0A= Use:=20 Optional=0A= =0A= =0A= XML Element: =0A= =0A= =0A= Description: The plain=20 language name of the manufacturer of the=0A= device.=0A= =0A= =0A= Reason=20 for Need: Used by PSAP management for post-mortem=0A= =20 investigation/resolution.=0A= =0A= =0A= How Used by Call Taker: Probably not=20 used by calltaker, but by PSAP=0A= management.=0A= =0A= 6.3. Device Model=20 Number=0A= =0A= Data Element: Device Model Number=0A= =0A= =0A= Use: Optional=0A= =0A= =0A= =20 XML Element: =0A= =0A= =0A= Description: Model number of the=20 device.=0A= =0A= =0A= Reason for Need: Used by PSAP management for after=20 action=0A= investigation/resolution.=0A= =0A= =0A= How Used by Call Taker:=20 Probably not used by calltaker, but by PSAP=0A= management.=0A= =0A= 6.4.=20 Unique Device Identifier=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al. Expires=20 May 3, 2012 [Page 17]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= Data Element:=20 Unique Device Identifier=0A= =0A= =0A= Use: Optional=0A= =0A= =0A= XML Element:=20 =0A= =0A= =0A= Description: String that identify the specific=20 device making the=0A= RG ^ ies=0A= =20 call or creating an event.=0A= =0A= =0A= Reason for Need: Uniquely identifies=20 the device as opposed to any=0A= signaling identifiers encountered=20 in the call signaling stream.=0A= =0A= =0A= How Used by Call Taker: Probably=20 not used by calltaker they would=0A= need to refer to management=20 for investigation.=0A= =0A= 6.5. Type of Device Identifier=0A= =0A= Data Element:=20 Type of Device Identifier=0A= =0A= =0A= Use: Optional=0A= =0A= =0A= XML Element:=20 =0A= =0A= =0A= Description: Identifies the type of device=20 identifier being=0A= generated in the unique device identifier data=20 element. A=0A= registry will reflect the following valid=20 entries:=0A= =0A= * MEID (CDMA)=0A= =0A= * ESN (Electronic Serial=20 Number - superseded by MEID)=0A= RG ^=20 --=0A= =0A= * MAC (Media Access Control) Address - any IEEE device=20 with an=0A= RG ^=20 ^^^^^^^^^^^^^^^^^^^^^^^=0A= RG ^=20 --=0A= Ethernet, Wi-Fi connection=0A= RG=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^=0A= RG ^^ IEEE-delegated address of any=20 of the interfaces of=0A= RG the device with a MAC address (e.g.,=20 Ethernet, WiFi)=0A= =0A= * WiMAX has a device certificate=0A= RG >>>>> OK,=20 so it has one, but what value is to be=0A= RG >>>>> included here?=0A= =0A= =20 * IMEI (International Mobile Equipment Identifier - GSM)=0A= RG=20 ^ --=0A= =0A= * Unique Device Identifier (Unique identifier for=20 medical=0A= devices)=0A= RG >>>>> If this is something for medical=20 devices, perhaps it=0A= RG >>>>> should have a less generic name, one=20 that reflect that=0A= RG >>>>> it is for medical devices. Also, is this=20 value unique=0A= RG >>>>> to a type of device, a device model, or a=20 specific=0A= RG >>>>> individual device?=0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 18]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= * RFID (Radio=20 Frequency Identification)=0A= =0A= * Sensors (types to be identified=20 in a future document version)=0A= =0A= * Manufacturer Serial Number=0A= =0A= =20 * Other=0A= =0A= =0A= Reason for Need: Identifies how to interpret the=20 Unique Device=0A= Identifier.=0A= =0A= =0A= How Used by Call Taker:=20 Additional information that may be used to=0A= assist with call=20 handling.=0A= =0A= 6.6. Device/Service Specific Additional Data Structure=20 Type=0A= =0A= Data Element: Type of Device/service specific additional=20 data=0A= structure=0A= =0A= =0A= Use: Conditional. MUST be provided when=20 Device/service specific=0A= additional URI is provided=0A= =0A= =0A= XML=20 Element: =0A= =0A= =0A= Description: Value from a=20 registry defined by this document to=0A= describe the type of data=20 that can be retrieved from the Device/=0A= service specific=20 additional data structure. Initial values are:=0A= =0A= * NPAC=0A= =0A= =20 * Hazmat International Association of Fire Chiefs=0A= =0A= * DHS/EPA=20 E-Plan for HazMat=0A= =0A= * NFPA - National Fire ProtectionAssociation=0A= =0A= =20 * National Alliance for Public Safety GIS (NA-PSG)=0A= =0A= * US DOT=20 Pipeline and Hazardous Materials Safety Administration=0A= =20 (PHMSA) examples of additional data.=0A= =0A= * Fire Service Data=20 Model=0A= =0A= =0A= =0A= =0A= Rosen, et al. Expires May 3, 2012=20 [Page 19]=0A= =0C=0A= Internet-Draft Additional Call Data=20 October 2011=0A= =0A= =0A= * IEEE 1512 - USDOT Model for traffic=20 incidents=0A= =0A= * Smart Building (NIST)=0A= =0A= * VEDS=0A= =0A= =0A= Reason=20 for Need: This data element will allow for identification of=0A= RG=20 XXXX ^s=0A= externally defined schemas, which may have=20 additional data that=0A= will assist in emergency response.=0A= RG=20 ^^^^ may=0A= =0A= =0A= How Used by Call Taker: This data element will allow=20 the end user=0A= RG XXXX=20 ^sd=0A= (calltaker or first responder) to know what type of=20 additional=0A= data may be available to aid in providing the needed=20 emergency=0A= services.=0A= =0A= 6.7. Device/Service Specific Additional=20 Data Structure=0A= =0A= Data Element: Device/service specific additional=20 data structure=0A= =0A= =0A= Use: Optional=0A= =0A= =0A= XML Element:=20 =0A= =0A= =0A= Description: A URI representing=20 additional data whose schema is=0A= specific to the device or=20 service which created it. An example is=0A= the VEDs structure for=20 a vehicle telematics device. The URI, when=0A= dereferenced, MUST=20 yield a data structure defined by the Device/=0A= service specific=20 additional data type value. Different data may=0A= be created by=20 each classification; i.e., telematics creates VEDS=0A= RG=20 ^^^^^ e.g.,=0A= data set - can be different types of data depending=20 on device.=0A= RG ^ -- there=0A= May want to describe type=20 of data for each device.=0A= RG >>>>> What does this last sentence mean?=20 Does it refer to a=0A= RG >>>>> needed edit of this document to add this,=20 or does it refer=0A= RG >>>>> to an item within the date, or something=20 else?=0A= =0A= =0A= Reason for Need: Provides device/service specific data=20 that may be=0A= used by the call taker and/or responders.=0A= =0A= =0A= How=20 Used by Call Taker: Provide information to guide call takers to=0A= =20 select appropriate responders, give appropriate pre-arrival=0A= =20 instructions to callers, and advise responders of what to be=0A= =20 prepared for. May be used by responders to guide assistance=0A= =20 provided.=0A= =0A= =0A= =0A= =0A= Rosen, et al. Expires May 3, 2012=20 [Page 20]=0A= =0C=0A= Internet-Draft Additional Call Data=20 October 2011=0A= =0A= =0A= 6.8. addDataDevInfo XML Schema=0A= =0A= =0A= =0A= =0A= =0A= =20 =0A= =0A= =0A= =0A= =20 =0A= =0A= =0A= =0A= =20 =0A= =20 =0A= =20 =0A= =20 =0A= =20 =0A= =0A= =0A= =20 =0A= =0A= Figure 3: addDataDevInfo XML=20 Schema=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al. Expires May 3, 2012=20 [Page 21]=0A= =0C=0A= Internet-Draft Additional Call Data=20 October 2011=0A= =0A= =0A= 7. Owner/Subscriber Information=0A= =0A= This block=20 describes the owner of the device (if provided by the=0A= device) or=20 the subscriber information, if provided by a service=0A= provider.=20 The contact location is not necessarily the location of=0A= the caller=20 or incident, but is rather the nominal contact address.=0A= The mime=20 type is "addCallSub+xml".=0A= =0A= 7.1. vCARD for Subscriber's Data=0A= =0A= Data=20 Element: vCARD for Subscriber's Data=0A= =0A= =0A= Use: Required=0A= =0A= =0A= XML=20 Element: =0A= =0A= =0A= Description: Information known by=20 the service provider or device=0A= about the subscriber; i.e.,=20 Name, Address, Calling Party Number,=0A= RG=20 ^^^^^ e.g.,=0A= Main Telephone Number and any other data. If the=20 subscriber is an=0A= enterprise, this is the vCARD of the=20 enterprise and the Company=0A= Name is used not the Name of the=20 Caller. The telephone number is=0A= the main telephone number at=20 the location of the call. The=0A= address should be where the call=20 is originating from.=0A= =0A= =0A= Reason for Need: Critical information=20 required for proper call=0A= handling and dispatching.=0A= =0A= =0A= How=20 Used by Call Taker: Critical information required for proper=0A= =20 call handling and dispatching.=0A= =0A= 7.2. addCallSub XML=20 Schema=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al. Expires May 3, 2012=20 [Page 22]=0A= =0C=0A= Internet-Draft Additional Call Data=20 October 2011=0A= =0A= =0A= =0A= =0A= =0A= =20 =0A= =0A= =0A= =0A= =20 =0A= =0A= =20 =0A= =0A= =0A= =20 =0A= =0A= Figure 4: addCallSub XML=20 Schema=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al. Expires=20 May 3, 2012 [Page 23]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= 8. Example=0A= =0A= =0A= =20 INVITE sips:bob@biloxi.example.com SIP/2.0=0A= Via: SIPS/2.0/TLS=20 pc33.atlanta.example.com;branch=3Dz9hG4bK74bf9=0A= Max-Forwards: 70=0A= =20 To: Bob =0A= From: Alice=20 ;tag=3D9fxced76sl=0A= Call-ID:=20 3848276298220188511@atlanta.example.com=0A= Call-Info:=20 ;purpose=3Dicon,=0A= =20 ;purpose=3Dinfo,=0A= =20 ;purpose=3DemergencyCallData=0A= =20 Geolocation: =0A= =20 Geolocation-Routing: no=0A= Accept: application/sdp,=20 application/pidf+xml=0A= CSeq: 31862 INVITE=0A= Contact:=20 =0A= Content-Type: multipart/mixed;=20 boundary=3Dboundary1=0A= =0A= Content-Length: ...=0A= =0A= --boundary1=0A= =0A= =20 Content-Type: application/sdp=0A= =0A= ...SDP goes here=0A= =0A= =20 --boundary1=0A= =0A= Content-Type: application/pidf+xml=0A= Content-ID:=20 =0A= =0A= ...PIDF-LO goes here=0A= =0A= =20 --boundary1--=0A= =0A= Content-Type: application/pidf+xml=0A= =20 Content-ID: <1234567890@atlanta.example.com>=0A= =0A= ...Additional Data=20 goes here=0A= =0A= --boundary1--=0A= =0A= Example: Attaching Additional=20 Data via CID to a SIP INVITE=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 24]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= 9. Security=20 Considerations=0A= =0A= The information in this data structure will=20 usually be considered=0A= private. HTTPS is specified to require the=20 provider of the=0A= RG >>>>> Mandating use of HTTPS does not mandate=20 client-side=0A= RG >>>>> certificates. If you intend to mandate=20 client-side=0A= RG >>>>> certs, do so, but also need to include language=20 specifying=0A= RG >>>>> the criteria by which a server accepts a=20 certificate as=0A= RG >>>>> providing authorization to access the data.=0A= =20 information to validate the credentials of the requester. While the=0A= =20 creation of a PKI that has global scope may be difficult, the=0A= =20 alternatives to creating devices and services that can provide=0A= =20 critical information securely are more daunting.=0A= =0A= The Call-info=20 header with purpose=3D'emergencyCallData' MUST only be=0A= sent on an=20 emergency call, which can be ascertained by the presence=0A= of an=20 emergency service urn in a Route header of a SIP message.=0A= RG >>>>>=20 This normative text should be moved to earlier in the=20 document,=0A= RG >>>>> where the use of Call-Info is specified. The=20 Security=0A= RG >>>>> Considerations sections should then have text=20 describing the=0A= RG >>>>> consequences of complying or failure to=20 comply, and detection=0A= RG >>>>> and enforcement.=0A= =0A= =0A= RG >>>>> Needs text.=0A= =0A= =0A= RG >>>>> Needs text.=0A= =0A= =0A= RG >>>>> Needs text.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et=20 al. Expires May 3, 2012 [Page=20 25]=0A= =0C=0A= Internet-Draft Additional Call Data=20 October 2011=0A= =0A= =0A= 10. Privacy Considerations=0A= =0A= [Editor's Note: The=20 privacy considerations outlined in=0A= =20 [I-D.iab-privacy-considerations] need to be addressed here in a=0A= =20 future version of this document.=0A= RG >>>>> Needs text.=0A= =0A= There is=20 much private data in this information. Local regulations=0A= may=20 govern what data must be provided in emergency calls, but in=0A= =20 general, the emergency call system is often aided by the kinds of=0A= =20 information described in this document. There is a tradeoff between=0A= =20 the privacy considerations and the utility of the data. Certainly,=0A= =20 if the data cannot be protected, due to failure of the TLS=20 mechanisms=0A= described here, data not required by regulation SHOULD=20 not be sent.=0A= RG=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^=0A= RG=20 ^ data SHOULD NOT be sent unless specifically=0A= RG ^=20 required by regulation=0A= RG=0A= RG >>>>> Need to describe what is meant by=20 "failure of the TLS=20 mechanism"=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 26]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= 11. IANA=20 Considerations=0A= =0A= [Editor's Note: The IANA section is missing the=20 description of new=0A= registries. A future version of this draft=20 will contain the=0A= necessary information.]=0A= RG >>>>> Needs=20 text.=0A= =0A= =0A= 11.1. 'emergencyCallData' Purpose Parameter Value=0A= =0A= This=20 document defines the 'emergencyCallData' value for the "purpose"=0A= =20 parameter of the Call-Info header field. The Call-Info header and=0A= =20 the corresponding registry for the 'purpose' parameter was=0A= =20 established with RFC 3261 [RFC3261].=0A= =0A= =0A= Header Parameter=20 New=0A= Field Name Value Reference=0A= =20 ---------- --------- ----------------- ---------=0A= =20 Call-Info purpose emergencyCallData [This RFC]=0A= =0A= 11.2. URN=20 Sub-Namespace Registration for provided-by Registry Entry=0A= =0A= This=20 section registers the namespace specified in ??? in the=0A= RG >>>>>=20 ^^^=0A= provided-by registry established by RFC 4119.=0A= =0A= 11.3. MIME=20 Registrations=0A= =0A= 11.3.1. MIME Content-type Registration for=20 'application/=0A= addDataProviderInfo+xml'=0A= =0A= This=20 specification requests the registration of a new MIME type=0A= =20 according to the procedures of RFC 4288 [RFC4288] and guidelines in=0A= =20 RFC 3023 [RFC3023].=0A= =0A= MIME media type name: application=0A= =0A= =20 MIME subtype name: addDataProviderInfo+xml=0A= =0A= Mandatory=20 parameters: none=0A= =0A= Optional parameters: charset=0A= =0A= Indicates=20 the character encoding of enclosed XML.=0A= =0A= Encoding=20 considerations:=0A= =0A= Uses XML, which can employ 8-bit characters,=20 depending on the=0A= character encoding used. See Section 3.2 of=20 RFC 3023 [RFC3023].=0A= =0A= =0A= =0A= =0A= Rosen, et al. Expires May 3,=20 2012 [Page 27]=0A= =0C=0A= Internet-Draft Additional=20 Call Data October 2011=0A= =0A= =0A= Security=20 considerations:=0A= =0A= This content type is designed to carry the=20 data provider=0A= information, which is a sub-category of=20 additional data about an=0A= emergency call.=0A= =0A= Since this data=20 contains personal information appropriate=0A= precautions have to=20 be taken to limit unauthorized access,=0A= inappropriate disclosure=20 to third parties, and eavesdropping of=0A= this information.=20 Please refer to Section 9 and Section 10 for=0A= more=20 information.=0A= =0A= Interoperability considerations: None=0A= =0A= =20 Published specification: [TBD: This specification]=0A= =0A= =20 Applications which use this media type: Emergency Services=0A= =0A= =20 Additional information:=0A= =0A= Magic Number: None=0A= =0A= File=20 Extension: .xml=0A= =0A= Macintosh file type code: 'TEXT'=0A= =0A= =0A= =20 Personal and email address for further information: Hannes=0A= RG=20 XX=0A= Tschofenig, Hannes.Tschofenig@gmx.net=0A= =0A= Intended usage:=20 LIMITED USE=0A= =0A= Author: This specification is a work item of the=20 IETF ECRIT=0A= working group, with mailing list address=20 .=0A= =0A= Change controller: The IESG=20 =0A= =0A= 11.3.2. MIME Content-type Registration for=20 'application/=0A= addCallSvcInfo+xml'=0A= =0A= This specification=20 requests the registration of a new MIME type=0A= according to the=20 procedures of RFC 4288 [RFC4288] and guidelines in=0A= RFC 3023=20 [RFC3023].=0A= =0A= MIME media type name: application=0A= =0A= MIME=20 subtype name: addCallSvcInfo+xml=0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 28]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= Mandatory=20 parameters: none=0A= =0A= Optional parameters: charset=0A= =0A= Indicates=20 the character encoding of enclosed XML.=0A= =0A= Encoding=20 considerations:=0A= =0A= Uses XML, which can employ 8-bit characters,=20 depending on the=0A= character encoding used. See Section 3.2 of=20 RFC 3023 [RFC3023].=0A= =0A= Security considerations:=0A= =0A= This=20 content type is designed to carry the service information,=0A= =20 which is a sub-category of additional data about an emergency=0A= =20 call.=0A= =0A= Since this data contains personal information=20 appropriate=0A= precautions have to be taken to limit unauthorized=20 access,=0A= inappropriate disclosure to third parties, and=20 eavesdropping of=0A= this information. Please refer to Section 9=20 and Section 10 for=0A= more information.=0A= =0A= Interoperability=20 considerations: None=0A= =0A= Published specification: [TBD: This=20 specification]=0A= =0A= Applications which use this media type:=20 Emergency Services=0A= =0A= Additional information:=0A= =0A= Magic=20 Number: None=0A= =0A= File Extension: .xml=0A= =0A= Macintosh file type=20 code: 'TEXT'=0A= =0A= =0A= Personal and email address for further=20 information: Hannes=0A= RG XX=0A= Tschofenig,=20 Hannes.Tschofenig@gmx.net=0A= =0A= Intended usage: LIMITED USE=0A= =0A= =20 Author: This specification is a work item of the IETF ECRIT=0A= =20 working group, with mailing list address .=0A= =0A= =20 Change controller: The IESG =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 29]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= 11.3.3. MIME=20 Content-type Registration for 'application/=0A= =20 addDataDevInfo+xml'=0A= =0A= This specification requests the registration=20 of a new MIME type=0A= according to the procedures of RFC 4288=20 [RFC4288] and guidelines in=0A= RFC 3023 [RFC3023].=0A= =0A= MIME media=20 type name: application=0A= =0A= MIME subtype name: addDataDevInfo+xml=0A= =0A= =20 Mandatory parameters: none=0A= =0A= Optional parameters: charset=0A= =0A= =20 Indicates the character encoding of enclosed XML.=0A= =0A= Encoding=20 considerations:=0A= =0A= Uses XML, which can employ 8-bit characters,=20 depending on the=0A= character encoding used. See Section 3.2 of=20 RFC 3023 [RFC3023].=0A= =0A= Security considerations:=0A= =0A= This=20 content type is designed to carry the device information=0A= =20 information, which is a sub-category of additional data about an=0A= =20 emergency call.=0A= =0A= Since this data contains personal information=20 appropriate=0A= precautions have to be taken to limit unauthorized=20 access,=0A= inappropriate disclosure to third parties, and=20 eavesdropping of=0A= this information. Please refer to Section 9=20 and Section 10 for=0A= more information.=0A= =0A= Interoperability=20 considerations: None=0A= =0A= Published specification: [TBD: This=20 specification]=0A= =0A= Applications which use this media type:=20 Emergency Services=0A= =0A= Additional information:=0A= =0A= Magic=20 Number: None=0A= =0A= File Extension: .xml=0A= =0A= Macintosh file type=20 code: 'TEXT'=0A= =0A= =0A= =0A= =0A= Rosen, et al. Expires May 3, 2012=20 [Page 30]=0A= =0C=0A= Internet-Draft Additional Call Data=20 October 2011=0A= =0A= =0A= Personal and email address for further=20 information: Hannes=0A= RG XX=0A= Tschofenig,=20 Hannes.Tschofenig@gmx.net=0A= =0A= Intended usage: LIMITED USE=0A= =0A= =20 Author: This specification is a work item of the IETF ECRIT=0A= =20 working group, with mailing list address .=0A= =0A= =20 Change controller: The IESG =0A= =0A= 11.3.4. MIME=20 Content-type Registration for 'application/addCallSub+xml'=0A= =0A= This=20 specification requests the registration of a new MIME type=0A= =20 according to the procedures of RFC 4288 [RFC4288] and guidelines in=0A= =20 RFC 3023 [RFC3023].=0A= =0A= MIME media type name: application=0A= =0A= =20 MIME subtype name: addCallSub+xml=0A= =0A= Mandatory parameters: none=0A= =0A= =20 Optional parameters: charset=0A= =0A= Indicates the character encoding=20 of enclosed XML.=0A= =0A= Encoding considerations:=0A= =0A= Uses XML,=20 which can employ 8-bit characters, depending on the=0A= character=20 encoding used. See Section 3.2 of RFC 3023 [RFC3023].=0A= =0A= =20 Security considerations:=0A= =0A= This content type is designed to=20 carry owner/subscriber=0A= information, which is a sub-category of=20 additional data about an=0A= emergency call.=0A= =0A= Since this data=20 contains personal information appropriate=0A= precautions have to=20 be taken to limit unauthorized access,=0A= inappropriate disclosure=20 to third parties, and eavesdropping of=0A= this information.=20 Please refer to Section 9 and Section 10 for=0A= more=20 information.=0A= =0A= Interoperability considerations: None=0A= =0A= =20 Published specification: [TBD: This specification]=0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 31]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= Applications=20 which use this media type: Emergency Services=0A= =0A= Additional=20 information:=0A= =0A= Magic Number: None=0A= =0A= File Extension: .xml=0A= =0A= =20 Macintosh file type code: 'TEXT'=0A= =0A= =0A= Personal and email address=20 for further information: Hannes=0A= RG XX=0A= Tschofenig,=20 Hannes.Tschofenig@gmx.net=0A= =0A= Intended usage: LIMITED USE=0A= =0A= =20 Author: This specification is a work item of the IETF ECRIT=0A= =20 working group, with mailing list address .=0A= =0A= =20 Change controller: The IESG =0A= =0A= 11.4. URN Sub-Namespace=20 Registration=0A= =0A= 11.4.1. Registration for=20 urn:ietf:params:xml:ns:addDataProviderInfo=0A= =0A= This section registers=20 a new XML namespace, as per the guidelines in=0A= RFC 3688=20 [RFC3688].=0A= =0A= URI: urn:ietf:params:xml:ns:addDataProviderInfo=0A= =0A= =20 Registrant Contact: IETF, ECRIT working group, , as=0A= =20 delegated by the IESG .=0A= =0A= =20 XML:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al. Expires May 3, 2012=20 [Page 32]=0A= =0C=0A= Internet-Draft Additional Call Data=20 October 2011=0A= =0A= =0A= BEGIN=0A= =0A= =0A= =0A= =0A= =0A= Namespace for=20 Additional Emergency Call Data:=0A= Data Provider=20 Information=0A= =0A= =0A=

Namespace for=20 Additional Data related to an Emergency Call

=0A=

Data=20 Provider Information

=0A=

See [TBD: This document].

=0A= =20 =0A= =0A= END=0A= =0A= =0A= 11.4.2. Registration for=20 urn:ietf:params:xml:ns:addCallSvcInfo=0A= =0A= This section registers a=20 new XML namespace, as per the guidelines in=0A= RFC 3688 [RFC3688].=0A= =0A= =20 URI: urn:ietf:params:xml:ns:addCallSvcInfo=0A= =0A= Registrant Contact:=20 IETF, ECRIT working group, , as=0A= delegated by=20 the IESG .=0A= =0A= XML:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 33]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= BEGIN=0A= =0A= =0A= =20 =0A= =0A= =0A= Namespace for=20 Additional Emergency Call Data:=0A= Service=20 Information=0A= =0A= =0A=

Namespace for=20 Additional Data related to an Emergency Call

=0A=

Service=20 Information

=0A=

See [TBD: This document].

=0A= =0A= =20 =0A= END=0A= =0A= =0A= 11.4.3. Registration for=20 urn:ietf:params:xml:ns:addDataDevInfo=0A= =0A= This section registers a=20 new XML namespace, as per the guidelines in=0A= RFC 3688 [RFC3688].=0A= =0A= =20 URI: urn:ietf:params:xml:ns:addDataDevInfo=0A= =0A= Registrant Contact:=20 IETF, ECRIT working group, , as=0A= delegated by=20 the IESG .=0A= =0A= XML:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 34]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= BEGIN=0A= =0A= =0A= =20 =0A= =0A= =0A= Namespace for=20 Additional Emergency Call Data:=0A= Device=20 Information=0A= =0A= =0A=

Namespace for=20 Additional Data related to an Emergency Call

=0A=

Device=20 Information

=0A=

See [TBD: This document].

=0A= =0A= =20 =0A= END=0A= =0A= =0A= 11.4.4. Registration for=20 urn:ietf:params:xml:ns:addCallSub=0A= =0A= This section registers a new=20 XML namespace, as per the guidelines in=0A= RFC 3688 [RFC3688].=0A= =0A= =20 URI: urn:ietf:params:xml:ns:addCallSub=0A= =0A= Registrant Contact:=20 IETF, ECRIT working group, , as=0A= delegated by=20 the IESG .=0A= =0A= XML:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 35]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= BEGIN=0A= =0A= =0A= =20 =0A= =0A= =0A= Namespace for=20 Additional Emergency Call Data:=0A= Owner/Subscriber=20 Information=0A= =0A= =0A=

Namespace for=20 Additional Data related to an Emergency Call

=0A=

=20 Owner/Subscriber Information

=0A=

See [TBD: This=20 document].

=0A= =0A= =0A= END=0A= =0A= =0A= 11.5. Schema=20 Registrations=0A= =0A= This specification registers four schemas, as per=20 the guidelines in=0A= RFC 3688 [RFC3688].=0A= =0A= URI:=0A= =20 urn:ietf:params:xml:schema:additional-data:addDataProviderInfo=0A= =0A= =20 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as=0A= =20 delegated by the IESG (iesg@ietf.org).=0A= =0A= XML: The XML schema can=20 be found in Figure 1.=0A= =0A= URI:=20 urn:ietf:params:xml:schema:additional-data:addCallSvcInfo=0A= =0A= =20 Registrant Contact: IETF, ECRIT Working Group (ectit@ietf.org), as=0A= =20 delegated by the IESG (iesg@ietf.org).=0A= =0A= XML: The XML schema can=20 be found in Figure 2.=0A= =0A= URI:=20 urn:ietf:params:xml:schema:additional-data:addDataDevInfo=0A= =0A= =20 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as=0A= =20 delegated by the IESG (iesg@ietf.org).=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 36]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= XML: The XML=20 schema can be found in Figure 3.=0A= =0A= URI:=20 urn:ietf:params:xml:schema:additional-data:addCallSub=0A= =0A= =20 Registrant Contact: IETF, ECRIT Working Group (ecrit@ietf.org), as=0A= =20 delegated by the IESG (iesg@ietf.org).=0A= =0A= XML: The XML schema can=20 be found in Figure=20 4.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 37]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= 12.=20 Acknowledgments=0A= =0A= The authors would like to thank the following=20 persons for their work=0A= in the NENA Data Technical Committee:=20 Delaine Arnold (Data Technical=0A= Committee Chair), Marc Berryman,=20 Erica Aubut (Data Technical=0A= Committee Vice-Chair), Susan Sherwood,=20 Ric Atkins, Patty Bluhm,=0A= Eileen Boroski, David Connel, Maryls=20 Davis, Paul-David de la Rosby,=0A= Gordon Chinander, David=20 Froneberger, Marilyn Haroutunian, Roger=0A= Hixson, Rick Jones, Roger=20 Marshall, Tom Muehleisen, Ira Pyles, Carl=0A= Reed, Susan Seet, and=20 Skip Walls. The authors would also like to=0A= thank Tom Breen,=20 Technical Committee Chair/Liaison; Busam, Technical=0A= Committee=20 Vice-Chair/Liaison; Pete Eggimann, Operations Committee=0A= =20 Chair/Liaison; Wendy Lively, Operations Committee Chair/Liaison;=0A= =20 Roger Hixson, Technical Director; and Rick Jones, Operations Issues=0A= =20 Director for their support and assistance.=0A= =0A= [Editor's Note: Add=20 the participants of the NENA Additional Data=0A= Working group lead by=20 Matt Serra.]=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 38]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= 13.=20 References=0A= =0A= 13.1. Normative References=0A= =0A= [RFC2119] Bradner, S.,=20 "Key words for use in RFCs to Indicate=0A= Requirement=20 Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC2392] Levinson, E.,=20 "Content-ID and Message-ID Uniform Resource=0A= Locators",=20 RFC 2392, August 1998.=0A= =0A= [RFC3023] Murata, M., St. Laurent, S.,=20 and D. Kohn, "XML Media=0A= Types", RFC 3023, January=20 2001.=0A= =0A= [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,=20 Johnston,=0A= A., Peterson, J., Sparks, R., Handley, M.,=20 and E.=0A= Schooler, "SIP: Session Initiation Protocol",=20 RFC 3261,=0A= June 2002.=0A= =0A= [RFC3688] Mealling, M., "The=20 IETF XML Registry", BCP 81, RFC 3688,=0A= January 2004.=0A= =0A= =20 [RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object=0A= =20 Format", RFC 4119, December 2005.=0A= =0A= [RFC4288] Freed, N. and J.=20 Klensin, "Media Type Specifications and=0A= Registration=20 Procedures", BCP 13, RFC 4288, December 2005.=0A= =0A= [RFC6351]=20 Perreault, S., "xCard: vCard XML Representation",=0A= RFC=20 6351, August 2011.=0A= =0A= 13.2. Informational References=0A= =0A= =20 [I-D.iab-privacy-considerations]=0A= Cooper, A.,=20 Tschofenig, H., Aboba, B., Peterson, J., and=0A= J. Morris,=20 "Privacy Considerations for Internet=0A= Protocols",=20 draft-iab-privacy-considerations-01 (work in=0A= progress),=20 October 2011.=0A= =0A= [I-D.ietf-ecrit-framework]=0A= Rosen, B.,=20 Schulzrinne, H., Polk, J., and A. Newton,=0A= "Framework=20 for Emergency Calling using Internet=0A= Multimedia",=20 draft-ietf-ecrit-framework-13 (work in=0A= progress),=20 September 2011.=0A= =0A= [I-D.ietf-ecrit-phonebcp]=0A= Rosen, B.=20 and J. Polk, "Best Current Practice for=0A= Communications=20 Services in support of Emergency Calling",=0A= =20 draft-ietf-ecrit-phonebcp-20 (work in progress),=0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 39]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= =20 September=20 2011.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 40]=0A= =0C=0A= Internet-Draft=20 Additional Call Data October 2011=0A= =0A= =0A= Authors' Addresses=0A= =0A= =20 Brian Rosen=0A= NeuStar=0A= 470 Conrad Dr.=0A= Mars, PA 16046=0A= US=0A= =0A= =20 Phone: +1 724 382 1051=0A= Email: br@brianrosen.net=0A= =0A= =0A= Hannes=20 Tschofenig=0A= Nokia Siemens Networks=0A= Linnoitustie 6=0A= Espoo=20 02600=0A= Finland=0A= =0A= Phone: +358 (50) 4871445=0A= Email:=20 Hannes.Tschofenig@gmx.net=0A= URI: http://www.tschofenig.priv.at=0A= =0A= =0A= =20 Roger Marshall=0A= TeleCommunication Systems, Inc.=0A= 2401 Elliott=20 Avenue=0A= Seattle, WA 98121=0A= US=0A= =0A= Phone: +1 206 792 2424=0A= =20 Email: rmarshall@telecomsys.com=0A= URI:=20 http://www.telecomsys.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Rosen, et al.=20 Expires May 3, 2012 [Page 41]=0A= =0C=0A= --============_-890293485==_============-- From rbarnes@bbn.com Mon Nov 21 06:09:18 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1DE021F8B3B for ; Mon, 21 Nov 2011 06:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.576 X-Spam-Level: X-Spam-Status: No, score=-106.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6YM5uNqoK5x for ; Mon, 21 Nov 2011 06:09:18 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id E772821F8B38 for ; Mon, 21 Nov 2011 06:09:17 -0800 (PST) Received: from [128.89.255.91] (port=59607) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RSUYe-0004Mb-Is; Mon, 21 Nov 2011 09:09:16 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Richard Barnes In-Reply-To: <58EF06B3-2C98-4FD6-91F0-A9A15820A909@gmx.net> Date: Mon, 21 Nov 2011 09:08:44 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <58EF06B3-2C98-4FD6-91F0-A9A15820A909@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.1251.1) Cc: ECRIT Org Subject: Re: [Ecrit] draft-ietf-ecrit-unauthenticated-access-03 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 14:09:18 -0000 > 1) No Access Authentication (NAA) >=20 > I suggested to address the fraud problem that results from a host that = attaches to a network using some special link layer authentication = procedure without actually having credentials for that specific network = by not routing the emergency calls via the VSP but instead contacting = the PSAP directly.=20 >=20 > =46rom the feedback during the meeting I believe folks are fine with = that approach but are looking forward to see the details.=20 This approach actually makes me nervous. As others have pointed out in = several contexts, code paths that only get exercised in emergencies tend = to be less reliable than the normal code paths. So we might RECOMMEND = that the calling device go directly to the PSAP, we should allow that it = MAY use a VSP. The fraud risks are probably not that daunting. As with the = trustworthy-location / PSAP protection cases, there are several "softer" = mitigations that can be applied here. For example, you could limit the = type and number of flows per endpoint to something that looks like VoIP, = e.g., allowing a single SIP or TLS session and some number of RTP/SRTP = flows. This may start to sound like DPI, but really you can do it = mostly at the TCP/IP layer. > 2) Deployment Reality >=20 > Bernard and Martin had some comments about the current deployment = limitations of many access networks. For example, many hotspots require = user interactions prior to get network access granted. There is not = really anything we can do about it other than mentioning the challenges = in a limitation section. I suggested to introduce such a section.=20 The general question is how endpoints determine which state they're in = -- namely, do they have a real Internet connection or not. There are = actually some deployed solutions to this today. If you look at Mac OS X = Lion or recent versions of iOS, they do a test HTTP query to an Apple = server and see if they get the right response back. I understand that = Blackberry devices do something similar. =20 It might be worthwhile to write an RFC standardizing a mechanism for = this, to make the whole system more predictable in general (not just in = emergency cases). I've been meaning to bring this up in APPSAWG, but = haven't gotten around to it. =20 > 3) Lack of authorization to perform network access >=20 > The document currently considers the Zero-Balance ASP where an = emergency caller is not authorized to make the emergency call. This lack = of authorization is visible at the application layer. Bernard suggested = to add a discussion about lack of authorization at the network layer as = well.=20 > I am OK with adding such text.=20 The more I think about it, the more absurd this case seems. ASPs should = allow emergency calls. Rather than requiring special handling on the = client side, we should provide guidance to ASPs on how to determine = whether a call is an emergency call, using LoST. =20 (Someone should build a service that builds a global list of PSAP/ESRP = URIs from LoST and distributes it to interested parties. You could even = do something clever like make it a Bloom filter.) --Richard= From hgs@cs.columbia.edu Mon Nov 21 06:34:00 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CFB21F8AD9 for ; Mon, 21 Nov 2011 06:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG4GpIgTzfvG for ; Mon, 21 Nov 2011 06:34:00 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id E93EC21F8ABD for ; Mon, 21 Nov 2011 06:33:59 -0800 (PST) Received: from dhcp-13-72.cs.columbia.edu (dhcp-13-72.cs.columbia.edu [128.59.13.72]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pALEXoI1028262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 21 Nov 2011 09:33:50 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Mon, 21 Nov 2011 09:33:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <209B5BA6-9569-4FC2-9771-D1B367CA54A9@cs.columbia.edu> References: <58EF06B3-2C98-4FD6-91F0-A9A15820A909@gmx.net> To: Richard Barnes X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: ECRIT Org Subject: Re: [Ecrit] draft-ietf-ecrit-unauthenticated-access-03 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 14:34:00 -0000 Some comments inline. On Nov 21, 2011, at 9:08 AM, Richard Barnes wrote: >> 1) No Access Authentication (NAA) >>=20 >> I suggested to address the fraud problem that results from a host = that attaches to a network using some special link layer authentication = procedure without actually having credentials for that specific network = by not routing the emergency calls via the VSP but instead contacting = the PSAP directly.=20 >>=20 >> =46rom the feedback during the meeting I believe folks are fine with = that approach but are looking forward to see the details.=20 >=20 > This approach actually makes me nervous. As others have pointed out = in several contexts, code paths that only get exercised in emergencies = tend to be less reliable than the normal code paths. So we might = RECOMMEND that the calling device go directly to the PSAP, we should = allow that it MAY use a VSP. Agreed. This may also be difficult to do due to the architecture of = ESInets (hierarchical LoST routing, policy filters at the edge of the = ESInet, etc.) >=20 > The fraud risks are probably not that daunting. As with the = trustworthy-location / PSAP protection cases, there are several "softer" = mitigations that can be applied here. For example, you could limit the = type and number of flows per endpoint to something that looks like VoIP, = e.g., allowing a single SIP or TLS session and some number of RTP/SRTP = flows. This may start to sound like DPI, but really you can do it = mostly at the TCP/IP layer. I suspect the fraud concern would be "free phone calls". It seems hard = to distinguish an emergency voice call from a regular phone call. One could restrict such calls by bandwidth or duration, but that comes = with its own set of issues. (Realistically, few people are going to = shell out $10 to make a five-minute phone call via WiFi, so the lost = revenue seems small. Counterargument would be the per-minute access = offered by Skype.) For large operators, you could imagine a more sophisticated solution = that allows the operator to check whether an unauthenticated access call = is indeed an emergency call by querying a database (e.g., by IP = address). Such calls are presumably going to be pretty rare. It is not = clear whether such a mechanism is worth the deployment, operational and = false-negative cost. >=20 >=20 >> 2) Deployment Reality >>=20 >> Bernard and Martin had some comments about the current deployment = limitations of many access networks. For example, many hotspots require = user interactions prior to get network access granted. There is not = really anything we can do about it other than mentioning the challenges = in a limitation section. I suggested to introduce such a section.=20 >=20 > The general question is how endpoints determine which state they're in = -- namely, do they have a real Internet connection or not. There are = actually some deployed solutions to this today. If you look at Mac OS X = Lion or recent versions of iOS, they do a test HTTP query to an Apple = server and see if they get the right response back. I understand that = Blackberry devices do something similar. =20 >=20 > It might be worthwhile to write an RFC standardizing a mechanism for = this, to make the whole system more predictable in general (not just in = emergency cases). I've been meaning to bring this up in APPSAWG, but = haven't gotten around to it. =20 As I mentioned earlier, the HotSpot 2.0 initiative tackles this problem, = as far as I can tell. It also tries to avoid splash screens, to deal = with mobile devices and seamless handoff. >=20 >=20 >> 3) Lack of authorization to perform network access >>=20 >> The document currently considers the Zero-Balance ASP where an = emergency caller is not authorized to make the emergency call. This lack = of authorization is visible at the application layer. Bernard suggested = to add a discussion about lack of authorization at the network layer as = well.=20 >> I am OK with adding such text.=20 >=20 > The more I think about it, the more absurd this case seems. ASPs = should allow emergency calls. Rather than requiring special handling on = the client side, we should provide guidance to ASPs on how to determine = whether a call is an emergency call, using LoST. =20 >=20 > (Someone should build a service that builds a global list of PSAP/ESRP = URIs from LoST and distributes it to interested parties. You could even = do something clever like make it a Bloom filter.) It might help if we divide the problem into three cases: (1) Large, national operators, such as Boingo. They can offer a LoST = server and outbound SIP proxy that's keyed to the LoST server URLs. They = already maintain white lists of URLs for unpaid access, so this does not = seem that hard. (2) Local paid WiFi, such as in hotels. Somewhat problematic. May need = some kind of access duration/speed restriction. (3) Free WiFi with disclaimer screens (Starbucks, Panera, etc.). Fraud = is not a major concern. Henning From rbarnes@bbn.com Mon Nov 21 06:42:24 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF9211E8096 for ; Mon, 21 Nov 2011 06:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHZ9f4BL3UAN for ; Mon, 21 Nov 2011 06:42:23 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id DA1D621F8B42 for ; Mon, 21 Nov 2011 06:42:23 -0800 (PST) Received: from ros-dhcp192-1-51-60.bbn.com ([192.1.51.60]:52667) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RSV4a-000509-Gf; Mon, 21 Nov 2011 09:42:16 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <209B5BA6-9569-4FC2-9771-D1B367CA54A9@cs.columbia.edu> Date: Mon, 21 Nov 2011 09:42:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <12820CD8-135E-42E5-B37F-FC597F84A47C@bbn.com> References: <58EF06B3-2C98-4FD6-91F0-A9A15820A909@gmx.net> <209B5BA6-9569-4FC2-9771-D1B367CA54A9@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1084) Cc: ECRIT Org Subject: Re: [Ecrit] draft-ietf-ecrit-unauthenticated-access-03 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2011 14:42:24 -0000 >> The fraud risks are probably not that daunting. As with the = trustworthy-location / PSAP protection cases, there are several "softer" = mitigations that can be applied here. For example, you could limit the = type and number of flows per endpoint to something that looks like VoIP, = e.g., allowing a single SIP or TLS session and some number of RTP/SRTP = flows. This may start to sound like DPI, but really you can do it = mostly at the TCP/IP layer. >=20 > I suspect the fraud concern would be "free phone calls". It seems hard = to distinguish an emergency voice call from a regular phone call. True. But at least this limits things to phone calls, as opposed to, = say, Netflix or YouTube. At least until someone sets up a = Netflix-to-SIP gateway. >>> Bernard and Martin had some comments about the current deployment = limitations of many access networks. For example, many hotspots require = user interactions prior to get network access granted. There is not = really anything we can do about it other than mentioning the challenges = in a limitation section. I suggested to introduce such a section.=20 >>=20 >> The general question is how endpoints determine which state they're = in -- namely, do they have a real Internet connection or not. There are = actually some deployed solutions to this today. If you look at Mac OS X = Lion or recent versions of iOS, they do a test HTTP query to an Apple = server and see if they get the right response back. I understand that = Blackberry devices do something similar. =20 >>=20 >> It might be worthwhile to write an RFC standardizing a mechanism for = this, to make the whole system more predictable in general (not just in = emergency cases). I've been meaning to bring this up in APPSAWG, but = haven't gotten around to it. =20 >=20 > As I mentioned earlier, the HotSpot 2.0 initiative tackles this = problem, as far as I can tell. It also tries to avoid splash screens, to = deal with mobile devices and seamless handoff. HotSpot 2.0 solves the problem for WiFi. I have run into similar = systems on other types of network, including both Ethernet and WiMAX. = So it might be useful to solve this at the Internet level, even if only = by reference to the HS2.0 solution. --Richard= From christer.holmberg@ericsson.com Thu Nov 24 02:51:06 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDEC21F8B6D for ; Thu, 24 Nov 2011 02:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tiNv8yAEvtNP for ; Thu, 24 Nov 2011 02:51:05 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 417C521F8B62 for ; Thu, 24 Nov 2011 02:51:05 -0800 (PST) X-AuditID: c1b4fb3d-b7b5fae00000219a-94-4ece2197cd19 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 68.2C.08602.7912ECE4; Thu, 24 Nov 2011 11:51:03 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 24 Nov 2011 11:51:03 +0100 From: Christer Holmberg To: ECRIT Date: Thu, 24 Nov 2011 11:51:01 +0100 Thread-Topic: PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AcyqlvT4iePunOjGSp6s9bWNjomV3w== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852C3A81564FESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: 'Adam Roach' , Paul Kyzivat Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 10:51:06 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3A81564FESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In Taipei, it was indicated that people would prefer another mechanism than= a new GRUU type for solving the issue of identifying PSAP callback calls. A new Resource-Priority header field value, that PSAPs would insert in call= back calls, was suggested. It would solve the requirement of allowing netwo= rk entities (and the UA) to identity the callback call, e.g. in order to gi= ve special treatment. (The requirement to reach the same UA device that made the emergency call c= an be solved with the existing GRUU mechanism, so nothing new is needed the= re). So, I would like to know whether people are ok with a Resource-Priority app= roach? Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852C3A81564FESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
In Taipei, it was indicated that people would prefer = another mechanism than a new GRUU type for solving the issue of identifying= PSAP callback calls.
 
A new Resource-Priority header field value, that PSAP= s would insert in callback calls, was suggested. It would solve the require= ment of allowing network entities (and the UA) to identity the callback cal= l, e.g. in order to give special treatment.
 
(The requirement to reach the same UA device that mad= e the emergency call can be solved with the existing GRUU mechanism, so not= hing new is needed there).
 
So, I would like to know whether people are ok with a= Resource-Priority approach?
 
Regards,
 
Christer
 
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3A81564FESESSCMS0356e_-- From christer.holmberg@ericsson.com Thu Nov 24 02:54:22 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D516621F8AD6 for ; Thu, 24 Nov 2011 02:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zU28WELcdhHv for ; Thu, 24 Nov 2011 02:54:21 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id F292D21F8BB1 for ; Thu, 24 Nov 2011 02:54:20 -0800 (PST) X-AuditID: c1b4fb3d-b7b5fae00000219a-a4-4ece225b25fd Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5D.AC.08602.B522ECE4; Thu, 24 Nov 2011 11:54:20 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 24 Nov 2011 11:54:19 +0100 From: Christer Holmberg To: ECRIT , Paul Kyzivat Date: Thu, 24 Nov 2011 11:54:18 +0100 Thread-Topic: RE: [Ecrit] draft-holmberg-ecrit-emergency-callback-id Thread-Index: Acyql2pZ8g6gZFsaSkO8tiFhuo6YIg== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A815656@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852C3A815656ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [Ecrit] draft-holmberg-ecrit-emergency-callback-id X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 10:54:22 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3A815656ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, My take from the ECRIT session was that we don't want to move forward with = the gruu approach, but rather use something else (e.g. a new RPH value), so= I don't know how much time we should spend on discussing the gruu. But, I'll try address also the gruu related questions anyway :) ----------------- > After the meeting this morning I read the document. Here are a bunch of c= omments to start some discussion. > > Section 4: > > - An eGRUU MUST be constructed following the same principles and > rules that apply for constructing a public GRUU. > > Section 6.2 > > If the Call-ID changes in a register refresh, the server will > invalidate all eGRUUs associated with that UA instance; the only > valid one will be the new one returned in that REGISTER response. > > This language is analogous to that for temp gruus, not permanent gruus. > Yet the stated intent is that the egruu be like a public gruu. The text used to say that an eGRUU is constructed following the same princi= ples and rules that apply for constructioning a temporary GRUU, so I guess = that text is something that by misstake was left unchanged. ------------------------------------ > Section 6.4: > > A UA MUST NOT construct a self-made eGRUU. > > There may be a reason for this in IMS, but I see no general reason for th= is. > > A UA that assigns a gruu for itself to use in emergency calls can then > recognize emergency callbacks and process them in a special way. Yes, the UA can do that, but network entities may not be able to. ------------------------------------ > The requirement for a registrar assigned egruu seems to be predicated > on emergency services provided by the registrar, or proxies and > application servers in the routing path from the home proxy. The > presence of such things, and how they work, is environment dependent. Yes. The idea is not to specify WHAT the networks do, simply to be able to = identify callback calls, IF they need to do something. ------------------------------------ > Section 6.6 > > NOTE: If the Contact header field of an initial SIP INVITE request > for an emergency call did not contain a "psabcb" parameter, a UA, > representing a PSAP, can insert the "psapcb" parameter in the > Request-URI of the initial SIP INVITE request for an PSAP callback > call. > > This is dubious. Modifying a URI you received is in general a bad idea. That was indicated as an open issue in my presentation. ------------------------------------ > If a UA does not represent a PSAP, making a PSAP callback call, it > MUST NOT insert an eGRUU and a "psapcb" parameter in the Request-URI > of the intial SIP INVITE request for the call. > > This makes little sense, and its not enforceable because UAs that > don't implement this spec need not comply with it. In general, a UA > that wants to send an out of dialog request to some UA it has a dialog > with will simply use the remote Contact URI. True. I guess the key is that a UA that does understand the spec must not insert = the parameter in the Contact header field for any other calls than emergenc= y calls. ------------------------------------ > Then finally, I can find *no* explanation of what happens differently > for a request containing the psapcb parameter, vs. one that does not. > This is apparently very important, but totally opaque. > > Also, when the callback is generated with the egruu and its psapcb > parameter, the UA does not get the parameter, except possibly via H-I. > So its difficult for it to give special treatment for the callback call. > Is there an assumption that it will use H-I for this? That is something that was brought up at some point. So, if there is a need for entities beyond the registrar (that will re-writ= e the R-URI, and hence remove the "psapcb" parameter) to be informed about the ca= llback call, we would either need H-I, or something else. ------------------------------------ > I also reviewed draft-ietf-ecrit-psap-callback-03 and didn't find any > further enlightenment over this. > > ISTM that there are several requirements: > > - the callback should be addressed to the UA that initiated the > emergency call, not to the AOR of that UA. Existing GRUU technology > (either permanent, temporary, or self assigned satisfy this.) Correct. ------------------------------------ > - the signaling network that routes the callback should avoid special > treatments to callback calls that prevent the callback from reaching the > intended UA. This requires that it be possible to identify callback calls= . I think the text is a little missleading, when it talks about AVOID special= treatment. The idea is that a call that is identified as a callback call CAN be given = special treatment. Also, it is not only about preventing the UA from not getting the call (whi= ch could happen e.g. in call forwarding cases), but in general not to apply= services to callback calls (such as possibility to put the call on hold) So, something like: "should avoid applying services to the callback call, which in some cases m= ight prevent the call from reaching the UA" ------------------------------------ > - the UA should give special priority to callback calls. For instance, > drop other calls in order to take this one. This requires that it be > possible to identify callback calls. Correct. ------------------------------------ > - callback calls should be restricted to a limited set of callers, and > no others. The allowed set is not well defined, but includes the > recipient of the precipitating emergency call, plus some "friends". The > reason for this is to prevent others from getting the special treatment. > Defining this set is hard. Enforcing this limitation is also hard. I'm not sure about the background to this requirement, so I'll let others c= omment. The 3GPP requirement is that only the one who made the emergency call will = get the callback call. Of course, a PSAP can also call other users, but those calls are not seen o= r treated as callback calls. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852C3A815656ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi Paul,
 
My take from the ECRI= T session was that we don't want to move forward with the gruu approach, bu= t rather use something else (e.g. a new RPH value), so I don't know how muc= h time we should spend on discussing the gruu.
 
But, I'll try address= also the gruu related questions anyway :)
 
 
-----------------
 
 
> After the meetin= g this morning I read the document. Here are a bunch of comments to start s= ome discussion.
>
> Section 4:
>
>   = ; - An eGRUU MUST be constructed following the same principles and
>   = ; rules that apply for constructing a public GRUU.
>
> Section 6.2
>
>   = ; If the Call-ID changes in a register refresh, the server will
>   = ; invalidate all eGRUUs associated with that UA instance; the only
>   vali= d one will be the new one returned in that REGISTER response.
>
> This language is= analogous to that for temp gruus, not permanent gruus.
> Yet the stated i= ntent is that the egruu be like a public gruu.
 
The text used to say = that an eGRUU is constructed following the same principles and rules that a= pply for constructioning a temporary GRUU, so I guess that text is somethin= g that by misstake was left unchanged.
 
 
---------------------= ---------------
 
 
> Section 6.4:
>
>   = ; A UA MUST NOT construct a self-made eGRUU.
>
> There may be a r= eason for this in IMS, but I see no general reason for this.
>
> A UA that assign= s a gruu for itself to use in emergency calls can then
> recognize emerge= ncy callbacks and process them in a special way.
 
Yes, the UA can do th= at, but network entities may not be able to.
 
 
---------------------= ---------------
 
 
> The requirement = for a registrar assigned egruu seems to be predicated
> on emergency ser= vices provided by the registrar, or proxies and
> application serv= ers in the routing path from the home proxy. The
> presence of such= things, and how they work, is environment dependent.
 
Yes. The idea is not = to specify WHAT the networks do, simply to be able to identify callback cal= ls, IF they need to do something.
 
 
---------------------= ---------------
 
 
> Section 6.6
>
>   = ; NOTE: If the Contact header field of an initial SIP INVITE request=
>   = ; for an emergency call did not contain a "psabcb" parameter, a U= A,
>   = ; representing a PSAP, can insert the "psapcb" parameter in the
>   = ; Request-URI of the initial SIP INVITE request for an PSAP callback=
>   = ; call.
>
> This is dubious.= Modifying a URI you received is in general a bad idea.
 
That was indicated as= an open issue in my presentation.
 
 
---------------------= ---------------
 
 
>   = ; If a UA does not represent a PSAP, making a PSAP callback call, it=
>   = ; MUST NOT insert an eGRUU and a "psapcb" parameter in the Reques= t-URI
>   = ; of the intial SIP INVITE request for the call.
>
> This makes littl= e sense, and its not enforceable because UAs that
> don't implement = this spec need not comply with it. In general, a UA
> that wants to se= nd an out of dialog request to some UA it has a dialog
> with will simply= use the remote Contact URI.
 
True.
 
I guess the key is th= at a UA that does understand the spec must not insert the parameter in the = Contact header field for any other calls than emergency calls.
 
 
---------------------= ---------------
 
 
> Then finally, I = can find *no* explanation of what happens differently
> for a request co= ntaining the psapcb parameter, vs. one that does not.
> This is apparent= ly very important, but totally opaque.
>
> Also, when the c= allback is generated with the egruu and its psapcb
> parameter, the U= A does not get the parameter, except possibly via H-I.
> So its difficult= for it to give special treatment for the callback call.
> Is there an assu= mption that it will use H-I for this?
 
That is something tha= t was brought up at some point.
 
So, if there is a nee= d for entities beyond the registrar (that will re-write the
R-URI, and hence remo= ve the "psapcb" parameter) to be informed about the callback call= ,
we would either need = H-I, or something else.
 
 
---------------------= ---------------
 
 
> I also reviewed = draft-ietf-ecrit-psap-callback-03 and didn't find any
> further enlighte= nment over this.
>
> ISTM that there = are several requirements:
>
> - the callback s= hould be addressed to the UA that initiated the
> emergency call, = not to the AOR of that UA. Existing GRUU technology
> (either permanen= t, temporary, or self assigned satisfy this.)
 
Correct.
 
 
---------------------= ---------------
 
 
> - the signaling = network that routes the callback should avoid special
> treatments to ca= llback calls that prevent the callback from reaching the
> intended UA. Thi= s requires that it be possible to identify callback calls.
 
I think the text is a= little missleading, when it talks about AVOID special treatment.
The idea is that a ca= ll that is identified as a callback call CAN be given special treatment.
 
Also, it is not only = about preventing the UA from not getting the call (which could happen e.g. = in call forwarding cases), but in general not to apply services to callback= calls (such as possibility to put the call on hold)
 
So, something like:
 
"should avoid ap= plying services to the callback call, which in some cases might prevent the= call from reaching the UA"
 
 
---------------------= ---------------
 
 
> - the UA should = give special priority to callback calls. For instance,
> drop other calls= in order to take this one. This requires that it be
> possible to iden= tify callback calls.
 
Correct.
 
 
---------------------= ---------------
 
 
> - callback calls= should be restricted to a limited set of callers, and
> no others. The a= llowed set is not well defined, but includes the
> recipient of the= precipitating emergency call, plus some "friends". The
> reason for this = is to prevent others from getting the special treatment.
> Defining this se= t is hard. Enforcing this limitation is also hard.
 
I'm not sure about th= e background to this requirement, so I'll let others comment.
 
The 3GPP requirement = is that only the one who made the emergency call will get the callback call= .
 
Of course, a PSAP can= also call other users, but those calls are not seen or treated as callback= calls.
 
Regards,
 
Christer
 
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3A815656ESESSCMS0356e_-- From hannes.tschofenig@nsn.com Thu Nov 24 02:57:16 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD14421F8C0C for ; Thu, 24 Nov 2011 02:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.66 X-Spam-Level: X-Spam-Status: No, score=-106.66 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAWe46n9TG1z for ; Thu, 24 Nov 2011 02:57:15 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id A059221F8C09 for ; Thu, 24 Nov 2011 02:57:14 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pAOAv8fJ008746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Nov 2011 11:57:08 +0100 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pAOAuoEl023376; Thu, 24 Nov 2011 11:57:07 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Nov 2011 11:57:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCAA97.CBF9497B" Date: Thu, 24 Nov 2011 12:57:02 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DCD2357@FIESEXC035.nsn-intra.net> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AcyqlvT4iePunOjGSp6s9bWNjomV3wAABihw References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Christer Holmberg" , "ECRIT" X-OriginalArrivalTime: 24 Nov 2011 10:57:05.0321 (UTC) FILETIME=[CD9B9190:01CCAA97] Cc: Adam Roach , Paul Kyzivat Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 10:57:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCAA97.CBF9497B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Christer,=20 =20 In earlier discussions I was told that the SIP Resource Priority concept refers to a different type of resource and so I had proposed a new header in the past. However, when looking at RFC 4412 it may be vague enough to allow the RPH concept to be re-used for this purpose: =20 SIP applications may involve at least five different resources that may become scarce and congested during emergencies. These resources include gateway resources, circuit-switched network resources, IP network resources, receiving end-system resources, and SIP proxy resources. IP network resources are beyond the scope of SIP signaling and are therefore not considered here. =20 Does his include "bypassing whitelists and other authorization policies at proxies" and "ignoring user interface settings like 'silent mode'"?=20 =20 What do you think?=20 =20 Ciao Hannes =20 From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of ext Christer Holmberg Sent: Thursday, November 24, 2011 12:51 PM To: ECRIT Cc: 'Adam Roach'; Paul Kyzivat Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU =20 =20 Hi, =20 In Taipei, it was indicated that people would prefer another mechanism than a new GRUU type for solving the issue of identifying PSAP callback calls. =20 A new Resource-Priority header field value, that PSAPs would insert in callback calls, was suggested. It would solve the requirement of allowing network entities (and the UA) to identity the callback call, e.g. in order to give special treatment. =20 (The requirement to reach the same UA device that made the emergency call can be solved with the existing GRUU mechanism, so nothing new is needed there). =20 So, I would like to know whether people are ok with a Resource-Priority approach? =20 Regards, =20 Christer =20 =20 =20 ------_=_NextPart_001_01CCAA97.CBF9497B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Christer,

 

In earlier discussions I was told that the SIP Resource = Priority concept refers to a different type of resource and so I had proposed a = new header in the past. However, when looking at RFC 4412 it may be vague = enough to allow the RPH concept to be re-used for this = purpose:

 

   SIP applications may involve at least five different resources = that

   may become scarce and congested during emergencies.  These = resources

   include gateway resources, circuit-switched network resources, = IP

   network resources, receiving end-system resources, and SIP = proxy

   resources.  IP network resources are beyond the scope of = SIP

   signaling and are therefore not considered here.

 

Does his include “bypassing whitelists and other authorization policies = at proxies” and “ignoring user interface settings like ‘silent = mode’”?

 

What do you think?

 

Ciao
Hannes

 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of = ext Christer Holmberg
Sent: Thursday, November 24, 2011 12:51 PM
To: ECRIT
Cc: 'Adam Roach'; Paul Kyzivat
Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority = instead of eGRUU

 

 

Hi,

 =

In Taipei, it was indicated that people would prefer another mechanism than = a new GRUU type for solving the issue of identifying PSAP callback = calls.

 =

A new Resource-Priority header field value, that PSAPs would insert in = callback calls, was suggested. It would solve the requirement of allowing network entities (and the UA) to identity the callback call, e.g. in order to = give special treatment.

 =

(The requirement to reach the same UA device that made the emergency call can = be solved with the existing GRUU mechanism, so nothing new is needed = there).

 =

So, I would like to know whether people are ok with a Resource-Priority = approach?

 =

Regards,

 =

Christer

 =

 =

 =

------_=_NextPart_001_01CCAA97.CBF9497B-- From christer.holmberg@ericsson.com Sat Nov 26 06:01:00 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9DD621F8B24 for ; Sat, 26 Nov 2011 06:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I70dHRx6AMa8 for ; Sat, 26 Nov 2011 06:01:00 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6162221F8B20 for ; Sat, 26 Nov 2011 06:00:49 -0800 (PST) X-AuditID: c1b4fb3d-b7b5fae00000219a-bc-4ed0f10d4b30 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 96.92.08602.D01F0DE4; Sat, 26 Nov 2011 15:00:45 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sat, 26 Nov 2011 15:00:45 +0100 From: Christer Holmberg To: "ecrit@ietf.org" Date: Sat, 26 Nov 2011 15:00:44 +0100 Thread-Topic: [Ecrit] draft-holmberg-ecrit-emergency-callback-id Thread-Index: Acyq64Y5j59+7GppQQeatIUWWcMdCQBV22n8 Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D16@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A815656@ESESSCMS0356.eemea.ericsson.se>, <4ECEAF73.6030607@alum.mit.edu> In-Reply-To: <4ECEAF73.6030607@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "pkyzivat@cisco.com" Subject: Re: [Ecrit] draft-holmberg-ecrit-emergency-callback-id X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 14:01:01 -0000 Hi, Another question that came up was which WG should be doing the protocol wor= k. Assuming we would simply define a new RPH namespace for PSAP callback calls= , my understanding is that we could do that in ECRIT. Right? Regards, Christer ________________________________________ From: Paul Kyzivat [pkyzivat@alum.mit.edu] Sent: Thursday, November 24, 2011 10:56 PM To: Christer Holmberg Cc: ECRIT Subject: Re: [Ecrit] draft-holmberg-ecrit-emergency-callback-id On 11/24/11 6:54 PM, Christer Holmberg wrote: > Hi Paul, > My take from the ECRIT session was that we don't want to move forward > with the gruu approach, but rather use something else (e.g. a new RPH > value), so I don't know how much time we should spend on discussing the > gruu. I'm happy with that direction. Thanks, Paul > But, I'll try address also the gruu related questions anyway :) > ----------------- > > After the meeting this morning I read the document. Here are a bunch > of comments to start some discussion. > > > > Section 4: > > > > - An eGRUU MUST be constructed following the same principles and > > rules that apply for constructing a public GRUU. > > > > Section 6.2 > > > > If the Call-ID changes in a register refresh, the server will > > invalidate all eGRUUs associated with that UA instance; the only > > valid one will be the new one returned in that REGISTER response. > > > > This language is analogous to that for temp gruus, not permanent gruus= . > > Yet the stated intent is that the egruu be like a public gruu. > The text used to say that an eGRUU is constructed following the same > principles and rules that apply for constructioning a temporary GRUU, so > I guess that text is something that by misstake was left unchanged. > ------------------------------------ > > Section 6.4: > > > > A UA MUST NOT construct a self-made eGRUU. > > > > There may be a reason for this in IMS, but I see no general reason > for this. > > > > A UA that assigns a gruu for itself to use in emergency calls can then > > recognize emergency callbacks and process them in a special way. > Yes, the UA can do that, but network entities may not be able to. > ------------------------------------ > > The requirement for a registrar assigned egruu seems to be predicated > > on emergency services provided by the registrar, or proxies and > > application servers in the routing path from the home proxy. The > > presence of such things, and how they work, is environment dependent. > Yes. The idea is not to specify WHAT the networks do, simply to be able > to identify callback calls, IF they need to do something. > ------------------------------------ > > Section 6.6 > > > > NOTE: If the Contact header field of an initial SIP INVITE request > > for an emergency call did not contain a "psabcb" parameter, a UA, > > representing a PSAP, can insert the "psapcb" parameter in the > > Request-URI of the initial SIP INVITE request for an PSAP callback > > call. > > > > This is dubious. Modifying a URI you received is in general a bad idea= . > That was indicated as an open issue in my presentation. > ------------------------------------ > > If a UA does not represent a PSAP, making a PSAP callback call, it > > MUST NOT insert an eGRUU and a "psapcb" parameter in the Request-URI > > of the intial SIP INVITE request for the call. > > > > This makes little sense, and its not enforceable because UAs that > > don't implement this spec need not comply with it. In general, a UA > > that wants to send an out of dialog request to some UA it has a dialog > > with will simply use the remote Contact URI. > True. > I guess the key is that a UA that does understand the spec must not > insert the parameter in the Contact header field for any other calls > than emergency calls. > ------------------------------------ > > Then finally, I can find *no* explanation of what happens differently > > for a request containing the psapcb parameter, vs. one that does not. > > This is apparently very important, but totally opaque. > > > > Also, when the callback is generated with the egruu and its psapcb > > parameter, the UA does not get the parameter, except possibly via H-I. > > So its difficult for it to give special treatment for the callback cal= l. > > Is there an assumption that it will use H-I for this? > That is something that was brought up at some point. > So, if there is a need for entities beyond the registrar (that will > re-write the > R-URI, and hence remove the "psapcb" parameter) to be informed about the > callback call, > we would either need H-I, or something else. > ------------------------------------ > > I also reviewed draft-ietf-ecrit-psap-callback-03 and didn't find any > > further enlightenment over this. > > > > ISTM that there are several requirements: > > > > - the callback should be addressed to the UA that initiated the > > emergency call, not to the AOR of that UA. Existing GRUU technology > > (either permanent, temporary, or self assigned satisfy this.) > Correct. > ------------------------------------ > > - the signaling network that routes the callback should avoid special > > treatments to callback calls that prevent the callback from reaching t= he > > intended UA. This requires that it be possible to identify callback > calls. > I think the text is a little missleading, when it talks about AVOID > special treatment. > The idea is that a call that is identified as a callback call CAN be > given special treatment. > Also, it is not only about preventing the UA from not getting the call > (which could happen e.g. in call forwarding cases), but in general not > to apply services to callback calls (such as possibility to put the call > on hold) > So, something like: > "should avoid applying services to the callback call, which in some > cases might prevent the call from reaching the UA" > ------------------------------------ > > - the UA should give special priority to callback calls. For instance, > > drop other calls in order to take this one. This requires that it be > > possible to identify callback calls. > Correct. > ------------------------------------ > > - callback calls should be restricted to a limited set of callers, and > > no others. The allowed set is not well defined, but includes the > > recipient of the precipitating emergency call, plus some "friends". Th= e > > reason for this is to prevent others from getting the special treatmen= t. > > Defining this set is hard. Enforcing this limitation is also hard. > I'm not sure about the background to this requirement, so I'll let > others comment. > The 3GPP requirement is that only the one who made the emergency call > will get the callback call. > Of course, a PSAP can also call other users, but those calls are not > seen or treated as callback calls. > Regards, > Christer From hannes.tschofenig@nsn.com Sat Nov 26 06:21:20 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF5821F8B39 for ; Sat, 26 Nov 2011 06:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.644 X-Spam-Level: X-Spam-Status: No, score=-106.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzNHchYJX+Xw for ; Sat, 26 Nov 2011 06:21:19 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0139F21F8B3E for ; Sat, 26 Nov 2011 06:21:12 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pAQEL8v1006317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 26 Nov 2011 15:21:08 +0100 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pAQEL7rc009129; Sat, 26 Nov 2011 15:21:08 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Nov 2011 15:21:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 26 Nov 2011 16:22:59 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DD08D92@FIESEXC035.nsn-intra.net> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D16@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-holmberg-ecrit-emergency-callback-id Thread-Index: Acyq64Y5j59+7GppQQeatIUWWcMdCQBV22n8AADl+AA= References: <7F2072F1E0DE894DA4B517B93C6A05852C3A815656@ESESSCMS0356.eemea.ericsson.se>, <4ECEAF73.6030607@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D16@ESESSCMS0356.eemea.ericsson.se> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Christer Holmberg" , X-OriginalArrivalTime: 26 Nov 2011 14:21:07.0889 (UTC) FILETIME=[A392B210:01CCAC46] Cc: pkyzivat@cisco.com Subject: Re: [Ecrit] draft-holmberg-ecrit-emergency-callback-id X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2011 14:21:21 -0000 Hi Christer,=20 I would do the work in ECRIT of course with reviews from the folks in other RAI groups. My argument is that the motivation of the work comes from ECRIT.=20 The work on SIP Location Conveyance illustrated that problems show up when you move the work away from the group where the requirements and usage scenario come from. Ciao Hannes > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of ext Christer Holmberg > Sent: Saturday, November 26, 2011 4:01 PM > To: ecrit@ietf.org > Cc: pkyzivat@cisco.com > Subject: Re: [Ecrit] draft-holmberg-ecrit-emergency-callback-id >=20 >=20 >=20 > Hi, >=20 > Another question that came up was which WG should be doing the protocol > work. >=20 > Assuming we would simply define a new RPH namespace for PSAP callback > calls, my understanding is that we could do that in ECRIT. >=20 > Right? >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > ________________________________________ > From: Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Thursday, November 24, 2011 10:56 PM > To: Christer Holmberg > Cc: ECRIT > Subject: Re: [Ecrit] draft-holmberg-ecrit-emergency-callback-id >=20 > On 11/24/11 6:54 PM, Christer Holmberg wrote: > > Hi Paul, > > My take from the ECRIT session was that we don't want to move forward > > with the gruu approach, but rather use something else (e.g. a new RPH > > value), so I don't know how much time we should spend on discussing > the > > gruu. >=20 > I'm happy with that direction. >=20 > Thanks, > Paul >=20 > > But, I'll try address also the gruu related questions anyway :) > > ----------------- > > > After the meeting this morning I read the document. Here are a > bunch > > of comments to start some discussion. > > > > > > Section 4: > > > > > > - An eGRUU MUST be constructed following the same principles and > > > rules that apply for constructing a public GRUU. > > > > > > Section 6.2 > > > > > > If the Call-ID changes in a register refresh, the server will > > > invalidate all eGRUUs associated with that UA instance; the only > > > valid one will be the new one returned in that REGISTER response. > > > > > > This language is analogous to that for temp gruus, not permanent > gruus. > > > Yet the stated intent is that the egruu be like a public gruu. > > The text used to say that an eGRUU is constructed following the same > > principles and rules that apply for constructioning a temporary GRUU, > so > > I guess that text is something that by misstake was left unchanged. > > ------------------------------------ > > > Section 6.4: > > > > > > A UA MUST NOT construct a self-made eGRUU. > > > > > > There may be a reason for this in IMS, but I see no general reason > > for this. > > > > > > A UA that assigns a gruu for itself to use in emergency calls can > then > > > recognize emergency callbacks and process them in a special way. > > Yes, the UA can do that, but network entities may not be able to. > > ------------------------------------ > > > The requirement for a registrar assigned egruu seems to be > predicated > > > on emergency services provided by the registrar, or proxies and > > > application servers in the routing path from the home proxy. The > > > presence of such things, and how they work, is environment > dependent. > > Yes. The idea is not to specify WHAT the networks do, simply to be > able > > to identify callback calls, IF they need to do something. > > ------------------------------------ > > > Section 6.6 > > > > > > NOTE: If the Contact header field of an initial SIP INVITE request > > > for an emergency call did not contain a "psabcb" parameter, a UA, > > > representing a PSAP, can insert the "psapcb" parameter in the > > > Request-URI of the initial SIP INVITE request for an PSAP callback > > > call. > > > > > > This is dubious. Modifying a URI you received is in general a bad > idea. > > That was indicated as an open issue in my presentation. > > ------------------------------------ > > > If a UA does not represent a PSAP, making a PSAP callback call, it > > > MUST NOT insert an eGRUU and a "psapcb" parameter in the Request- > URI > > > of the intial SIP INVITE request for the call. > > > > > > This makes little sense, and its not enforceable because UAs that > > > don't implement this spec need not comply with it. In general, a > UA > > > that wants to send an out of dialog request to some UA it has a > dialog > > > with will simply use the remote Contact URI. > > True. > > I guess the key is that a UA that does understand the spec must not > > insert the parameter in the Contact header field for any other calls > > than emergency calls. > > ------------------------------------ > > > Then finally, I can find *no* explanation of what happens > differently > > > for a request containing the psapcb parameter, vs. one that does > not. > > > This is apparently very important, but totally opaque. > > > > > > Also, when the callback is generated with the egruu and its psapcb > > > parameter, the UA does not get the parameter, except possibly via > H-I. > > > So its difficult for it to give special treatment for the callback > call. > > > Is there an assumption that it will use H-I for this? > > That is something that was brought up at some point. > > So, if there is a need for entities beyond the registrar (that will > > re-write the > > R-URI, and hence remove the "psapcb" parameter) to be informed about > the > > callback call, > > we would either need H-I, or something else. > > ------------------------------------ > > > I also reviewed draft-ietf-ecrit-psap-callback-03 and didn't find > any > > > further enlightenment over this. > > > > > > ISTM that there are several requirements: > > > > > > - the callback should be addressed to the UA that initiated the > > > emergency call, not to the AOR of that UA. Existing GRUU > technology > > > (either permanent, temporary, or self assigned satisfy this.) > > Correct. > > ------------------------------------ > > > - the signaling network that routes the callback should avoid > special > > > treatments to callback calls that prevent the callback from > reaching the > > > intended UA. This requires that it be possible to identify > callback > > calls. > > I think the text is a little missleading, when it talks about AVOID > > special treatment. > > The idea is that a call that is identified as a callback call CAN be > > given special treatment. > > Also, it is not only about preventing the UA from not getting the > call > > (which could happen e.g. in call forwarding cases), but in general > not > > to apply services to callback calls (such as possibility to put the > call > > on hold) > > So, something like: > > "should avoid applying services to the callback call, which in some > > cases might prevent the call from reaching the UA" > > ------------------------------------ > > > - the UA should give special priority to callback calls. For > instance, > > > drop other calls in order to take this one. This requires that it > be > > > possible to identify callback calls. > > Correct. > > ------------------------------------ > > > - callback calls should be restricted to a limited set of callers, > and > > > no others. The allowed set is not well defined, but includes the > > > recipient of the precipitating emergency call, plus some "friends". > The > > > reason for this is to prevent others from getting the special > treatment. > > > Defining this set is hard. Enforcing this limitation is also hard. > > I'm not sure about the background to this requirement, so I'll let > > others comment. > > The 3GPP requirement is that only the one who made the emergency call > > will get the callback call. > > Of course, a PSAP can also call other users, but those calls are not > > seen or treated as callback calls. > > Regards, > > Christer >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From keith.drage@alcatel-lucent.com Mon Nov 28 10:05:38 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB7D21F8D3E for ; Mon, 28 Nov 2011 10:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.041 X-Spam-Level: X-Spam-Status: No, score=-105.041 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0Il7j50tfKh for ; Mon, 28 Nov 2011 10:05:37 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 346C621F8D3D for ; Mon, 28 Nov 2011 10:05:37 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pASI5SRQ031513 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Nov 2011 19:05:28 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 28 Nov 2011 19:05:28 +0100 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , ECRIT Date: Mon, 28 Nov 2011 19:05:19 +0100 Thread-Topic: PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AcyqlvT4iePunOjGSp6s9bWNjomV3wDQGoDA Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE221A00EF9FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: 'Adam Roach' , Paul Kyzivat Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 18:05:38 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE221A00EF9FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can people indicate why they see a synergy with resource priority. This header field is primarily used for giving priority in the network. To = be used effectively, it needs to be processed first in any message at all S= IP entities, and the rest of the message handling depends on it. While there may possibly be a use for Resource-Priority on emergency callba= cks, in order to give priority, I would suggest that to give it a purpose b= eyond that where priority itself is not needed, is not using that header fo= r its prime purpose, and indeed detracts from the main usage. Further, one thing that could well disappear at country boundaries is the R= esource-Priority header field, because different regulatory regimes have di= fferent sets of rules as to what namespaces may be used, and do not necessa= rily map one to another. Any 3GPP roaming user will need to cross the same = country twice (on the signalling path) for the callback call, because the c= allback will go via the home network. So while I have no axes to grind on losing a GRUU dependency, I do think Re= source-Priority is a poor fit. Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: 24 November 2011 10:51 To: ECRIT Cc: 'Adam Roach'; Paul Kyzivat Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGR= UU Hi, In Taipei, it was indicated that people would prefer another mechanism than= a new GRUU type for solving the issue of identifying PSAP callback calls. A new Resource-Priority header field value, that PSAPs would insert in call= back calls, was suggested. It would solve the requirement of allowing netwo= rk entities (and the UA) to identity the callback call, e.g. in order to gi= ve special treatment. (The requirement to reach the same UA device that made the emergency call c= an be solved with the existing GRUU mechanism, so nothing new is needed the= re). So, I would like to know whether people are ok with a Resource-Priority app= roach? Regards, Christer --_000_EDC0A1AE77C57744B664A310A0B23AE221A00EF9FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can people indicate why they see a syn= ergy with resource priority.

 

This header field is primarily used fo= r giving priority in the network. To be used effectively, it needs to be processed first in any message at all SIP entities, and the rest of the mes= sage handling depends on it.

 

While there may possibly be a use for Resource-Priority on emergency callbacks, in order to give priority, I woul= d suggest that to give it a purpose beyond that where priority itself is not needed, is not using that header for its prime purpose, and indeed detracts from the main usage.

 

Further, one thing that could well disappear at country boundaries is the Resource-Priority header field, beca= use different regulatory regimes have different sets of rules as to what namesp= aces may be used, and do not necessarily map one to another. Any 3GPP roaming us= er will need to cross the same country twice (on the signalling path) for the callback call, because the callback will go via the home network.

 

So while I have no axes to grind on lo= sing a GRUU dependency, I do think Resource-Priority is a poor fit.

 

Keith

 

From:= ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 24 November 2011 10:51=
To: ECRIT
Cc: 'Adam Roach'; Paul Kyziv= at
Subject: [Ecrit] PSAP Callba= ck indication: Resrouce-Priority instead of eGRUU

 

 

Hi,

 

In Taipei, it was indicated that people would prefer another mechanism than a new GRUU type for solving the issue of identifying PSAP callback calls.

 

A new Resource-Priority header field value, that PSAPs w= ould insert in callback calls, was suggested. It would solve the requirement of allowing network entities (and the UA) to identity the callback call, e.g. = in order to give special treatment.

 

(The requirement to reach the same UA device that made t= he emergency call can be solved with the existing GRUU mechanism, so nothing n= ew is needed there).

 

So, I would like to know whether people are ok with a Resource-Priority approach?

 

Regards,

 

Christer

 

 

 

--_000_EDC0A1AE77C57744B664A310A0B23AE221A00EF9FRMRSSXCHMBSC3d_-- From hgs@cs.columbia.edu Mon Nov 28 10:21:25 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0826C21F8D2D for ; Mon, 28 Nov 2011 10:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQGKMpy7462x for ; Mon, 28 Nov 2011 10:21:24 -0800 (PST) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id 732ED21F8D32 for ; Mon, 28 Nov 2011 10:21:23 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pASIL9xT009912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Nov 2011 13:21:10 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_EA65BB03-BD05-45EF-96AE-1075DB6CDF5A" From: Henning Schulzrinne In-Reply-To: Date: Mon, 28 Nov 2011 13:21:08 -0500 Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: 'Adam Roach' , ECRIT , Paul Kyzivat Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 18:21:25 -0000 --Apple-Mail=_EA65BB03-BD05-45EF-96AE-1075DB6CDF5A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I share the concern about this use of RPH. I see a few alternatives that = might be worth discussing: - The "Priority" SIP header, which already has an "emergency" value. - Using an sos service URN in the =46rom header field. In all cases, the In-Reply-To field allows the caller to determine that = the return call is indeed in response to a call made earlier, at least. = If the caller UA knows that the call-ID was an emergency call, this = provides reasonable assurance that the return call is from a PSAP (or = other entity that received the original call). If the calling UA did not = recognize the call as emergency, none of the marking mechanism are = likely to make much difference in terms of handling in any event. Henning On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: > Can people indicate why they see a synergy with resource priority. > =20 > This header field is primarily used for giving priority in the = network. To be used effectively, it needs to be processed first in any = message at all SIP entities, and the rest of the message handling = depends on it. > =20 > While there may possibly be a use for Resource-Priority on emergency = callbacks, in order to give priority, I would suggest that to give it a = purpose beyond that where priority itself is not needed, is not using = that header for its prime purpose, and indeed detracts from the main = usage. > =20 > Further, one thing that could well disappear at country boundaries is = the Resource-Priority header field, because different regulatory regimes = have different sets of rules as to what namespaces may be used, and do = not necessarily map one to another. Any 3GPP roaming user will need to = cross the same country twice (on the signalling path) for the callback = call, because the callback will go via the home network. > =20 > So while I have no axes to grind on losing a GRUU dependency, I do = think Resource-Priority is a poor fit. > =20 > Keith > =20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Christer Holmberg > Sent: 24 November 2011 10:51 > To: ECRIT > Cc: 'Adam Roach'; Paul Kyzivat > Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead = of eGRUU > =20 > =20 > Hi, > =20 > In Taipei, it was indicated that people would prefer another mechanism = than a new GRUU type for solving the issue of identifying PSAP callback = calls. > =20 > A new Resource-Priority header field value, that PSAPs would insert in = callback calls, was suggested. It would solve the requirement of = allowing network entities (and the UA) to identity the callback call, = e.g. in order to give special treatment. > =20 > (The requirement to reach the same UA device that made the emergency = call can be solved with the existing GRUU mechanism, so nothing new is = needed there). > =20 > So, I would like to know whether people are ok with a = Resource-Priority approach? > =20 > Regards, > =20 > Christer > =20 > =20 > =20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_EA65BB03-BD05-45EF-96AE-1075DB6CDF5A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

- Using an sos service URN in the =46rom = header field.

In all cases, the In-Reply-To = field allows the caller to determine that the return call is indeed in = response to a call made earlier, at least. If the caller UA knows that = the call-ID was an emergency call, this provides reasonable assurance = that the return call is from a PSAP (or other entity that received the = original call). If the calling UA did not recognize the call as = emergency, none of the marking mechanism are likely to make much = difference in terms of handling in any = event.

Henning

On Nov 28, = 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote:

=

Can people indicate why they see a = synergy with resource priority.

 

This header field is primarily used = for giving priority in the network. To be used effectively, it needs to be processed first in any message at all SIP entities, and the rest of the = message handling depends on it.

 

While there may possibly be a use = for Resource-Priority on emergency callbacks, in order to give priority, I = would suggest that to give it a purpose beyond that where priority itself is = not needed, is not using that header for its prime purpose, and indeed = detracts from the main usage.

 

Further, one thing that could well disappear at country boundaries is the Resource-Priority header field, = because different regulatory regimes have different sets of rules as to what = namespaces may be used, and do not necessarily map one to another. Any 3GPP roaming = user will need to cross the same country twice (on the signalling path) for = the callback call, because the callback will go via the home = network.

 

So while I have no axes to grind on = losing a GRUU dependency, I do think Resource-Priority is a poor = fit.

 

Keith

 

From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] On = Behalf Of Christer Holmberg
Sent: 24 November 2011 = 10:51
To: ECRIT
Cc: 'Adam Roach'; Paul = Kyzivat
Subject: [Ecrit] PSAP = Callback indication: Resrouce-Priority instead of eGRUU

 

 

Hi,

 

In Taipei, it was indicated that people would prefer another mechanism than a new = GRUU type for solving the issue of identifying PSAP callback = calls.

 

A new Resource-Priority header field value, that = PSAPs would insert in callback calls, was suggested. It would solve the requirement = of allowing network entities (and the UA) to identity the callback call, = e.g. in order to give special treatment.

 

(The requirement to reach the same UA device that = made the emergency call can be solved with the existing GRUU mechanism, so = nothing new is needed there).

 

So, I would like to know whether people are ok with a Resource-Priority approach?

 

Regards,

 

Christer

 

 

 

_______________________________________________
Ecrit mailing = list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit
<= /div>
= --Apple-Mail=_EA65BB03-BD05-45EF-96AE-1075DB6CDF5A-- From br@brianrosen.net Mon Nov 28 10:37:27 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D59611E808E for ; Mon, 28 Nov 2011 10:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTaiqoRhHQGU for ; Mon, 28 Nov 2011 10:37:26 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 2450311E8085 for ; Mon, 28 Nov 2011 10:37:26 -0800 (PST) X-ASG-Debug-ID: 1322505443-011a9f08fe2c6ff0004-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id lKoDROPj6vqrsqsK; Mon, 28 Nov 2011 10:37:24 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.29]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RV634-002t6m-H7; Mon, 28 Nov 2011 10:35:27 -0800 X-Barracuda-BBL-IP: 209.173.57.233 X-Barracuda-RBL-IP: 209.173.57.233 Mime-Version: 1.0 (Apple Message framework v1251.1) X-ASG-Orig-Subj: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Content-Type: multipart/alternative; boundary="Apple-Mail=_A2D882BC-4A14-4DD7-A4BA-AD0AA9EDC610" From: Brian Rosen In-Reply-To: Date: Mon, 28 Nov 2011 13:35:21 -0500 Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1251.1) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1322505443 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.81564 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message Cc: 'Adam Roach' , ECRIT , Paul Kyzivat Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 18:37:27 -0000 --Apple-Mail=_A2D882BC-4A14-4DD7-A4BA-AD0AA9EDC610 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii One of the things the GRUU got you was a token that could be used for = authorization. It's not just that it's a call back. Brian On Nov 28, 2011, at 1:21 PM, Henning Schulzrinne wrote: > I share the concern about this use of RPH. I see a few alternatives = that might be worth discussing: >=20 > - The "Priority" SIP header, which already has an "emergency" value. >=20 > - Using an sos service URN in the =46rom header field. >=20 > In all cases, the In-Reply-To field allows the caller to determine = that the return call is indeed in response to a call made earlier, at = least. If the caller UA knows that the call-ID was an emergency call, = this provides reasonable assurance that the return call is from a PSAP = (or other entity that received the original call). If the calling UA did = not recognize the call as emergency, none of the marking mechanism are = likely to make much difference in terms of handling in any event. >=20 > Henning >=20 > On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: >=20 >> Can people indicate why they see a synergy with resource priority. >> =20 >> This header field is primarily used for giving priority in the = network. To be used effectively, it needs to be processed first in any = message at all SIP entities, and the rest of the message handling = depends on it. >> =20 >> While there may possibly be a use for Resource-Priority on emergency = callbacks, in order to give priority, I would suggest that to give it a = purpose beyond that where priority itself is not needed, is not using = that header for its prime purpose, and indeed detracts from the main = usage. >> =20 >> Further, one thing that could well disappear at country boundaries is = the Resource-Priority header field, because different regulatory regimes = have different sets of rules as to what namespaces may be used, and do = not necessarily map one to another. Any 3GPP roaming user will need to = cross the same country twice (on the signalling path) for the callback = call, because the callback will go via the home network. >> =20 >> So while I have no axes to grind on losing a GRUU dependency, I do = think Resource-Priority is a poor fit. >> =20 >> Keith >> =20 >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of Christer Holmberg >> Sent: 24 November 2011 10:51 >> To: ECRIT >> Cc: 'Adam Roach'; Paul Kyzivat >> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead = of eGRUU >> =20 >> =20 >> Hi, >> =20 >> In Taipei, it was indicated that people would prefer another = mechanism than a new GRUU type for solving the issue of identifying PSAP = callback calls. >> =20 >> A new Resource-Priority header field value, that PSAPs would insert = in callback calls, was suggested. It would solve the requirement of = allowing network entities (and the UA) to identity the callback call, = e.g. in order to give special treatment. >> =20 >> (The requirement to reach the same UA device that made the emergency = call can be solved with the existing GRUU mechanism, so nothing new is = needed there). >> =20 >> So, I would like to know whether people are ok with a = Resource-Priority approach? >> =20 >> Regards, >> =20 >> Christer >> =20 >> =20 >> =20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_A2D882BC-4A14-4DD7-A4BA-AD0AA9EDC610 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii One = of the things the GRUU got you was a token that could be used for = authorization.  It's not just that it's a call = back.

Brian

On Nov 28, 2011, = at 1:21 PM, Henning Schulzrinne wrote:

I share the concern about = this use of RPH. I see a few alternatives that might be worth = discussing:

- The "Priority" SIP header, which = already has an "emergency" value.

- Using an = sos service URN in the =46rom header field.

In = all cases, the In-Reply-To field allows the caller to determine that the = return call is indeed in response to a call made earlier, at least. If = the caller UA knows that the call-ID was an emergency call, this = provides reasonable assurance that the return call is from a PSAP (or = other entity that received the original call). If the calling UA did not = recognize the call as emergency, none of the marking mechanism are = likely to make much difference in terms of handling in any = event.

Henning

On Nov 28, = 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote:

=

Can people indicate why they see a = synergy with resource priority.

 

This header field is primarily used = for giving priority in the network. To be used effectively, it needs to be processed first in any message at all SIP entities, and the rest of the = message handling depends on it.

 

While there may possibly be a use = for Resource-Priority on emergency callbacks, in order to give priority, I = would suggest that to give it a purpose beyond that where priority itself is = not needed, is not using that header for its prime purpose, and indeed = detracts from the main usage.

 

Further, one thing that could well disappear at country boundaries is the Resource-Priority header field, = because different regulatory regimes have different sets of rules as to what = namespaces may be used, and do not necessarily map one to another. Any 3GPP roaming = user will need to cross the same country twice (on the signalling path) for = the callback call, because the callback will go via the home = network.

 

So while I have no axes to grind on = losing a GRUU dependency, I do think Resource-Priority is a poor = fit.

 

Keith

 

From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] On = Behalf Of Christer Holmberg
Sent: 24 November 2011 = 10:51
To: ECRIT
Cc: 'Adam Roach'; Paul = Kyzivat
Subject: [Ecrit] PSAP = Callback indication: Resrouce-Priority instead of eGRUU

 

 

Hi,

 

In Taipei, it was indicated that people would prefer another mechanism than a new = GRUU type for solving the issue of identifying PSAP callback = calls.

 

A new Resource-Priority header field value, that = PSAPs would insert in callback calls, was suggested. It would solve the requirement = of allowing network entities (and the UA) to identity the callback call, = e.g. in order to give special treatment.

 

(The requirement to reach the same UA device that = made the emergency call can be solved with the existing GRUU mechanism, so = nothing new is needed there).

 

So, I would like to know whether people are ok with a Resource-Priority approach?

 

Regards,

 

Christer

 

 

 

_______________________________________________
Ecrit mailing = list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit

_______________________________________________
Ecri= t mailing list
Ecrit@ietf.org
https://www.ietf.org/= mailman/listinfo/ecrit

= --Apple-Mail=_A2D882BC-4A14-4DD7-A4BA-AD0AA9EDC610-- From hgs@cs.columbia.edu Mon Nov 28 10:49:27 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2BB21F8CA3 for ; Mon, 28 Nov 2011 10:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zq9k9EMMAAE0 for ; Mon, 28 Nov 2011 10:49:26 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id 65A1921F8C96 for ; Mon, 28 Nov 2011 10:49:26 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pASInJ2T021998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Nov 2011 13:49:20 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Mon, 28 Nov 2011 13:49:19 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0CCFCF39-75D9-45F6-93D5-10317CAA3875@cs.columbia.edu> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> To: Brian Rosen X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: 'Adam Roach' , ECRIT , Paul Kyzivat Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 18:49:27 -0000 How would a GRUU authorize the caller as "this is a PSAP"? On Nov 28, 2011, at 1:35 PM, Brian Rosen wrote: > One of the things the GRUU got you was a token that could be used for = authorization. It's not just that it's a call back. >=20 > Brian From br@brianrosen.net Mon Nov 28 11:01:43 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5391F0C47 for ; Mon, 28 Nov 2011 11:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbQQgKc83mbe for ; Mon, 28 Nov 2011 11:01:42 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0E34B1F0C45 for ; Mon, 28 Nov 2011 11:01:42 -0800 (PST) X-ASG-Debug-ID: 1322506876-011a9f08fb2c8690001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id zO4FPYMwcuMa545J; Mon, 28 Nov 2011 11:01:16 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.29]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RV6S4-002yR5-3M; Mon, 28 Nov 2011 11:01:16 -0800 X-Barracuda-BBL-IP: 209.173.57.233 X-Barracuda-RBL-IP: 209.173.57.233 Mime-Version: 1.0 (Apple Message framework v1251.1) X-ASG-Orig-Subj: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <0CCFCF39-75D9-45F6-93D5-10317CAA3875@cs.columbia.edu> Date: Mon, 28 Nov 2011 14:01:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> <0CCFCF39-75D9-45F6-93D5-10317CAA3875@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1251.1) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1322506876 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.81564 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: 'Adam Roach' , ECRIT , Paul Kyzivat Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 19:01:43 -0000 The original call is set up as a emergency call. In that call is a = token that can be used as a call back authentication token. It's not = that it's a PSAP (although PSAPs may have credentials that prove they = are PSAPs), it's that it's a return call from the original emergency = call. If it's handled within https, it's even somewhat secure. Brian On Nov 28, 2011, at 1:49 PM, Henning Schulzrinne wrote: > How would a GRUU authorize the caller as "this is a PSAP"? >=20 > On Nov 28, 2011, at 1:35 PM, Brian Rosen wrote: >=20 >> One of the things the GRUU got you was a token that could be used for = authorization. It's not just that it's a call back. >>=20 >> Brian >=20 From hgs@cs.columbia.edu Mon Nov 28 11:07:47 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8683521F8B27 for ; Mon, 28 Nov 2011 11:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krZbexRgJwA1 for ; Mon, 28 Nov 2011 11:07:47 -0800 (PST) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id ED19821F8B20 for ; Mon, 28 Nov 2011 11:07:46 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pASJ7XAP020173 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Nov 2011 14:07:37 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Mon, 28 Nov 2011 14:07:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <268F21CD-48C6-46D8-8D10-90B1B8D7ED75@cs.columbia.edu> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> <0CCFCF39-75D9-45F6-93D5-10317CAA3875@cs.columbia.edu> To: Brian Rosen X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: 'Adam Roach' , ECRIT , Paul Kyzivat Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 19:07:47 -0000 But that's roughly the same authorization (nonce) model you have for the = In-Reply-To. You had said earlier that this works only for call-backs, = but that seems to be true for both. (The https security properties are = the same, either way.) This approach requires no special modification of = anything. Henning On Nov 28, 2011, at 2:01 PM, Brian Rosen wrote: > The original call is set up as a emergency call. In that call is a = token that can be used as a call back authentication token. It's not = that it's a PSAP (although PSAPs may have credentials that prove they = are PSAPs), it's that it's a return call from the original emergency = call. If it's handled within https, it's even somewhat secure. >=20 > Brian > On Nov 28, 2011, at 1:49 PM, Henning Schulzrinne wrote: >=20 >> How would a GRUU authorize the caller as "this is a PSAP"? >>=20 >> On Nov 28, 2011, at 1:35 PM, Brian Rosen wrote: >>=20 >>> One of the things the GRUU got you was a token that could be used = for authorization. It's not just that it's a call back. >>>=20 >>> Brian >>=20 >=20 >=20 From jmpolk@cisco.com Mon Nov 28 11:12:52 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AAA1F0C45 for ; Mon, 28 Nov 2011 11:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BGN+nKmOpDG for ; Mon, 28 Nov 2011 11:12:51 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 455CA1F0C41 for ; Mon, 28 Nov 2011 11:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=1641; q=dns/txt; s=iport; t=1322507571; x=1323717171; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=c1jrctBRrSkM1bZ+rlAqKjc4KKMvVKnKW5UXZqC1I34=; b=ejTkNyDDzESWGd2WlmMuAjknsg4HTL1tvkribOLI5/3fRw0Y8Aji7mpl xtuYtzW6sFaGiKw+6Z9RHmQf9z8S4LJSoK/BJc98ScHgJ/Wd9TvRuYMK4 8j8RXHf5XNsSGwDpTEzBVFm1M03e8PZsDJd7ZBgj366VTxJNEU+EZ31U/ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADLc006rRDoI/2dsb2JhbABDqm2BBYFyAQEBBBIBJQJPBwQYHhAZPgYBNKA7AZ5UimIEiCGeUw X-IronPort-AV: E=Sophos;i="4.69,585,1315180800"; d="scan'208";a="14874906" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 28 Nov 2011 19:12:51 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pASJCoXK016048; Mon, 28 Nov 2011 19:12:50 GMT Message-Id: <201111281912.pASJCoXK016048@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Nov 2011 13:12:49 -0600 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Christer Holmberg" , From: "James M. Polk" In-Reply-To: <999913AB42CC9341B05A99BBF358718DD08D92@FIESEXC035.nsn-intr a.net> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A815656@ESESSCMS0356.eemea.ericsson.se> <4ECEAF73.6030607@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D16@ESESSCMS0356.eemea.ericsson.se> <999913AB42CC9341B05A99BBF358718DD08D92@FIESEXC035.nsn-intra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Ecrit] draft-holmberg-ecrit-emergency-callback-id X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 19:12:52 -0000 At 08:22 AM 11/26/2011, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >The work on SIP Location Conveyance illustrated that problems show up >when you move the work away from the group where the requirements and >usage scenario come from. Location Conveyance started in 2003 in SIPPING (at the Vienna IETF), was moved to SIP, then back to SIPPING, then back to SIP, then on to SIPCORE. It was NEVER part of Geopriv, so that wasn't the problem. IMO the problems stemmed more from those insisting on requirements be met that didn't understand the construction of SIP than anything else, as SIP Location Conveyance was mostly transporting an already defined PIDF-LO (RFC 4119) or a URI (an ID that is in AD review now). The remainder of the issues all had to do with how what affected SIP (i.e., the header and header values that were mostly transparent to SIP within a SIP transaction). For example, inserting a header value that changed the routing of the SIP request by a proxy, most often causing confusion by location recipients (because the proxy doesn't remove the existing location inserted by the UAC - hence there are now at least two locations in the same SIP request with zero guidance which is better or more authoritative). I thank Jon for presenting how bad an idea that was (as well as several other bad ideas that were requirements placed on the editor - i.e., me), resulting in the great reduction in text as we cut out most of that cruft (and halved the size of the doc). Bottom line, stating Location Conveyance as an example here was a poor choice. James >Ciao >Hannes From br@brianrosen.net Mon Nov 28 11:23:51 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13CC21F8C40 for ; Mon, 28 Nov 2011 11:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ62JaHfC0Vo for ; Mon, 28 Nov 2011 11:23:50 -0800 (PST) Received: from barmail5.idig.net (barmail5.idig.net [64.34.111.236]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0CC21F8BF9 for ; Mon, 28 Nov 2011 11:23:50 -0800 (PST) X-ASG-Debug-ID: 1322508228-0491e50f2312df90003-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail5.idig.net with ESMTP id 8GvZlhWf7cq7AlX3; Mon, 28 Nov 2011 11:23:49 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.29]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RV6nM-0032rh-O6; Mon, 28 Nov 2011 11:23:17 -0800 X-Barracuda-BBL-IP: 209.173.57.233 X-Barracuda-RBL-IP: 209.173.57.233 Mime-Version: 1.0 (Apple Message framework v1251.1) X-ASG-Orig-Subj: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Content-Type: text/plain; charset=iso-8859-1 From: Brian Rosen In-Reply-To: <4ED3DB8A.3070807@alum.mit.edu> Date: Mon, 28 Nov 2011 14:23:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8F5317A5-2DF5-481B-9C2A-7DCAF27F72B1@brianrosen.net> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> <4ED3DB8A.3070807@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1322508229 X-Barracuda-URL: http://64.34.111.236:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.81567 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: 'Adam Roach' , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 19:23:51 -0000 I never understood the need for a special GRUU, but Christer thought it = was important. I'm not sure we need a marking. If we do, some urn in FROM is fine. = Not sure I would use urn:service:sos, but if it was limited to the = immediate return to the device that usually results from some sort of = premature disconnect, then it makes sense. A call back a few days later = (which is likely to the AoR, not Contact) with a from of urn:service:sos = makes little sense to me. Brian On Nov 28, 2011, at 2:05 PM, Paul Kyzivat wrote: > On 11/29/11 2:35 AM, Brian Rosen wrote: >> One of the things the GRUU got you was a token that could be used for >> authorization. It's not just that it's a call back. >=20 > I don't understand how that would work. >=20 > In any case, I don't object to using a GRUU for callback. (That's what = its for). But I do object to inventing a new sort of GRUU, that needs = to be widely understood, just for emergency calls. The mechanism is = pretty heavy weight to add on for that. >=20 > IMO it should be sufficient to use a temp gruu. There can be lots of = them, so the UAC can use a unique one for the emergency call, and = remember to treat callbacks to that one specially. The fact that it is a = gruu (the "gr" parameter) *should* be a cue that many disruptive = services should be disabled along the signaling path - not because it is = an emergency call, but because the call is intended to go to a specific = endpoint. And if that isn't enough, callerprefs could also be used to = request that automata be bypassed in favor of a human. >=20 > This could be coupled with other indicators, such as an sos urn in the = from field. >=20 > Thanks, > Paul >=20 >> Brian >>=20 >> On Nov 28, 2011, at 1:21 PM, Henning Schulzrinne wrote: >>=20 >>> I share the concern about this use of RPH. I see a few alternatives >>> that might be worth discussing: >>>=20 >>> - The "Priority" SIP header, which already has an "emergency" value. >>>=20 >>> - Using an sos service URN in the =46rom header field. >>>=20 >>> In all cases, the In-Reply-To field allows the caller to determine >>> that the return call is indeed in response to a call made earlier, = at >>> least. If the caller UA knows that the call-ID was an emergency = call, >>> this provides reasonable assurance that the return call is from a = PSAP >>> (or other entity that received the original call). If the calling UA >>> did not recognize the call as emergency, none of the marking = mechanism >>> are likely to make much difference in terms of handling in any = event. >>>=20 >>> Henning >>>=20 >>> On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: >>>=20 >>>> Can people indicate why they see a synergy with resource priority. >>>>=20 >>>> This header field is primarily used for giving priority in the >>>> network. To be used effectively, it needs to be processed first in >>>> any message at all SIP entities, and the rest of the message = handling >>>> depends on it. >>>>=20 >>>> While there may possibly be a use for Resource-Priority on = emergency >>>> callbacks, in order to give priority, I would suggest that to give = it >>>> a purpose beyond that where priority itself is not needed, is not >>>> using that header for its prime purpose, and indeed detracts from = the >>>> main usage. >>>>=20 >>>> Further, one thing that could well disappear at country boundaries = is >>>> the Resource-Priority header field, because different regulatory >>>> regimes have different sets of rules as to what namespaces may be >>>> used, and do not necessarily map one to another. Any 3GPP roaming >>>> user will need to cross the same country twice (on the signalling >>>> path) for the callback call, because the callback will go via the >>>> home network. >>>>=20 >>>> So while I have no axes to grind on losing a GRUU dependency, I do >>>> think Resource-Priority is a poor fit. >>>>=20 >>>> Keith >>>>=20 >>>> = ------------------------------------------------------------------------ >>>>=20 >>>> *From:*ecrit-bounces@ietf.org >>>> [mailto:ecrit-bounces@ietf.org] *On Behalf Of *Christer Holmberg >>>> *Sent:* 24 November 2011 10:51 >>>> *To:* ECRIT >>>> *Cc:* 'Adam Roach'; Paul Kyzivat >>>> *Subject:* [Ecrit] PSAP Callback indication: Resrouce-Priority >>>> instead of eGRUU >>>>=20 >>>> Hi, >>>>=20 >>>> In Taipei, it was indicated that people would prefer another >>>> mechanism than a new GRUU type for solving the issue of identifying >>>> PSAP callback calls. >>>>=20 >>>> A new Resource-Priority header field value, that PSAPs would insert >>>> in callback calls, was suggested. It would solve the requirement of >>>> allowing network entities (and the UA) to identity the callback = call, >>>> e.g. in order to give special treatment. >>>>=20 >>>> (The requirement to reach the same UA device that made the = emergency >>>> call can be solved with the existing GRUU mechanism, so nothing new >>>> is needed there). >>>>=20 >>>> So, I would like to know whether people are ok with a >>>> Resource-Priority approach? >>>>=20 >>>> Regards, >>>>=20 >>>> Christer >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 From br@brianrosen.net Mon Nov 28 11:24:16 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9501C21F8C4F for ; Mon, 28 Nov 2011 11:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhpffWvE61XF for ; Mon, 28 Nov 2011 11:24:16 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 15FC421F8C40 for ; Mon, 28 Nov 2011 11:24:16 -0800 (PST) X-ASG-Debug-ID: 1322508254-011a9f08f72c9fb0003-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id iPNj2H4J2sODLRv7; Mon, 28 Nov 2011 11:24:14 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.29]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RV6jU-0032BM-Cd; Mon, 28 Nov 2011 11:19:16 -0800 X-Barracuda-BBL-IP: 209.173.57.233 X-Barracuda-RBL-IP: 209.173.57.233 Mime-Version: 1.0 (Apple Message framework v1251.1) X-ASG-Orig-Subj: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <268F21CD-48C6-46D8-8D10-90B1B8D7ED75@cs.columbia.edu> Date: Mon, 28 Nov 2011 14:19:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <456B8087-3997-4C54-A15F-F50409BDB522@brianrosen.net> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> <0CCFCF39-75D9-45F6-93D5-10317CAA3875@cs.columbia.edu> <268F21CD-48C6-46D8-8D10-90B1B8D7ED75@cs.columbia.edu> To: Henning Schulzrinne X-Mailer: Apple Mail (2.1251.1) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1322508254 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.81566 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: 'Adam Roach' , ECRIT , Paul Kyzivat Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 19:24:16 -0000 Not sure that would work for IMS, but it's okay in general. Anyplace = where a parameter is allowed can be made to work if it is sent in the = call and accepted in the call back. =20 Brian On Nov 28, 2011, at 2:07 PM, Henning Schulzrinne wrote: > But that's roughly the same authorization (nonce) model you have for = the In-Reply-To. You had said earlier that this works only for = call-backs, but that seems to be true for both. (The https security = properties are the same, either way.) This approach requires no special = modification of anything. >=20 > Henning >=20 > On Nov 28, 2011, at 2:01 PM, Brian Rosen wrote: >=20 >> The original call is set up as a emergency call. In that call is a = token that can be used as a call back authentication token. It's not = that it's a PSAP (although PSAPs may have credentials that prove they = are PSAPs), it's that it's a return call from the original emergency = call. If it's handled within https, it's even somewhat secure. >>=20 >> Brian >> On Nov 28, 2011, at 1:49 PM, Henning Schulzrinne wrote: >>=20 >>> How would a GRUU authorize the caller as "this is a PSAP"? >>>=20 >>> On Nov 28, 2011, at 1:35 PM, Brian Rosen wrote: >>>=20 >>>> One of the things the GRUU got you was a token that could be used = for authorization. It's not just that it's a call back. >>>>=20 >>>> Brian >>>=20 >>=20 >>=20 >=20 From HKaplan@acmepacket.com Mon Nov 28 11:58:43 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F412721F8C50 for ; Mon, 28 Nov 2011 11:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4vkbhHQPXK0 for ; Mon, 28 Nov 2011 11:58:42 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 000DE21F8C00 for ; Mon, 28 Nov 2011 11:58:41 -0800 (PST) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 28 Nov 2011 14:58:40 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.245]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 28 Nov 2011 14:58:40 -0500 From: Hadriel Kaplan To: "DRAGE, Keith (Keith)" Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AQHMrggfPBE1dFos/E+9kH0Ve44rzA== Date: Mon, 28 Nov 2011 19:58:40 +0000 Message-ID: <1FA500FC-B6DB-4B0B-AD82-4DA63F7ED6D1@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D51FE30BD5AC249AA708361553C3545@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: Adam Roach , ECRIT , Paul Kyzivat Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 19:58:43 -0000 If I recall correctly, the reasons given in the Taipei meeting for indicati= ng a PSAP call-back is any "different" from a normal call to a normal GRUU = or a normal AoR or URI target, were so that:=20 (1) the network prioritize the call-back with respect to allocating resour= ces (2) the network bypass certain normal-call "treatments" (3) so that the reached UA could know to immediately answer the call.=20 For (1): if that's not the very definition of the RPH header's purpose, I d= on't know what is. For (2): we have never had a singular defined header or field in SIP which = was intended for this purpose, afaik - basically there are many headers/fie= lds/methods which in combination are used by proxy-ish devices to perform d= ifferent "treatments". In 3GPP, for example, I believe the filter-criteria= can and do use almost any header field. So really there's no field we can= 't use to accomplish this. For (3): using a new RPH namespace value for "psap-callback" actually makes= sense for this, since it's arguably asking the UA to make available its re= sources immediately, without waiting for user consent or to put another cal= l on hold. Having said all that, I'm not super-tied to using the RPH header either - I= just think using a new special GRUU type is wrong, both at an architectura= l level and a practical "it-needs-to-work" level. Even if the RPH field is= lost or modified or ignored, for example, the call will likely succeed - t= hat's a good property to have I would think.=20 -hadriel On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: > Can people indicate why they see a synergy with resource priority. > =20 > This header field is primarily used for giving priority in the network. T= o be used effectively, it needs to be processed first in any message at all= SIP entities, and the rest of the message handling depends on it. > =20 > While there may possibly be a use for Resource-Priority on emergency call= backs, in order to give priority, I would suggest that to give it a purpose= beyond that where priority itself is not needed, is not using that header = for its prime purpose, and indeed detracts from the main usage. > =20 > Further, one thing that could well disappear at country boundaries is the= Resource-Priority header field, because different regulatory regimes have = different sets of rules as to what namespaces may be used, and do not neces= sarily map one to another. Any 3GPP roaming user will need to cross the sam= e country twice (on the signalling path) for the callback call, because the= callback will go via the home network. > =20 > So while I have no axes to grind on losing a GRUU dependency, I do think = Resource-Priority is a poor fit. > =20 > Keith > =20 > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Christer Holmberg > Sent: 24 November 2011 10:51 > To: ECRIT > Cc: 'Adam Roach'; Paul Kyzivat > Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of e= GRUU > =20 > =20 > Hi, > =20 > In Taipei, it was indicated that people would prefer another mechanism th= an a new GRUU type for solving the issue of identifying PSAP callback calls= . > =20 > A new Resource-Priority header field value, that PSAPs would insert in ca= llback calls, was suggested. It would solve the requirement of allowing net= work entities (and the UA) to identity the callback call, e.g. in order to = give special treatment. > =20 > (The requirement to reach the same UA device that made the emergency call= can be solved with the existing GRUU mechanism, so nothing new is needed t= here). > =20 > So, I would like to know whether people are ok with a Resource-Priority a= pproach? > =20 > Regards, > =20 > Christer > =20 > =20 > =20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Mon Nov 28 12:19:29 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA3711E80F1 for ; Mon, 28 Nov 2011 12:19:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLIovuqJ0i1N for ; Mon, 28 Nov 2011 12:19:28 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2719C11E80D7 for ; Mon, 28 Nov 2011 12:19:28 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pASKIsej014120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 28 Nov 2011 15:18:54 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <1FA500FC-B6DB-4B0B-AD82-4DA63F7ED6D1@acmepacket.com> Date: Mon, 28 Nov 2011 15:18:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> <1FA500FC-B6DB-4B0B-AD82-4DA63F7ED6D1@acmepacket.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: Adam Roach , ECRIT , Paul Kyzivat Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 20:19:29 -0000 I see the issues as somewhat orthogonal. Thus, the use of GRUU or = In-Reply-To could easily be combined with RPH. Indeed, we've always distinguished Priority (meant to indicate the = desired priority at the receiving end system) and Resource-Priority = (meant to influence scheduling at intermediate nodes, such as gateways = and proxies). I agree that the fail-safe mode is desirable, in addition to making = spoofing such calls at least modestly difficult. We do not want = telemarketers to bypass call filters by slapping on an RPH. I admit that I still don't see what's wrong with the following = combination: - In-Reply-To allows the UA to match the call to an earlier emergency = call and thus prevents impersonation (weakly, but probably sufficiently = to deal with the most likely threat). It can also be used to bypass end = system call handling. - RPH can be added if needed, but seems likely to have modest to no = effect. Using it to bypass call handling by itself seems like a bad = idea, for the reason noted above. If the user's proxy keeps track of = outbound emergency calls, In-Reply-To works for that as well. - "Priority: emergency" can be used as well, as an indicator for call = handling, but obviously needs some validation. We need to decide whether we require proxies to keep state for recent = emergency calls; otherwise and in the absence of a PKI-like mechanism, = it seems difficult to prevent call impersonation at the user's proxy. There are other ways to solve this; in particular, Kumiko presented the = ARID proposal at the last DISPATCH meeting on how a callee could = validate caller properties. This requires more UA changes, but is = stateless in the UA and works across devices. Henning On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote: >=20 > If I recall correctly, the reasons given in the Taipei meeting for = indicating a PSAP call-back is any "different" from a normal call to a = normal GRUU or a normal AoR or URI target, were so that:=20 > (1) the network prioritize the call-back with respect to = allocating resources > (2) the network bypass certain normal-call "treatments" > (3) so that the reached UA could know to immediately answer the = call.=20 >=20 > For (1): if that's not the very definition of the RPH header's = purpose, I don't know what is. >=20 > For (2): we have never had a singular defined header or field in SIP = which was intended for this purpose, afaik - basically there are many = headers/fields/methods which in combination are used by proxy-ish = devices to perform different "treatments". In 3GPP, for example, I = believe the filter-criteria can and do use almost any header field. So = really there's no field we can't use to accomplish this. >=20 > For (3): using a new RPH namespace value for "psap-callback" actually = makes sense for this, since it's arguably asking the UA to make = available its resources immediately, without waiting for user consent or = to put another call on hold. >=20 > Having said all that, I'm not super-tied to using the RPH header = either - I just think using a new special GRUU type is wrong, both at an = architectural level and a practical "it-needs-to-work" level. Even if = the RPH field is lost or modified or ignored, for example, the call will = likely succeed - that's a good property to have I would think.=20 >=20 > -hadriel >=20 >=20 > On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: >=20 >> Can people indicate why they see a synergy with resource priority. >>=20 >> This header field is primarily used for giving priority in the = network. To be used effectively, it needs to be processed first in any = message at all SIP entities, and the rest of the message handling = depends on it. >>=20 >> While there may possibly be a use for Resource-Priority on emergency = callbacks, in order to give priority, I would suggest that to give it a = purpose beyond that where priority itself is not needed, is not using = that header for its prime purpose, and indeed detracts from the main = usage. >>=20 >> Further, one thing that could well disappear at country boundaries is = the Resource-Priority header field, because different regulatory regimes = have different sets of rules as to what namespaces may be used, and do = not necessarily map one to another. Any 3GPP roaming user will need to = cross the same country twice (on the signalling path) for the callback = call, because the callback will go via the home network. >>=20 >> So while I have no axes to grind on losing a GRUU dependency, I do = think Resource-Priority is a poor fit. >>=20 >> Keith >>=20 >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of Christer Holmberg >> Sent: 24 November 2011 10:51 >> To: ECRIT >> Cc: 'Adam Roach'; Paul Kyzivat >> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead = of eGRUU >>=20 >>=20 >> Hi, >>=20 >> In Taipei, it was indicated that people would prefer another = mechanism than a new GRUU type for solving the issue of identifying PSAP = callback calls. >>=20 >> A new Resource-Priority header field value, that PSAPs would insert = in callback calls, was suggested. It would solve the requirement of = allowing network entities (and the UA) to identity the callback call, = e.g. in order to give special treatment. >>=20 >> (The requirement to reach the same UA device that made the emergency = call can be solved with the existing GRUU mechanism, so nothing new is = needed there). >>=20 >> So, I would like to know whether people are ok with a = Resource-Priority approach? >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 From keith.drage@alcatel-lucent.com Mon Nov 28 12:49:03 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6FF511E80D7 for ; Mon, 28 Nov 2011 12:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.645 X-Spam-Level: X-Spam-Status: No, score=-105.645 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Jk5+o73UtNw for ; Mon, 28 Nov 2011 12:49:03 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id E038711E808E for ; Mon, 28 Nov 2011 12:49:02 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pASKms5L024673 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 28 Nov 2011 21:48:54 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 28 Nov 2011 21:48:53 +0100 From: "DRAGE, Keith (Keith)" To: Hadriel Kaplan Date: Mon, 28 Nov 2011 21:48:52 +0100 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AQHMrggfPBE1dFos/E+9kH0Ve44rzJXCvqVQ Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> <1FA500FC-B6DB-4B0B-AD82-4DA63F7ED6D1@acmepacket.com> In-Reply-To: <1FA500FC-B6DB-4B0B-AD82-4DA63F7ED6D1@acmepacket.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: Adam Roach , ECRIT , Paul Kyzivat Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 20:49:04 -0000 I have no problem with using Resource-Priority for (1). However not many ad= ministrations appear to prioritise callbacks either in the network or in th= e network access. Whether that will change when they have a means to do so = I do not known. It is when RPH is used for the other functions, particularl= y in the absence of a need for (1) that I have issues. I'd add a (4) or possibly a (3A) to your list which is that the UA bypasses= certain normal call treatments (such as removing call deflection from the = user's soft menu or such like). So for both (2) and (4) I would regard as the main uses, and RPH is not a g= ood fit for those two. I would contend that (3) is not a good use of RPH, as RPH works on areas of= trust of the namespace, is the recipient UA in the namespace, and does it = trust the sender? Surely this is the function of the Priority header field.= Indeed RPH specifically does not "asking the UA to make available its reso= urces immediately, without waiting for user consent or to put another call = on hold"; rather it asks the recipient to place the message in a queue appr= opriate to the received namespace (and possibly priority) and handle that q= ueue versus the normal call queue according to the rules of the namespace i= nvolved. As the namespace definitions (as in the RFCs) normally leave that = level of detail to the implementors of the namespace in the closed net of i= mplementing equipment, it is unlikely UA vendors will pick that information= up. Regards Keith > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: 28 November 2011 19:59 > To: DRAGE, Keith (Keith) > Cc: Christer Holmberg; ECRIT; Adam Roach; Paul Kyzivat > Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead > of eGRUU >=20 >=20 > If I recall correctly, the reasons given in the Taipei meeting for > indicating a PSAP call-back is any "different" from a normal call to a > normal GRUU or a normal AoR or URI target, were so that: > (1) the network prioritize the call-back with respect to allocating > resources > (2) the network bypass certain normal-call "treatments" > (3) so that the reached UA could know to immediately answer the call. >=20 > For (1): if that's not the very definition of the RPH header's purpose, I > don't know what is. >=20 > For (2): we have never had a singular defined header or field in SIP whic= h > was intended for this purpose, afaik - basically there are many > headers/fields/methods which in combination are used by proxy-ish devices > to perform different "treatments". In 3GPP, for example, I believe the > filter-criteria can and do use almost any header field. So really there'= s > no field we can't use to accomplish this. >=20 > For (3): using a new RPH namespace value for "psap-callback" actually > makes sense for this, since it's arguably asking the UA to make available > its resources immediately, without waiting for user consent or to put > another call on hold. >=20 > Having said all that, I'm not super-tied to using the RPH header either - > I just think using a new special GRUU type is wrong, both at an > architectural level and a practical "it-needs-to-work" level. Even if th= e > RPH field is lost or modified or ignored, for example, the call will > likely succeed - that's a good property to have I would think. >=20 > -hadriel >=20 >=20 > On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: >=20 > > Can people indicate why they see a synergy with resource priority. > > > > This header field is primarily used for giving priority in the network. > To be used effectively, it needs to be processed first in any message at > all SIP entities, and the rest of the message handling depends on it. > > > > While there may possibly be a use for Resource-Priority on emergency > callbacks, in order to give priority, I would suggest that to give it a > purpose beyond that where priority itself is not needed, is not using tha= t > header for its prime purpose, and indeed detracts from the main usage. > > > > Further, one thing that could well disappear at country boundaries is > the Resource-Priority header field, because different regulatory regimes > have different sets of rules as to what namespaces may be used, and do no= t > necessarily map one to another. Any 3GPP roaming user will need to cross > the same country twice (on the signalling path) for the callback call, > because the callback will go via the home network. > > > > So while I have no axes to grind on losing a GRUU dependency, I do thin= k > Resource-Priority is a poor fit. > > > > Keith > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Christer Holmberg > > Sent: 24 November 2011 10:51 > > To: ECRIT > > Cc: 'Adam Roach'; Paul Kyzivat > > Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of > eGRUU > > > > > > Hi, > > > > In Taipei, it was indicated that people would prefer another mechanism > than a new GRUU type for solving the issue of identifying PSAP callback > calls. > > > > A new Resource-Priority header field value, that PSAPs would insert in > callback calls, was suggested. It would solve the requirement of allowing > network entities (and the UA) to identity the callback call, e.g. in orde= r > to give special treatment. > > > > (The requirement to reach the same UA device that made the emergency > call can be solved with the existing GRUU mechanism, so nothing new is > needed there). > > > > So, I would like to know whether people are ok with a Resource-Priority > approach? > > > > Regards, > > > > Christer > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit From aallen@rim.com Mon Nov 28 13:57:23 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B81211E811F for ; Mon, 28 Nov 2011 13:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJtv3Z3HzJ7d for ; Mon, 28 Nov 2011 13:57:22 -0800 (PST) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8F89D11E80FC for ; Mon, 28 Nov 2011 13:57:21 -0800 (PST) X-AuditID: 0a41282f-b7f2d6d000006826-8c-4ed403bc25e7 Received: from XHT106CNC.rim.net (xht106cnc.rim.net [10.65.22.53]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id F4.3C.26662.CB304DE4; Mon, 28 Nov 2011 21:57:16 +0000 (GMT) Received: from XCT103ADS.rim.net (10.67.111.44) by XHT106CNC.rim.net (10.65.22.53) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 28 Nov 2011 16:57:15 -0500 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT103ADS.rim.net ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.01.0339.001; Mon, 28 Nov 2011 15:57:14 -0600 From: Andrew Allen To: Hadriel Kaplan , "DRAGE, Keith (Keith)" Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AQHMrggj43vMILUn30GVqvlVglAZOZXCzOvw Date: Mon, 28 Nov 2011 21:57:12 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> <1FA500FC-B6DB-4B0B-AD82-4DA63F7ED6D1@acmepacket.com> In-Reply-To: <1FA500FC-B6DB-4B0B-AD82-4DA63F7ED6D1@acmepacket.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.253] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIKsWRmVeSWpSXmKPExsXC5ShmqruH+YqfwZp+VYs9fxexWzQuespq Mffyc3aLp41nGS1WbDjA6sDqsWnyZjaP1md7WT3+vv/A5LFkyU8mj1k7n7AEsEY1MNok5uXl lySWpCqkpBYn2yr5pKYn5igEFGWWJSZXKrhkFifnJGbmphYpKWSm2CqZKCkU5CQmp+am5pXY KiUWFKTmpSjZcSlgABugssw8hdS85PyUzLx0WyXPYH9dCwtTS11DJTtdJJDwjzvj4KxTrAW/ TSpevTrB1sA4W6uLkZNDQsBE4seGV+wQtpjEhXvr2boYuTiEBHqYJLY8nMYI4SxllJjceIUJ pEpIYAujxNzN9SA2m4CyxPLfMxhBbBGBNInWP3PAapgFEiXmTFgANlVYIFjiXf9FdoiaEIkF S1cxQ9hGEl9e7wCLswioSqw73sECYvMKuEnsfXGIGWLxY0aJlufnwRo4BZwk7k/ZALaAUUBW YvfZ61DLxCVuPZnPBPGCgMSSPRD1EgKiEi8f/2OFsBUlFnV+Z4So15FYsPsTG4StLbFs4Wtm iMWCEidnPmGBeFJaYsfJNYwTGCVmIVkxC0n7LCTts5C0L2BkWcUomJtRbGBmkJyXrFeUmauX l1qyiRGcljT0dzD27dU6xCjAwajEw1vFcMVPiDWxrLgy9xCjBAezkgiv7OXLfkK8KYmVValF +fFFpTmpxYcYLYBBNJFZijs5H5gy80rijQ0MUDhK4rwR6nv8hATSgUksOzW1ILUIppWJg1Oq gZF33dE984TOdJf/CIxIq3g7yUJpY/nlrPc23JfXV2zoWDa/t+DEPI+FRndqeGUvlpTtXfVR dE1N44X3/1dsmLNXsVWQ+cJt+x8JG7+L6obO5tPz5TYtqa1vbTCNPBO5rOyZRlt8fP1jrXAZ F22WNgWhNr15rf7MiY5r7tmcWT5huexxh4lB9kosxRmJhlrMRcWJABLePSdkAwAA Cc: Adam Roach , ECRIT , Paul Kyzivat Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Nov 2011 21:57:23 -0000 With regard to 1)2)3) from Hariel 1) This is a new semantic for a GRUU but I don't think inconsistent with it.= A GRUU is just a URI and there is no reason a service provider cannot prior= itize handling of requests destined for certain URIs over other URIs. In fac= t they may do this already (for example when the R-URI contains the SOS URN)= . 2) Request's destined for GRUUs often would override call features (particul= arly those that would result in the request being redirected to a different= recipient other than that identified by the GRUU). So this seems to me perf= ectly consistent with GRUU usage and properties. 3) Determining whether to answer or not answer a call was one of the primary= reasons for being able to mint multiple but unique temporary GRUUs. So that= the caller (or calling UA) can identify the source (or type of source) of t= he incoming request based on knowing the purpose of the outgoing request tha= t provided the GRUU to the other party in the first place. This was the know= ing when the car salesman is calling you back privacy issue with regard to G= RUUs. So having a UA determine whether to accept a call based or not based o= n a particular GRUU being received in the R-URI seems totally appropriate to= me. I am sure we can come up with all kinds of new ways to indicate this but bas= ing this on the GRUU mechanism provides most of the properties that we need,= like temporary GRUUs, emergency GRUUs can be invalidated and new ones issue= d by the service provider to minimize the opportunity for abuse by other par= ties that might obtain them (if we define a new header or magic predefined t= oken what prevents someone else using it to spoof an emergency call back?).= Emergency GRUU also builds upon the existing mechanisms for GRUU allocation= and routing which we have already defined. In any case the PSAP needs to us= e a GRUU in the R-URI to ensure that the original terminal that placed the e= mergency call is reached so why not make this GRUU also the means of identif= ying that this is an emergency call back? Not being in Taipei was there a problem identified with the emergency GRUU p= roposal? Andrew > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Hadriel Kaplan > Sent: Monday, November 28, 2011 1:59 PM > To: DRAGE, Keith (Keith) > Cc: Adam Roach; ECRIT; Paul Kyzivat > Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead > of eGRUU > > > If I recall correctly, the reasons given in the Taipei meeting for > indicating a PSAP call-back is any "different" from a normal call to a > normal GRUU or a normal AoR or URI target, were so that: > (1) the network prioritize the call-back with respect to allocating > resources > (2) the network bypass certain normal-call "treatments" > (3) so that the reached UA could know to immediately answer the > call. > > For (1): if that's not the very definition of the RPH header's purpose, I > don't know what is. > > For (2): we have never had a singular defined header or field in SIP which > was intended for this purpose, afaik - basically there are many > headers/fields/methods which in combination are used by proxy-ish devices > to perform different "treatments". In 3GPP, for example, I believe the > filter-criteria can and do use almost any header field. So really there's > no field we can't use to accomplish this. > > For (3): using a new RPH namespace value for "psap-callback" actually > makes sense for this, since it's arguably asking the UA to make available > its resources immediately, without waiting for user consent or to put > another call on hold. > > Having said all that, I'm not super-tied to using the RPH header either - > I just think using a new special GRUU type is wrong, both at an > architectural level and a practical "it-needs-to-work" level. Even if the > RPH field is lost or modified or ignored, for example, the call will > likely succeed - that's a good property to have I would think. > > -hadriel > > > On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: > > > Can people indicate why they see a synergy with resource priority. > > > > This header field is primarily used for giving priority in the network. > To be used effectively, it needs to be processed first in any message at > all SIP entities, and the rest of the message handling depends on it. > > > > While there may possibly be a use for Resource-Priority on emergency > callbacks, in order to give priority, I would suggest that to give it a > purpose beyond that where priority itself is not needed, is not using that > header for its prime purpose, and indeed detracts from the main usage. > > > > Further, one thing that could well disappear at country boundaries is > the Resource-Priority header field, because different regulatory regimes > have different sets of rules as to what namespaces may be used, and do not > necessarily map one to another. Any 3GPP roaming user will need to cross > the same country twice (on the signalling path) for the callback call, > because the callback will go via the home network. > > > > So while I have no axes to grind on losing a GRUU dependency, I do think > Resource-Priority is a poor fit. > > > > Keith > > > > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf > Of Christer Holmberg > > Sent: 24 November 2011 10:51 > > To: ECRIT > > Cc: 'Adam Roach'; Paul Kyzivat > > Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of > eGRUU > > > > > > Hi, > > > > In Taipei, it was indicated that people would prefer another mechanism > than a new GRUU type for solving the issue of identifying PSAP callback > calls. > > > > A new Resource-Priority header field value, that PSAPs would insert in > callback calls, was suggested. It would solve the requirement of allowing > network entities (and the UA) to identity the callback call, e.g. in order > to give special treatment. > > > > (The requirement to reach the same UA device that made the emergency > call can be solved with the existing GRUU mechanism, so nothing new is > needed there). > > > > So, I would like to know whether people are ok with a Resource-Priority > approach? > > > > Regards, > > > > Christer > > > > > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Tue Nov 29 01:51:30 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC9A21F8B82 for ; Tue, 29 Nov 2011 01:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a46o32WWrWrv for ; Tue, 29 Nov 2011 01:51:29 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC7E21F8B80 for ; Tue, 29 Nov 2011 01:51:29 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-dc-4ed4ab1f7803 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3C.14.09514.F1BA4DE4; Tue, 29 Nov 2011 10:51:27 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Tue, 29 Nov 2011 10:51:27 +0100 From: Christer Holmberg To: Henning Schulzrinne , Hadriel Kaplan Date: Tue, 29 Nov 2011 10:51:25 +0100 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AcyuCwpAx06SFTh4RMObm1IOVNTNIwAX2DQA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A8A8519@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> <1FA500FC-B6DB-4B0B-AD82-4DA63F7ED6D1@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , ECRIT , Paul Kyzivat Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 09:51:30 -0000 =20 Hi, First, some background on the new gruu type: I had made the assumption (whi= ch turned out to be false) that we have very little influense when it comes= to PSAP behavior. So, using a new GRUU type, the UA would "provide" the id= entifier to the PSAP in the Contact header field of the emergency call from= the UE, and we would then only have to assume that the PSAP uses that Cont= act when making the PSAP Callback. An advantage of NOT using a new gruu type, but rather something generated b= y the PSAP itself, is of course that networks can identity PSAP Callbacks a= lso towards UAs that don't support the new gruu type. Second, regarding usage of In-Reply-To: while it may allow the UA to match = the calls, it won't work for network entities - not even if the network ent= ities are stateful, as the emergency call, and the associated PSAP Callback= , might not traverse the same network entities. As Keith said, at least in = a 3GPP roaming scenario, the PSAP Callback will traverse the home network. In addition, In-Reply-To contains a Call-Id, and we all know what SBCs etc = can do to those :) Regards, Christer > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Henning Schulzrinne > Sent: 28. marraskuuta 2011 22:19 > To: Hadriel Kaplan > Cc: Adam Roach; ECRIT; Paul Kyzivat > Subject: Re: [Ecrit] PSAP Callback indication:=20 > Resrouce-Priority instead of eGRUU >=20 > I see the issues as somewhat orthogonal. Thus, the use of=20 > GRUU or In-Reply-To could easily be combined with RPH. >=20 > Indeed, we've always distinguished Priority (meant to=20 > indicate the desired priority at the receiving end system)=20 > and Resource-Priority (meant to influence scheduling at=20 > intermediate nodes, such as gateways and proxies). >=20 > I agree that the fail-safe mode is desirable, in addition to=20 > making spoofing such calls at least modestly difficult. We do=20 > not want telemarketers to bypass call filters by slapping on an RPH. >=20 > I admit that I still don't see what's wrong with the=20 > following combination: >=20 > - In-Reply-To allows the UA to match the call to an earlier=20 > emergency call and thus prevents impersonation (weakly, but=20 > probably sufficiently to deal with the most likely threat).=20 > It can also be used to bypass end system call handling. >=20 > - RPH can be added if needed, but seems likely to have modest=20 > to no effect. Using it to bypass call handling by itself=20 > seems like a bad idea, for the reason noted above. If the=20 > user's proxy keeps track of outbound emergency calls,=20 > In-Reply-To works for that as well. >=20 > - "Priority: emergency" can be used as well, as an indicator=20 > for call handling, but obviously needs some validation. >=20 > We need to decide whether we require proxies to keep state=20 > for recent emergency calls; otherwise and in the absence of a=20 > PKI-like mechanism, it seems difficult to prevent call=20 > impersonation at the user's proxy. >=20 > There are other ways to solve this; in particular, Kumiko=20 > presented the ARID proposal at the last DISPATCH meeting on=20 > how a callee could validate caller properties. This requires=20 > more UA changes, but is stateless in the UA and works across devices. >=20 > Henning >=20 > On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote: >=20 > >=20 > > If I recall correctly, the reasons given in the Taipei=20 > meeting for indicating a PSAP call-back is any "different"=20 > from a normal call to a normal GRUU or a normal AoR or URI=20 > target, were so that:=20 > > (1) the network prioritize the call-back with respect=20 > to allocating resources > > (2) the network bypass certain normal-call "treatments" > > (3) so that the reached UA could know to immediately=20 > answer the call.=20 > >=20 > > For (1): if that's not the very definition of the RPH=20 > header's purpose, I don't know what is. > >=20 > > For (2): we have never had a singular defined header or=20 > field in SIP which was intended for this purpose, afaik -=20 > basically there are many headers/fields/methods which in=20 > combination are used by proxy-ish devices to perform=20 > different "treatments". In 3GPP, for example, I believe the=20 > filter-criteria can and do use almost any header field. So=20 > really there's no field we can't use to accomplish this. > >=20 > > For (3): using a new RPH namespace value for=20 > "psap-callback" actually makes sense for this, since it's=20 > arguably asking the UA to make available its resources=20 > immediately, without waiting for user consent or to put=20 > another call on hold. > >=20 > > Having said all that, I'm not super-tied to using the RPH=20 > header either - I just think using a new special GRUU type is=20 > wrong, both at an architectural level and a practical=20 > "it-needs-to-work" level. Even if the RPH field is lost or=20 > modified or ignored, for example, the call will likely=20 > succeed - that's a good property to have I would think.=20 > >=20 > > -hadriel > >=20 > >=20 > > On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: > >=20 > >> Can people indicate why they see a synergy with resource priority. > >>=20 > >> This header field is primarily used for giving priority in=20 > the network. To be used effectively, it needs to be processed=20 > first in any message at all SIP entities, and the rest of the=20 > message handling depends on it. > >>=20 > >> While there may possibly be a use for Resource-Priority on=20 > emergency callbacks, in order to give priority, I would=20 > suggest that to give it a purpose beyond that where priority=20 > itself is not needed, is not using that header for its prime=20 > purpose, and indeed detracts from the main usage. > >>=20 > >> Further, one thing that could well disappear at country=20 > boundaries is the Resource-Priority header field, because=20 > different regulatory regimes have different sets of rules as=20 > to what namespaces may be used, and do not necessarily map=20 > one to another. Any 3GPP roaming user will need to cross the=20 > same country twice (on the signalling path) for the callback=20 > call, because the callback will go via the home network. > >>=20 > >> So while I have no axes to grind on losing a GRUU=20 > dependency, I do think Resource-Priority is a poor fit. > >>=20 > >> Keith > >>=20 > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >> Behalf Of Christer Holmberg > >> Sent: 24 November 2011 10:51 > >> To: ECRIT > >> Cc: 'Adam Roach'; Paul Kyzivat > >> Subject: [Ecrit] PSAP Callback indication:=20 > Resrouce-Priority instead=20 > >> of eGRUU > >>=20 > >>=20 > >> Hi, > >>=20 > >> In Taipei, it was indicated that people would prefer=20 > another mechanism than a new GRUU type for solving the issue=20 > of identifying PSAP callback calls. > >>=20 > >> A new Resource-Priority header field value, that PSAPs=20 > would insert in callback calls, was suggested. It would solve=20 > the requirement of allowing network entities (and the UA) to=20 > identity the callback call, e.g. in order to give special treatment. > >>=20 > >> (The requirement to reach the same UA device that made the=20 > emergency call can be solved with the existing GRUU=20 > mechanism, so nothing new is needed there). > >>=20 > >> So, I would like to know whether people are ok with a=20 > Resource-Priority approach? > >>=20 > >> Regards, > >>=20 > >> Christer > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From jgunn6@csc.com Tue Nov 29 09:17:08 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0A81F0C6E; Tue, 29 Nov 2011 09:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vni1VGx9ZxMD; Tue, 29 Nov 2011 09:17:07 -0800 (PST) Received: from mail170.messagelabs.com (mail170.messagelabs.com [216.82.253.227]) by ietfa.amsl.com (Postfix) with ESMTP id C4FC01F0C6D; Tue, 29 Nov 2011 09:17:06 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-3.tower-170.messagelabs.com!1322587023!48441182!1 X-Originating-IP: [20.137.2.88] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29189 invoked from network); 29 Nov 2011 17:17:04 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-3.tower-170.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Nov 2011 17:17:04 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pATHGxjF029516; Tue, 29 Nov 2011 12:17:00 -0500 In-Reply-To: References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> <1FA500FC-B6DB-4B0B-AD82-4DA63F7ED6D1@acmepacket.com> To: Henning Schulzrinne MIME-Version: 1.0 X-KeepSent: 73261E82:8C0FE663-85257957:005D2873; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP1 SHF139 March 01, 2011 From: Janet P Gunn Message-ID: Date: Tue, 29 Nov 2011 12:16:56 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 11/29/2011 12:14:40 PM, Serialize complete at 11/29/2011 12:14:40 PM Content-Type: multipart/alternative; boundary="=_alternative 005EEFD885257957_=" Cc: Paul Kyzivat , Adam Roach , ECRIT , ecrit-bounces@ietf.org Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 17:17:08 -0000 This is a multipart message in MIME format. --=_alternative 005EEFD885257957_= Content-Type: text/plain; charset="US-ASCII" With regard to the use of a new RPH namespace to trigger special handling or treatment in the network , I guess it depends on what you mean by "bypass call handling" "bypass ... treatments" Requirement 13 of RFC 5390 (Requirements for Management of Overload in the Session Initiation Protocol) says REQ 13: The mechanism must not dictate a specific algorithm for prioritizing the processing of work within a proxy during times of overload. It must permit a proxy to prioritize requests based on any local policy, so that certain ones (such as a call for emergency services or a call with a specific value of the Resource-Priority header field [RFC4412]) are given preferential treatment, such as not being dropped, being given additional retransmission, or being processed ahead of others. This explicitly names the RPH header as a way to identify calls needing "special treatment" in the face of SIP overload. Not a complete "bypass", but definitely a "special treatment". WRT "We do not want telemarketers to bypass call filters by slapping on an RPH." This is true of any use of any RPH namespace. Use of RPH must always be combined with appropriate security/authentication/authorization measures to ensure that unauthorized entities can not "slap on an RPH". I agree that, in principle, "Priority" rather than "Resource Priority" is the appropriate way to inform the destination that special treatment at the destination is requested. However anyone can "slap on a Priority header", as there is no associated security/authentication/authorization . Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: Henning Schulzrinne To: Hadriel Kaplan Cc: Adam Roach , ECRIT , Paul Kyzivat Date: 11/28/2011 03:19 PM Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Sent by: ecrit-bounces@ietf.org I see the issues as somewhat orthogonal. Thus, the use of GRUU or In-Reply-To could easily be combined with RPH. Indeed, we've always distinguished Priority (meant to indicate the desired priority at the receiving end system) and Resource-Priority (meant to influence scheduling at intermediate nodes, such as gateways and proxies). I agree that the fail-safe mode is desirable, in addition to making spoofing such calls at least modestly difficult. We do not want telemarketers to bypass call filters by slapping on an RPH. I admit that I still don't see what's wrong with the following combination: - In-Reply-To allows the UA to match the call to an earlier emergency call and thus prevents impersonation (weakly, but probably sufficiently to deal with the most likely threat). It can also be used to bypass end system call handling. - RPH can be added if needed, but seems likely to have modest to no effect. Using it to bypass call handling by itself seems like a bad idea, for the reason noted above. If the user's proxy keeps track of outbound emergency calls, In-Reply-To works for that as well. - "Priority: emergency" can be used as well, as an indicator for call handling, but obviously needs some validation. We need to decide whether we require proxies to keep state for recent emergency calls; otherwise and in the absence of a PKI-like mechanism, it seems difficult to prevent call impersonation at the user's proxy. There are other ways to solve this; in particular, Kumiko presented the ARID proposal at the last DISPATCH meeting on how a callee could validate caller properties. This requires more UA changes, but is stateless in the UA and works across devices. Henning On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote: > > If I recall correctly, the reasons given in the Taipei meeting for indicating a PSAP call-back is any "different" from a normal call to a normal GRUU or a normal AoR or URI target, were so that: > (1) the network prioritize the call-back with respect to allocating resources > (2) the network bypass certain normal-call "treatments" > (3) so that the reached UA could know to immediately answer the call. > > For (1): if that's not the very definition of the RPH header's purpose, I don't know what is. > > For (2): we have never had a singular defined header or field in SIP which was intended for this purpose, afaik - basically there are many headers/fields/methods which in combination are used by proxy-ish devices to perform different "treatments". In 3GPP, for example, I believe the filter-criteria can and do use almost any header field. So really there's no field we can't use to accomplish this. > > For (3): using a new RPH namespace value for "psap-callback" actually makes sense for this, since it's arguably asking the UA to make available its resources immediately, without waiting for user consent or to put another call on hold. > > Having said all that, I'm not super-tied to using the RPH header either - I just think using a new special GRUU type is wrong, both at an architectural level and a practical "it-needs-to-work" level. Even if the RPH field is lost or modified or ignored, for example, the call will likely succeed - that's a good property to have I would think. > > -hadriel > > > On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: > >> Can people indicate why they see a synergy with resource priority. >> >> This header field is primarily used for giving priority in the network. To be used effectively, it needs to be processed first in any message at all SIP entities, and the rest of the message handling depends on it. >> >> While there may possibly be a use for Resource-Priority on emergency callbacks, in order to give priority, I would suggest that to give it a purpose beyond that where priority itself is not needed, is not using that header for its prime purpose, and indeed detracts from the main usage. >> >> Further, one thing that could well disappear at country boundaries is the Resource-Priority header field, because different regulatory regimes have different sets of rules as to what namespaces may be used, and do not necessarily map one to another. Any 3GPP roaming user will need to cross the same country twice (on the signalling path) for the callback call, because the callback will go via the home network. >> >> So while I have no axes to grind on losing a GRUU dependency, I do think Resource-Priority is a poor fit. >> >> Keith >> >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 24 November 2011 10:51 >> To: ECRIT >> Cc: 'Adam Roach'; Paul Kyzivat >> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU >> >> >> Hi, >> >> In Taipei, it was indicated that people would prefer another mechanism than a new GRUU type for solving the issue of identifying PSAP callback calls. >> >> A new Resource-Priority header field value, that PSAPs would insert in callback calls, was suggested. It would solve the requirement of allowing network entities (and the UA) to identity the callback call, e.g. in order to give special treatment. >> >> (The requirement to reach the same UA device that made the emergency call can be solved with the existing GRUU mechanism, so nothing new is needed there). >> >> So, I would like to know whether people are ok with a Resource-Priority approach? >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --=_alternative 005EEFD885257957_= Content-Type: text/html; charset="US-ASCII" With regard to the use of a new RPH namespace to trigger special handling or treatment in the network , I guess it depends on what you mean by
"bypass call handling"
"bypass ... treatments"

Requirement 13 of  RFC 5390 (Requirements for Management of Overload in the  Session Initiation Protocol) says

REQ 13:  The mechanism must not dictate a specific algorithm for
      prioritizing the processing of work within a proxy during times of
      overload.  It must permit a proxy to prioritize requests based on
      any local policy, so that certain ones (such as a call for
      emergency services or a call with a specific value of the
      Resource-Priority header field [RFC4412]) are given preferential
      treatment, such as not being dropped, being given additional
      retransmission, or being processed ahead of others.

This explicitly names  the RPH header as a way to identify calls needing "special treatment" in the face of SIP overload.  Not a complete "bypass", but definitely a "special treatment".

WRT "We do not want telemarketers to bypass call filters by slapping on an RPH." This is true of any use of any RPH namespace.  Use of RPH must always be combined with appropriate security/authentication/authorization  measures to ensure that unauthorized entities can not "slap on an RPH".

I agree that, in principle, "Priority" rather than "Resource Priority" is the appropriate way to inform the destination  that special treatment at the destination is requested.  However anyone can "slap on a Priority header", as there is no associated security/authentication/authorization .

Janet


This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.



From:        Henning Schulzrinne <hgs@cs.columbia.edu>
To:        Hadriel Kaplan <HKaplan@acmepacket.com>
Cc:        Adam Roach <adam@nostrum.com>, ECRIT <ecrit@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Date:        11/28/2011 03:19 PM
Subject:        Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead        of        eGRUU
Sent by:        ecrit-bounces@ietf.org



I see the issues as somewhat orthogonal. Thus, the use of GRUU or In-Reply-To could easily be combined with RPH.

Indeed, we've always distinguished Priority (meant to indicate the desired priority at the receiving end system) and Resource-Priority (meant to influence scheduling at intermediate nodes, such as gateways and proxies).

I agree that the fail-safe mode is desirable, in addition to making spoofing such calls at least modestly difficult. We do not want telemarketers to bypass call filters by slapping on an RPH.

I admit that I still don't see what's wrong with the following combination:

- In-Reply-To allows the UA to match the call to an earlier emergency call and thus prevents impersonation (weakly, but probably sufficiently to deal with the most likely threat). It can also be used to bypass end system call handling.

- RPH can be added if needed, but seems likely to have modest to no effect. Using it to bypass call handling by itself seems like a bad idea, for the reason noted above. If the user's proxy keeps track of outbound emergency calls, In-Reply-To works for that as well.

- "Priority: emergency" can be used as well, as an indicator for call handling, but obviously needs some validation.

We need to decide whether we require proxies to keep state for recent emergency calls; otherwise and in the absence of a PKI-like mechanism, it seems difficult to prevent call impersonation at the user's proxy.

There are other ways to solve this; in particular, Kumiko presented the ARID proposal at the last DISPATCH meeting on how a callee could validate caller properties. This requires more UA changes, but is stateless in the UA and works across devices.

Henning

On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote:

>
> If I recall correctly, the reasons given in the Taipei meeting for indicating a PSAP call-back is any "different" from a normal call to a normal GRUU or a normal AoR or URI target, were so that:
>                  (1) the network prioritize the call-back with respect to allocating resources
>                  (2) the network bypass certain normal-call "treatments"
>                  (3) so that the reached UA could know to immediately answer the call.
>
> For (1): if that's not the very definition of the RPH header's purpose, I don't know what is.
>
> For (2): we have never had a singular defined header or field in SIP which was intended for this purpose, afaik - basically there are many headers/fields/methods which in combination are used by proxy-ish devices to perform different "treatments".  In 3GPP, for example, I believe the filter-criteria can and do use almost any header field.  So really there's no field we can't use to accomplish this.
>
> For (3): using a new RPH namespace value for "psap-callback" actually makes sense for this, since it's arguably asking the UA to make available its resources immediately, without waiting for user consent or to put another call on hold.
>
> Having said all that, I'm not super-tied to using the RPH header either - I just think using a new special GRUU type is wrong, both at an architectural level and a practical "it-needs-to-work" level.  Even if the RPH field is lost or modified or ignored, for example, the call will likely succeed - that's a good property to have I would think.
>
> -hadriel
>
>
> On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote:
>
>> Can people indicate why they see a synergy with resource priority.
>>
>> This header field is primarily used for giving priority in the network. To be used effectively, it needs to be processed first in any message at all SIP entities, and the rest of the message handling depends on it.
>>
>> While there may possibly be a use for Resource-Priority on emergency callbacks, in order to give priority, I would suggest that to give it a purpose beyond that where priority itself is not needed, is not using that header for its prime purpose, and indeed detracts from the main usage.
>>
>> Further, one thing that could well disappear at country boundaries is the Resource-Priority header field, because different regulatory regimes have different sets of rules as to what namespaces may be used, and do not necessarily map one to another. Any 3GPP roaming user will need to cross the same country twice (on the signalling path) for the callback call, because the callback will go via the home network.
>>
>> So while I have no axes to grind on losing a GRUU dependency, I do think Resource-Priority is a poor fit.
>>
>> Keith
>>
>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
>> Sent: 24 November 2011 10:51
>> To: ECRIT
>> Cc: 'Adam Roach'; Paul Kyzivat
>> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU
>>
>>
>> Hi,
>>
>> In Taipei, it was indicated that people would prefer another mechanism than a new GRUU type for solving the issue of identifying PSAP callback calls.
>>
>> A new Resource-Priority header field value, that PSAPs would insert in callback calls, was suggested. It would solve the requirement of allowing network entities (and the UA) to identity the callback call, e.g. in order to give special treatment.
>>
>> (The requirement to reach the same UA device that made the emergency call can be solved with the existing GRUU mechanism, so nothing new is needed there).
>>
>> So, I would like to know whether people are ok with a Resource-Priority approach?
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--=_alternative 005EEFD885257957_=-- From hgs@cs.columbia.edu Tue Nov 29 09:41:46 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A1221F8B76; Tue, 29 Nov 2011 09:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-oQQRkX8myn; Tue, 29 Nov 2011 09:41:44 -0800 (PST) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9E86821F8AFD; Tue, 29 Nov 2011 09:41:44 -0800 (PST) Received: from ice.cs.columbia.edu (ice.cs.columbia.edu [128.59.18.177]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pATHfc1U004799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Nov 2011 12:41:38 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_5703194A-B940-46D6-84B7-E7448C66527C" From: Henning Schulzrinne In-Reply-To: Date: Tue, 29 Nov 2011 12:41:37 -0500 Message-Id: <96B2009A-1C87-4070-8CB8-F1778664B16B@cs.columbia.edu> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A81564F@ESESSCMS0356.eemea.ericsson.se> <1FA500FC-B6DB-4B0B-AD82-4DA63F7ED6D1@acmepacket.com> To: Janet P Gunn X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: Paul Kyzivat , Adam Roach , ECRIT , ecrit-bounces@ietf.org Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 17:41:46 -0000 --Apple-Mail=_5703194A-B940-46D6-84B7-E7448C66527C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Janet, I think we all agree that no label by itself (whether some special =46rom = value, a Priority header or RPH) is sufficient to prevent abuse. It = would only be useful in conjunction with another mechanism that allows = caller-trusted parties, including the UA, to determine that the call is = indeed in response to an earlier emergency call, or, alternatively, that = only such calls can reach a special address, such as a GRUU. The logic = would be something like if (call claims to be an emergency-callback) check if earlier call was indeed an emergency call Henning On Nov 29, 2011, at 12:16 PM, Janet P Gunn wrote: > With regard to the use of a new RPH namespace to trigger special = handling or treatment in the network , I guess it depends on what you = mean by=20 > "bypass call handling"=20 > "bypass ... treatments"=20 >=20 > Requirement 13 of RFC 5390 (Requirements for Management of Overload = in the Session Initiation Protocol) says=20 >=20 > REQ 13: The mechanism must not dictate a specific algorithm for=20 > prioritizing the processing of work within a proxy during times = of=20 > overload. It must permit a proxy to prioritize requests based = on=20 > any local policy, so that certain ones (such as a call for=20 > emergency services or a call with a specific value of the=20 > Resource-Priority header field [RFC4412]) are given preferential=20= > treatment, such as not being dropped, being given additional=20 > retransmission, or being processed ahead of others.=20 >=20 > This explicitly names the RPH header as a way to identify calls = needing "special treatment" in the face of SIP overload. Not a complete = "bypass", but definitely a "special treatment".=20 >=20 > WRT "We do not want telemarketers to bypass call filters by slapping = on an RPH." This is true of any use of any RPH namespace. Use of RPH = must always be combined with appropriate = security/authentication/authorization measures to ensure that = unauthorized entities can not "slap on an RPH".=20 >=20 > I agree that, in principle, "Priority" rather than "Resource Priority" = is the appropriate way to inform the destination that special treatment = at the destination is requested. However anyone can "slap on a Priority = header", as there is no associated security/authentication/authorization = .=20 >=20 > Janet=20 >=20 >=20 > This is a PRIVATE message. If you are not the intended recipient, = please delete without copying and kindly advise us by e-mail of the = mistake in delivery. NOTE: Regardless of content, this e-mail shall not = operate to bind CSC to any order or other contract unless pursuant to = explicit written agreement or government initiative expressly permitting = the use of e-mail for such purpose.=20 >=20 >=20 >=20 > From: Henning Schulzrinne =20 > To: Hadriel Kaplan =20 > Cc: Adam Roach , ECRIT , Paul = Kyzivat =20 > Date: 11/28/2011 03:19 PM=20 > Subject: Re: [Ecrit] PSAP Callback indication: = Resrouce-Priority instead of eGRUU=20 > Sent by: ecrit-bounces@ietf.org=20 >=20 >=20 >=20 > I see the issues as somewhat orthogonal. Thus, the use of GRUU or = In-Reply-To could easily be combined with RPH. >=20 > Indeed, we've always distinguished Priority (meant to indicate the = desired priority at the receiving end system) and Resource-Priority = (meant to influence scheduling at intermediate nodes, such as gateways = and proxies). >=20 > I agree that the fail-safe mode is desirable, in addition to making = spoofing such calls at least modestly difficult. We do not want = telemarketers to bypass call filters by slapping on an RPH. >=20 > I admit that I still don't see what's wrong with the following = combination: >=20 > - In-Reply-To allows the UA to match the call to an earlier emergency = call and thus prevents impersonation (weakly, but probably sufficiently = to deal with the most likely threat). It can also be used to bypass end = system call handling. >=20 > - RPH can be added if needed, but seems likely to have modest to no = effect. Using it to bypass call handling by itself seems like a bad = idea, for the reason noted above. If the user's proxy keeps track of = outbound emergency calls, In-Reply-To works for that as well. >=20 > - "Priority: emergency" can be used as well, as an indicator for call = handling, but obviously needs some validation. >=20 > We need to decide whether we require proxies to keep state for recent = emergency calls; otherwise and in the absence of a PKI-like mechanism, = it seems difficult to prevent call impersonation at the user's proxy. >=20 > There are other ways to solve this; in particular, Kumiko presented = the ARID proposal at the last DISPATCH meeting on how a callee could = validate caller properties. This requires more UA changes, but is = stateless in the UA and works across devices. >=20 > Henning >=20 > On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote: >=20 > >=20 > > If I recall correctly, the reasons given in the Taipei meeting for = indicating a PSAP call-back is any "different" from a normal call to a = normal GRUU or a normal AoR or URI target, were so that:=20 > > (1) the network prioritize the call-back with = respect to allocating resources > > (2) the network bypass certain normal-call = "treatments" > > (3) so that the reached UA could know to = immediately answer the call.=20 > >=20 > > For (1): if that's not the very definition of the RPH header's = purpose, I don't know what is. > >=20 > > For (2): we have never had a singular defined header or field in SIP = which was intended for this purpose, afaik - basically there are many = headers/fields/methods which in combination are used by proxy-ish = devices to perform different "treatments". In 3GPP, for example, I = believe the filter-criteria can and do use almost any header field. So = really there's no field we can't use to accomplish this. > >=20 > > For (3): using a new RPH namespace value for "psap-callback" = actually makes sense for this, since it's arguably asking the UA to make = available its resources immediately, without waiting for user consent or = to put another call on hold. > >=20 > > Having said all that, I'm not super-tied to using the RPH header = either - I just think using a new special GRUU type is wrong, both at an = architectural level and a practical "it-needs-to-work" level. Even if = the RPH field is lost or modified or ignored, for example, the call will = likely succeed - that's a good property to have I would think.=20 > >=20 > > -hadriel > >=20 > >=20 > > On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: > >=20 > >> Can people indicate why they see a synergy with resource priority. > >>=20 > >> This header field is primarily used for giving priority in the = network. To be used effectively, it needs to be processed first in any = message at all SIP entities, and the rest of the message handling = depends on it. > >>=20 > >> While there may possibly be a use for Resource-Priority on = emergency callbacks, in order to give priority, I would suggest that to = give it a purpose beyond that where priority itself is not needed, is = not using that header for its prime purpose, and indeed detracts from = the main usage. > >>=20 > >> Further, one thing that could well disappear at country boundaries = is the Resource-Priority header field, because different regulatory = regimes have different sets of rules as to what namespaces may be used, = and do not necessarily map one to another. Any 3GPP roaming user will = need to cross the same country twice (on the signalling path) for the = callback call, because the callback will go via the home network. > >>=20 > >> So while I have no axes to grind on losing a GRUU dependency, I do = think Resource-Priority is a poor fit. > >>=20 > >> Keith > >>=20 > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf Of Christer Holmberg > >> Sent: 24 November 2011 10:51 > >> To: ECRIT > >> Cc: 'Adam Roach'; Paul Kyzivat > >> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority = instead of eGRUU > >>=20 > >>=20 > >> Hi, > >>=20 > >> In Taipei, it was indicated that people would prefer another = mechanism than a new GRUU type for solving the issue of identifying PSAP = callback calls. > >>=20 > >> A new Resource-Priority header field value, that PSAPs would insert = in callback calls, was suggested. It would solve the requirement of = allowing network entities (and the UA) to identity the callback call, = e.g. in order to give special treatment. > >>=20 > >> (The requirement to reach the same UA device that made the = emergency call can be solved with the existing GRUU mechanism, so = nothing new is needed there). > >>=20 > >> So, I would like to know whether people are ok with a = Resource-Priority approach? > >>=20 > >> Regards, > >>=20 > >> Christer > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit >=20 --Apple-Mail=_5703194A-B940-46D6-84B7-E7448C66527C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
With regard to the use of a new RPH = namespace to trigger special handling or treatment in the network , I guess it = depends on what you mean by
"bypass call handling"
"bypass ... treatments"

Requirement 13 of  RFC = 5390 (Requirements for Management of Overload in the  Session Initiation Protocol) = says

REQ 13:  The mechanism = must not dictate a specific algorithm for
      = prioritizing the processing of work within a proxy during times of
      overload. =  It must permit a proxy to prioritize requests based on
      any local = policy, so that certain ones (such as a call for
      emergency = services or a call with a specific value of the
      = Resource-Priority header field [RFC4412]) are given preferential
      treatment, = such as not being dropped, being given additional
      = retransmission, or being processed ahead of others.

This explicitly names  the = RPH header as a way to identify calls needing "special treatment" in the face of SIP overload.  Not a complete "bypass", but definitely a "special treatment".

WRT "We do not want telemarketers to bypass call filters by slapping on an = RPH." This is true of any use of any RPH namespace.  Use of RPH must = always be combined with appropriate security/authentication/authorization =  measures to ensure that unauthorized entities can not "slap on an RPH".

I agree that, in principle, = "Priority" rather than "Resource Priority" is the appropriate way to inform the destination  that special treatment at the destination is = requested.  However anyone can "slap on a Priority header", as there is no associated security/authentication/authorization .

Janet


This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit = written agreement or government initiative expressly permitting the use of = e-mail for such purpose.



From:   =      Henning Schulzrinne <hgs@cs.columbia.edu>
To:   =      Hadriel Kaplan <HKaplan@acmepacket.com>
Cc:   =      Adam Roach <adam@nostrum.com>, ECRIT <ecrit@ietf.org>, Paul = Kyzivat <pkyzivat@alum.mit.edu>=
Date:   =      11/28/2011 03:19 = PM
Subject: =        Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead        of        eGRUU
Sent by: =        ecrit-bounces@ietf.org



I see the issues as somewhat orthogonal. Thus, = the use of GRUU or In-Reply-To could easily be combined with RPH.

Indeed, we've always distinguished Priority (meant to indicate the = desired priority at the receiving end system) and Resource-Priority (meant to = influence scheduling at intermediate nodes, such as gateways and proxies).

I agree that the fail-safe mode is desirable, in addition to making = spoofing such calls at least modestly difficult. We do not want telemarketers to bypass call filters by slapping on an RPH.

I admit that I still don't see what's wrong with the following = combination:

- In-Reply-To allows the UA to match the call to an earlier emergency = call and thus prevents impersonation (weakly, but probably sufficiently to = deal with the most likely threat). It can also be used to bypass end system call handling.

- RPH can be added if needed, but seems likely to have modest to no = effect. Using it to bypass call handling by itself seems like a bad idea, for = the reason noted above. If the user's proxy keeps track of outbound = emergency calls, In-Reply-To works for that as well.

- "Priority: emergency" can be used as well, as an indicator for call handling, but obviously needs some validation.

We need to decide whether we require proxies to keep state for recent = emergency calls; otherwise and in the absence of a PKI-like mechanism, it seems = difficult to prevent call impersonation at the user's proxy.

There are other ways to solve this; in particular, Kumiko presented the ARID proposal at the last DISPATCH meeting on how a callee could = validate caller properties. This requires more UA changes, but is stateless in = the UA and works across devices.

Henning

On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote:

>
> If I recall correctly, the reasons given in the Taipei meeting for indicating a PSAP call-back is any "different" from a normal call to a normal GRUU or a normal AoR or URI target, were so that:
>                  (1) the network prioritize the call-back with respect to allocating = resources
>                  (2) the network bypass certain normal-call "treatments"
>                  (3) so that the reached UA could know to immediately answer the call.
>
> For (1): if that's not the very definition of the RPH header's = purpose, I don't know what is.
>
> For (2): we have never had a singular defined header or field in = SIP which was intended for this purpose, afaik - basically there are many = headers/fields/methods which in combination are used by proxy-ish devices to perform different "treatments".  In 3GPP, for example, I believe the filter-criteria can and do use almost any header field.  So really there's no field we can't use to accomplish this.
>
> For (3): using a new RPH namespace value for "psap-callback" actually makes sense for this, since it's arguably asking the UA to make available its resources immediately, without waiting for user consent or to put another call on hold.
>
> Having said all that, I'm not super-tied to using the RPH header = either - I just think using a new special GRUU type is wrong, both at an = architectural level and a practical "it-needs-to-work" level.  Even if the RPH field is lost or modified or ignored, for example, the call will likely succeed - that's a good property to have I would think.
>
> -hadriel
>
>
> On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote:
>
>> Can people indicate why they see a synergy with resource = priority.
>>
>> This header field is primarily used for giving priority in the network. To be used effectively, it needs to be processed first in any message at all SIP entities, and the rest of the message handling = depends on it.
>>
>> While there may possibly be a use for Resource-Priority on = emergency callbacks, in order to give priority, I would suggest that to give it a purpose beyond that where priority itself is not needed, is not using = that header for its prime purpose, and indeed detracts from the main = usage.
>>
>> Further, one thing that could well disappear at country = boundaries is the Resource-Priority header field, because different regulatory = regimes have different sets of rules as to what namespaces may be used, and do not necessarily map one to another. Any 3GPP roaming user will need to cross the same country twice (on the signalling path) for the callback call, because the callback will go via the home network.
>>
>> So while I have no axes to grind on losing a GRUU dependency, I do think Resource-Priority is a poor fit.
>>
>> Keith
>>
>> From: ecrit-bounces@ietf.org = [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg
>> Sent: 24 November 2011 10:51
>> To: ECRIT
>> Cc: 'Adam Roach'; Paul Kyzivat
>> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority = instead of eGRUU
>>
>>
>> Hi,
>>
>> In Taipei, it was indicated that people would prefer another = mechanism than a new GRUU type for solving the issue of identifying PSAP callback calls.
>>
>> A new Resource-Priority header field value, that PSAPs would = insert in callback calls, was suggested. It would solve the requirement of = allowing network entities (and the UA) to identity the callback call, e.g. in = order to give special treatment.
>>
>> (The requirement to reach the same UA device that made the = emergency call can be solved with the existing GRUU mechanism, so nothing new is needed there).
>>
>> So, I would like to know whether people are ok with a = Resource-Priority approach?
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>> _______________________________________________
>> Ecrit mailing list
>> Ecrit@ietf.org
>> https://www.ietf.org/mailman/listinfo/ecrit=
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit=
>

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit=


= --Apple-Mail=_5703194A-B940-46D6-84B7-E7448C66527C-- From christer.holmberg@ericsson.com Tue Nov 29 11:44:19 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C9311E80FE; Tue, 29 Nov 2011 11:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhYZ9ZORqiLl; Tue, 29 Nov 2011 11:44:18 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DF3F511E80F8; Tue, 29 Nov 2011 11:44:14 -0800 (PST) X-AuditID: c1b4fb3d-b7b5fae00000219a-b1-4ed5360dd062 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 92.54.08602.D0635DE4; Tue, 29 Nov 2011 20:44:13 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Tue, 29 Nov 2011 20:44:13 +0100 From: Christer Holmberg To: Henning Schulzrinne , Janet P Gunn Date: Tue, 29 Nov 2011 20:44:12 +0100 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AQHMrs9FWZ4lGUPUyk6kqOPwKPPqDg== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , ECRIT , Paul Kyzivat , "ecrit-bounces@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Nov 2011 19:44:19 -0000 Hi, I agree that, whatever protocol element we use, the element itself is not e= nough to prevent abuse. If the request comes from a non-trusted entity, the= re needs to be a way to verify it. However, different networks might have different ways of doing that, and I = don't think we need to standardize a mechanism before moving forward with s= pecifying the identifier itself. We do need, however, have strong wording a= bout the fact that there must be A way to verify that the call comes from a= PSAP. >if (call claims to be an emergency-callback) > check if earlier call was indeed an emergency call That does not work for all network entities, as they might not be aware of = the previous emergency call. But, once the identifier has been verified, ot= her entities within the trust domain can use that verification. Regards, Christer ________________________________________ From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of Henning = Schulzrinne [hgs@cs.columbia.edu] Sent: Tuesday, November 29, 2011 7:41 PM To: Janet P Gunn Cc: Paul Kyzivat; Adam Roach; ECRIT; ecrit-bounces@ietf.org Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority ins= tead of eGRUU Janet, I think we all agree that no label by itself (whether some special From val= ue, a Priority header or RPH) is sufficient to prevent abuse. It would only= be useful in conjunction with another mechanism that allows caller-trusted= parties, including the UA, to determine that the call is indeed in respons= e to an earlier emergency call, or, alternatively, that only such calls can= reach a special address, such as a GRUU. The logic would be something like if (call claims to be an emergency-callback) check if earlier call was indeed an emergency call Henning On Nov 29, 2011, at 12:16 PM, Janet P Gunn wrote: With regard to the use of a new RPH namespace to trigger special handling o= r treatment in the network , I guess it depends on what you mean by "bypass call handling" "bypass ... treatments" Requirement 13 of RFC 5390 (Requirements for Management of Overload in the= Session Initiation Protocol) says REQ 13: The mechanism must not dictate a specific algorithm for prioritizing the processing of work within a proxy during times of overload. It must permit a proxy to prioritize requests based on any local policy, so that certain ones (such as a call for emergency services or a call with a specific value of the Resource-Priority header field [RFC4412]) are given preferential treatment, such as not being dropped, being given additional retransmission, or being processed ahead of others. This explicitly names the RPH header as a way to identify calls needing "s= pecial treatment" in the face of SIP overload. Not a complete "bypass", bu= t definitely a "special treatment". WRT "We do not want telemarketers to bypass call filters by slapping on an = RPH." This is true of any use of any RPH namespace. Use of RPH must always= be combined with appropriate security/authentication/authorization measur= es to ensure that unauthorized entities can not "slap on an RPH". I agree that, in principle, "Priority" rather than "Resource Priority" is t= he appropriate way to inform the destination that special treatment at the= destination is requested. However anyone can "slap on a Priority header",= as there is no associated security/authentication/authorization . Janet This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. From: Henning Schulzrinne > To: Hadriel Kaplan > Cc: Adam Roach >, ECRIT >, Paul Kyzivat > Date: 11/28/2011 03:19 PM Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority ins= tead of eGRUU Sent by: ecrit-bounces@ietf.org ________________________________ I see the issues as somewhat orthogonal. Thus, the use of GRUU or In-Reply-= To could easily be combined with RPH. Indeed, we've always distinguished Priority (meant to indicate the desired = priority at the receiving end system) and Resource-Priority (meant to influ= ence scheduling at intermediate nodes, such as gateways and proxies). I agree that the fail-safe mode is desirable, in addition to making spoofin= g such calls at least modestly difficult. We do not want telemarketers to b= ypass call filters by slapping on an RPH. I admit that I still don't see what's wrong with the following combination: - In-Reply-To allows the UA to match the call to an earlier emergency call = and thus prevents impersonation (weakly, but probably sufficiently to deal = with the most likely threat). It can also be used to bypass end system call= handling. - RPH can be added if needed, but seems likely to have modest to no effect.= Using it to bypass call handling by itself seems like a bad idea, for the = reason noted above. If the user's proxy keeps track of outbound emergency c= alls, In-Reply-To works for that as well. - "Priority: emergency" can be used as well, as an indicator for call handl= ing, but obviously needs some validation. We need to decide whether we require proxies to keep state for recent emerg= ency calls; otherwise and in the absence of a PKI-like mechanism, it seems = difficult to prevent call impersonation at the user's proxy. There are other ways to solve this; in particular, Kumiko presented the ARI= D proposal at the last DISPATCH meeting on how a callee could validate call= er properties. This requires more UA changes, but is stateless in the UA an= d works across devices. Henning On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote: > > If I recall correctly, the reasons given in the Taipei meeting for indica= ting a PSAP call-back is any "different" from a normal call to a normal GRU= U or a normal AoR or URI target, were so that: > (1) the network prioritize the call-back with respect to= allocating resources > (2) the network bypass certain normal-call "treatments" > (3) so that the reached UA could know to immediately ans= wer the call. > > For (1): if that's not the very definition of the RPH header's purpose, I= don't know what is. > > For (2): we have never had a singular defined header or field in SIP whic= h was intended for this purpose, afaik - basically there are many headers/f= ields/methods which in combination are used by proxy-ish devices to perform= different "treatments". In 3GPP, for example, I believe the filter-criter= ia can and do use almost any header field. So really there's no field we c= an't use to accomplish this. > > For (3): using a new RPH namespace value for "psap-callback" actually mak= es sense for this, since it's arguably asking the UA to make available its = resources immediately, without waiting for user consent or to put another c= all on hold. > > Having said all that, I'm not super-tied to using the RPH header either -= I just think using a new special GRUU type is wrong, both at an architectu= ral level and a practical "it-needs-to-work" level. Even if the RPH field = is lost or modified or ignored, for example, the call will likely succeed -= that's a good property to have I would think. > > -hadriel > > > On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: > >> Can people indicate why they see a synergy with resource priority. >> >> This header field is primarily used for giving priority in the network. = To be used effectively, it needs to be processed first in any message at al= l SIP entities, and the rest of the message handling depends on it. >> >> While there may possibly be a use for Resource-Priority on emergency cal= lbacks, in order to give priority, I would suggest that to give it a purpos= e beyond that where priority itself is not needed, is not using that header= for its prime purpose, and indeed detracts from the main usage. >> >> Further, one thing that could well disappear at country boundaries is th= e Resource-Priority header field, because different regulatory regimes have= different sets of rules as to what namespaces may be used, and do not nece= ssarily map one to another. Any 3GPP roaming user will need to cross the sa= me country twice (on the signalling path) for the callback call, because th= e callback will go via the home network. >> >> So while I have no axes to grind on losing a GRUU dependency, I do think= Resource-Priority is a poor fit. >> >> Keith >> >> From: ecrit-bounces@ietf.org [mailto:ecri= t-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 24 November 2011 10:51 >> To: ECRIT >> Cc: 'Adam Roach'; Paul Kyzivat >> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of = eGRUU >> >> >> Hi, >> >> In Taipei, it was indicated that people would prefer another mechanism t= han a new GRUU type for solving the issue of identifying PSAP callback call= s. >> >> A new Resource-Priority header field value, that PSAPs would insert in c= allback calls, was suggested. It would solve the requirement of allowing ne= twork entities (and the UA) to identity the callback call, e.g. in order to= give special treatment. >> >> (The requirement to reach the same UA device that made the emergency cal= l can be solved with the existing GRUU mechanism, so nothing new is needed = there). >> >> So, I would like to know whether people are ok with a Resource-Priority = approach? >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From jmpolk@cisco.com Tue Nov 29 18:26:28 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC2621F846D; Tue, 29 Nov 2011 18:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OAV7HtFzllu; Tue, 29 Nov 2011 18:26:27 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id F002D21F8477; Tue, 29 Nov 2011 18:26:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=13328; q=dns/txt; s=iport; t=1322619986; x=1323829586; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=9ipKppZaCNeR529ScpOPQv3UZsBFRlpei/kYOBJ6AoE=; b=bYSFGDBHa83VE9EeHjuvdBMiGZspKcDsWUqPYnRpKzDsbX7k84im7q3S Ggzh1mDOMV8WQdiSQzsC8TerioFVHftiaP1kSa7H90n7tSTNhPTnjBGqA SdltIQ33HRCjEpY7Wm5X1LtD1h/UXopZ6bLiBo8UdIiAq0uv095urLvMQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAAAJaT1U6rRDoH/2dsb2JhbAA5AQkOmlqQGYEFgXIBAQEEAQEBDwEKGwI0CxAHBBEDAQEBARUJCQcZDh8JCAYBEAIih2uZSAGORY9xBIddARKDIQSIKJ4IVh4 X-IronPort-AV: E=Sophos;i="4.69,595,1315180800"; d="scan'208";a="16849015" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 30 Nov 2011 02:26:26 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAU2QOeO016560; Wed, 30 Nov 2011 02:26:25 GMT Message-Id: <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Nov 2011 20:26:23 -0600 To: Christer Holmberg , Henning Schulzrinne , Janet P Gunn From: "James M. Polk" In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.ee mea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Adam Roach , ECRIT , Paul Kyzivat , "ecrit-bounces@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 02:26:28 -0000 Christer The fundamental requirement is to provide an indication to SIP request receivers (i.e., each SIP server along the way until you reach the ultimate destination UAS - which is the original UAC that placed the emergency call) to give that SIP request - which is an emergency callback 3 transaction - extra attention if needed to make sure it goes through, right? If this is the general problem, then IMO Priority: Emergency does not accomplish this goal, as the Priority header value is for users of UAs, not for intermediaries to take into account in any way. Further, since there must be a new Call-ID value, there is no way to tie this back to the initial emergency call. Additionally, the original UAC, may have called for emergency twice, and gotten connected to two different PSAPs. A generic "this is a 911 callback" indication is insufficient, as I believe this needs to be tied somehow to which 911 call was placed. Given that the 911 callback path could traverse a different set of SIP servers back to the original caller, SIP servers would have to blindly give preferential treatment to any SIP request that contains this "this is a 911 callback" - which is begging for misuse and other problems. What sounds like the best proposal to me, and I'm not sure who mentioned it (Brian?), is for the original 911 caller to insert a token that is received during the callback INVITE (along with the sos URN somewhere in the INVITE). Maybe the token is something encrypted with the public key that identifies the PSAP from the 200 OK in the original transaction. If that same identifier comes back in the callback INVITE, the UAS knows who it is talking to. That doesn't solve for what has to happen within the SIP servers or in the network to ensure this SIP request gets preferential treatment, but most here already believe this is going to take a couple of pieces to get to where we want to go. James At 01:44 PM 11/29/2011, Christer Holmberg wrote: >Hi, > >I agree that, whatever protocol element we use, the element itself >is not enough to prevent abuse. If the request comes from a >non-trusted entity, there needs to be a way to verify it. > >However, different networks might have different ways of doing that, >and I don't think we need to standardize a mechanism before moving >forward with specifying the identifier itself. We do need, however, >have strong wording about the fact that there must be A way to >verify that the call comes from a PSAP. > > >if (call claims to be an emergency-callback) > > check if earlier call was indeed an emergency call > >That does not work for all network entities, as they might not be >aware of the previous emergency call. But, once the identifier has >been verified, other entities within the trust domain can use that >verification. > >Regards, > >Christer > > >________________________________________ >From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >Henning Schulzrinne [hgs@cs.columbia.edu] >Sent: Tuesday, November 29, 2011 7:41 PM >To: Janet P Gunn >Cc: Paul Kyzivat; Adam Roach; ECRIT; ecrit-bounces@ietf.org >Subject: Re: [Ecrit] PSAP Callback indication: >Resrouce-Priority instead of eGRUU > >Janet, > >I think we all agree that no label by itself (whether some special > From value, a Priority header or RPH) is sufficient to prevent >abuse. It would only be useful in conjunction with another mechanism >that allows caller-trusted parties, including the UA, to determine >that the call is indeed in response to an earlier emergency call, >or, alternatively, that only such calls can reach a special address, >such as a GRUU. The logic would be something like > >if (call claims to be an emergency-callback) > check if earlier call was indeed an emergency call > >Henning > >On Nov 29, 2011, at 12:16 PM, Janet P Gunn wrote: > >With regard to the use of a new RPH namespace to trigger special >handling or treatment in the network , I guess it depends on what you mean by >"bypass call handling" >"bypass ... treatments" > >Requirement 13 of RFC 5390 (Requirements for Management of Overload >in the Session Initiation Protocol) says > >REQ 13: The mechanism must not dictate a specific algorithm for > prioritizing the processing of work within a proxy during times of > overload. It must permit a proxy to prioritize requests based on > any local policy, so that certain ones (such as a call for > emergency services or a call with a specific value of the > Resource-Priority header field [RFC4412]) are given preferential > treatment, such as not being dropped, being given additional > retransmission, or being processed ahead of others. > >This explicitly names the RPH header as a way to identify calls >needing "special treatment" in the face of SIP overload. Not a >complete "bypass", but definitely a "special treatment". > >WRT "We do not want telemarketers to bypass call filters by slapping >on an RPH." This is true of any use of any RPH namespace. Use of >RPH must always be combined with appropriate >security/authentication/authorization measures to ensure that >unauthorized entities can not "slap on an RPH". > >I agree that, in principle, "Priority" rather than "Resource >Priority" is the appropriate way to inform the destination that >special treatment at the destination is requested. However anyone >can "slap on a Priority header", as there is no associated >security/authentication/authorization . > >Janet > > >This is a PRIVATE message. If you are not the intended recipient, >please delete without copying and kindly advise us by e-mail of the >mistake in delivery. NOTE: Regardless of content, this e-mail shall >not operate to bind CSC to any order or other contract unless >pursuant to explicit written agreement or government initiative >expressly permitting the use of e-mail for such purpose. > > > >From: Henning Schulzrinne >> >To: Hadriel Kaplan >> >Cc: Adam Roach >, >ECRIT >, Paul Kyzivat >> >Date: 11/28/2011 03:19 PM >Subject: Re: [Ecrit] PSAP Callback indication: >Resrouce-Priority instead of eGRUU >Sent by: ecrit-bounces@ietf.org >________________________________ > > > >I see the issues as somewhat orthogonal. Thus, the use of GRUU or >In-Reply-To could easily be combined with RPH. > >Indeed, we've always distinguished Priority (meant to indicate the >desired priority at the receiving end system) and Resource-Priority >(meant to influence scheduling at intermediate nodes, such as >gateways and proxies). > >I agree that the fail-safe mode is desirable, in addition to making >spoofing such calls at least modestly difficult. We do not want >telemarketers to bypass call filters by slapping on an RPH. > >I admit that I still don't see what's wrong with the following combination: > >- In-Reply-To allows the UA to match the call to an earlier >emergency call and thus prevents impersonation (weakly, but probably >sufficiently to deal with the most likely threat). It can also be >used to bypass end system call handling. > >- RPH can be added if needed, but seems likely to have modest to no >effect. Using it to bypass call handling by itself seems like a bad >idea, for the reason noted above. If the user's proxy keeps track of >outbound emergency calls, In-Reply-To works for that as well. > >- "Priority: emergency" can be used as well, as an indicator for >call handling, but obviously needs some validation. > >We need to decide whether we require proxies to keep state for >recent emergency calls; otherwise and in the absence of a PKI-like >mechanism, it seems difficult to prevent call impersonation at the >user's proxy. > >There are other ways to solve this; in particular, Kumiko presented >the ARID proposal at the last DISPATCH meeting on how a callee could >validate caller properties. This requires more UA changes, but is >stateless in the UA and works across devices. > >Henning > >On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote: > > > > > If I recall correctly, the reasons given in the Taipei meeting > for indicating a PSAP call-back is any "different" from a normal > call to a normal GRUU or a normal AoR or URI target, were so that: > > (1) the network prioritize the call-back with > respect to allocating resources > > (2) the network bypass certain normal-call "treatments" > > (3) so that the reached UA could know to > immediately answer the call. > > > > For (1): if that's not the very definition of the RPH header's > purpose, I don't know what is. > > > > For (2): we have never had a singular defined header or field in > SIP which was intended for this purpose, afaik - basically there > are many headers/fields/methods which in combination are used by > proxy-ish devices to perform different "treatments". In 3GPP, for > example, I believe the filter-criteria can and do use almost any > header field. So really there's no field we can't use to accomplish this. > > > > For (3): using a new RPH namespace value for "psap-callback" > actually makes sense for this, since it's arguably asking the UA to > make available its resources immediately, without waiting for user > consent or to put another call on hold. > > > > Having said all that, I'm not super-tied to using the RPH header > either - I just think using a new special GRUU type is wrong, both > at an architectural level and a practical "it-needs-to-work" > level. Even if the RPH field is lost or modified or ignored, for > example, the call will likely succeed - that's a good property to > have I would think. > > > > -hadriel > > > > > > On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: > > > >> Can people indicate why they see a synergy with resource priority. > >> > >> This header field is primarily used for giving priority in the > network. To be used effectively, it needs to be processed first in > any message at all SIP entities, and the rest of the message > handling depends on it. > >> > >> While there may possibly be a use for Resource-Priority on > emergency callbacks, in order to give priority, I would suggest > that to give it a purpose beyond that where priority itself is not > needed, is not using that header for its prime purpose, and indeed > detracts from the main usage. > >> > >> Further, one thing that could well disappear at country > boundaries is the Resource-Priority header field, because different > regulatory regimes have different sets of rules as to what > namespaces may be used, and do not necessarily map one to another. > Any 3GPP roaming user will need to cross the same country twice (on > the signalling path) for the callback call, because the callback > will go via the home network. > >> > >> So while I have no axes to grind on losing a GRUU dependency, I > do think Resource-Priority is a poor fit. > >> > >> Keith > >> > >> From: ecrit-bounces@ietf.org > [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg > >> Sent: 24 November 2011 10:51 > >> To: ECRIT > >> Cc: 'Adam Roach'; Paul Kyzivat > >> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority > instead of eGRUU > >> > >> > >> Hi, > >> > >> In Taipei, it was indicated that people would prefer another > mechanism than a new GRUU type for solving the issue of identifying > PSAP callback calls. > >> > >> A new Resource-Priority header field value, that PSAPs would > insert in callback calls, was suggested. It would solve the > requirement of allowing network entities (and the UA) to identity > the callback call, e.g. in order to give special treatment. > >> > >> (The requirement to reach the same UA device that made the > emergency call can be solved with the existing GRUU mechanism, so > nothing new is needed there). > >> > >> So, I would like to know whether people are ok with a > Resource-Priority approach? > >> > >> Regards, > >> > >> Christer > >> > >> > >> > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit > > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit > > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Wed Nov 30 02:22:08 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28ABE21F8ADE; Wed, 30 Nov 2011 02:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QRGMPr8vypue; Wed, 30 Nov 2011 02:22:06 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 026B221F8ABD; Wed, 30 Nov 2011 02:22:05 -0800 (PST) X-AuditID: c1b4fb3d-b7b5fae00000219a-00-4ed603cc6a6f Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 09.67.08602.CC306DE4; Wed, 30 Nov 2011 11:22:04 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 30 Nov 2011 11:22:04 +0100 From: Christer Holmberg To: "James M. Polk" , Henning Schulzrinne , Janet P Gunn Date: Wed, 30 Nov 2011 11:22:03 +0100 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AcyvB3fs3F7PCjRpRYaqVyXoS7OQrgAPs/sA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> In-Reply-To: <201111300226.pAU2QOeO016560@mtv-core-2.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , ECRIT , Paul Kyzivat , "ecrit-bounces@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 10:22:08 -0000 Hi James, > The fundamental requirement is to provide an indication to > SIP request receivers (i.e., each SIP server along the way > until you reach the ultimate destination UAS - which is the > original UAC that placed the emergency call) to give that SIP > request - which is an emergency callback 3 transaction - > extra attention if needed to make sure it goes through, right? Yes. (There is also a requirement to be able to reach the same UA that made the = emergency call. But, gruu provides that, so we don't need to specify anythi= ng new.) > If this is the general problem, then IMO > > Priority: Emergency > > does not accomplish this goal, as the Priority header value > is for users of UAs, not for intermediaries to take into > account in any way. Please remember that lots of the actions taken by the intermediaries are on= behalf of the user/UA. For example, an intermediarie would normally trigge= r a specific service for a specific user/UA, but it would not do so in the = case of a PSAP Callback towards that user/UA. > Further, since there must be a new Call-ID value, there is no > way to tie this back to the initial emergency call. I think Henning's idea was to use the In-Reply-To header field, which would= contain the Call-Id of the associated emergency call. But, as I said, it would not work with SBCs, and it would not work with int= ermediaries that weren't involved in the emergency call. > Additionally, the original UAC, may have called for emergency > twice, and gotten connected to two different PSAPs. A generic > "this is a 911 callback" indication is insufficient, as I > believe this needs to be tied somehow to which 911 call was > placed. Given that the 911 callback path could traverse a > different set of SIP servers back to the original caller, SIP > servers would have to blindly give preferential treatment to > any SIP request that contains this "this is a 911 callback" - > which is begging for misuse and other problems. There would need to be a way for networks, when receiving a "this is a 911 = callback" request from a non-trusted network, to be able to verify that the= call comes from a PSAP. But, again, at least in a 3GPP roaming scenario the home network might not = have a clue about the associated emergency call. > What sounds like the best proposal to me, and I'm not sure > who mentioned it (Brian?), is for the original 911 caller to > insert a token that is received during the callback INVITE > (along with the sos URN somewhere in the INVITE). Maybe the > token is something encrypted with the public key that > identifies the PSAP from the 200 OK in the original > transaction. If that same identifier comes back in the > callback INVITE, the UAS knows who it is talking to. The original idea with the emergency gruu was that the home registrar provi= des such token to the UAS. The home registrar could then use that token to = identify the PSAP Callback. One problem with that was that there might also be other entities that need= to identify the PSAP Callback, and for that reason the draft suggests a "s= tatic" token value ("psapcb"). But, with a static value you of course have = the fraud/misuse issue. Regards, Christer > That doesn't solve for what has to happen within the SIP servers > or in the network to ensure this SIP request gets > preferential treatment, but most here already believe this is > going to take a couple of pieces to get to where we want to go. > James > > At 01:44 PM 11/29/2011, Christer Holmberg wrote: > > >Hi, > > > >I agree that, whatever protocol element we use, the element > itself is > >not enough to prevent abuse. If the request comes from a non-trusted > >entity, there needs to be a way to verify it. > > > >However, different networks might have different ways of doing that, > >and I don't think we need to standardize a mechanism before moving > >forward with specifying the identifier itself. We do need, however, > >have strong wording about the fact that there must be A way > to verify > >that the call comes from a PSAP. > > > > >if (call claims to be an emergency-callback) > > > check if earlier call was indeed an emergency call > > > >That does not work for all network entities, as they might > not be aware > >of the previous emergency call. But, once the identifier has been > >verified, other entities within the trust domain can use that > >verification. > > > >Regards, > > > >Christer > > > > > >________________________________________ > >From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of > >Henning Schulzrinne [hgs@cs.columbia.edu] > >Sent: Tuesday, November 29, 2011 7:41 PM > >To: Janet P Gunn > >Cc: Paul Kyzivat; Adam Roach; ECRIT; ecrit-bounces@ietf.org > >Subject: Re: [Ecrit] PSAP Callback indication: > >Resrouce-Priority instead of eGRUU > > > >Janet, > > > >I think we all agree that no label by itself (whether some special > >From value, a Priority header or RPH) is sufficient to > prevent abuse. > >It would only be useful in conjunction with another mechanism that > >allows caller-trusted parties, including the UA, to > determine that the > >call is indeed in response to an earlier emergency call, or, > >alternatively, that only such calls can reach a special > address, such > >as a GRUU. The logic would be something like > > > >if (call claims to be an emergency-callback) > > check if earlier call was indeed an emergency call > > > >Henning > > > >On Nov 29, 2011, at 12:16 PM, Janet P Gunn wrote: > > > >With regard to the use of a new RPH namespace to trigger special > >handling or treatment in the network , I guess it depends on > what you > >mean by "bypass call handling" > >"bypass ... treatments" > > > >Requirement 13 of RFC 5390 (Requirements for Management of > Overload in > >the Session Initiation Protocol) says > > > >REQ 13: The mechanism must not dictate a specific algorithm for > > prioritizing the processing of work within a proxy > during times of > > overload. It must permit a proxy to prioritize > requests based on > > any local policy, so that certain ones (such as a call for > > emergency services or a call with a specific value of the > > Resource-Priority header field [RFC4412]) are given > preferential > > treatment, such as not being dropped, being given additional > > retransmission, or being processed ahead of others. > > > >This explicitly names the RPH header as a way to identify calls > >needing "special treatment" in the face of SIP overload. Not a > >complete "bypass", but definitely a "special treatment". > > > >WRT "We do not want telemarketers to bypass call filters by > slapping on > >an RPH." This is true of any use of any RPH namespace. Use > of RPH must > >always be combined with appropriate > >security/authentication/authorization measures to ensure that > >unauthorized entities can not "slap on an RPH". > > > >I agree that, in principle, "Priority" rather than "Resource > Priority" > >is the appropriate way to inform the destination that special > >treatment at the destination is requested. However anyone > can "slap on > >a Priority header", as there is no associated > >security/authentication/authorization . > > > >Janet > > > > > >This is a PRIVATE message. If you are not the intended recipient, > >please delete without copying and kindly advise us by e-mail of the > >mistake in delivery. NOTE: Regardless of content, this > e-mail shall not > >operate to bind CSC to any order or other contract unless > pursuant to > >explicit written agreement or government initiative expressly > >permitting the use of e-mail for such purpose. > > > > > > > >From: Henning Schulzrinne > >> > >To: Hadriel Kaplan > >> > >Cc: Adam Roach >, > >ECRIT >, Paul Kyzivat > >> > >Date: 11/28/2011 03:19 PM > >Subject: Re: [Ecrit] PSAP Callback indication: > >Resrouce-Priority instead of eGRUU > >Sent by: ecrit-bounces@ietf.org > >________________________________ > > > > > > > >I see the issues as somewhat orthogonal. Thus, the use of GRUU or > >In-Reply-To could easily be combined with RPH. > > > >Indeed, we've always distinguished Priority (meant to indicate the > >desired priority at the receiving end system) and Resource-Priority > >(meant to influence scheduling at intermediate nodes, such > as gateways > >and proxies). > > > >I agree that the fail-safe mode is desirable, in addition to making > >spoofing such calls at least modestly difficult. We do not want > >telemarketers to bypass call filters by slapping on an RPH. > > > >I admit that I still don't see what's wrong with the > following combination: > > > >- In-Reply-To allows the UA to match the call to an earlier > emergency > >call and thus prevents impersonation (weakly, but probably > sufficiently > >to deal with the most likely threat). It can also be used to > bypass end > >system call handling. > > > >- RPH can be added if needed, but seems likely to have modest to no > >effect. Using it to bypass call handling by itself seems like a bad > >idea, for the reason noted above. If the user's proxy keeps track of > >outbound emergency calls, In-Reply-To works for that as well. > > > >- "Priority: emergency" can be used as well, as an indicator > for call > >handling, but obviously needs some validation. > > > >We need to decide whether we require proxies to keep state > for recent > >emergency calls; otherwise and in the absence of a PKI-like > mechanism, > >it seems difficult to prevent call impersonation at the user's proxy. > > > >There are other ways to solve this; in particular, Kumiko > presented the > >ARID proposal at the last DISPATCH meeting on how a callee could > >validate caller properties. This requires more UA changes, but is > >stateless in the UA and works across devices. > > > >Henning > > > >On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote: > > > > > > > > If I recall correctly, the reasons given in the Taipei meeting > > for indicating a PSAP call-back is any "different" from a > normal call > > to a normal GRUU or a normal AoR or URI target, were so that: > > > (1) the network prioritize the call-back with > > respect to allocating resources > > > (2) the network bypass certain > normal-call "treatments" > > > (3) so that the reached UA could know to > > immediately answer the call. > > > > > > For (1): if that's not the very definition of the RPH header's > > purpose, I don't know what is. > > > > > > For (2): we have never had a singular defined header or field in > > SIP which was intended for this purpose, afaik - basically > there are > > many headers/fields/methods which in combination are used > by proxy-ish > > devices to perform different "treatments". In 3GPP, for example, I > > believe the filter-criteria can and do use almost any > header field. > > So really there's no field we can't use to accomplish this. > > > > > > For (3): using a new RPH namespace value for "psap-callback" > > actually makes sense for this, since it's arguably asking the UA to > > make available its resources immediately, without waiting for user > > consent or to put another call on hold. > > > > > > Having said all that, I'm not super-tied to using the RPH header > > either - I just think using a new special GRUU type is > wrong, both at > > an architectural level and a practical "it-needs-to-work" > > level. Even if the RPH field is lost or modified or ignored, for > > example, the call will likely succeed - that's a good > property to have > > I would think. > > > > > > -hadriel > > > > > > > > > On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: > > > > > >> Can people indicate why they see a synergy with resource > priority. > > >> > > >> This header field is primarily used for giving priority in the > > network. To be used effectively, it needs to be processed > first in any > > message at all SIP entities, and the rest of the message handling > > depends on it. > > >> > > >> While there may possibly be a use for Resource-Priority on > > emergency callbacks, in order to give priority, I would > suggest that > > to give it a purpose beyond that where priority itself is > not needed, > > is not using that header for its prime purpose, and indeed detracts > > from the main usage. > > >> > > >> Further, one thing that could well disappear at country > > boundaries is the Resource-Priority header field, because different > > regulatory regimes have different sets of rules as to what > namespaces > > may be used, and do not necessarily map one to another. > > Any 3GPP roaming user will need to cross the same country twice (on > > the signalling path) for the callback call, because the > callback will > > go via the home network. > > >> > > >> So while I have no axes to grind on losing a GRUU dependency, I > > do think Resource-Priority is a poor fit. > > >> > > >> Keith > > >> > > >> From: ecrit-bounces@ietf.org > > [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg > > >> Sent: 24 November 2011 10:51 > > >> To: ECRIT > > >> Cc: 'Adam Roach'; Paul Kyzivat > > >> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority > > instead of eGRUU > > >> > > >> > > >> Hi, > > >> > > >> In Taipei, it was indicated that people would prefer another > > mechanism than a new GRUU type for solving the issue of identifying > > PSAP callback calls. > > >> > > >> A new Resource-Priority header field value, that PSAPs would > > insert in callback calls, was suggested. It would solve the > > requirement of allowing network entities (and the UA) to > identity the > > callback call, e.g. in order to give special treatment. > > >> > > >> (The requirement to reach the same UA device that made the > > emergency call can be solved with the existing GRUU mechanism, so > > nothing new is needed there). > > >> > > >> So, I would like to know whether people are ok with a > > Resource-Priority approach? > > >> > > >> Regards, > > >> > > >> Christer > > >> > > >> > > >> > > >> _______________________________________________ > > >> Ecrit mailing list > > >> Ecrit@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ecrit > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www.ietf.org/mailman/listinfo/ecrit > > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > > > > >_______________________________________________ > >Ecrit mailing list > >Ecrit@ietf.org > >https://www.ietf.org/mailman/listinfo/ecrit > > From pkyzivat@alum.mit.edu Wed Nov 30 07:08:38 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D6B21F8B5A for ; Wed, 30 Nov 2011 07:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TpK4PDpNLAt for ; Wed, 30 Nov 2011 07:08:37 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id C9C4E21F85EF for ; Wed, 30 Nov 2011 07:08:36 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 3QqB1i0041ap0As5BT8dKT; Wed, 30 Nov 2011 15:08:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id 3T8c1i01007duvL3iT8cgn; Wed, 30 Nov 2011 15:08:37 +0000 Message-ID: <4ED646F5.30300@alum.mit.edu> Date: Wed, 30 Nov 2011 23:08:37 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 15:08:38 -0000 ISTM that a callback to the Contact address of a prior call should typically bypass many treatments, regardless of who it is from. In particular, it ought to go to the specific device identified by the contact address, not to some other device, VM server, etc. Perhaps that isn't what happens with IMS right now, but then maybe that ought to be re-thought. If that was normal behavior, then what else would be required for callbacks by a psap? There may need to be special treatment by the UA itself, but that can be handled by using a unique temp gruu for the emergency call and remembering it in order to detect emergency callbacks in the UA. What am I missing? What sort of disruptive services do you expect will be applied to calls to a gruu? Thanks, Paul On 11/30/11 6:22 PM, Christer Holmberg wrote: > > Hi James, > >> The fundamental requirement is to provide an indication to >> SIP request receivers (i.e., each SIP server along the way >> until you reach the ultimate destination UAS - which is the >> original UAC that placed the emergency call) to give that SIP >> request - which is an emergency callback 3 transaction - >> extra attention if needed to make sure it goes through, right? > > Yes. > > (There is also a requirement to be able to reach the same UA that made the emergency call. But, gruu provides that, so we don't need to specify anything new.) > > >> If this is the general problem, then IMO >> >> Priority: Emergency >> >> does not accomplish this goal, as the Priority header value >> is for users of UAs, not for intermediaries to take into >> account in any way. > > Please remember that lots of the actions taken by the intermediaries are on behalf of the user/UA. For example, an intermediarie would normally trigger a specific service for a specific user/UA, but it would not do so in the case of a PSAP Callback towards that user/UA. > > > >> Further, since there must be a new Call-ID value, there is no >> way to tie this back to the initial emergency call. > > I think Henning's idea was to use the In-Reply-To header field, which would contain the Call-Id of the associated emergency call. > > But, as I said, it would not work with SBCs, and it would not work with intermediaries that weren't involved in the emergency call. > > >> Additionally, the original UAC, may have called for emergency >> twice, and gotten connected to two different PSAPs. A generic >> "this is a 911 callback" indication is insufficient, as I >> believe this needs to be tied somehow to which 911 call was >> placed. Given that the 911 callback path could traverse a >> different set of SIP servers back to the original caller, SIP >> servers would have to blindly give preferential treatment to >> any SIP request that contains this "this is a 911 callback" - >> which is begging for misuse and other problems. > > There would need to be a way for networks, when receiving a "this is a 911 callback" request from a non-trusted network, to be able to verify that the call comes from a PSAP. > > But, again, at least in a 3GPP roaming scenario the home network might not have a clue about the associated emergency call. > > >> What sounds like the best proposal to me, and I'm not sure >> who mentioned it (Brian?), is for the original 911 caller to >> insert a token that is received during the callback INVITE >> (along with the sos URN somewhere in the INVITE). Maybe the >> token is something encrypted with the public key that >> identifies the PSAP from the 200 OK in the original >> transaction. If that same identifier comes back in the >> callback INVITE, the UAS knows who it is talking to. > > The original idea with the emergency gruu was that the home registrar provides such token to the UAS. The home registrar could then use that token to identify the PSAP Callback. > > One problem with that was that there might also be other entities that need to identify the PSAP Callback, and for that reason the draft suggests a "static" token value ("psapcb"). But, with a static value you of course have the fraud/misuse issue. > > Regards, > > Christer > > >> That doesn't solve for what has to happen within the SIP servers >> or in the network to ensure this SIP request gets >> preferential treatment, but most here already believe this is >> going to take a couple of pieces to get to where we want to go. > > > > > > > > > > > >> James >> >> At 01:44 PM 11/29/2011, Christer Holmberg wrote: >> >>> Hi, >>> >>> I agree that, whatever protocol element we use, the element >> itself is >>> not enough to prevent abuse. If the request comes from a non-trusted >>> entity, there needs to be a way to verify it. >>> >>> However, different networks might have different ways of doing that, >>> and I don't think we need to standardize a mechanism before moving >>> forward with specifying the identifier itself. We do need, however, >>> have strong wording about the fact that there must be A way >> to verify >>> that the call comes from a PSAP. >>> >>>> if (call claims to be an emergency-callback) >>>> check if earlier call was indeed an emergency call >>> >>> That does not work for all network entities, as they might >> not be aware >>> of the previous emergency call. But, once the identifier has been >>> verified, other entities within the trust domain can use that >>> verification. >>> >>> Regards, >>> >>> Christer >>> >>> >>> ________________________________________ >>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >>> Henning Schulzrinne [hgs@cs.columbia.edu] >>> Sent: Tuesday, November 29, 2011 7:41 PM >>> To: Janet P Gunn >>> Cc: Paul Kyzivat; Adam Roach; ECRIT; ecrit-bounces@ietf.org >>> Subject: Re: [Ecrit] PSAP Callback indication: >>> Resrouce-Priority instead of eGRUU >>> >>> Janet, >>> >>> I think we all agree that no label by itself (whether some special >> > From value, a Priority header or RPH) is sufficient to >> prevent abuse. >>> It would only be useful in conjunction with another mechanism that >>> allows caller-trusted parties, including the UA, to >> determine that the >>> call is indeed in response to an earlier emergency call, or, >>> alternatively, that only such calls can reach a special >> address, such >>> as a GRUU. The logic would be something like >>> >>> if (call claims to be an emergency-callback) >>> check if earlier call was indeed an emergency call >>> >>> Henning >>> >>> On Nov 29, 2011, at 12:16 PM, Janet P Gunn wrote: >>> >>> With regard to the use of a new RPH namespace to trigger special >>> handling or treatment in the network , I guess it depends on >> what you >>> mean by "bypass call handling" >>> "bypass ... treatments" >>> >>> Requirement 13 of RFC 5390 (Requirements for Management of >> Overload in >>> the Session Initiation Protocol) says >>> >>> REQ 13: The mechanism must not dictate a specific algorithm for >>> prioritizing the processing of work within a proxy >> during times of >>> overload. It must permit a proxy to prioritize >> requests based on >>> any local policy, so that certain ones (such as a call for >>> emergency services or a call with a specific value of the >>> Resource-Priority header field [RFC4412]) are given >> preferential >>> treatment, such as not being dropped, being given additional >>> retransmission, or being processed ahead of others. >>> >>> This explicitly names the RPH header as a way to identify calls >>> needing "special treatment" in the face of SIP overload. Not a >>> complete "bypass", but definitely a "special treatment". >>> >>> WRT "We do not want telemarketers to bypass call filters by >> slapping on >>> an RPH." This is true of any use of any RPH namespace. Use >> of RPH must >>> always be combined with appropriate >>> security/authentication/authorization measures to ensure that >>> unauthorized entities can not "slap on an RPH". >>> >>> I agree that, in principle, "Priority" rather than "Resource >> Priority" >>> is the appropriate way to inform the destination that special >>> treatment at the destination is requested. However anyone >> can "slap on >>> a Priority header", as there is no associated >>> security/authentication/authorization . >>> >>> Janet >>> >>> >>> This is a PRIVATE message. If you are not the intended recipient, >>> please delete without copying and kindly advise us by e-mail of the >>> mistake in delivery. NOTE: Regardless of content, this >> e-mail shall not >>> operate to bind CSC to any order or other contract unless >> pursuant to >>> explicit written agreement or government initiative expressly >>> permitting the use of e-mail for such purpose. >>> >>> >>> >>> From: Henning Schulzrinne >>> > >>> To: Hadriel Kaplan >>> > >>> Cc: Adam Roach>, >>> ECRIT>, Paul Kyzivat >>> > >>> Date: 11/28/2011 03:19 PM >>> Subject: Re: [Ecrit] PSAP Callback indication: >>> Resrouce-Priority instead of eGRUU >>> Sent by: ecrit-bounces@ietf.org >>> ________________________________ >>> >>> >>> >>> I see the issues as somewhat orthogonal. Thus, the use of GRUU or >>> In-Reply-To could easily be combined with RPH. >>> >>> Indeed, we've always distinguished Priority (meant to indicate the >>> desired priority at the receiving end system) and Resource-Priority >>> (meant to influence scheduling at intermediate nodes, such >> as gateways >>> and proxies). >>> >>> I agree that the fail-safe mode is desirable, in addition to making >>> spoofing such calls at least modestly difficult. We do not want >>> telemarketers to bypass call filters by slapping on an RPH. >>> >>> I admit that I still don't see what's wrong with the >> following combination: >>> >>> - In-Reply-To allows the UA to match the call to an earlier >> emergency >>> call and thus prevents impersonation (weakly, but probably >> sufficiently >>> to deal with the most likely threat). It can also be used to >> bypass end >>> system call handling. >>> >>> - RPH can be added if needed, but seems likely to have modest to no >>> effect. Using it to bypass call handling by itself seems like a bad >>> idea, for the reason noted above. If the user's proxy keeps track of >>> outbound emergency calls, In-Reply-To works for that as well. >>> >>> - "Priority: emergency" can be used as well, as an indicator >> for call >>> handling, but obviously needs some validation. >>> >>> We need to decide whether we require proxies to keep state >> for recent >>> emergency calls; otherwise and in the absence of a PKI-like >> mechanism, >>> it seems difficult to prevent call impersonation at the user's proxy. >>> >>> There are other ways to solve this; in particular, Kumiko >> presented the >>> ARID proposal at the last DISPATCH meeting on how a callee could >>> validate caller properties. This requires more UA changes, but is >>> stateless in the UA and works across devices. >>> >>> Henning >>> >>> On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote: >>> >>>> >>>> If I recall correctly, the reasons given in the Taipei meeting >>> for indicating a PSAP call-back is any "different" from a >> normal call >>> to a normal GRUU or a normal AoR or URI target, were so that: >>>> (1) the network prioritize the call-back with >>> respect to allocating resources >>>> (2) the network bypass certain >> normal-call "treatments" >>>> (3) so that the reached UA could know to >>> immediately answer the call. >>>> >>>> For (1): if that's not the very definition of the RPH header's >>> purpose, I don't know what is. >>>> >>>> For (2): we have never had a singular defined header or field in >>> SIP which was intended for this purpose, afaik - basically >> there are >>> many headers/fields/methods which in combination are used >> by proxy-ish >>> devices to perform different "treatments". In 3GPP, for example, I >>> believe the filter-criteria can and do use almost any >> header field. >>> So really there's no field we can't use to accomplish this. >>>> >>>> For (3): using a new RPH namespace value for "psap-callback" >>> actually makes sense for this, since it's arguably asking the UA to >>> make available its resources immediately, without waiting for user >>> consent or to put another call on hold. >>>> >>>> Having said all that, I'm not super-tied to using the RPH header >>> either - I just think using a new special GRUU type is >> wrong, both at >>> an architectural level and a practical "it-needs-to-work" >>> level. Even if the RPH field is lost or modified or ignored, for >>> example, the call will likely succeed - that's a good >> property to have >>> I would think. >>>> >>>> -hadriel >>>> >>>> >>>> On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: >>>> >>>>> Can people indicate why they see a synergy with resource >> priority. >>>>> >>>>> This header field is primarily used for giving priority in the >>> network. To be used effectively, it needs to be processed >> first in any >>> message at all SIP entities, and the rest of the message handling >>> depends on it. >>>>> >>>>> While there may possibly be a use for Resource-Priority on >>> emergency callbacks, in order to give priority, I would >> suggest that >>> to give it a purpose beyond that where priority itself is >> not needed, >>> is not using that header for its prime purpose, and indeed detracts >>> from the main usage. >>>>> >>>>> Further, one thing that could well disappear at country >>> boundaries is the Resource-Priority header field, because different >>> regulatory regimes have different sets of rules as to what >> namespaces >>> may be used, and do not necessarily map one to another. >>> Any 3GPP roaming user will need to cross the same country twice (on >>> the signalling path) for the callback call, because the >> callback will >>> go via the home network. >>>>> >>>>> So while I have no axes to grind on losing a GRUU dependency, I >>> do think Resource-Priority is a poor fit. >>>>> >>>>> Keith >>>>> >>>>> From: ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg >>>>> Sent: 24 November 2011 10:51 >>>>> To: ECRIT >>>>> Cc: 'Adam Roach'; Paul Kyzivat >>>>> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority >>> instead of eGRUU >>>>> >>>>> >>>>> Hi, >>>>> >>>>> In Taipei, it was indicated that people would prefer another >>> mechanism than a new GRUU type for solving the issue of identifying >>> PSAP callback calls. >>>>> >>>>> A new Resource-Priority header field value, that PSAPs would >>> insert in callback calls, was suggested. It would solve the >>> requirement of allowing network entities (and the UA) to >> identity the >>> callback call, e.g. in order to give special treatment. >>>>> >>>>> (The requirement to reach the same UA device that made the >>> emergency call can be solved with the existing GRUU mechanism, so >>> nothing new is needed there). >>>>> >>>>> So, I would like to know whether people are ok with a >>> Resource-Priority approach? >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> > From christer.holmberg@ericsson.com Wed Nov 30 11:22:16 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A8E11E8098 for ; Wed, 30 Nov 2011 11:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3l3GbpPbP54E for ; Wed, 30 Nov 2011 11:22:15 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 521D721F8A6C for ; Wed, 30 Nov 2011 11:22:14 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-cd-4ed68264c8d2 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B5.C1.09514.46286DE4; Wed, 30 Nov 2011 20:22:12 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 30 Nov 2011 20:22:12 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 30 Nov 2011 20:22:11 +0100 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AcyvcfARWpZ3V4rPTLW2ycWkW+gIVwAISk2r Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> In-Reply-To: <4ED646F5.30300@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 19:22:16 -0000 Hi, > ISTM that a callback to the Contact address of a prior call should > typically bypass many treatments, regardless of who it is from. > > In particular, it ought to go to the specific device identified by the > contact address, not to some other device, VM server, etc. > > Perhaps that isn't what happens with IMS right now, but then maybe that > ought to be re-thought. > > If that was normal behavior, then what else would be required for > callbacks by a psap? > > There may need to be special treatment by the UA > itself, but that can be handled by using a unique temp gruu for the > emergency call and remembering it in order to detect emergency callbacks > in the UA. > > What am I missing? What sort of disruptive services do you expect will > be applied to calls to a gruu? I don't think one can assume that any type of call, non-PSAP-callbacks and = PSAP-callbacks, will be given the same special treatment by the network, ju= st because they are addressed using a Contact. And, it is not only about routing to another device, but also other service= s that normally would be applied. Regards, Christer On 11/30/11 6:22 PM, Christer Holmberg wrote: > > Hi James, > >> The fundamental requirement is to provide an indication to >> SIP request receivers (i.e., each SIP server along the way >> until you reach the ultimate destination UAS - which is the >> original UAC that placed the emergency call) to give that SIP >> request - which is an emergency callback 3 transaction - >> extra attention if needed to make sure it goes through, right? > > Yes. > > (There is also a requirement to be able to reach the same UA that made th= e emergency call. But, gruu provides that, so we don't need to specify anyt= hing new.) > > >> If this is the general problem, then IMO >> >> Priority: Emergency >> >> does not accomplish this goal, as the Priority header value >> is for users of UAs, not for intermediaries to take into >> account in any way. > > Please remember that lots of the actions taken by the intermediaries are = on behalf of the user/UA. For example, an intermediarie would normally trig= ger a specific service for a specific user/UA, but it would not do so in th= e case of a PSAP Callback towards that user/UA. > > > >> Further, since there must be a new Call-ID value, there is no >> way to tie this back to the initial emergency call. > > I think Henning's idea was to use the In-Reply-To header field, which wou= ld contain the Call-Id of the associated emergency call. > > But, as I said, it would not work with SBCs, and it would not work with i= ntermediaries that weren't involved in the emergency call. > > >> Additionally, the original UAC, may have called for emergency >> twice, and gotten connected to two different PSAPs. A generic >> "this is a 911 callback" indication is insufficient, as I >> believe this needs to be tied somehow to which 911 call was >> placed. Given that the 911 callback path could traverse a >> different set of SIP servers back to the original caller, SIP >> servers would have to blindly give preferential treatment to >> any SIP request that contains this "this is a 911 callback" - >> which is begging for misuse and other problems. > > There would need to be a way for networks, when receiving a "this is a 91= 1 callback" request from a non-trusted network, to be able to verify that t= he call comes from a PSAP. > > But, again, at least in a 3GPP roaming scenario the home network might no= t have a clue about the associated emergency call. > > >> What sounds like the best proposal to me, and I'm not sure >> who mentioned it (Brian?), is for the original 911 caller to >> insert a token that is received during the callback INVITE >> (along with the sos URN somewhere in the INVITE). Maybe the >> token is something encrypted with the public key that >> identifies the PSAP from the 200 OK in the original >> transaction. If that same identifier comes back in the >> callback INVITE, the UAS knows who it is talking to. > > The original idea with the emergency gruu was that the home registrar pro= vides such token to the UAS. The home registrar could then use that token t= o identify the PSAP Callback. > > One problem with that was that there might also be other entities that ne= ed to identify the PSAP Callback, and for that reason the draft suggests a = "static" token value ("psapcb"). But, with a static value you of course hav= e the fraud/misuse issue. > > Regards, > > Christer > > >> That doesn't solve for what has to happen within the SIP servers >> or in the network to ensure this SIP request gets >> preferential treatment, but most here already believe this is >> going to take a couple of pieces to get to where we want to go. > > > > > > > > > > > >> James >> >> At 01:44 PM 11/29/2011, Christer Holmberg wrote: >> >>> Hi, >>> >>> I agree that, whatever protocol element we use, the element >> itself is >>> not enough to prevent abuse. If the request comes from a non-trusted >>> entity, there needs to be a way to verify it. >>> >>> However, different networks might have different ways of doing that, >>> and I don't think we need to standardize a mechanism before moving >>> forward with specifying the identifier itself. We do need, however, >>> have strong wording about the fact that there must be A way >> to verify >>> that the call comes from a PSAP. >>> >>>> if (call claims to be an emergency-callback) >>>> check if earlier call was indeed an emergency call >>> >>> That does not work for all network entities, as they might >> not be aware >>> of the previous emergency call. But, once the identifier has been >>> verified, other entities within the trust domain can use that >>> verification. >>> >>> Regards, >>> >>> Christer >>> >>> >>> ________________________________________ >>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >>> Henning Schulzrinne [hgs@cs.columbia.edu] >>> Sent: Tuesday, November 29, 2011 7:41 PM >>> To: Janet P Gunn >>> Cc: Paul Kyzivat; Adam Roach; ECRIT; ecrit-bounces@ietf.org >>> Subject: Re: [Ecrit] PSAP Callback indication: >>> Resrouce-Priority instead of eGRUU >>> >>> Janet, >>> >>> I think we all agree that no label by itself (whether some special >> > From value, a Priority header or RPH) is sufficient to >> prevent abuse. >>> It would only be useful in conjunction with another mechanism that >>> allows caller-trusted parties, including the UA, to >> determine that the >>> call is indeed in response to an earlier emergency call, or, >>> alternatively, that only such calls can reach a special >> address, such >>> as a GRUU. The logic would be something like >>> >>> if (call claims to be an emergency-callback) >>> check if earlier call was indeed an emergency call >>> >>> Henning >>> >>> On Nov 29, 2011, at 12:16 PM, Janet P Gunn wrote: >>> >>> With regard to the use of a new RPH namespace to trigger special >>> handling or treatment in the network , I guess it depends on >> what you >>> mean by "bypass call handling" >>> "bypass ... treatments" >>> >>> Requirement 13 of RFC 5390 (Requirements for Management of >> Overload in >>> the Session Initiation Protocol) says >>> >>> REQ 13: The mechanism must not dictate a specific algorithm for >>> prioritizing the processing of work within a proxy >> during times of >>> overload. It must permit a proxy to prioritize >> requests based on >>> any local policy, so that certain ones (such as a call for >>> emergency services or a call with a specific value of the >>> Resource-Priority header field [RFC4412]) are given >> preferential >>> treatment, such as not being dropped, being given additional >>> retransmission, or being processed ahead of others. >>> >>> This explicitly names the RPH header as a way to identify calls >>> needing "special treatment" in the face of SIP overload. Not a >>> complete "bypass", but definitely a "special treatment". >>> >>> WRT "We do not want telemarketers to bypass call filters by >> slapping on >>> an RPH." This is true of any use of any RPH namespace. Use >> of RPH must >>> always be combined with appropriate >>> security/authentication/authorization measures to ensure that >>> unauthorized entities can not "slap on an RPH". >>> >>> I agree that, in principle, "Priority" rather than "Resource >> Priority" >>> is the appropriate way to inform the destination that special >>> treatment at the destination is requested. However anyone >> can "slap on >>> a Priority header", as there is no associated >>> security/authentication/authorization . >>> >>> Janet >>> >>> >>> This is a PRIVATE message. If you are not the intended recipient, >>> please delete without copying and kindly advise us by e-mail of the >>> mistake in delivery. NOTE: Regardless of content, this >> e-mail shall not >>> operate to bind CSC to any order or other contract unless >> pursuant to >>> explicit written agreement or government initiative expressly >>> permitting the use of e-mail for such purpose. >>> >>> >>> >>> From: Henning Schulzrinne >>> > >>> To: Hadriel Kaplan >>> > >>> Cc: Adam Roach>, >>> ECRIT>, Paul Kyzivat >>> > >>> Date: 11/28/2011 03:19 PM >>> Subject: Re: [Ecrit] PSAP Callback indication: >>> Resrouce-Priority instead of eGRUU >>> Sent by: ecrit-bounces@ietf.org >>> ________________________________ >>> >>> >>> >>> I see the issues as somewhat orthogonal. Thus, the use of GRUU or >>> In-Reply-To could easily be combined with RPH. >>> >>> Indeed, we've always distinguished Priority (meant to indicate the >>> desired priority at the receiving end system) and Resource-Priority >>> (meant to influence scheduling at intermediate nodes, such >> as gateways >>> and proxies). >>> >>> I agree that the fail-safe mode is desirable, in addition to making >>> spoofing such calls at least modestly difficult. We do not want >>> telemarketers to bypass call filters by slapping on an RPH. >>> >>> I admit that I still don't see what's wrong with the >> following combination: >>> >>> - In-Reply-To allows the UA to match the call to an earlier >> emergency >>> call and thus prevents impersonation (weakly, but probably >> sufficiently >>> to deal with the most likely threat). It can also be used to >> bypass end >>> system call handling. >>> >>> - RPH can be added if needed, but seems likely to have modest to no >>> effect. Using it to bypass call handling by itself seems like a bad >>> idea, for the reason noted above. If the user's proxy keeps track of >>> outbound emergency calls, In-Reply-To works for that as well. >>> >>> - "Priority: emergency" can be used as well, as an indicator >> for call >>> handling, but obviously needs some validation. >>> >>> We need to decide whether we require proxies to keep state >> for recent >>> emergency calls; otherwise and in the absence of a PKI-like >> mechanism, >>> it seems difficult to prevent call impersonation at the user's proxy. >>> >>> There are other ways to solve this; in particular, Kumiko >> presented the >>> ARID proposal at the last DISPATCH meeting on how a callee could >>> validate caller properties. This requires more UA changes, but is >>> stateless in the UA and works across devices. >>> >>> Henning >>> >>> On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote: >>> >>>> >>>> If I recall correctly, the reasons given in the Taipei meeting >>> for indicating a PSAP call-back is any "different" from a >> normal call >>> to a normal GRUU or a normal AoR or URI target, were so that: >>>> (1) the network prioritize the call-back with >>> respect to allocating resources >>>> (2) the network bypass certain >> normal-call "treatments" >>>> (3) so that the reached UA could know to >>> immediately answer the call. >>>> >>>> For (1): if that's not the very definition of the RPH header's >>> purpose, I don't know what is. >>>> >>>> For (2): we have never had a singular defined header or field in >>> SIP which was intended for this purpose, afaik - basically >> there are >>> many headers/fields/methods which in combination are used >> by proxy-ish >>> devices to perform different "treatments". In 3GPP, for example, I >>> believe the filter-criteria can and do use almost any >> header field. >>> So really there's no field we can't use to accomplish this. >>>> >>>> For (3): using a new RPH namespace value for "psap-callback" >>> actually makes sense for this, since it's arguably asking the UA to >>> make available its resources immediately, without waiting for user >>> consent or to put another call on hold. >>>> >>>> Having said all that, I'm not super-tied to using the RPH header >>> either - I just think using a new special GRUU type is >> wrong, both at >>> an architectural level and a practical "it-needs-to-work" >>> level. Even if the RPH field is lost or modified or ignored, for >>> example, the call will likely succeed - that's a good >> property to have >>> I would think. >>>> >>>> -hadriel >>>> >>>> >>>> On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: >>>> >>>>> Can people indicate why they see a synergy with resource >> priority. >>>>> >>>>> This header field is primarily used for giving priority in the >>> network. To be used effectively, it needs to be processed >> first in any >>> message at all SIP entities, and the rest of the message handling >>> depends on it. >>>>> >>>>> While there may possibly be a use for Resource-Priority on >>> emergency callbacks, in order to give priority, I would >> suggest that >>> to give it a purpose beyond that where priority itself is >> not needed, >>> is not using that header for its prime purpose, and indeed detracts >>> from the main usage. >>>>> >>>>> Further, one thing that could well disappear at country >>> boundaries is the Resource-Priority header field, because different >>> regulatory regimes have different sets of rules as to what >> namespaces >>> may be used, and do not necessarily map one to another. >>> Any 3GPP roaming user will need to cross the same country twice (on >>> the signalling path) for the callback call, because the >> callback will >>> go via the home network. >>>>> >>>>> So while I have no axes to grind on losing a GRUU dependency, I >>> do think Resource-Priority is a poor fit. >>>>> >>>>> Keith >>>>> >>>>> From: ecrit-bounces@ietf.org >>> [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg >>>>> Sent: 24 November 2011 10:51 >>>>> To: ECRIT >>>>> Cc: 'Adam Roach'; Paul Kyzivat >>>>> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority >>> instead of eGRUU >>>>> >>>>> >>>>> Hi, >>>>> >>>>> In Taipei, it was indicated that people would prefer another >>> mechanism than a new GRUU type for solving the issue of identifying >>> PSAP callback calls. >>>>> >>>>> A new Resource-Priority header field value, that PSAPs would >>> insert in callback calls, was suggested. It would solve the >>> requirement of allowing network entities (and the UA) to >> identity the >>> callback call, e.g. in order to give special treatment. >>>>> >>>>> (The requirement to reach the same UA device that made the >>> emergency call can be solved with the existing GRUU mechanism, so >>> nothing new is needed there). >>>>> >>>>> So, I would like to know whether people are ok with a >>> Resource-Priority approach? >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> > From pkyzivat@alum.mit.edu Wed Nov 30 11:51:09 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9F421F8880 for ; Wed, 30 Nov 2011 11:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S50USYD+2A8W for ; Wed, 30 Nov 2011 11:51:08 -0800 (PST) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3F911E80A4 for ; Wed, 30 Nov 2011 11:51:01 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta07.westchester.pa.mail.comcast.net with comcast id 3XYS1i0031uE5Es57Xr22c; Wed, 30 Nov 2011 19:51:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id 3Xr11i01c07duvL3cXr1tC; Wed, 30 Nov 2011 19:51:02 +0000 Message-ID: <4ED68923.4060808@alum.mit.edu> Date: Thu, 01 Dec 2011 03:50:59 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 19:51:09 -0000 On 12/1/11 3:22 AM, Christer Holmberg wrote: > > Hi, > >> ISTM that a callback to the Contact address of a prior call should >> typically bypass many treatments, regardless of who it is from. >> >> In particular, it ought to go to the specific device identified by the >> contact address, not to some other device, VM server, etc. >> >> Perhaps that isn't what happens with IMS right now, but then maybe that >> ought to be re-thought. >> >> If that was normal behavior, then what else would be required for >> callbacks by a psap? >> >> There may need to be special treatment by the UA >> itself, but that can be handled by using a unique temp gruu for the >> emergency call and remembering it in order to detect emergency callbacks >> in the UA. >> >> What am I missing? What sort of disruptive services do you expect will >> be applied to calls to a gruu? > > I don't think one can assume that any type of call, non-PSAP-callbacks and PSAP-callbacks, will be given the same special treatment by the network, just because they are addressed using a Contact. > > And, it is not only about routing to another device, but also other services that normally would be applied. Rather than talk generically about "services", can we get tangible about what sorts of things the network might do that would be detrimental to a psap callback? AFAIK about the only thing that the network can do involves routing to some device other than the one addressed by the r-uri. E.g. - route to a VM server or message server that responds in some way. - forward to some other configured address IMO neither of those are appropriate if the URI is a gruu for a specific device and that device is reachable. They would be appropriate even for a psap callback if the device is not reachable. The other thing it could do is blacklist the call - returning an error response. That would be bad, and we should be considering how to avoid that. But perhaps it is the only thing to worry about. Thanks, Paul > Regards, > > Christer > > > On 11/30/11 6:22 PM, Christer Holmberg wrote: >> >> Hi James, >> >>> The fundamental requirement is to provide an indication to >>> SIP request receivers (i.e., each SIP server along the way >>> until you reach the ultimate destination UAS - which is the >>> original UAC that placed the emergency call) to give that SIP >>> request - which is an emergency callback 3 transaction - >>> extra attention if needed to make sure it goes through, right? >> >> Yes. >> >> (There is also a requirement to be able to reach the same UA that made the emergency call. But, gruu provides that, so we don't need to specify anything new.) >> >> >>> If this is the general problem, then IMO >>> >>> Priority: Emergency >>> >>> does not accomplish this goal, as the Priority header value >>> is for users of UAs, not for intermediaries to take into >>> account in any way. >> >> Please remember that lots of the actions taken by the intermediaries are on behalf of the user/UA. For example, an intermediarie would normally trigger a specific service for a specific user/UA, but it would not do so in the case of a PSAP Callback towards that user/UA. >> >> >> >>> Further, since there must be a new Call-ID value, there is no >>> way to tie this back to the initial emergency call. >> >> I think Henning's idea was to use the In-Reply-To header field, which would contain the Call-Id of the associated emergency call. >> >> But, as I said, it would not work with SBCs, and it would not work with intermediaries that weren't involved in the emergency call. >> >> >>> Additionally, the original UAC, may have called for emergency >>> twice, and gotten connected to two different PSAPs. A generic >>> "this is a 911 callback" indication is insufficient, as I >>> believe this needs to be tied somehow to which 911 call was >>> placed. Given that the 911 callback path could traverse a >>> different set of SIP servers back to the original caller, SIP >>> servers would have to blindly give preferential treatment to >>> any SIP request that contains this "this is a 911 callback" - >>> which is begging for misuse and other problems. >> >> There would need to be a way for networks, when receiving a "this is a 911 callback" request from a non-trusted network, to be able to verify that the call comes from a PSAP. >> >> But, again, at least in a 3GPP roaming scenario the home network might not have a clue about the associated emergency call. >> >> >>> What sounds like the best proposal to me, and I'm not sure >>> who mentioned it (Brian?), is for the original 911 caller to >>> insert a token that is received during the callback INVITE >>> (along with the sos URN somewhere in the INVITE). Maybe the >>> token is something encrypted with the public key that >>> identifies the PSAP from the 200 OK in the original >>> transaction. If that same identifier comes back in the >>> callback INVITE, the UAS knows who it is talking to. >> >> The original idea with the emergency gruu was that the home registrar provides such token to the UAS. The home registrar could then use that token to identify the PSAP Callback. >> >> One problem with that was that there might also be other entities that need to identify the PSAP Callback, and for that reason the draft suggests a "static" token value ("psapcb"). But, with a static value you of course have the fraud/misuse issue. >> >> Regards, >> >> Christer >> >> >>> That doesn't solve for what has to happen within the SIP servers >>> or in the network to ensure this SIP request gets >>> preferential treatment, but most here already believe this is >>> going to take a couple of pieces to get to where we want to go. >> >> >> >> >> >> >> >> >> >> >> >>> James >>> >>> At 01:44 PM 11/29/2011, Christer Holmberg wrote: >>> >>>> Hi, >>>> >>>> I agree that, whatever protocol element we use, the element >>> itself is >>>> not enough to prevent abuse. If the request comes from a non-trusted >>>> entity, there needs to be a way to verify it. >>>> >>>> However, different networks might have different ways of doing that, >>>> and I don't think we need to standardize a mechanism before moving >>>> forward with specifying the identifier itself. We do need, however, >>>> have strong wording about the fact that there must be A way >>> to verify >>>> that the call comes from a PSAP. >>>> >>>>> if (call claims to be an emergency-callback) >>>>> check if earlier call was indeed an emergency call >>>> >>>> That does not work for all network entities, as they might >>> not be aware >>>> of the previous emergency call. But, once the identifier has been >>>> verified, other entities within the trust domain can use that >>>> verification. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> ________________________________________ >>>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >>>> Henning Schulzrinne [hgs@cs.columbia.edu] >>>> Sent: Tuesday, November 29, 2011 7:41 PM >>>> To: Janet P Gunn >>>> Cc: Paul Kyzivat; Adam Roach; ECRIT; ecrit-bounces@ietf.org >>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>> Resrouce-Priority instead of eGRUU >>>> >>>> Janet, >>>> >>>> I think we all agree that no label by itself (whether some special >>>> From value, a Priority header or RPH) is sufficient to >>> prevent abuse. >>>> It would only be useful in conjunction with another mechanism that >>>> allows caller-trusted parties, including the UA, to >>> determine that the >>>> call is indeed in response to an earlier emergency call, or, >>>> alternatively, that only such calls can reach a special >>> address, such >>>> as a GRUU. The logic would be something like >>>> >>>> if (call claims to be an emergency-callback) >>>> check if earlier call was indeed an emergency call >>>> >>>> Henning >>>> >>>> On Nov 29, 2011, at 12:16 PM, Janet P Gunn wrote: >>>> >>>> With regard to the use of a new RPH namespace to trigger special >>>> handling or treatment in the network , I guess it depends on >>> what you >>>> mean by "bypass call handling" >>>> "bypass ... treatments" >>>> >>>> Requirement 13 of RFC 5390 (Requirements for Management of >>> Overload in >>>> the Session Initiation Protocol) says >>>> >>>> REQ 13: The mechanism must not dictate a specific algorithm for >>>> prioritizing the processing of work within a proxy >>> during times of >>>> overload. It must permit a proxy to prioritize >>> requests based on >>>> any local policy, so that certain ones (such as a call for >>>> emergency services or a call with a specific value of the >>>> Resource-Priority header field [RFC4412]) are given >>> preferential >>>> treatment, such as not being dropped, being given additional >>>> retransmission, or being processed ahead of others. >>>> >>>> This explicitly names the RPH header as a way to identify calls >>>> needing "special treatment" in the face of SIP overload. Not a >>>> complete "bypass", but definitely a "special treatment". >>>> >>>> WRT "We do not want telemarketers to bypass call filters by >>> slapping on >>>> an RPH." This is true of any use of any RPH namespace. Use >>> of RPH must >>>> always be combined with appropriate >>>> security/authentication/authorization measures to ensure that >>>> unauthorized entities can not "slap on an RPH". >>>> >>>> I agree that, in principle, "Priority" rather than "Resource >>> Priority" >>>> is the appropriate way to inform the destination that special >>>> treatment at the destination is requested. However anyone >>> can "slap on >>>> a Priority header", as there is no associated >>>> security/authentication/authorization . >>>> >>>> Janet >>>> >>>> >>>> This is a PRIVATE message. If you are not the intended recipient, >>>> please delete without copying and kindly advise us by e-mail of the >>>> mistake in delivery. NOTE: Regardless of content, this >>> e-mail shall not >>>> operate to bind CSC to any order or other contract unless >>> pursuant to >>>> explicit written agreement or government initiative expressly >>>> permitting the use of e-mail for such purpose. >>>> >>>> >>>> >>>> From: Henning Schulzrinne >>>> > >>>> To: Hadriel Kaplan >>>> > >>>> Cc: Adam Roach>, >>>> ECRIT>, Paul Kyzivat >>>> > >>>> Date: 11/28/2011 03:19 PM >>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>> Resrouce-Priority instead of eGRUU >>>> Sent by: ecrit-bounces@ietf.org >>>> ________________________________ >>>> >>>> >>>> >>>> I see the issues as somewhat orthogonal. Thus, the use of GRUU or >>>> In-Reply-To could easily be combined with RPH. >>>> >>>> Indeed, we've always distinguished Priority (meant to indicate the >>>> desired priority at the receiving end system) and Resource-Priority >>>> (meant to influence scheduling at intermediate nodes, such >>> as gateways >>>> and proxies). >>>> >>>> I agree that the fail-safe mode is desirable, in addition to making >>>> spoofing such calls at least modestly difficult. We do not want >>>> telemarketers to bypass call filters by slapping on an RPH. >>>> >>>> I admit that I still don't see what's wrong with the >>> following combination: >>>> >>>> - In-Reply-To allows the UA to match the call to an earlier >>> emergency >>>> call and thus prevents impersonation (weakly, but probably >>> sufficiently >>>> to deal with the most likely threat). It can also be used to >>> bypass end >>>> system call handling. >>>> >>>> - RPH can be added if needed, but seems likely to have modest to no >>>> effect. Using it to bypass call handling by itself seems like a bad >>>> idea, for the reason noted above. If the user's proxy keeps track of >>>> outbound emergency calls, In-Reply-To works for that as well. >>>> >>>> - "Priority: emergency" can be used as well, as an indicator >>> for call >>>> handling, but obviously needs some validation. >>>> >>>> We need to decide whether we require proxies to keep state >>> for recent >>>> emergency calls; otherwise and in the absence of a PKI-like >>> mechanism, >>>> it seems difficult to prevent call impersonation at the user's proxy. >>>> >>>> There are other ways to solve this; in particular, Kumiko >>> presented the >>>> ARID proposal at the last DISPATCH meeting on how a callee could >>>> validate caller properties. This requires more UA changes, but is >>>> stateless in the UA and works across devices. >>>> >>>> Henning >>>> >>>> On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote: >>>> >>>>> >>>>> If I recall correctly, the reasons given in the Taipei meeting >>>> for indicating a PSAP call-back is any "different" from a >>> normal call >>>> to a normal GRUU or a normal AoR or URI target, were so that: >>>>> (1) the network prioritize the call-back with >>>> respect to allocating resources >>>>> (2) the network bypass certain >>> normal-call "treatments" >>>>> (3) so that the reached UA could know to >>>> immediately answer the call. >>>>> >>>>> For (1): if that's not the very definition of the RPH header's >>>> purpose, I don't know what is. >>>>> >>>>> For (2): we have never had a singular defined header or field in >>>> SIP which was intended for this purpose, afaik - basically >>> there are >>>> many headers/fields/methods which in combination are used >>> by proxy-ish >>>> devices to perform different "treatments". In 3GPP, for example, I >>>> believe the filter-criteria can and do use almost any >>> header field. >>>> So really there's no field we can't use to accomplish this. >>>>> >>>>> For (3): using a new RPH namespace value for "psap-callback" >>>> actually makes sense for this, since it's arguably asking the UA to >>>> make available its resources immediately, without waiting for user >>>> consent or to put another call on hold. >>>>> >>>>> Having said all that, I'm not super-tied to using the RPH header >>>> either - I just think using a new special GRUU type is >>> wrong, both at >>>> an architectural level and a practical "it-needs-to-work" >>>> level. Even if the RPH field is lost or modified or ignored, for >>>> example, the call will likely succeed - that's a good >>> property to have >>>> I would think. >>>>> >>>>> -hadriel >>>>> >>>>> >>>>> On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: >>>>> >>>>>> Can people indicate why they see a synergy with resource >>> priority. >>>>>> >>>>>> This header field is primarily used for giving priority in the >>>> network. To be used effectively, it needs to be processed >>> first in any >>>> message at all SIP entities, and the rest of the message handling >>>> depends on it. >>>>>> >>>>>> While there may possibly be a use for Resource-Priority on >>>> emergency callbacks, in order to give priority, I would >>> suggest that >>>> to give it a purpose beyond that where priority itself is >>> not needed, >>>> is not using that header for its prime purpose, and indeed detracts >>>> from the main usage. >>>>>> >>>>>> Further, one thing that could well disappear at country >>>> boundaries is the Resource-Priority header field, because different >>>> regulatory regimes have different sets of rules as to what >>> namespaces >>>> may be used, and do not necessarily map one to another. >>>> Any 3GPP roaming user will need to cross the same country twice (on >>>> the signalling path) for the callback call, because the >>> callback will >>>> go via the home network. >>>>>> >>>>>> So while I have no axes to grind on losing a GRUU dependency, I >>>> do think Resource-Priority is a poor fit. >>>>>> >>>>>> Keith >>>>>> >>>>>> From: ecrit-bounces@ietf.org >>>> [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg >>>>>> Sent: 24 November 2011 10:51 >>>>>> To: ECRIT >>>>>> Cc: 'Adam Roach'; Paul Kyzivat >>>>>> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority >>>> instead of eGRUU >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> In Taipei, it was indicated that people would prefer another >>>> mechanism than a new GRUU type for solving the issue of identifying >>>> PSAP callback calls. >>>>>> >>>>>> A new Resource-Priority header field value, that PSAPs would >>>> insert in callback calls, was suggested. It would solve the >>>> requirement of allowing network entities (and the UA) to >>> identity the >>>> callback call, e.g. in order to give special treatment. >>>>>> >>>>>> (The requirement to reach the same UA device that made the >>>> emergency call can be solved with the existing GRUU mechanism, so >>>> nothing new is needed there). >>>>>> >>>>>> So, I would like to know whether people are ok with a >>>> Resource-Priority approach? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> > > From christer.holmberg@ericsson.com Wed Nov 30 11:58:00 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE4221F8B0C for ; Wed, 30 Nov 2011 11:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyClIpxK7p4z for ; Wed, 30 Nov 2011 11:57:59 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 934E221F8B07 for ; Wed, 30 Nov 2011 11:57:58 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-d8-4ed68ac58d71 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 46.04.09514.5CA86DE4; Wed, 30 Nov 2011 20:57:57 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Wed, 30 Nov 2011 20:57:57 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 30 Nov 2011 20:57:56 +0100 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AcyvmWQOoMrxNWxLTUyE/4utF/D+cwAACxSo Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> In-Reply-To: <4ED68923.4060808@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 19:58:00 -0000 Hi, >>> ISTM that a callback to the Contact address of a prior call should >>> typically bypass many treatments, regardless of who it is from. >>> >>> In particular, it ought to go to the specific device identified by the >>> contact address, not to some other device, VM server, etc. >>> >>> Perhaps that isn't what happens with IMS right now, but then maybe that >>> ought to be re-thought. >>> >>> If that was normal behavior, then what else would be required for >>> callbacks by a psap? >>> >>> There may need to be special treatment by the UA >>> itself, but that can be handled by using a unique temp gruu for the >>> emergency call and remembering it in order to detect emergency callback= s >>> in the UA. >>> >>> What am I missing? What sort of disruptive services do you expect will >>> be applied to calls to a gruu? >> >> I don't think one can assume that any type of call, non-PSAP-callbacks a= nd PSAP-callbacks, will be given the same special treatment by the network,= just because they are addressed using a Contact. >> >> And, it is not only about routing to another device, but also other serv= ices that normally would be applied. > > Rather than talk generically about "services", can we get tangible about > what sorts of things the network might do that would be detrimental to a > psap callback? > > AFAIK about the only thing that the network can do involves routing to > some device other than the one addressed by the r-uri. E.g. > - route to a VM server or message server that responds in some way. > - forward to some other configured address > > IMO neither of those are appropriate if the URI is a gruu for a specific > device and that device is reachable. They would be appropriate even for > a psap callback if the device is not reachable. Again, it's not only about routing to a specific device. Before the request even reaches the device, it might e.g. be routed to diff= erent application servers in the network, triggering different kind of non-= routing related services. A "normal" gruu addressed call could still be rou= ted to such application servers, while a PSAP callback wouldn't. Regards, Christer The other thing it could do is blacklist the call - returning an error response. That would be bad, and we should be considering how to avoid that. But perhaps it is the only thing to worry about. Thanks, Paul > Regards, > > Christer > > > On 11/30/11 6:22 PM, Christer Holmberg wrote: >> >> Hi James, >> >>> The fundamental requirement is to provide an indication to >>> SIP request receivers (i.e., each SIP server along the way >>> until you reach the ultimate destination UAS - which is the >>> original UAC that placed the emergency call) to give that SIP >>> request - which is an emergency callback 3 transaction - >>> extra attention if needed to make sure it goes through, right? >> >> Yes. >> >> (There is also a requirement to be able to reach the same UA that made t= he emergency call. But, gruu provides that, so we don't need to specify any= thing new.) >> >> >>> If this is the general problem, then IMO >>> >>> Priority: Emergency >>> >>> does not accomplish this goal, as the Priority header value >>> is for users of UAs, not for intermediaries to take into >>> account in any way. >> >> Please remember that lots of the actions taken by the intermediaries are= on behalf of the user/UA. For example, an intermediarie would normally tri= gger a specific service for a specific user/UA, but it would not do so in t= he case of a PSAP Callback towards that user/UA. >> >> >> >>> Further, since there must be a new Call-ID value, there is no >>> way to tie this back to the initial emergency call. >> >> I think Henning's idea was to use the In-Reply-To header field, which wo= uld contain the Call-Id of the associated emergency call. >> >> But, as I said, it would not work with SBCs, and it would not work with = intermediaries that weren't involved in the emergency call. >> >> >>> Additionally, the original UAC, may have called for emergency >>> twice, and gotten connected to two different PSAPs. A generic >>> "this is a 911 callback" indication is insufficient, as I >>> believe this needs to be tied somehow to which 911 call was >>> placed. Given that the 911 callback path could traverse a >>> different set of SIP servers back to the original caller, SIP >>> servers would have to blindly give preferential treatment to >>> any SIP request that contains this "this is a 911 callback" - >>> which is begging for misuse and other problems. >> >> There would need to be a way for networks, when receiving a "this is a 9= 11 callback" request from a non-trusted network, to be able to verify that = the call comes from a PSAP. >> >> But, again, at least in a 3GPP roaming scenario the home network might n= ot have a clue about the associated emergency call. >> >> >>> What sounds like the best proposal to me, and I'm not sure >>> who mentioned it (Brian?), is for the original 911 caller to >>> insert a token that is received during the callback INVITE >>> (along with the sos URN somewhere in the INVITE). Maybe the >>> token is something encrypted with the public key that >>> identifies the PSAP from the 200 OK in the original >>> transaction. If that same identifier comes back in the >>> callback INVITE, the UAS knows who it is talking to. >> >> The original idea with the emergency gruu was that the home registrar pr= ovides such token to the UAS. The home registrar could then use that token = to identify the PSAP Callback. >> >> One problem with that was that there might also be other entities that n= eed to identify the PSAP Callback, and for that reason the draft suggests a= "static" token value ("psapcb"). But, with a static value you of course ha= ve the fraud/misuse issue. >> >> Regards, >> >> Christer >> >> >>> That doesn't solve for what has to happen within the SIP servers >>> or in the network to ensure this SIP request gets >>> preferential treatment, but most here already believe this is >>> going to take a couple of pieces to get to where we want to go. >> >> >> >> >> >> >> >> >> >> >> >>> James >>> >>> At 01:44 PM 11/29/2011, Christer Holmberg wrote: >>> >>>> Hi, >>>> >>>> I agree that, whatever protocol element we use, the element >>> itself is >>>> not enough to prevent abuse. If the request comes from a non-trusted >>>> entity, there needs to be a way to verify it. >>>> >>>> However, different networks might have different ways of doing that, >>>> and I don't think we need to standardize a mechanism before moving >>>> forward with specifying the identifier itself. We do need, however, >>>> have strong wording about the fact that there must be A way >>> to verify >>>> that the call comes from a PSAP. >>>> >>>>> if (call claims to be an emergency-callback) >>>>> check if earlier call was indeed an emergency call >>>> >>>> That does not work for all network entities, as they might >>> not be aware >>>> of the previous emergency call. But, once the identifier has been >>>> verified, other entities within the trust domain can use that >>>> verification. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>> ________________________________________ >>>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >>>> Henning Schulzrinne [hgs@cs.columbia.edu] >>>> Sent: Tuesday, November 29, 2011 7:41 PM >>>> To: Janet P Gunn >>>> Cc: Paul Kyzivat; Adam Roach; ECRIT; ecrit-bounces@ietf.org >>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>> Resrouce-Priority instead of eGRUU >>>> >>>> Janet, >>>> >>>> I think we all agree that no label by itself (whether some special >>>> From value, a Priority header or RPH) is sufficient to >>> prevent abuse. >>>> It would only be useful in conjunction with another mechanism that >>>> allows caller-trusted parties, including the UA, to >>> determine that the >>>> call is indeed in response to an earlier emergency call, or, >>>> alternatively, that only such calls can reach a special >>> address, such >>>> as a GRUU. The logic would be something like >>>> >>>> if (call claims to be an emergency-callback) >>>> check if earlier call was indeed an emergency call >>>> >>>> Henning >>>> >>>> On Nov 29, 2011, at 12:16 PM, Janet P Gunn wrote: >>>> >>>> With regard to the use of a new RPH namespace to trigger special >>>> handling or treatment in the network , I guess it depends on >>> what you >>>> mean by "bypass call handling" >>>> "bypass ... treatments" >>>> >>>> Requirement 13 of RFC 5390 (Requirements for Management of >>> Overload in >>>> the Session Initiation Protocol) says >>>> >>>> REQ 13: The mechanism must not dictate a specific algorithm for >>>> prioritizing the processing of work within a proxy >>> during times of >>>> overload. It must permit a proxy to prioritize >>> requests based on >>>> any local policy, so that certain ones (such as a call for >>>> emergency services or a call with a specific value of the >>>> Resource-Priority header field [RFC4412]) are given >>> preferential >>>> treatment, such as not being dropped, being given additional >>>> retransmission, or being processed ahead of others. >>>> >>>> This explicitly names the RPH header as a way to identify calls >>>> needing "special treatment" in the face of SIP overload. Not a >>>> complete "bypass", but definitely a "special treatment". >>>> >>>> WRT "We do not want telemarketers to bypass call filters by >>> slapping on >>>> an RPH." This is true of any use of any RPH namespace. Use >>> of RPH must >>>> always be combined with appropriate >>>> security/authentication/authorization measures to ensure that >>>> unauthorized entities can not "slap on an RPH". >>>> >>>> I agree that, in principle, "Priority" rather than "Resource >>> Priority" >>>> is the appropriate way to inform the destination that special >>>> treatment at the destination is requested. However anyone >>> can "slap on >>>> a Priority header", as there is no associated >>>> security/authentication/authorization . >>>> >>>> Janet >>>> >>>> >>>> This is a PRIVATE message. If you are not the intended recipient, >>>> please delete without copying and kindly advise us by e-mail of the >>>> mistake in delivery. NOTE: Regardless of content, this >>> e-mail shall not >>>> operate to bind CSC to any order or other contract unless >>> pursuant to >>>> explicit written agreement or government initiative expressly >>>> permitting the use of e-mail for such purpose. >>>> >>>> >>>> >>>> From: Henning Schulzrinne >>>> > >>>> To: Hadriel Kaplan >>>> > >>>> Cc: Adam Roach>, >>>> ECRIT>, Paul Kyzivat >>>> > >>>> Date: 11/28/2011 03:19 PM >>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>> Resrouce-Priority instead of eGRUU >>>> Sent by: ecrit-bounces@ietf.org >>>> ________________________________ >>>> >>>> >>>> >>>> I see the issues as somewhat orthogonal. Thus, the use of GRUU or >>>> In-Reply-To could easily be combined with RPH. >>>> >>>> Indeed, we've always distinguished Priority (meant to indicate the >>>> desired priority at the receiving end system) and Resource-Priority >>>> (meant to influence scheduling at intermediate nodes, such >>> as gateways >>>> and proxies). >>>> >>>> I agree that the fail-safe mode is desirable, in addition to making >>>> spoofing such calls at least modestly difficult. We do not want >>>> telemarketers to bypass call filters by slapping on an RPH. >>>> >>>> I admit that I still don't see what's wrong with the >>> following combination: >>>> >>>> - In-Reply-To allows the UA to match the call to an earlier >>> emergency >>>> call and thus prevents impersonation (weakly, but probably >>> sufficiently >>>> to deal with the most likely threat). It can also be used to >>> bypass end >>>> system call handling. >>>> >>>> - RPH can be added if needed, but seems likely to have modest to no >>>> effect. Using it to bypass call handling by itself seems like a bad >>>> idea, for the reason noted above. If the user's proxy keeps track of >>>> outbound emergency calls, In-Reply-To works for that as well. >>>> >>>> - "Priority: emergency" can be used as well, as an indicator >>> for call >>>> handling, but obviously needs some validation. >>>> >>>> We need to decide whether we require proxies to keep state >>> for recent >>>> emergency calls; otherwise and in the absence of a PKI-like >>> mechanism, >>>> it seems difficult to prevent call impersonation at the user's proxy. >>>> >>>> There are other ways to solve this; in particular, Kumiko >>> presented the >>>> ARID proposal at the last DISPATCH meeting on how a callee could >>>> validate caller properties. This requires more UA changes, but is >>>> stateless in the UA and works across devices. >>>> >>>> Henning >>>> >>>> On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote: >>>> >>>>> >>>>> If I recall correctly, the reasons given in the Taipei meeting >>>> for indicating a PSAP call-back is any "different" from a >>> normal call >>>> to a normal GRUU or a normal AoR or URI target, were so that: >>>>> (1) the network prioritize the call-back with >>>> respect to allocating resources >>>>> (2) the network bypass certain >>> normal-call "treatments" >>>>> (3) so that the reached UA could know to >>>> immediately answer the call. >>>>> >>>>> For (1): if that's not the very definition of the RPH header's >>>> purpose, I don't know what is. >>>>> >>>>> For (2): we have never had a singular defined header or field in >>>> SIP which was intended for this purpose, afaik - basically >>> there are >>>> many headers/fields/methods which in combination are used >>> by proxy-ish >>>> devices to perform different "treatments". In 3GPP, for example, I >>>> believe the filter-criteria can and do use almost any >>> header field. >>>> So really there's no field we can't use to accomplish this. >>>>> >>>>> For (3): using a new RPH namespace value for "psap-callback" >>>> actually makes sense for this, since it's arguably asking the UA to >>>> make available its resources immediately, without waiting for user >>>> consent or to put another call on hold. >>>>> >>>>> Having said all that, I'm not super-tied to using the RPH header >>>> either - I just think using a new special GRUU type is >>> wrong, both at >>>> an architectural level and a practical "it-needs-to-work" >>>> level. Even if the RPH field is lost or modified or ignored, for >>>> example, the call will likely succeed - that's a good >>> property to have >>>> I would think. >>>>> >>>>> -hadriel >>>>> >>>>> >>>>> On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: >>>>> >>>>>> Can people indicate why they see a synergy with resource >>> priority. >>>>>> >>>>>> This header field is primarily used for giving priority in the >>>> network. To be used effectively, it needs to be processed >>> first in any >>>> message at all SIP entities, and the rest of the message handling >>>> depends on it. >>>>>> >>>>>> While there may possibly be a use for Resource-Priority on >>>> emergency callbacks, in order to give priority, I would >>> suggest that >>>> to give it a purpose beyond that where priority itself is >>> not needed, >>>> is not using that header for its prime purpose, and indeed detracts >>>> from the main usage. >>>>>> >>>>>> Further, one thing that could well disappear at country >>>> boundaries is the Resource-Priority header field, because different >>>> regulatory regimes have different sets of rules as to what >>> namespaces >>>> may be used, and do not necessarily map one to another. >>>> Any 3GPP roaming user will need to cross the same country twice (on >>>> the signalling path) for the callback call, because the >>> callback will >>>> go via the home network. >>>>>> >>>>>> So while I have no axes to grind on losing a GRUU dependency, I >>>> do think Resource-Priority is a poor fit. >>>>>> >>>>>> Keith >>>>>> >>>>>> From: ecrit-bounces@ietf.org >>>> [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg >>>>>> Sent: 24 November 2011 10:51 >>>>>> To: ECRIT >>>>>> Cc: 'Adam Roach'; Paul Kyzivat >>>>>> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority >>>> instead of eGRUU >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> In Taipei, it was indicated that people would prefer another >>>> mechanism than a new GRUU type for solving the issue of identifying >>>> PSAP callback calls. >>>>>> >>>>>> A new Resource-Priority header field value, that PSAPs would >>>> insert in callback calls, was suggested. It would solve the >>>> requirement of allowing network entities (and the UA) to >>> identity the >>>> callback call, e.g. in order to give special treatment. >>>>>> >>>>>> (The requirement to reach the same UA device that made the >>>> emergency call can be solved with the existing GRUU mechanism, so >>>> nothing new is needed there). >>>>>> >>>>>> So, I would like to know whether people are ok with a >>>> Resource-Priority approach? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>> >>> >> > > From pkyzivat@alum.mit.edu Wed Nov 30 12:06:07 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28411F0C56 for ; Wed, 30 Nov 2011 12:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78cLsZFUQNK0 for ; Wed, 30 Nov 2011 12:06:06 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 385EC21F84AC for ; Wed, 30 Nov 2011 12:06:06 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta05.westchester.pa.mail.comcast.net with comcast id 3WXh1i0041ZXKqc55Y666l; Wed, 30 Nov 2011 20:06:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id 3Y661i00A07duvL3hY660B; Wed, 30 Nov 2011 20:06:06 +0000 Message-ID: <4ED68CAB.5080602@alum.mit.edu> Date: Thu, 01 Dec 2011 04:06:03 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 20:06:07 -0000 On 12/1/11 3:57 AM, Christer Holmberg wrote: > > Hi, > >>>> ISTM that a callback to the Contact address of a prior call should >>>> typically bypass many treatments, regardless of who it is from. >>>> >>>> In particular, it ought to go to the specific device identified by the >>>> contact address, not to some other device, VM server, etc. >>>> >>>> Perhaps that isn't what happens with IMS right now, but then maybe that >>>> ought to be re-thought. >>>> >>>> If that was normal behavior, then what else would be required for >>>> callbacks by a psap? >>>> >>>> There may need to be special treatment by the UA >>>> itself, but that can be handled by using a unique temp gruu for the >>>> emergency call and remembering it in order to detect emergency callbacks >>>> in the UA. >>>> >>>> What am I missing? What sort of disruptive services do you expect will >>>> be applied to calls to a gruu? >>> >>> I don't think one can assume that any type of call, non-PSAP-callbacks and PSAP-callbacks, will be given the same special treatment by the network, just because they are addressed using a Contact. >>> >>> And, it is not only about routing to another device, but also other services that normally would be applied. >> >> Rather than talk generically about "services", can we get tangible about >> what sorts of things the network might do that would be detrimental to a >> psap callback? >> >> AFAIK about the only thing that the network can do involves routing to >> some device other than the one addressed by the r-uri. E.g. >> - route to a VM server or message server that responds in some way. >> - forward to some other configured address >> >> IMO neither of those are appropriate if the URI is a gruu for a specific >> device and that device is reachable. They would be appropriate even for >> a psap callback if the device is not reachable. > > Again, it's not only about routing to a specific device. > > Before the request even reaches the device, it might e.g. be routed to different application servers in the network, triggering different kind of non-routing related services. A "normal" gruu addressed call could still be routed to such application servers, while a PSAP callback wouldn't. Without some tangible examples, what you say is just so much "mumble,mumble" to me. Either it is routed to some alternative device that terminates the call instead of the intended device, or else it is routed through some device that simply acts as an intermediary, still allowing the call to reach the intended device, or else it fails the call. Anything that acts as an intermediary, still allowing the call to reach the intended destination, is probably benign. (Do you have a counter-example?) Anything that routes to someplace other than the intended device is of dubious appropriateness when the r-uri is a GRUU. Again I'd be interested to hear some examples. Thanks, Paul From jmpolk@cisco.com Wed Nov 30 13:00:43 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5331F0C80 for ; Wed, 30 Nov 2011 13:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz1KTdBSkLlV for ; Wed, 30 Nov 2011 13:00:41 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4C11F0C7F for ; Wed, 30 Nov 2011 13:00:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=18940; q=dns/txt; s=iport; t=1322686841; x=1323896441; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=O18rbToG6xCb/67XT/K0k10qgUtbg4nOZ/AMPhx0bfI=; b=k7olRAyRC/hAg7tTHJTQiG8dyEKikLI1YtNh1H6VadCy0PtzgH9bDobT ypPjTVLKn75UylGI47n3Q3b1j4PXx24o6+VbZitD3/EH5EGH0w6ial0o3 576FOtnCp2JtI7JU8R7zyoPebts8+PIfKTC1VWnV6jxzmnDtifiZpD1IA A=; X-IronPort-AV: E=Sophos;i="4.71,273,1320624000"; d="scan'208";a="17012535" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 30 Nov 2011 21:00:41 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAUL0dBU010082; Wed, 30 Nov 2011 21:00:40 GMT Message-Id: <201111302100.pAUL0dBU010082@mtv-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 30 Nov 2011 15:00:32 -0600 To: Paul Kyzivat , Christer Holmberg From: "James M. Polk" In-Reply-To: <4ED68923.4060808@alum.mit.edu> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se> <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se> <4ED68923.4060808@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:00:43 -0000 At 01:50 PM 11/30/2011, Paul Kyzivat wrote: >On 12/1/11 3:22 AM, Christer Holmberg wrote: >> >>Hi, >> >>>ISTM that a callback to the Contact address of a prior call should >>>typically bypass many treatments, regardless of who it is from. >>> >>>In particular, it ought to go to the specific device identified by the >>>contact address, not to some other device, VM server, etc. >>> >>>Perhaps that isn't what happens with IMS right now, but then maybe that >>>ought to be re-thought. >>> >>>If that was normal behavior, then what else would be required for >>>callbacks by a psap? >>> >>>There may need to be special treatment by the UA >>>itself, but that can be handled by using a unique temp gruu for the >>>emergency call and remembering it in order to detect emergency callbacks >>>in the UA. >>> >>>What am I missing? What sort of disruptive services do you expect will >>>be applied to calls to a gruu? >> >>I don't think one can assume that any type of call, >>non-PSAP-callbacks and PSAP-callbacks, will be given the same >>special treatment by the network, just because they are addressed >>using a Contact. >> >>And, it is not only about routing to another device, but also other >>services that normally would be applied. > >Rather than talk generically about "services", can we get tangible >about what sorts of things the network might do that would be >detrimental to a psap callback? > >AFAIK about the only thing that the network can do involves routing >to some device other than the one addressed by the r-uri. E.g. >- route to a VM server or message server that responds in some way. >- forward to some other configured address > >IMO neither of those are appropriate if the URI is a gruu for a >specific device and that device is reachable. They would be >appropriate even for a psap callback if the device is not reachable. however ISTM that if any intermediary is in a congestion state, this callback would suffer like all other INVITEs (especially if SOC mechanisms are implemented), which - I don't believe - we or Christer wants to have happen. In that case, RP is the defined SIP mechanism to give special treatment to the request, but it can't be the only aspect that's different about this INVITE. I think you still need a GRUU (at least). James >The other thing it could do is blacklist the call - returning an >error response. That would be bad, and we should be considering how >to avoid that. But perhaps it is the only thing to worry about. > > Thanks, > Paul > >>Regards, >> >>Christer >> >> >>On 11/30/11 6:22 PM, Christer Holmberg wrote: >>> >>>Hi James, >>> >>>>The fundamental requirement is to provide an indication to >>>>SIP request receivers (i.e., each SIP server along the way >>>>until you reach the ultimate destination UAS - which is the >>>>original UAC that placed the emergency call) to give that SIP >>>>request - which is an emergency callback 3 transaction - >>>>extra attention if needed to make sure it goes through, right? >>> >>>Yes. >>> >>>(There is also a requirement to be able to reach the same UA that >>>made the emergency call. But, gruu provides that, so we don't need >>>to specify anything new.) >>> >>> >>>>If this is the general problem, then IMO >>>> >>>> Priority: Emergency >>>> >>>>does not accomplish this goal, as the Priority header value >>>>is for users of UAs, not for intermediaries to take into >>>>account in any way. >>> >>>Please remember that lots of the actions taken by the >>>intermediaries are on behalf of the user/UA. For example, an >>>intermediarie would normally trigger a specific service for a >>>specific user/UA, but it would not do so in the case of a PSAP >>>Callback towards that user/UA. >>> >>> >>> >>>>Further, since there must be a new Call-ID value, there is no >>>>way to tie this back to the initial emergency call. >>> >>>I think Henning's idea was to use the In-Reply-To header field, >>>which would contain the Call-Id of the associated emergency call. >>> >>>But, as I said, it would not work with SBCs, and it would not work >>>with intermediaries that weren't involved in the emergency call. >>> >>> >>>>Additionally, the original UAC, may have called for emergency >>>>twice, and gotten connected to two different PSAPs. A generic >>>>"this is a 911 callback" indication is insufficient, as I >>>>believe this needs to be tied somehow to which 911 call was >>>>placed. Given that the 911 callback path could traverse a >>>>different set of SIP servers back to the original caller, SIP >>>>servers would have to blindly give preferential treatment to >>>>any SIP request that contains this "this is a 911 callback" - >>>>which is begging for misuse and other problems. >>> >>>There would need to be a way for networks, when receiving a "this >>>is a 911 callback" request from a non-trusted network, to be able >>>to verify that the call comes from a PSAP. >>> >>>But, again, at least in a 3GPP roaming scenario the home network >>>might not have a clue about the associated emergency call. >>> >>> >>>>What sounds like the best proposal to me, and I'm not sure >>>>who mentioned it (Brian?), is for the original 911 caller to >>>>insert a token that is received during the callback INVITE >>>>(along with the sos URN somewhere in the INVITE). Maybe the >>>>token is something encrypted with the public key that >>>>identifies the PSAP from the 200 OK in the original >>>>transaction. If that same identifier comes back in the >>>>callback INVITE, the UAS knows who it is talking to. >>> >>>The original idea with the emergency gruu was that the home >>>registrar provides such token to the UAS. The home registrar could >>>then use that token to identify the PSAP Callback. >>> >>>One problem with that was that there might also be other entities >>>that need to identify the PSAP Callback, and for that reason the >>>draft suggests a "static" token value ("psapcb"). But, with a >>>static value you of course have the fraud/misuse issue. >>> >>>Regards, >>> >>>Christer >>> >>> >>>>That doesn't solve for what has to happen within the SIP servers >>>>or in the network to ensure this SIP request gets >>>>preferential treatment, but most here already believe this is >>>>going to take a couple of pieces to get to where we want to go. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>>James >>>> >>>>At 01:44 PM 11/29/2011, Christer Holmberg wrote: >>>> >>>>>Hi, >>>>> >>>>>I agree that, whatever protocol element we use, the element >>>>itself is >>>>>not enough to prevent abuse. If the request comes from a non-trusted >>>>>entity, there needs to be a way to verify it. >>>>> >>>>>However, different networks might have different ways of doing that, >>>>>and I don't think we need to standardize a mechanism before moving >>>>>forward with specifying the identifier itself. We do need, however, >>>>>have strong wording about the fact that there must be A way >>>>to verify >>>>>that the call comes from a PSAP. >>>>> >>>>>>if (call claims to be an emergency-callback) >>>>>> check if earlier call was indeed an emergency call >>>>> >>>>>That does not work for all network entities, as they might >>>>not be aware >>>>>of the previous emergency call. But, once the identifier has been >>>>>verified, other entities within the trust domain can use that >>>>>verification. >>>>> >>>>>Regards, >>>>> >>>>>Christer >>>>> >>>>> >>>>>________________________________________ >>>>>From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >>>>>Henning Schulzrinne [hgs@cs.columbia.edu] >>>>>Sent: Tuesday, November 29, 2011 7:41 PM >>>>>To: Janet P Gunn >>>>>Cc: Paul Kyzivat; Adam Roach; ECRIT; ecrit-bounces@ietf.org >>>>>Subject: Re: [Ecrit] PSAP Callback indication: >>>>>Resrouce-Priority instead of eGRUU >>>>> >>>>>Janet, >>>>> >>>>>I think we all agree that no label by itself (whether some special >>>>> From value, a Priority header or RPH) is sufficient to >>>>prevent abuse. >>>>>It would only be useful in conjunction with another mechanism that >>>>>allows caller-trusted parties, including the UA, to >>>>determine that the >>>>>call is indeed in response to an earlier emergency call, or, >>>>>alternatively, that only such calls can reach a special >>>>address, such >>>>>as a GRUU. The logic would be something like >>>>> >>>>>if (call claims to be an emergency-callback) >>>>> check if earlier call was indeed an emergency call >>>>> >>>>>Henning >>>>> >>>>>On Nov 29, 2011, at 12:16 PM, Janet P Gunn wrote: >>>>> >>>>>With regard to the use of a new RPH namespace to trigger special >>>>>handling or treatment in the network , I guess it depends on >>>>what you >>>>>mean by "bypass call handling" >>>>>"bypass ... treatments" >>>>> >>>>>Requirement 13 of RFC 5390 (Requirements for Management of >>>>Overload in >>>>>the Session Initiation Protocol) says >>>>> >>>>>REQ 13: The mechanism must not dictate a specific algorithm for >>>>> prioritizing the processing of work within a proxy >>>>during times of >>>>> overload. It must permit a proxy to prioritize >>>>requests based on >>>>> any local policy, so that certain ones (such as a call for >>>>> emergency services or a call with a specific value of the >>>>> Resource-Priority header field [RFC4412]) are given >>>>preferential >>>>> treatment, such as not being dropped, being given additional >>>>> retransmission, or being processed ahead of others. >>>>> >>>>>This explicitly names the RPH header as a way to identify calls >>>>>needing "special treatment" in the face of SIP overload. Not a >>>>>complete "bypass", but definitely a "special treatment". >>>>> >>>>>WRT "We do not want telemarketers to bypass call filters by >>>>slapping on >>>>>an RPH." This is true of any use of any RPH namespace. Use >>>>of RPH must >>>>>always be combined with appropriate >>>>>security/authentication/authorization measures to ensure that >>>>>unauthorized entities can not "slap on an RPH". >>>>> >>>>>I agree that, in principle, "Priority" rather than "Resource >>>>Priority" >>>>>is the appropriate way to inform the destination that special >>>>>treatment at the destination is requested. However anyone >>>>can "slap on >>>>>a Priority header", as there is no associated >>>>>security/authentication/authorization . >>>>> >>>>>Janet >>>>> >>>>> >>>>>This is a PRIVATE message. If you are not the intended recipient, >>>>>please delete without copying and kindly advise us by e-mail of the >>>>>mistake in delivery. NOTE: Regardless of content, this >>>>e-mail shall not >>>>>operate to bind CSC to any order or other contract unless >>>>pursuant to >>>>>explicit written agreement or government initiative expressly >>>>>permitting the use of e-mail for such purpose. >>>>> >>>>> >>>>> >>>>>From: Henning Schulzrinne >>>>>> >>>>>To: Hadriel Kaplan >>>>>> >>>>>Cc: Adam Roach>, >>>>>ECRIT>, Paul Kyzivat >>>>>> >>>>>Date: 11/28/2011 03:19 PM >>>>>Subject: Re: [Ecrit] PSAP Callback indication: >>>>>Resrouce-Priority instead of eGRUU >>>>>Sent by: ecrit-bounces@ietf.org >>>>>________________________________ >>>>> >>>>> >>>>> >>>>>I see the issues as somewhat orthogonal. Thus, the use of GRUU or >>>>>In-Reply-To could easily be combined with RPH. >>>>> >>>>>Indeed, we've always distinguished Priority (meant to indicate the >>>>>desired priority at the receiving end system) and Resource-Priority >>>>>(meant to influence scheduling at intermediate nodes, such >>>>as gateways >>>>>and proxies). >>>>> >>>>>I agree that the fail-safe mode is desirable, in addition to making >>>>>spoofing such calls at least modestly difficult. We do not want >>>>>telemarketers to bypass call filters by slapping on an RPH. >>>>> >>>>>I admit that I still don't see what's wrong with the >>>>following combination: >>>>> >>>>>- In-Reply-To allows the UA to match the call to an earlier >>>>emergency >>>>>call and thus prevents impersonation (weakly, but probably >>>>sufficiently >>>>>to deal with the most likely threat). It can also be used to >>>>bypass end >>>>>system call handling. >>>>> >>>>>- RPH can be added if needed, but seems likely to have modest to no >>>>>effect. Using it to bypass call handling by itself seems like a bad >>>>>idea, for the reason noted above. If the user's proxy keeps track of >>>>>outbound emergency calls, In-Reply-To works for that as well. >>>>> >>>>>- "Priority: emergency" can be used as well, as an indicator >>>>for call >>>>>handling, but obviously needs some validation. >>>>> >>>>>We need to decide whether we require proxies to keep state >>>>for recent >>>>>emergency calls; otherwise and in the absence of a PKI-like >>>>mechanism, >>>>>it seems difficult to prevent call impersonation at the user's proxy. >>>>> >>>>>There are other ways to solve this; in particular, Kumiko >>>>presented the >>>>>ARID proposal at the last DISPATCH meeting on how a callee could >>>>>validate caller properties. This requires more UA changes, but is >>>>>stateless in the UA and works across devices. >>>>> >>>>>Henning >>>>> >>>>>On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote: >>>>> >>>>>> >>>>>>If I recall correctly, the reasons given in the Taipei meeting >>>>>for indicating a PSAP call-back is any "different" from a >>>>normal call >>>>>to a normal GRUU or a normal AoR or URI target, were so that: >>>>>> (1) the network prioritize the call-back with >>>>>respect to allocating resources >>>>>> (2) the network bypass certain >>>>normal-call "treatments" >>>>>> (3) so that the reached UA could know to >>>>>immediately answer the call. >>>>>> >>>>>>For (1): if that's not the very definition of the RPH header's >>>>>purpose, I don't know what is. >>>>>> >>>>>>For (2): we have never had a singular defined header or field in >>>>>SIP which was intended for this purpose, afaik - basically >>>>there are >>>>>many headers/fields/methods which in combination are used >>>>by proxy-ish >>>>>devices to perform different "treatments". In 3GPP, for example, I >>>>>believe the filter-criteria can and do use almost any >>>>header field. >>>>>So really there's no field we can't use to accomplish this. >>>>>> >>>>>>For (3): using a new RPH namespace value for "psap-callback" >>>>>actually makes sense for this, since it's arguably asking the UA to >>>>>make available its resources immediately, without waiting for user >>>>>consent or to put another call on hold. >>>>>> >>>>>>Having said all that, I'm not super-tied to using the RPH header >>>>>either - I just think using a new special GRUU type is >>>>wrong, both at >>>>>an architectural level and a practical "it-needs-to-work" >>>>>level. Even if the RPH field is lost or modified or ignored, for >>>>>example, the call will likely succeed - that's a good >>>>property to have >>>>>I would think. >>>>>> >>>>>>-hadriel >>>>>> >>>>>> >>>>>>On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: >>>>>> >>>>>>>Can people indicate why they see a synergy with resource >>>>priority. >>>>>>> >>>>>>>This header field is primarily used for giving priority in the >>>>>network. To be used effectively, it needs to be processed >>>>first in any >>>>>message at all SIP entities, and the rest of the message handling >>>>>depends on it. >>>>>>> >>>>>>>While there may possibly be a use for Resource-Priority on >>>>>emergency callbacks, in order to give priority, I would >>>>suggest that >>>>>to give it a purpose beyond that where priority itself is >>>>not needed, >>>>>is not using that header for its prime purpose, and indeed detracts >>>>>from the main usage. >>>>>>> >>>>>>>Further, one thing that could well disappear at country >>>>>boundaries is the Resource-Priority header field, because different >>>>>regulatory regimes have different sets of rules as to what >>>>namespaces >>>>>may be used, and do not necessarily map one to another. >>>>>Any 3GPP roaming user will need to cross the same country twice (on >>>>>the signalling path) for the callback call, because the >>>>callback will >>>>>go via the home network. >>>>>>> >>>>>>>So while I have no axes to grind on losing a GRUU dependency, I >>>>>do think Resource-Priority is a poor fit. >>>>>>> >>>>>>>Keith >>>>>>> >>>>>>>From: ecrit-bounces@ietf.org >>>>>[mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg >>>>>>>Sent: 24 November 2011 10:51 >>>>>>>To: ECRIT >>>>>>>Cc: 'Adam Roach'; Paul Kyzivat >>>>>>>Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority >>>>>instead of eGRUU >>>>>>> >>>>>>> >>>>>>>Hi, >>>>>>> >>>>>>>In Taipei, it was indicated that people would prefer another >>>>>mechanism than a new GRUU type for solving the issue of identifying >>>>>PSAP callback calls. >>>>>>> >>>>>>>A new Resource-Priority header field value, that PSAPs would >>>>>insert in callback calls, was suggested. It would solve the >>>>>requirement of allowing network entities (and the UA) to >>>>identity the >>>>>callback call, e.g. in order to give special treatment. >>>>>>> >>>>>>>(The requirement to reach the same UA device that made the >>>>>emergency call can be solved with the existing GRUU mechanism, so >>>>>nothing new is needed there). >>>>>>> >>>>>>>So, I would like to know whether people are ok with a >>>>>Resource-Priority approach? >>>>>>> >>>>>>>Regards, >>>>>>> >>>>>>>Christer >>>>>>> >>>>>>> >>>>>>> >>>>>>>_______________________________________________ >>>>>>>Ecrit mailing list >>>>>>>Ecrit@ietf.org >>>>>>>https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>>_______________________________________________ >>>>>>Ecrit mailing list >>>>>>Ecrit@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>>_______________________________________________ >>>>>Ecrit mailing list >>>>>Ecrit@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>>>> >>>>>_______________________________________________ >>>>>Ecrit mailing list >>>>>Ecrit@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/ecrit >>>> >> From timothy.dwight@verizon.com Wed Nov 30 13:08:19 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1269F1F0C85 for ; Wed, 30 Nov 2011 13:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sjk8KyOr3QQy for ; Wed, 30 Nov 2011 13:08:18 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id 17F2E1F0C83 for ; Wed, 30 Nov 2011 13:08:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe02.verizon.com with ESMTP; 30 Nov 2011 21:08:17 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.71,273,1320624000"; d="scan'208";a="187155241" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi03.verizon.com with ESMTP; 30 Nov 2011 21:08:17 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.197]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Wed, 30 Nov 2011 16:08:17 -0500 To: Paul Kyzivat Date: Wed, 30 Nov 2011 16:08:15 -0500 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: Acyvodso9zC3gmA1RV2AchEJeETSawAACG8g Message-ID: <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> <4ED68CAB.5080602@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C255@FHDP1LUMXC7V31.us.one.verizon.com> <4ED69757.708@alum.mit.edu> In-Reply-To: <4ED69757.708@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:08:19 -0000 Paul, "call barring" is a standard GSM service. You can invoke it yourself with = a "star code" or "hash code". It's also possible to bar incoming calls onl= y when roaming. Similarly there are various flavors of call diversion (aka= call forwarding) that can be set similarly. This is what I meant. Servic= es the user invokes or to which he is subscribed, that have the effect of p= reventing delivery of a call. tim > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: Wednesday, November 30, 2011 2:52 PM > To: Dwight, Timothy M (Tim) > Subject: Re: [Ecrit] PSAP Callback indication:=20 > Resrouce-Priority instead of eGRUU >=20 > On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: > > Paul, > > > > I assume this "mumble mumble" refers to features in the=20 > service provider network that might otherwise prevent the=20 > callback from being delivered. The subscriber might have=20 > incoming calls barred for example. >=20 > Do you mean that the provider has barred calls because the=20 > bill has not=20 > been paid? I wouldn't consider this a "service" to the user of the=20 > phone, but its a reality to deal with. >=20 > I guess that is a significant issue in the case where=20 > outgoing emergency=20 > calls are allowed. >=20 > This needs to be mentioned on the list. > =09 > Thanks, > Paul >=20 >=20 >=20 > > tim > > > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >> On Behalf Of Paul Kyzivat > >> Sent: Wednesday, November 30, 2011 2:06 PM > >> To: Christer Holmberg > >> Cc: Adam Roach; ECRIT > >> Subject: Re: [Ecrit] PSAP Callback indication: > >> Resrouce-Priority instead of eGRUU > >> > >> On 12/1/11 3:57 AM, Christer Holmberg wrote: > >>> > >>> Hi, > >>> > >>>>>> ISTM that a callback to the Contact address of a prior > >> call should > >>>>>> typically bypass many treatments, regardless of who it is from. > >>>>>> > >>>>>> In particular, it ought to go to the specific device > >> identified by the > >>>>>> contact address, not to some other device, VM server, etc. > >>>>>> > >>>>>> Perhaps that isn't what happens with IMS right now, but > >> then maybe that > >>>>>> ought to be re-thought. > >>>>>> > >>>>>> If that was normal behavior, then what else would be=20 > required for > >>>>>> callbacks by a psap? > >>>>>> > >>>>>> There may need to be special treatment by the UA > >>>>>> itself, but that can be handled by using a unique temp > >> gruu for the > >>>>>> emergency call and remembering it in order to detect > >> emergency callbacks > >>>>>> in the UA. > >>>>>> > >>>>>> What am I missing? What sort of disruptive services do > >> you expect will > >>>>>> be applied to calls to a gruu? > >>>>> > >>>>> I don't think one can assume that any type of call, > >> non-PSAP-callbacks and PSAP-callbacks, will be given the same > >> special treatment by the network, just because they are > >> addressed using a Contact. > >>>>> > >>>>> And, it is not only about routing to another device, but > >> also other services that normally would be applied. > >>>> > >>>> Rather than talk generically about "services", can we get > >> tangible about > >>>> what sorts of things the network might do that would be > >> detrimental to a > >>>> psap callback? > >>>> > >>>> AFAIK about the only thing that the network can do > >> involves routing to > >>>> some device other than the one addressed by the r-uri. E.g. > >>>> - route to a VM server or message server that responds=20 > in some way. > >>>> - forward to some other configured address > >>>> > >>>> IMO neither of those are appropriate if the URI is a gruu > >> for a specific > >>>> device and that device is reachable. They would be > >> appropriate even for > >>>> a psap callback if the device is not reachable. > >>> > >>> Again, it's not only about routing to a specific device. > >>> > >>> Before the request even reaches the device, it might e.g. > >> be routed to different application servers in the network, > >> triggering different kind of non-routing related services. A > >> "normal" gruu addressed call could still be routed to such > >> application servers, while a PSAP callback wouldn't. > >> > >> Without some tangible examples, what you say is just so much > >> "mumble,mumble" to me. > >> > >> Either it is routed to some alternative device that > >> terminates the call > >> instead of the intended device, or else it is routed through > >> some device > >> that simply acts as an intermediary, still allowing the=20 > call to reach > >> the intended device, or else it fails the call. > >> > >> Anything that acts as an intermediary, still allowing the > >> call to reach > >> the intended destination, is probably benign. (Do you have a > >> counter-example?) > >> > >> Anything that routes to someplace other than the intended > >> device is of > >> dubious appropriateness when the r-uri is a GRUU. Again I'd be > >> interested to hear some examples. > >> > >> Thanks, > >> Paul > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >> >=20 > = From pkyzivat@alum.mit.edu Wed Nov 30 13:29:52 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F9411E80E1 for ; Wed, 30 Nov 2011 13:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukYsXKXIELoi for ; Wed, 30 Nov 2011 13:29:52 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id B456311E80E2 for ; Wed, 30 Nov 2011 13:29:51 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta08.westchester.pa.mail.comcast.net with comcast id 3Wv21i0041uE5Es58ZVsTa; Wed, 30 Nov 2011 21:29:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id 3ZVr1i02u07duvL3cZVsA7; Wed, 30 Nov 2011 21:29:52 +0000 Message-ID: <4ED6A04D.5000705@alum.mit.edu> Date: Thu, 01 Dec 2011 05:29:49 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Dwight, Timothy M (Tim)" References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> <4ED68CAB.5080602@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C255@FHDP1LUMXC7V31.us.one.verizon.com> <4ED69757.708@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:29:52 -0000 On 12/1/11 5:08 AM, Dwight, Timothy M (Tim) wrote: > Paul, > > "call barring" is a standard GSM service. You can invoke it yourself with a "star code" or "hash code". It's also possible to bar incoming calls only when roaming. Similarly there are various flavors of call diversion (aka call forwarding) that can be set similarly. This is what I meant. Services the user invokes or to which he is subscribed, that have the effect of preventing delivery of a call. OK. These examples are much more helpful. So it seems you are looking for another attribute that can be input to a policy engine that makes such decisions. So, on one hand its desired to indicate that the caller wants this call to receive special treatment, and then there is the issue of determining if the caller is entitled to ask for such treatment. ISTM that Priority:emergency should be sufficient as an indicator that the treatment is required. Its been stated that this is intended for use by the UAS. But the kinds of services we are discussing bypassing are in general provided on behalf of the UAS, so I think it still applies. The Resource-Priority header probably also has a role here in cases where there are resource constraints in the network. Deciding if the caller is permitted to request this then becomes the hard part. Thanks, Paul > tim > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Wednesday, November 30, 2011 2:52 PM >> To: Dwight, Timothy M (Tim) >> Subject: Re: [Ecrit] PSAP Callback indication: >> Resrouce-Priority instead of eGRUU >> >> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: >>> Paul, >>> >>> I assume this "mumble mumble" refers to features in the >> service provider network that might otherwise prevent the >> callback from being delivered. The subscriber might have >> incoming calls barred for example. >> >> Do you mean that the provider has barred calls because the >> bill has not >> been paid? I wouldn't consider this a "service" to the user of the >> phone, but its a reality to deal with. >> >> I guess that is a significant issue in the case where >> outgoing emergency >> calls are allowed. >> >> This needs to be mentioned on the list. >> >> Thanks, >> Paul >> >> >> >>> tim >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >>>> On Behalf Of Paul Kyzivat >>>> Sent: Wednesday, November 30, 2011 2:06 PM >>>> To: Christer Holmberg >>>> Cc: Adam Roach; ECRIT >>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>> Resrouce-Priority instead of eGRUU >>>> >>>> On 12/1/11 3:57 AM, Christer Holmberg wrote: >>>>> >>>>> Hi, >>>>> >>>>>>>> ISTM that a callback to the Contact address of a prior >>>> call should >>>>>>>> typically bypass many treatments, regardless of who it is from. >>>>>>>> >>>>>>>> In particular, it ought to go to the specific device >>>> identified by the >>>>>>>> contact address, not to some other device, VM server, etc. >>>>>>>> >>>>>>>> Perhaps that isn't what happens with IMS right now, but >>>> then maybe that >>>>>>>> ought to be re-thought. >>>>>>>> >>>>>>>> If that was normal behavior, then what else would be >> required for >>>>>>>> callbacks by a psap? >>>>>>>> >>>>>>>> There may need to be special treatment by the UA >>>>>>>> itself, but that can be handled by using a unique temp >>>> gruu for the >>>>>>>> emergency call and remembering it in order to detect >>>> emergency callbacks >>>>>>>> in the UA. >>>>>>>> >>>>>>>> What am I missing? What sort of disruptive services do >>>> you expect will >>>>>>>> be applied to calls to a gruu? >>>>>>> >>>>>>> I don't think one can assume that any type of call, >>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same >>>> special treatment by the network, just because they are >>>> addressed using a Contact. >>>>>>> >>>>>>> And, it is not only about routing to another device, but >>>> also other services that normally would be applied. >>>>>> >>>>>> Rather than talk generically about "services", can we get >>>> tangible about >>>>>> what sorts of things the network might do that would be >>>> detrimental to a >>>>>> psap callback? >>>>>> >>>>>> AFAIK about the only thing that the network can do >>>> involves routing to >>>>>> some device other than the one addressed by the r-uri. E.g. >>>>>> - route to a VM server or message server that responds >> in some way. >>>>>> - forward to some other configured address >>>>>> >>>>>> IMO neither of those are appropriate if the URI is a gruu >>>> for a specific >>>>>> device and that device is reachable. They would be >>>> appropriate even for >>>>>> a psap callback if the device is not reachable. >>>>> >>>>> Again, it's not only about routing to a specific device. >>>>> >>>>> Before the request even reaches the device, it might e.g. >>>> be routed to different application servers in the network, >>>> triggering different kind of non-routing related services. A >>>> "normal" gruu addressed call could still be routed to such >>>> application servers, while a PSAP callback wouldn't. >>>> >>>> Without some tangible examples, what you say is just so much >>>> "mumble,mumble" to me. >>>> >>>> Either it is routed to some alternative device that >>>> terminates the call >>>> instead of the intended device, or else it is routed through >>>> some device >>>> that simply acts as an intermediary, still allowing the >> call to reach >>>> the intended device, or else it fails the call. >>>> >>>> Anything that acts as an intermediary, still allowing the >>>> call to reach >>>> the intended destination, is probably benign. (Do you have a >>>> counter-example?) >>>> >>>> Anything that routes to someplace other than the intended >>>> device is of >>>> dubious appropriateness when the r-uri is a GRUU. Again I'd be >>>> interested to hear some examples. >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >> >> From pkyzivat@alum.mit.edu Wed Nov 30 13:33:12 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB64C11E80C0 for ; Wed, 30 Nov 2011 13:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MJ6GizGnFAc for ; Wed, 30 Nov 2011 13:33:11 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 019DA11E80BF for ; Wed, 30 Nov 2011 13:33:10 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta14.westchester.pa.mail.comcast.net with comcast id 3RMF1i0081YDfWL5EZZAk5; Wed, 30 Nov 2011 21:33:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id 3ZZA1i00y07duvL3gZZA0B; Wed, 30 Nov 2011 21:33:10 +0000 Message-ID: <4ED6A114.1060504@alum.mit.edu> Date: Thu, 01 Dec 2011 05:33:08 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "James M. Polk" References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se> <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se> <4ED68923.4060808@alum.mit.edu> <201111302100.pAUL0dBU010082@mtv-core-4.cisco.com> In-Reply-To: <201111302100.pAUL0dBU010082@mtv-core-4.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:33:12 -0000 On 12/1/11 5:00 AM, James M. Polk wrote: > At 01:50 PM 11/30/2011, Paul Kyzivat wrote: >> On 12/1/11 3:22 AM, Christer Holmberg wrote: >>> >>> Hi, >>> >>>> ISTM that a callback to the Contact address of a prior call should >>>> typically bypass many treatments, regardless of who it is from. >>>> >>>> In particular, it ought to go to the specific device identified by the >>>> contact address, not to some other device, VM server, etc. >>>> >>>> Perhaps that isn't what happens with IMS right now, but then maybe that >>>> ought to be re-thought. >>>> >>>> If that was normal behavior, then what else would be required for >>>> callbacks by a psap? >>>> >>>> There may need to be special treatment by the UA >>>> itself, but that can be handled by using a unique temp gruu for the >>>> emergency call and remembering it in order to detect emergency >>>> callbacks >>>> in the UA. >>>> >>>> What am I missing? What sort of disruptive services do you expect will >>>> be applied to calls to a gruu? >>> >>> I don't think one can assume that any type of call, >>> non-PSAP-callbacks and PSAP-callbacks, will be given the same special >>> treatment by the network, just because they are addressed using a >>> Contact. >>> >>> And, it is not only about routing to another device, but also other >>> services that normally would be applied. >> >> Rather than talk generically about "services", can we get tangible >> about what sorts of things the network might do that would be >> detrimental to a psap callback? >> >> AFAIK about the only thing that the network can do involves routing to >> some device other than the one addressed by the r-uri. E.g. >> - route to a VM server or message server that responds in some way. >> - forward to some other configured address >> >> IMO neither of those are appropriate if the URI is a gruu for a >> specific device and that device is reachable. They would be >> appropriate even for a psap callback if the device is not reachable. > > however ISTM that if any intermediary is in a congestion state, this > callback would suffer like all other INVITEs (especially if SOC > mechanisms are implemented), which - I don't believe - we or Christer > wants to have happen. In that case, RP is the defined SIP mechanism to > give special treatment to the request, but it can't be the only aspect > that's different about this INVITE. I agree. > I think you still need a GRUU (at > least). Maybe gruu helps here, maybe not. It seems that gruu isn't sufficient to bypass call barring policies. If something else is needed for that then gruu may be irrelevant. Thanks, Paul > James > > >> The other thing it could do is blacklist the call - returning an error >> response. That would be bad, and we should be considering how to avoid >> that. But perhaps it is the only thing to worry about. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> >>> On 11/30/11 6:22 PM, Christer Holmberg wrote: >>>> >>>> Hi James, >>>> >>>>> The fundamental requirement is to provide an indication to >>>>> SIP request receivers (i.e., each SIP server along the way >>>>> until you reach the ultimate destination UAS - which is the >>>>> original UAC that placed the emergency call) to give that SIP >>>>> request - which is an emergency callback 3 transaction - >>>>> extra attention if needed to make sure it goes through, right? >>>> >>>> Yes. >>>> >>>> (There is also a requirement to be able to reach the same UA that >>>> made the emergency call. But, gruu provides that, so we don't need >>>> to specify anything new.) >>>> >>>> >>>>> If this is the general problem, then IMO >>>>> >>>>> Priority: Emergency >>>>> >>>>> does not accomplish this goal, as the Priority header value >>>>> is for users of UAs, not for intermediaries to take into >>>>> account in any way. >>>> >>>> Please remember that lots of the actions taken by the intermediaries >>>> are on behalf of the user/UA. For example, an intermediarie would >>>> normally trigger a specific service for a specific user/UA, but it >>>> would not do so in the case of a PSAP Callback towards that user/UA. >>>> >>>> >>>> >>>>> Further, since there must be a new Call-ID value, there is no >>>>> way to tie this back to the initial emergency call. >>>> >>>> I think Henning's idea was to use the In-Reply-To header field, >>>> which would contain the Call-Id of the associated emergency call. >>>> >>>> But, as I said, it would not work with SBCs, and it would not work >>>> with intermediaries that weren't involved in the emergency call. >>>> >>>> >>>>> Additionally, the original UAC, may have called for emergency >>>>> twice, and gotten connected to two different PSAPs. A generic >>>>> "this is a 911 callback" indication is insufficient, as I >>>>> believe this needs to be tied somehow to which 911 call was >>>>> placed. Given that the 911 callback path could traverse a >>>>> different set of SIP servers back to the original caller, SIP >>>>> servers would have to blindly give preferential treatment to >>>>> any SIP request that contains this "this is a 911 callback" - >>>>> which is begging for misuse and other problems. >>>> >>>> There would need to be a way for networks, when receiving a "this is >>>> a 911 callback" request from a non-trusted network, to be able to >>>> verify that the call comes from a PSAP. >>>> >>>> But, again, at least in a 3GPP roaming scenario the home network >>>> might not have a clue about the associated emergency call. >>>> >>>> >>>>> What sounds like the best proposal to me, and I'm not sure >>>>> who mentioned it (Brian?), is for the original 911 caller to >>>>> insert a token that is received during the callback INVITE >>>>> (along with the sos URN somewhere in the INVITE). Maybe the >>>>> token is something encrypted with the public key that >>>>> identifies the PSAP from the 200 OK in the original >>>>> transaction. If that same identifier comes back in the >>>>> callback INVITE, the UAS knows who it is talking to. >>>> >>>> The original idea with the emergency gruu was that the home >>>> registrar provides such token to the UAS. The home registrar could >>>> then use that token to identify the PSAP Callback. >>>> >>>> One problem with that was that there might also be other entities >>>> that need to identify the PSAP Callback, and for that reason the >>>> draft suggests a "static" token value ("psapcb"). But, with a static >>>> value you of course have the fraud/misuse issue. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>>> That doesn't solve for what has to happen within the SIP servers >>>>> or in the network to ensure this SIP request gets >>>>> preferential treatment, but most here already believe this is >>>>> going to take a couple of pieces to get to where we want to go. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> James >>>>> >>>>> At 01:44 PM 11/29/2011, Christer Holmberg wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I agree that, whatever protocol element we use, the element >>>>> itself is >>>>>> not enough to prevent abuse. If the request comes from a non-trusted >>>>>> entity, there needs to be a way to verify it. >>>>>> >>>>>> However, different networks might have different ways of doing that, >>>>>> and I don't think we need to standardize a mechanism before moving >>>>>> forward with specifying the identifier itself. We do need, however, >>>>>> have strong wording about the fact that there must be A way >>>>> to verify >>>>>> that the call comes from a PSAP. >>>>>> >>>>>>> if (call claims to be an emergency-callback) >>>>>>> check if earlier call was indeed an emergency call >>>>>> >>>>>> That does not work for all network entities, as they might >>>>> not be aware >>>>>> of the previous emergency call. But, once the identifier has been >>>>>> verified, other entities within the trust domain can use that >>>>>> verification. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf Of >>>>>> Henning Schulzrinne [hgs@cs.columbia.edu] >>>>>> Sent: Tuesday, November 29, 2011 7:41 PM >>>>>> To: Janet P Gunn >>>>>> Cc: Paul Kyzivat; Adam Roach; ECRIT; ecrit-bounces@ietf.org >>>>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>>>> Resrouce-Priority instead of eGRUU >>>>>> >>>>>> Janet, >>>>>> >>>>>> I think we all agree that no label by itself (whether some special >>>>>> From value, a Priority header or RPH) is sufficient to >>>>> prevent abuse. >>>>>> It would only be useful in conjunction with another mechanism that >>>>>> allows caller-trusted parties, including the UA, to >>>>> determine that the >>>>>> call is indeed in response to an earlier emergency call, or, >>>>>> alternatively, that only such calls can reach a special >>>>> address, such >>>>>> as a GRUU. The logic would be something like >>>>>> >>>>>> if (call claims to be an emergency-callback) >>>>>> check if earlier call was indeed an emergency call >>>>>> >>>>>> Henning >>>>>> >>>>>> On Nov 29, 2011, at 12:16 PM, Janet P Gunn wrote: >>>>>> >>>>>> With regard to the use of a new RPH namespace to trigger special >>>>>> handling or treatment in the network , I guess it depends on >>>>> what you >>>>>> mean by "bypass call handling" >>>>>> "bypass ... treatments" >>>>>> >>>>>> Requirement 13 of RFC 5390 (Requirements for Management of >>>>> Overload in >>>>>> the Session Initiation Protocol) says >>>>>> >>>>>> REQ 13: The mechanism must not dictate a specific algorithm for >>>>>> prioritizing the processing of work within a proxy >>>>> during times of >>>>>> overload. It must permit a proxy to prioritize >>>>> requests based on >>>>>> any local policy, so that certain ones (such as a call for >>>>>> emergency services or a call with a specific value of the >>>>>> Resource-Priority header field [RFC4412]) are given >>>>> preferential >>>>>> treatment, such as not being dropped, being given additional >>>>>> retransmission, or being processed ahead of others. >>>>>> >>>>>> This explicitly names the RPH header as a way to identify calls >>>>>> needing "special treatment" in the face of SIP overload. Not a >>>>>> complete "bypass", but definitely a "special treatment". >>>>>> >>>>>> WRT "We do not want telemarketers to bypass call filters by >>>>> slapping on >>>>>> an RPH." This is true of any use of any RPH namespace. Use >>>>> of RPH must >>>>>> always be combined with appropriate >>>>>> security/authentication/authorization measures to ensure that >>>>>> unauthorized entities can not "slap on an RPH". >>>>>> >>>>>> I agree that, in principle, "Priority" rather than "Resource >>>>> Priority" >>>>>> is the appropriate way to inform the destination that special >>>>>> treatment at the destination is requested. However anyone >>>>> can "slap on >>>>>> a Priority header", as there is no associated >>>>>> security/authentication/authorization . >>>>>> >>>>>> Janet >>>>>> >>>>>> >>>>>> This is a PRIVATE message. If you are not the intended recipient, >>>>>> please delete without copying and kindly advise us by e-mail of the >>>>>> mistake in delivery. NOTE: Regardless of content, this >>>>> e-mail shall not >>>>>> operate to bind CSC to any order or other contract unless >>>>> pursuant to >>>>>> explicit written agreement or government initiative expressly >>>>>> permitting the use of e-mail for such purpose. >>>>>> >>>>>> >>>>>> >>>>>> From: Henning Schulzrinne >>>>>> > >>>>>> To: Hadriel Kaplan >>>>>> > >>>>>> Cc: Adam Roach>, >>>>>> ECRIT>, Paul Kyzivat >>>>>> > >>>>>> Date: 11/28/2011 03:19 PM >>>>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>>>> Resrouce-Priority instead of eGRUU >>>>>> Sent by: ecrit-bounces@ietf.org >>>>>> ________________________________ >>>>>> >>>>>> >>>>>> >>>>>> I see the issues as somewhat orthogonal. Thus, the use of GRUU or >>>>>> In-Reply-To could easily be combined with RPH. >>>>>> >>>>>> Indeed, we've always distinguished Priority (meant to indicate the >>>>>> desired priority at the receiving end system) and Resource-Priority >>>>>> (meant to influence scheduling at intermediate nodes, such >>>>> as gateways >>>>>> and proxies). >>>>>> >>>>>> I agree that the fail-safe mode is desirable, in addition to making >>>>>> spoofing such calls at least modestly difficult. We do not want >>>>>> telemarketers to bypass call filters by slapping on an RPH. >>>>>> >>>>>> I admit that I still don't see what's wrong with the >>>>> following combination: >>>>>> >>>>>> - In-Reply-To allows the UA to match the call to an earlier >>>>> emergency >>>>>> call and thus prevents impersonation (weakly, but probably >>>>> sufficiently >>>>>> to deal with the most likely threat). It can also be used to >>>>> bypass end >>>>>> system call handling. >>>>>> >>>>>> - RPH can be added if needed, but seems likely to have modest to no >>>>>> effect. Using it to bypass call handling by itself seems like a bad >>>>>> idea, for the reason noted above. If the user's proxy keeps track of >>>>>> outbound emergency calls, In-Reply-To works for that as well. >>>>>> >>>>>> - "Priority: emergency" can be used as well, as an indicator >>>>> for call >>>>>> handling, but obviously needs some validation. >>>>>> >>>>>> We need to decide whether we require proxies to keep state >>>>> for recent >>>>>> emergency calls; otherwise and in the absence of a PKI-like >>>>> mechanism, >>>>>> it seems difficult to prevent call impersonation at the user's proxy. >>>>>> >>>>>> There are other ways to solve this; in particular, Kumiko >>>>> presented the >>>>>> ARID proposal at the last DISPATCH meeting on how a callee could >>>>>> validate caller properties. This requires more UA changes, but is >>>>>> stateless in the UA and works across devices. >>>>>> >>>>>> Henning >>>>>> >>>>>> On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote: >>>>>> >>>>>>> >>>>>>> If I recall correctly, the reasons given in the Taipei meeting >>>>>> for indicating a PSAP call-back is any "different" from a >>>>> normal call >>>>>> to a normal GRUU or a normal AoR or URI target, were so that: >>>>>>> (1) the network prioritize the call-back with >>>>>> respect to allocating resources >>>>>>> (2) the network bypass certain >>>>> normal-call "treatments" >>>>>>> (3) so that the reached UA could know to >>>>>> immediately answer the call. >>>>>>> >>>>>>> For (1): if that's not the very definition of the RPH header's >>>>>> purpose, I don't know what is. >>>>>>> >>>>>>> For (2): we have never had a singular defined header or field in >>>>>> SIP which was intended for this purpose, afaik - basically >>>>> there are >>>>>> many headers/fields/methods which in combination are used >>>>> by proxy-ish >>>>>> devices to perform different "treatments". In 3GPP, for example, I >>>>>> believe the filter-criteria can and do use almost any >>>>> header field. >>>>>> So really there's no field we can't use to accomplish this. >>>>>>> >>>>>>> For (3): using a new RPH namespace value for "psap-callback" >>>>>> actually makes sense for this, since it's arguably asking the UA to >>>>>> make available its resources immediately, without waiting for user >>>>>> consent or to put another call on hold. >>>>>>> >>>>>>> Having said all that, I'm not super-tied to using the RPH header >>>>>> either - I just think using a new special GRUU type is >>>>> wrong, both at >>>>>> an architectural level and a practical "it-needs-to-work" >>>>>> level. Even if the RPH field is lost or modified or ignored, for >>>>>> example, the call will likely succeed - that's a good >>>>> property to have >>>>>> I would think. >>>>>>> >>>>>>> -hadriel >>>>>>> >>>>>>> >>>>>>> On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: >>>>>>> >>>>>>>> Can people indicate why they see a synergy with resource >>>>> priority. >>>>>>>> >>>>>>>> This header field is primarily used for giving priority in the >>>>>> network. To be used effectively, it needs to be processed >>>>> first in any >>>>>> message at all SIP entities, and the rest of the message handling >>>>>> depends on it. >>>>>>>> >>>>>>>> While there may possibly be a use for Resource-Priority on >>>>>> emergency callbacks, in order to give priority, I would >>>>> suggest that >>>>>> to give it a purpose beyond that where priority itself is >>>>> not needed, >>>>>> is not using that header for its prime purpose, and indeed detracts >>>>>> from the main usage. >>>>>>>> >>>>>>>> Further, one thing that could well disappear at country >>>>>> boundaries is the Resource-Priority header field, because different >>>>>> regulatory regimes have different sets of rules as to what >>>>> namespaces >>>>>> may be used, and do not necessarily map one to another. >>>>>> Any 3GPP roaming user will need to cross the same country twice (on >>>>>> the signalling path) for the callback call, because the >>>>> callback will >>>>>> go via the home network. >>>>>>>> >>>>>>>> So while I have no axes to grind on losing a GRUU dependency, I >>>>>> do think Resource-Priority is a poor fit. >>>>>>>> >>>>>>>> Keith >>>>>>>> >>>>>>>> From: ecrit-bounces@ietf.org >>>>>> [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg >>>>>>>> Sent: 24 November 2011 10:51 >>>>>>>> To: ECRIT >>>>>>>> Cc: 'Adam Roach'; Paul Kyzivat >>>>>>>> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority >>>>>> instead of eGRUU >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> In Taipei, it was indicated that people would prefer another >>>>>> mechanism than a new GRUU type for solving the issue of identifying >>>>>> PSAP callback calls. >>>>>>>> >>>>>>>> A new Resource-Priority header field value, that PSAPs would >>>>>> insert in callback calls, was suggested. It would solve the >>>>>> requirement of allowing network entities (and the UA) to >>>>> identity the >>>>>> callback call, e.g. in order to give special treatment. >>>>>>>> >>>>>>>> (The requirement to reach the same UA device that made the >>>>>> emergency call can be solved with the existing GRUU mechanism, so >>>>>> nothing new is needed there). >>>>>>>> >>>>>>>> So, I would like to know whether people are ok with a >>>>>> Resource-Priority approach? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Christer >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>> > > From christer.holmberg@ericsson.com Wed Nov 30 13:40:27 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1517F1F0C84 for ; Wed, 30 Nov 2011 13:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZW4JRo+Zp6cW for ; Wed, 30 Nov 2011 13:40:26 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9B24A1F0C78 for ; Wed, 30 Nov 2011 13:40:25 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-86-4ed6a2c80f23 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AA.3A.09514.8C2A6DE4; Wed, 30 Nov 2011 22:40:24 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 30 Nov 2011 22:40:24 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , "Dwight, Timothy M (Tim)" Date: Wed, 30 Nov 2011 22:40:23 +0100 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: Acyvp0CS1nxLO339S76iuwY9Hph1BwAADecg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFA@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> <4ED68CAB.5080602@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C255@FHDP1LUMXC7V31.us.one.verizon.com> <4ED69757.708@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> <4ED6A04D.5000705@alum.mit.edu> In-Reply-To: <4ED6A04D.5000705@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:40:27 -0000 Hi,=20 >> "call barring" is a standard GSM service. You can invoke it yourself wi= th a "star code" or "hash code".=20 >> It's also possible to bar incoming calls only when roaming. Similarly t= here are various flavors of call=20 >> diversion (aka call forwarding) that can be set similarly. This is what= I meant. Services the user=20 >> invokes or to which he is subscribed, that have the effect of preventing= delivery of a call. > > OK. These examples are much more helpful. Yes, this is a good example of where the service logic would be different. But, in general, the idea is to not forward requests to application servers= at all (even if the call would eventually still reach the correct device),= e.g. due to the the risk of congestion etc (as indicated by James). >> So it seems you are looking for another attribute that can be input to a= policy engine that makes such decisions. > > So, on one hand its desired to indicate that the caller wants this call t= o receive special treatment, and then there is the issue of determining if = the caller is entitled to ask for such treatment. Correct. > ISTM that Priority:emergency should be sufficient as an indicator that th= e treatment is required. Its been stated that this is intended for use by t= he UAS. But the kinds of services we are discussing=20 > bypassing are in general provided on behalf of the UAS, so I think it sti= ll applies. Agree (I earlier indicated the same). > The Resource-Priority header probably also has a role here in cases where= there are resource constraints in the network. > > Deciding if the caller is permitted to request this then becomes the hard= part. Yes. There needs to be a way for the network, when it receives a request cl= aiming to be a PSAP Callback, to determine that the call comes from a PSAP.= There might be different ways of doing that, depending on networks, enviro= nments, operator agreements etc. Regards, Christer >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Wednesday, November 30, 2011 2:52 PM >> To: Dwight, Timothy M (Tim) >> Subject: Re: [Ecrit] PSAP Callback indication: >> Resrouce-Priority instead of eGRUU >> >> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: >>> Paul, >>> >>> I assume this "mumble mumble" refers to features in the >> service provider network that might otherwise prevent the callback=20 >> from being delivered. The subscriber might have incoming calls=20 >> barred for example. >> >> Do you mean that the provider has barred calls because the bill has=20 >> not been paid? I wouldn't consider this a "service" to the user of=20 >> the phone, but its a reality to deal with. >> >> I guess that is a significant issue in the case where outgoing=20 >> emergency calls are allowed. >> >> This needs to be mentioned on the list. >> =09 >> Thanks, >> Paul >> >> >> >>> tim >>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >>>> Behalf Of Paul Kyzivat >>>> Sent: Wednesday, November 30, 2011 2:06 PM >>>> To: Christer Holmberg >>>> Cc: Adam Roach; ECRIT >>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>> Resrouce-Priority instead of eGRUU >>>> >>>> On 12/1/11 3:57 AM, Christer Holmberg wrote: >>>>> >>>>> Hi, >>>>> >>>>>>>> ISTM that a callback to the Contact address of a prior >>>> call should >>>>>>>> typically bypass many treatments, regardless of who it is from. >>>>>>>> >>>>>>>> In particular, it ought to go to the specific device >>>> identified by the >>>>>>>> contact address, not to some other device, VM server, etc. >>>>>>>> >>>>>>>> Perhaps that isn't what happens with IMS right now, but >>>> then maybe that >>>>>>>> ought to be re-thought. >>>>>>>> >>>>>>>> If that was normal behavior, then what else would be >> required for >>>>>>>> callbacks by a psap? >>>>>>>> >>>>>>>> There may need to be special treatment by the UA itself, but=20 >>>>>>>> that can be handled by using a unique temp >>>> gruu for the >>>>>>>> emergency call and remembering it in order to detect >>>> emergency callbacks >>>>>>>> in the UA. >>>>>>>> >>>>>>>> What am I missing? What sort of disruptive services do >>>> you expect will >>>>>>>> be applied to calls to a gruu? >>>>>>> >>>>>>> I don't think one can assume that any type of call, >>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same=20 >>>> special treatment by the network, just because they are addressed=20 >>>> using a Contact. >>>>>>> >>>>>>> And, it is not only about routing to another device, but >>>> also other services that normally would be applied. >>>>>> >>>>>> Rather than talk generically about "services", can we get >>>> tangible about >>>>>> what sorts of things the network might do that would be >>>> detrimental to a >>>>>> psap callback? >>>>>> >>>>>> AFAIK about the only thing that the network can do >>>> involves routing to >>>>>> some device other than the one addressed by the r-uri. E.g. >>>>>> - route to a VM server or message server that responds >> in some way. >>>>>> - forward to some other configured address >>>>>> >>>>>> IMO neither of those are appropriate if the URI is a gruu >>>> for a specific >>>>>> device and that device is reachable. They would be >>>> appropriate even for >>>>>> a psap callback if the device is not reachable. >>>>> >>>>> Again, it's not only about routing to a specific device. >>>>> >>>>> Before the request even reaches the device, it might e.g. >>>> be routed to different application servers in the network,=20 >>>> triggering different kind of non-routing related services. A=20 >>>> "normal" gruu addressed call could still be routed to such=20 >>>> application servers, while a PSAP callback wouldn't. >>>> >>>> Without some tangible examples, what you say is just so much=20 >>>> "mumble,mumble" to me. >>>> >>>> Either it is routed to some alternative device that terminates the=20 >>>> call instead of the intended device, or else it is routed through=20 >>>> some device that simply acts as an intermediary, still allowing the >> call to reach >>>> the intended device, or else it fails the call. >>>> >>>> Anything that acts as an intermediary, still allowing the call to=20 >>>> reach the intended destination, is probably benign. (Do you have a >>>> counter-example?) >>>> >>>> Anything that routes to someplace other than the intended device is=20 >>>> of dubious appropriateness when the r-uri is a GRUU. Again I'd be=20 >>>> interested to hear some examples. >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >> >> _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Wed Nov 30 13:43:34 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF7321F8B29 for ; Wed, 30 Nov 2011 13:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AodvnE2E2KLE for ; Wed, 30 Nov 2011 13:43:32 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1781C21F8B24 for ; Wed, 30 Nov 2011 13:43:31 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-12-4ed6a3828ec6 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8A.9A.09514.283A6DE4; Wed, 30 Nov 2011 22:43:31 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 30 Nov 2011 22:43:30 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , "James M. Polk" Date: Wed, 30 Nov 2011 22:43:30 +0100 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: Acyvp6jaJt5iiEpmT7ayRdOoe488igAAQ82w Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFB@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se> <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se> <4ED68923.4060808@alum.mit.edu> <201111302100.pAUL0dBU010082@mtv-core-4.cisco.com> <4ED6A114.1060504@alum.mit.edu> In-Reply-To: <4ED6A114.1060504@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:43:34 -0000 Hi, >> I think you still need a GRUU (at least). > > Maybe gruu helps here, maybe not. It seems that gruu isn't sufficient to = bypass call barring policies. If something else is needed for that then gru= u may be irrelevant. The proposal was that the emergency gruu would contain a "psapcb" token, wh= ich would have been used as an indicator for bypassing policies etc. (But, yes, the verification of the sender still applies also to the egruu) Regards, Christer > James > > >> The other thing it could do is blacklist the call - returning an >> error response. That would be bad, and we should be considering how >> to avoid that. But perhaps it is the only thing to worry about. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> >>> On 11/30/11 6:22 PM, Christer Holmberg wrote: >>>> >>>> Hi James, >>>> >>>>> The fundamental requirement is to provide an indication to SIP >>>>> request receivers (i.e., each SIP server along the way until you >>>>> reach the ultimate destination UAS - which is the original UAC >>>>> that placed the emergency call) to give that SIP request - which >>>>> is an emergency callback 3 transaction - extra attention if needed >>>>> to make sure it goes through, right? >>>> >>>> Yes. >>>> >>>> (There is also a requirement to be able to reach the same UA that >>>> made the emergency call. But, gruu provides that, so we don't need >>>> to specify anything new.) >>>> >>>> >>>>> If this is the general problem, then IMO >>>>> >>>>> Priority: Emergency >>>>> >>>>> does not accomplish this goal, as the Priority header value is for >>>>> users of UAs, not for intermediaries to take into account in any >>>>> way. >>>> >>>> Please remember that lots of the actions taken by the >>>> intermediaries are on behalf of the user/UA. For example, an >>>> intermediarie would normally trigger a specific service for a >>>> specific user/UA, but it would not do so in the case of a PSAP Callbac= k towards that user/UA. >>>> >>>> >>>> >>>>> Further, since there must be a new Call-ID value, there is no way >>>>> to tie this back to the initial emergency call. >>>> >>>> I think Henning's idea was to use the In-Reply-To header field, >>>> which would contain the Call-Id of the associated emergency call. >>>> >>>> But, as I said, it would not work with SBCs, and it would not work >>>> with intermediaries that weren't involved in the emergency call. >>>> >>>> >>>>> Additionally, the original UAC, may have called for emergency >>>>> twice, and gotten connected to two different PSAPs. A generic >>>>> "this is a 911 callback" indication is insufficient, as I believe >>>>> this needs to be tied somehow to which 911 call was placed. Given >>>>> that the 911 callback path could traverse a different set of SIP >>>>> servers back to the original caller, SIP servers would have to >>>>> blindly give preferential treatment to any SIP request that >>>>> contains this "this is a 911 callback" - which is begging for >>>>> misuse and other problems. >>>> >>>> There would need to be a way for networks, when receiving a "this >>>> is a 911 callback" request from a non-trusted network, to be able >>>> to verify that the call comes from a PSAP. >>>> >>>> But, again, at least in a 3GPP roaming scenario the home network >>>> might not have a clue about the associated emergency call. >>>> >>>> >>>>> What sounds like the best proposal to me, and I'm not sure who >>>>> mentioned it (Brian?), is for the original 911 caller to insert a >>>>> token that is received during the callback INVITE (along with the >>>>> sos URN somewhere in the INVITE). Maybe the token is something >>>>> encrypted with the public key that identifies the PSAP from the >>>>> 200 OK in the original transaction. If that same identifier comes >>>>> back in the callback INVITE, the UAS knows who it is talking to. >>>> >>>> The original idea with the emergency gruu was that the home >>>> registrar provides such token to the UAS. The home registrar could >>>> then use that token to identify the PSAP Callback. >>>> >>>> One problem with that was that there might also be other entities >>>> that need to identify the PSAP Callback, and for that reason the >>>> draft suggests a "static" token value ("psapcb"). But, with a >>>> static value you of course have the fraud/misuse issue. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>>> That doesn't solve for what has to happen within the SIP servers >>>>> or in the network to ensure this SIP request gets preferential >>>>> treatment, but most here already believe this is going to take a >>>>> couple of pieces to get to where we want to go. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> James >>>>> >>>>> At 01:44 PM 11/29/2011, Christer Holmberg wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I agree that, whatever protocol element we use, the element >>>>> itself is >>>>>> not enough to prevent abuse. If the request comes from a >>>>>> non-trusted entity, there needs to be a way to verify it. >>>>>> >>>>>> However, different networks might have different ways of doing >>>>>> that, and I don't think we need to standardize a mechanism before >>>>>> moving forward with specifying the identifier itself. We do need, >>>>>> however, have strong wording about the fact that there must be A >>>>>> way >>>>> to verify >>>>>> that the call comes from a PSAP. >>>>>> >>>>>>> if (call claims to be an emergency-callback) check if earlier >>>>>>> call was indeed an emergency call >>>>>> >>>>>> That does not work for all network entities, as they might >>>>> not be aware >>>>>> of the previous emergency call. But, once the identifier has been >>>>>> verified, other entities within the trust domain can use that >>>>>> verification. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> ________________________________________ >>>>>> From: ecrit-bounces@ietf.org [ecrit-bounces@ietf.org] On Behalf >>>>>> Of Henning Schulzrinne [hgs@cs.columbia.edu] >>>>>> Sent: Tuesday, November 29, 2011 7:41 PM >>>>>> To: Janet P Gunn >>>>>> Cc: Paul Kyzivat; Adam Roach; ECRIT; ecrit-bounces@ietf.org >>>>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>>>> Resrouce-Priority instead of eGRUU >>>>>> >>>>>> Janet, >>>>>> >>>>>> I think we all agree that no label by itself (whether some >>>>>> special From value, a Priority header or RPH) is sufficient to >>>>> prevent abuse. >>>>>> It would only be useful in conjunction with another mechanism >>>>>> that allows caller-trusted parties, including the UA, to >>>>> determine that the >>>>>> call is indeed in response to an earlier emergency call, or, >>>>>> alternatively, that only such calls can reach a special >>>>> address, such >>>>>> as a GRUU. The logic would be something like >>>>>> >>>>>> if (call claims to be an emergency-callback) check if earlier >>>>>> call was indeed an emergency call >>>>>> >>>>>> Henning >>>>>> >>>>>> On Nov 29, 2011, at 12:16 PM, Janet P Gunn wrote: >>>>>> >>>>>> With regard to the use of a new RPH namespace to trigger special >>>>>> handling or treatment in the network , I guess it depends on >>>>> what you >>>>>> mean by "bypass call handling" >>>>>> "bypass ... treatments" >>>>>> >>>>>> Requirement 13 of RFC 5390 (Requirements for Management of >>>>> Overload in >>>>>> the Session Initiation Protocol) says >>>>>> >>>>>> REQ 13: The mechanism must not dictate a specific algorithm for >>>>>> prioritizing the processing of work within a proxy >>>>> during times of >>>>>> overload. It must permit a proxy to prioritize >>>>> requests based on >>>>>> any local policy, so that certain ones (such as a call for >>>>>> emergency services or a call with a specific value of the >>>>>> Resource-Priority header field [RFC4412]) are given >>>>> preferential >>>>>> treatment, such as not being dropped, being given additional >>>>>> retransmission, or being processed ahead of others. >>>>>> >>>>>> This explicitly names the RPH header as a way to identify calls >>>>>> needing "special treatment" in the face of SIP overload. Not a >>>>>> complete "bypass", but definitely a "special treatment". >>>>>> >>>>>> WRT "We do not want telemarketers to bypass call filters by >>>>> slapping on >>>>>> an RPH." This is true of any use of any RPH namespace. Use >>>>> of RPH must >>>>>> always be combined with appropriate >>>>>> security/authentication/authorization measures to ensure that >>>>>> unauthorized entities can not "slap on an RPH". >>>>>> >>>>>> I agree that, in principle, "Priority" rather than "Resource >>>>> Priority" >>>>>> is the appropriate way to inform the destination that special >>>>>> treatment at the destination is requested. However anyone >>>>> can "slap on >>>>>> a Priority header", as there is no associated >>>>>> security/authentication/authorization . >>>>>> >>>>>> Janet >>>>>> >>>>>> >>>>>> This is a PRIVATE message. If you are not the intended recipient, >>>>>> please delete without copying and kindly advise us by e-mail of >>>>>> the mistake in delivery. NOTE: Regardless of content, this >>>>> e-mail shall not >>>>>> operate to bind CSC to any order or other contract unless >>>>> pursuant to >>>>>> explicit written agreement or government initiative expressly >>>>>> permitting the use of e-mail for such purpose. >>>>>> >>>>>> >>>>>> >>>>>> From: Henning Schulzrinne >>>>>> > >>>>>> To: Hadriel Kaplan >>>>>> > >>>>>> Cc: Adam Roach>, >>>>>> ECRIT>, Paul Kyzivat >>>>>> > >>>>>> Date: 11/28/2011 03:19 PM >>>>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>>>> Resrouce-Priority instead of eGRUU Sent by: >>>>>> ecrit-bounces@ietf.org >>>>>> ________________________________ >>>>>> >>>>>> >>>>>> >>>>>> I see the issues as somewhat orthogonal. Thus, the use of GRUU or >>>>>> In-Reply-To could easily be combined with RPH. >>>>>> >>>>>> Indeed, we've always distinguished Priority (meant to indicate >>>>>> the desired priority at the receiving end system) and >>>>>> Resource-Priority (meant to influence scheduling at intermediate >>>>>> nodes, such >>>>> as gateways >>>>>> and proxies). >>>>>> >>>>>> I agree that the fail-safe mode is desirable, in addition to >>>>>> making spoofing such calls at least modestly difficult. We do not >>>>>> want telemarketers to bypass call filters by slapping on an RPH. >>>>>> >>>>>> I admit that I still don't see what's wrong with the >>>>> following combination: >>>>>> >>>>>> - In-Reply-To allows the UA to match the call to an earlier >>>>> emergency >>>>>> call and thus prevents impersonation (weakly, but probably >>>>> sufficiently >>>>>> to deal with the most likely threat). It can also be used to >>>>> bypass end >>>>>> system call handling. >>>>>> >>>>>> - RPH can be added if needed, but seems likely to have modest to >>>>>> no effect. Using it to bypass call handling by itself seems like >>>>>> a bad idea, for the reason noted above. If the user's proxy keeps >>>>>> track of outbound emergency calls, In-Reply-To works for that as wel= l. >>>>>> >>>>>> - "Priority: emergency" can be used as well, as an indicator >>>>> for call >>>>>> handling, but obviously needs some validation. >>>>>> >>>>>> We need to decide whether we require proxies to keep state >>>>> for recent >>>>>> emergency calls; otherwise and in the absence of a PKI-like >>>>> mechanism, >>>>>> it seems difficult to prevent call impersonation at the user's proxy= . >>>>>> >>>>>> There are other ways to solve this; in particular, Kumiko >>>>> presented the >>>>>> ARID proposal at the last DISPATCH meeting on how a callee could >>>>>> validate caller properties. This requires more UA changes, but is >>>>>> stateless in the UA and works across devices. >>>>>> >>>>>> Henning >>>>>> >>>>>> On Nov 28, 2011, at 2:58 PM, Hadriel Kaplan wrote: >>>>>> >>>>>>> >>>>>>> If I recall correctly, the reasons given in the Taipei meeting >>>>>> for indicating a PSAP call-back is any "different" from a >>>>> normal call >>>>>> to a normal GRUU or a normal AoR or URI target, were so that: >>>>>>> (1) the network prioritize the call-back with >>>>>> respect to allocating resources >>>>>>> (2) the network bypass certain >>>>> normal-call "treatments" >>>>>>> (3) so that the reached UA could know to >>>>>> immediately answer the call. >>>>>>> >>>>>>> For (1): if that's not the very definition of the RPH header's >>>>>> purpose, I don't know what is. >>>>>>> >>>>>>> For (2): we have never had a singular defined header or field in >>>>>> SIP which was intended for this purpose, afaik - basically >>>>> there are >>>>>> many headers/fields/methods which in combination are used >>>>> by proxy-ish >>>>>> devices to perform different "treatments". In 3GPP, for example, >>>>>> I believe the filter-criteria can and do use almost any >>>>> header field. >>>>>> So really there's no field we can't use to accomplish this. >>>>>>> >>>>>>> For (3): using a new RPH namespace value for "psap-callback" >>>>>> actually makes sense for this, since it's arguably asking the UA >>>>>> to make available its resources immediately, without waiting for >>>>>> user consent or to put another call on hold. >>>>>>> >>>>>>> Having said all that, I'm not super-tied to using the RPH header >>>>>> either - I just think using a new special GRUU type is >>>>> wrong, both at >>>>>> an architectural level and a practical "it-needs-to-work" >>>>>> level. Even if the RPH field is lost or modified or ignored, for >>>>>> example, the call will likely succeed - that's a good >>>>> property to have >>>>>> I would think. >>>>>>> >>>>>>> -hadriel >>>>>>> >>>>>>> >>>>>>> On Nov 28, 2011, at 1:05 PM, DRAGE, Keith (Keith) wrote: >>>>>>> >>>>>>>> Can people indicate why they see a synergy with resource >>>>> priority. >>>>>>>> >>>>>>>> This header field is primarily used for giving priority in the >>>>>> network. To be used effectively, it needs to be processed >>>>> first in any >>>>>> message at all SIP entities, and the rest of the message handling >>>>>> depends on it. >>>>>>>> >>>>>>>> While there may possibly be a use for Resource-Priority on >>>>>> emergency callbacks, in order to give priority, I would >>>>> suggest that >>>>>> to give it a purpose beyond that where priority itself is >>>>> not needed, >>>>>> is not using that header for its prime purpose, and indeed >>>>>> detracts from the main usage. >>>>>>>> >>>>>>>> Further, one thing that could well disappear at country >>>>>> boundaries is the Resource-Priority header field, because >>>>>> different regulatory regimes have different sets of rules as to >>>>>> what >>>>> namespaces >>>>>> may be used, and do not necessarily map one to another. >>>>>> Any 3GPP roaming user will need to cross the same country twice >>>>>> (on the signalling path) for the callback call, because the >>>>> callback will >>>>>> go via the home network. >>>>>>>> >>>>>>>> So while I have no axes to grind on losing a GRUU dependency, I >>>>>> do think Resource-Priority is a poor fit. >>>>>>>> >>>>>>>> Keith >>>>>>>> >>>>>>>> From: ecrit-bounces@ietf.org >>>>>> [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg >>>>>>>> Sent: 24 November 2011 10:51 >>>>>>>> To: ECRIT >>>>>>>> Cc: 'Adam Roach'; Paul Kyzivat >>>>>>>> Subject: [Ecrit] PSAP Callback indication: Resrouce-Priority >>>>>> instead of eGRUU >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> In Taipei, it was indicated that people would prefer another >>>>>> mechanism than a new GRUU type for solving the issue of >>>>>> identifying PSAP callback calls. >>>>>>>> >>>>>>>> A new Resource-Priority header field value, that PSAPs would >>>>>> insert in callback calls, was suggested. It would solve the >>>>>> requirement of allowing network entities (and the UA) to >>>>> identity the >>>>>> callback call, e.g. in order to give special treatment. >>>>>>>> >>>>>>>> (The requirement to reach the same UA device that made the >>>>>> emergency call can be solved with the existing GRUU mechanism, so >>>>>> nothing new is needed there). >>>>>>>> >>>>>>>> So, I would like to know whether people are ok with a >>>>>> Resource-Priority approach? >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Christer >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ecrit mailing list >>>>>>>> Ecrit@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ecrit mailing list >>>>>> Ecrit@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>> >>> > > From timothy.dwight@verizon.com Wed Nov 30 13:55:34 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3CB11E80CC for ; Wed, 30 Nov 2011 13:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-vQTvM06mIj for ; Wed, 30 Nov 2011 13:55:34 -0800 (PST) Received: from fldsmtpe03.verizon.com (fldsmtpe03.verizon.com [140.108.26.142]) by ietfa.amsl.com (Postfix) with ESMTP id B026D11E8081 for ; Wed, 30 Nov 2011 13:55:33 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe03.verizon.com with ESMTP; 30 Nov 2011 21:55:30 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.71,273,1320624000"; d="scan'208";a="187141371" Received: from fhdp1lumxc7hb05.verizon.com (HELO FHDP1LUMXC7HB05.us.one.verizon.com) ([166.68.59.192]) by fldsmtpi01.verizon.com with ESMTP; 30 Nov 2011 21:55:14 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.197]) by FHDP1LUMXC7HB05.us.one.verizon.com ([166.68.59.192]) with mapi; Wed, 30 Nov 2011 16:55:14 -0500 To: Paul Kyzivat Date: Wed, 30 Nov 2011 16:55:12 -0500 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AcyvpzJJO6MPQkjtTJmk5aENDzlDoAAAQxpg Message-ID: <2B0F677F0B95454297753F58D4A07FA3B397C373@FHDP1LUMXC7V31.us.one.verizon.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> <4ED68CAB.5080602@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C255@FHDP1LUMXC7V31.us.one.verizon.com> <4ED69757.708@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> <4ED6A04D.5000705@alum.mit.edu> In-Reply-To: <4ED6A04D.5000705@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:55:34 -0000 Paul, Does there need also to be some "time limit"? ISTM that after some [relati= vely short] period of time, a call from a PSAP is no longer a "call back" a= nd needn't be prioritized. =20 tim > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 > Sent: Wednesday, November 30, 2011 3:30 PM > To: Dwight, Timothy M (Tim) > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback indication:=20 > Resrouce-Priority instead of eGRUU >=20 > On 12/1/11 5:08 AM, Dwight, Timothy M (Tim) wrote: > > Paul, > > > > "call barring" is a standard GSM service. You can invoke=20 > it yourself with a "star code" or "hash code". It's also=20 > possible to bar incoming calls only when roaming. Similarly=20 > there are various flavors of call diversion (aka call=20 > forwarding) that can be set similarly. This is what I meant.=20 > Services the user invokes or to which he is subscribed, that=20 > have the effect of preventing delivery of a call. >=20 > OK. These examples are much more helpful. > So it seems you are looking for another attribute that can be=20 > input to a=20 > policy engine that makes such decisions. >=20 > So, on one hand its desired to indicate that the caller wants=20 > this call=20 > to receive special treatment, and then there is the issue of=20 > determining=20 > if the caller is entitled to ask for such treatment. >=20 > ISTM that Priority:emergency should be sufficient as an=20 > indicator that=20 > the treatment is required. Its been stated that this is=20 > intended for use=20 > by the UAS. But the kinds of services we are discussing=20 > bypassing are in=20 > general provided on behalf of the UAS, so I think it still applies. >=20 > The Resource-Priority header probably also has a role here in cases=20 > where there are resource constraints in the network. >=20 > Deciding if the caller is permitted to request this then becomes the=20 > hard part. >=20 > Thanks, > Paul >=20 > > tim > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Wednesday, November 30, 2011 2:52 PM > >> To: Dwight, Timothy M (Tim) > >> Subject: Re: [Ecrit] PSAP Callback indication: > >> Resrouce-Priority instead of eGRUU > >> > >> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: > >>> Paul, > >>> > >>> I assume this "mumble mumble" refers to features in the > >> service provider network that might otherwise prevent the > >> callback from being delivered. The subscriber might have > >> incoming calls barred for example. > >> > >> Do you mean that the provider has barred calls because the > >> bill has not > >> been paid? I wouldn't consider this a "service" to the user of the > >> phone, but its a reality to deal with. > >> > >> I guess that is a significant issue in the case where > >> outgoing emergency > >> calls are allowed. > >> > >> This needs to be mentioned on the list. > >> =09 > >> Thanks, > >> Paul > >> > >> > >> > >>> tim > >>> > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] > >>>> On Behalf Of Paul Kyzivat > >>>> Sent: Wednesday, November 30, 2011 2:06 PM > >>>> To: Christer Holmberg > >>>> Cc: Adam Roach; ECRIT > >>>> Subject: Re: [Ecrit] PSAP Callback indication: > >>>> Resrouce-Priority instead of eGRUU > >>>> > >>>> On 12/1/11 3:57 AM, Christer Holmberg wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>>>>> ISTM that a callback to the Contact address of a prior > >>>> call should > >>>>>>>> typically bypass many treatments, regardless of who=20 > it is from. > >>>>>>>> > >>>>>>>> In particular, it ought to go to the specific device > >>>> identified by the > >>>>>>>> contact address, not to some other device, VM server, etc. > >>>>>>>> > >>>>>>>> Perhaps that isn't what happens with IMS right now, but > >>>> then maybe that > >>>>>>>> ought to be re-thought. > >>>>>>>> > >>>>>>>> If that was normal behavior, then what else would be > >> required for > >>>>>>>> callbacks by a psap? > >>>>>>>> > >>>>>>>> There may need to be special treatment by the UA > >>>>>>>> itself, but that can be handled by using a unique temp > >>>> gruu for the > >>>>>>>> emergency call and remembering it in order to detect > >>>> emergency callbacks > >>>>>>>> in the UA. > >>>>>>>> > >>>>>>>> What am I missing? What sort of disruptive services do > >>>> you expect will > >>>>>>>> be applied to calls to a gruu? > >>>>>>> > >>>>>>> I don't think one can assume that any type of call, > >>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same > >>>> special treatment by the network, just because they are > >>>> addressed using a Contact. > >>>>>>> > >>>>>>> And, it is not only about routing to another device, but > >>>> also other services that normally would be applied. > >>>>>> > >>>>>> Rather than talk generically about "services", can we get > >>>> tangible about > >>>>>> what sorts of things the network might do that would be > >>>> detrimental to a > >>>>>> psap callback? > >>>>>> > >>>>>> AFAIK about the only thing that the network can do > >>>> involves routing to > >>>>>> some device other than the one addressed by the r-uri. E.g. > >>>>>> - route to a VM server or message server that responds > >> in some way. > >>>>>> - forward to some other configured address > >>>>>> > >>>>>> IMO neither of those are appropriate if the URI is a gruu > >>>> for a specific > >>>>>> device and that device is reachable. They would be > >>>> appropriate even for > >>>>>> a psap callback if the device is not reachable. > >>>>> > >>>>> Again, it's not only about routing to a specific device. > >>>>> > >>>>> Before the request even reaches the device, it might e.g. > >>>> be routed to different application servers in the network, > >>>> triggering different kind of non-routing related services. A > >>>> "normal" gruu addressed call could still be routed to such > >>>> application servers, while a PSAP callback wouldn't. > >>>> > >>>> Without some tangible examples, what you say is just so much > >>>> "mumble,mumble" to me. > >>>> > >>>> Either it is routed to some alternative device that > >>>> terminates the call > >>>> instead of the intended device, or else it is routed through > >>>> some device > >>>> that simply acts as an intermediary, still allowing the > >> call to reach > >>>> the intended device, or else it fails the call. > >>>> > >>>> Anything that acts as an intermediary, still allowing the > >>>> call to reach > >>>> the intended destination, is probably benign. (Do you have a > >>>> counter-example?) > >>>> > >>>> Anything that routes to someplace other than the intended > >>>> device is of > >>>> dubious appropriateness when the r-uri is a GRUU. Again I'd be > >>>> interested to hear some examples. > >>>> > >>>> Thanks, > >>>> Paul > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >> > >> >=20 > = From timothy.dwight@verizon.com Wed Nov 30 14:04:47 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB9461F0C5A for ; Wed, 30 Nov 2011 14:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSt5SGu1g4zb for ; Wed, 30 Nov 2011 14:04:46 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id A370A1F0C35 for ; Wed, 30 Nov 2011 14:04:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 30 Nov 2011 22:04:35 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.71,273,1320624000"; d="scan'208";a="187034079" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi02.verizon.com with ESMTP; 30 Nov 2011 22:04:35 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.197]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Wed, 30 Nov 2011 17:04:35 -0500 To: Christer Holmberg , 'Paul Kyzivat' Date: Wed, 30 Nov 2011 17:04:34 -0500 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: Acyvp0CS1nxLO339S76iuwY9Hph1BwAADecgAADs2oA= Message-ID: <2B0F677F0B95454297753F58D4A07FA3B397C38E@FHDP1LUMXC7V31.us.one.verizon.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> <4ED68CAB.5080602@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C255@FHDP1LUMXC7V31.us.one.verizon.com> <4ED69757.708@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> <4ED6A04D.5000705@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFA@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFA@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:04:47 -0000 Christer, It seems a little dangerous to say that a PSAP callback would bypass all ap= plication servers. Sometimes network routing functions are implemented in = devices that architecturally (because of how they attach to the network) ar= e considered application servers. Consider the 3GPP VCC-AS for example... Would inclusion of RPH sufficiently address potential server congestion? tim > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Wednesday, November 30, 2011 3:40 PM > To: 'Paul Kyzivat'; Dwight, Timothy M (Tim) > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] PSAP Callback indication:=20 > Resrouce-Priority instead of eGRUU >=20 >=20 > Hi,=20 >=20 > >> "call barring" is a standard GSM service. You can invoke=20 > it yourself with a "star code" or "hash code".=20 > >> It's also possible to bar incoming calls only when=20 > roaming. Similarly there are various flavors of call=20 > >> diversion (aka call forwarding) that can be set similarly.=20 > This is what I meant. Services the user=20 > >> invokes or to which he is subscribed, that have the effect=20 > of preventing delivery of a call. > > > > OK. These examples are much more helpful. >=20 > Yes, this is a good example of where the service logic would=20 > be different. >=20 > But, in general, the idea is to not forward requests to=20 > application servers at all (even if the call would eventually=20 > still reach the correct device), e.g. due to the the risk of=20 > congestion etc (as indicated by James). >=20 > >> So it seems you are looking for another attribute that can=20 > be input to a policy engine that makes such decisions. > > > > So, on one hand its desired to indicate that the caller=20 > wants this call to receive special treatment, and then there=20 > is the issue of determining if the caller is entitled to ask=20 > for such treatment. >=20 > Correct. >=20 > > ISTM that Priority:emergency should be sufficient as an=20 > indicator that the treatment is required. Its been stated=20 > that this is intended for use by the UAS. But the kinds of=20 > services we are discussing=20 > > bypassing are in general provided on behalf of the UAS, so=20 > I think it still applies. >=20 > Agree (I earlier indicated the same). >=20 > > The Resource-Priority header probably also has a role here=20 > in cases where there are resource constraints in the network. > > > > Deciding if the caller is permitted to request this then=20 > becomes the hard part. >=20 > Yes. There needs to be a way for the network, when it=20 > receives a request claiming to be a PSAP Callback, to=20 > determine that the call comes from a PSAP. There might be=20 > different ways of doing that, depending on networks,=20 > environments, operator agreements etc. >=20 > Regards, >=20 > Christer >=20 >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Wednesday, November 30, 2011 2:52 PM > >> To: Dwight, Timothy M (Tim) > >> Subject: Re: [Ecrit] PSAP Callback indication: > >> Resrouce-Priority instead of eGRUU > >> > >> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: > >>> Paul, > >>> > >>> I assume this "mumble mumble" refers to features in the > >> service provider network that might otherwise prevent the callback=20 > >> from being delivered. The subscriber might have incoming calls=20 > >> barred for example. > >> > >> Do you mean that the provider has barred calls because the=20 > bill has=20 > >> not been paid? I wouldn't consider this a "service" to the user of=20 > >> the phone, but its a reality to deal with. > >> > >> I guess that is a significant issue in the case where outgoing=20 > >> emergency calls are allowed. > >> > >> This needs to be mentioned on the list. > >> =09 > >> Thanks, > >> Paul > >> > >> > >> > >>> tim > >>> > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Wednesday, November 30, 2011 2:06 PM > >>>> To: Christer Holmberg > >>>> Cc: Adam Roach; ECRIT > >>>> Subject: Re: [Ecrit] PSAP Callback indication: > >>>> Resrouce-Priority instead of eGRUU > >>>> > >>>> On 12/1/11 3:57 AM, Christer Holmberg wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>>>>> ISTM that a callback to the Contact address of a prior > >>>> call should > >>>>>>>> typically bypass many treatments, regardless of who=20 > it is from. > >>>>>>>> > >>>>>>>> In particular, it ought to go to the specific device > >>>> identified by the > >>>>>>>> contact address, not to some other device, VM server, etc. > >>>>>>>> > >>>>>>>> Perhaps that isn't what happens with IMS right now, but > >>>> then maybe that > >>>>>>>> ought to be re-thought. > >>>>>>>> > >>>>>>>> If that was normal behavior, then what else would be > >> required for > >>>>>>>> callbacks by a psap? > >>>>>>>> > >>>>>>>> There may need to be special treatment by the UA itself, but=20 > >>>>>>>> that can be handled by using a unique temp > >>>> gruu for the > >>>>>>>> emergency call and remembering it in order to detect > >>>> emergency callbacks > >>>>>>>> in the UA. > >>>>>>>> > >>>>>>>> What am I missing? What sort of disruptive services do > >>>> you expect will > >>>>>>>> be applied to calls to a gruu? > >>>>>>> > >>>>>>> I don't think one can assume that any type of call, > >>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same=20 > >>>> special treatment by the network, just because they are=20 > addressed=20 > >>>> using a Contact. > >>>>>>> > >>>>>>> And, it is not only about routing to another device, but > >>>> also other services that normally would be applied. > >>>>>> > >>>>>> Rather than talk generically about "services", can we get > >>>> tangible about > >>>>>> what sorts of things the network might do that would be > >>>> detrimental to a > >>>>>> psap callback? > >>>>>> > >>>>>> AFAIK about the only thing that the network can do > >>>> involves routing to > >>>>>> some device other than the one addressed by the r-uri. E.g. > >>>>>> - route to a VM server or message server that responds > >> in some way. > >>>>>> - forward to some other configured address > >>>>>> > >>>>>> IMO neither of those are appropriate if the URI is a gruu > >>>> for a specific > >>>>>> device and that device is reachable. They would be > >>>> appropriate even for > >>>>>> a psap callback if the device is not reachable. > >>>>> > >>>>> Again, it's not only about routing to a specific device. > >>>>> > >>>>> Before the request even reaches the device, it might e.g. > >>>> be routed to different application servers in the network,=20 > >>>> triggering different kind of non-routing related services. A=20 > >>>> "normal" gruu addressed call could still be routed to such=20 > >>>> application servers, while a PSAP callback wouldn't. > >>>> > >>>> Without some tangible examples, what you say is just so much=20 > >>>> "mumble,mumble" to me. > >>>> > >>>> Either it is routed to some alternative device that=20 > terminates the=20 > >>>> call instead of the intended device, or else it is=20 > routed through=20 > >>>> some device that simply acts as an intermediary, still=20 > allowing the > >> call to reach > >>>> the intended device, or else it fails the call. > >>>> > >>>> Anything that acts as an intermediary, still allowing=20 > the call to=20 > >>>> reach the intended destination, is probably benign. (Do=20 > you have a > >>>> counter-example?) > >>>> > >>>> Anything that routes to someplace other than the=20 > intended device is=20 > >>>> of dubious appropriateness when the r-uri is a GRUU.=20 > Again I'd be=20 > >>>> interested to hear some examples. > >>>> > >>>> Thanks, > >>>> Paul > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >> > >> >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From christer.holmberg@ericsson.com Wed Nov 30 14:04:53 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484E51F0C62 for ; Wed, 30 Nov 2011 14:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.437 X-Spam-Level: X-Spam-Status: No, score=-6.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCZ5VbQcp3U7 for ; Wed, 30 Nov 2011 14:04:52 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id F066E1F0C61 for ; Wed, 30 Nov 2011 14:04:51 -0800 (PST) X-AuditID: c1b4fb3d-b7b5fae00000219a-27-4ed6a882a496 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2C.76.08602.288A6DE4; Wed, 30 Nov 2011 23:04:50 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 30 Nov 2011 23:04:50 +0100 From: Christer Holmberg To: "'Dwight, Timothy M (Tim)'" , Paul Kyzivat Date: Wed, 30 Nov 2011 23:04:50 +0100 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AcyvpzJJO6MPQkjtTJmk5aENDzlDoAAAQxpgAADIp4A= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFC@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> <4ED68CAB.5080602@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C255@FHDP1LUMXC7V31.us.one.verizon.com> <4ED69757.708@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> <4ED6A04D.5000705@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C373@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3B397C373@FHDP1LUMXC7V31.us.one.verizon.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:04:53 -0000 Hi, I'm not Paul, but I will reply anyway :) I will double check, but I don think that there is any time limit (at least= not a "relatively short" one) for a call to be considered and treated as a= callback. The network entities that makes the prioritization may not even = know when the associtaed emergency call was made (so, if there were some ti= me limit I think the callback would need to contain timing information). Regards, Christer -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of D= wight, Timothy M (Tim) Sent: 30. marraskuuta 2011 23:55 To: Paul Kyzivat Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of= eGRUU Paul, Does there need also to be some "time limit"? ISTM that after some [relati= vely short] period of time, a call from a PSAP is no longer a "call back" a= nd needn't be prioritized. =20 tim > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Wednesday, November 30, 2011 3:30 PM > To: Dwight, Timothy M (Tim) > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback indication:=20 > Resrouce-Priority instead of eGRUU >=20 > On 12/1/11 5:08 AM, Dwight, Timothy M (Tim) wrote: > > Paul, > > > > "call barring" is a standard GSM service. You can invoke > it yourself with a "star code" or "hash code". It's also possible to=20 > bar incoming calls only when roaming. Similarly there are various=20 > flavors of call diversion (aka call > forwarding) that can be set similarly. This is what I meant.=20 > Services the user invokes or to which he is subscribed, that have the=20 > effect of preventing delivery of a call. >=20 > OK. These examples are much more helpful. > So it seems you are looking for another attribute that can be input to=20 > a policy engine that makes such decisions. >=20 > So, on one hand its desired to indicate that the caller wants this=20 > call to receive special treatment, and then there is the issue of=20 > determining if the caller is entitled to ask for such treatment. >=20 > ISTM that Priority:emergency should be sufficient as an indicator that=20 > the treatment is required. Its been stated that this is intended for=20 > use by the UAS. But the kinds of services we are discussing bypassing=20 > are in general provided on behalf of the UAS, so I think it still=20 > applies. >=20 > The Resource-Priority header probably also has a role here in cases=20 > where there are resource constraints in the network. >=20 > Deciding if the caller is permitted to request this then becomes the=20 > hard part. >=20 > Thanks, > Paul >=20 > > tim > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Wednesday, November 30, 2011 2:52 PM > >> To: Dwight, Timothy M (Tim) > >> Subject: Re: [Ecrit] PSAP Callback indication: > >> Resrouce-Priority instead of eGRUU > >> > >> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: > >>> Paul, > >>> > >>> I assume this "mumble mumble" refers to features in the > >> service provider network that might otherwise prevent the callback=20 > >> from being delivered. The subscriber might have incoming calls=20 > >> barred for example. > >> > >> Do you mean that the provider has barred calls because the bill has=20 > >> not been paid? I wouldn't consider this a "service" to the user of=20 > >> the phone, but its a reality to deal with. > >> > >> I guess that is a significant issue in the case where outgoing=20 > >> emergency calls are allowed. > >> > >> This needs to be mentioned on the list. > >> =09 > >> Thanks, > >> Paul > >> > >> > >> > >>> tim > >>> > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Wednesday, November 30, 2011 2:06 PM > >>>> To: Christer Holmberg > >>>> Cc: Adam Roach; ECRIT > >>>> Subject: Re: [Ecrit] PSAP Callback indication: > >>>> Resrouce-Priority instead of eGRUU > >>>> > >>>> On 12/1/11 3:57 AM, Christer Holmberg wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>>>>> ISTM that a callback to the Contact address of a prior > >>>> call should > >>>>>>>> typically bypass many treatments, regardless of who > it is from. > >>>>>>>> > >>>>>>>> In particular, it ought to go to the specific device > >>>> identified by the > >>>>>>>> contact address, not to some other device, VM server, etc. > >>>>>>>> > >>>>>>>> Perhaps that isn't what happens with IMS right now, but > >>>> then maybe that > >>>>>>>> ought to be re-thought. > >>>>>>>> > >>>>>>>> If that was normal behavior, then what else would be > >> required for > >>>>>>>> callbacks by a psap? > >>>>>>>> > >>>>>>>> There may need to be special treatment by the UA itself, but=20 > >>>>>>>> that can be handled by using a unique temp > >>>> gruu for the > >>>>>>>> emergency call and remembering it in order to detect > >>>> emergency callbacks > >>>>>>>> in the UA. > >>>>>>>> > >>>>>>>> What am I missing? What sort of disruptive services do > >>>> you expect will > >>>>>>>> be applied to calls to a gruu? > >>>>>>> > >>>>>>> I don't think one can assume that any type of call, > >>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same=20 > >>>> special treatment by the network, just because they are addressed=20 > >>>> using a Contact. > >>>>>>> > >>>>>>> And, it is not only about routing to another device, but > >>>> also other services that normally would be applied. > >>>>>> > >>>>>> Rather than talk generically about "services", can we get > >>>> tangible about > >>>>>> what sorts of things the network might do that would be > >>>> detrimental to a > >>>>>> psap callback? > >>>>>> > >>>>>> AFAIK about the only thing that the network can do > >>>> involves routing to > >>>>>> some device other than the one addressed by the r-uri. E.g. > >>>>>> - route to a VM server or message server that responds > >> in some way. > >>>>>> - forward to some other configured address > >>>>>> > >>>>>> IMO neither of those are appropriate if the URI is a gruu > >>>> for a specific > >>>>>> device and that device is reachable. They would be > >>>> appropriate even for > >>>>>> a psap callback if the device is not reachable. > >>>>> > >>>>> Again, it's not only about routing to a specific device. > >>>>> > >>>>> Before the request even reaches the device, it might e.g. > >>>> be routed to different application servers in the network,=20 > >>>> triggering different kind of non-routing related services. A=20 > >>>> "normal" gruu addressed call could still be routed to such=20 > >>>> application servers, while a PSAP callback wouldn't. > >>>> > >>>> Without some tangible examples, what you say is just so much=20 > >>>> "mumble,mumble" to me. > >>>> > >>>> Either it is routed to some alternative device that terminates=20 > >>>> the call instead of the intended device, or else it is routed=20 > >>>> through some device that simply acts as an intermediary, still=20 > >>>> allowing the > >> call to reach > >>>> the intended device, or else it fails the call. > >>>> > >>>> Anything that acts as an intermediary, still allowing the call to=20 > >>>> reach the intended destination, is probably benign. (Do you have=20 > >>>> a > >>>> counter-example?) > >>>> > >>>> Anything that routes to someplace other than the intended device=20 > >>>> is of dubious appropriateness when the r-uri is a GRUU. Again I'd=20 > >>>> be interested to hear some examples. > >>>> > >>>> Thanks, > >>>> Paul > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >> > >> >=20 >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From christer.holmberg@ericsson.com Wed Nov 30 14:09:14 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D903121F853E for ; Wed, 30 Nov 2011 14:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhWK9HmBxej6 for ; Wed, 30 Nov 2011 14:09:13 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7B91921F8770 for ; Wed, 30 Nov 2011 14:09:09 -0800 (PST) X-AuditID: c1b4fb3d-b7b5fae00000219a-03-4ed6a9841760 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EB.B6.08602.489A6DE4; Wed, 30 Nov 2011 23:09:08 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 30 Nov 2011 23:09:08 +0100 From: Christer Holmberg To: "'Dwight, Timothy M (Tim)'" , 'Paul Kyzivat' Date: Wed, 30 Nov 2011 23:09:07 +0100 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: Acyvp0CS1nxLO339S76iuwY9Hph1BwAADecgAADs2oAAADyo4A== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFD@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> <4ED68CAB.5080602@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C255@FHDP1LUMXC7V31.us.one.verizon.com> <4ED69757.708@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> <4ED6A04D.5000705@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFA@ESESSCMS0356.eemea.ericsson.se> <2B0F677F0B95454297753F58D4A07FA3B397C38E@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3B397C38E@FHDP1LUMXC7V31.us.one.verizon.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:09:14 -0000 Hi,=20 > It seems a little dangerous to say that a PSAP callback would bypass all = application servers. Sometimes network routing functions are implemented i= n devices that architecturally (because of how they=20 > attach to the network) are considered application servers. Consider the = 3GPP VCC-AS for example... I didn't mean to say that callbacks by defualt would always bypass all appl= ication servers - the operator will have to configure that. The point is th= at the operator shall be able to configure bypassing (and/or other policies= ) for callbacks.=20 > Would inclusion of RPH sufficiently address potential server congestion? I see no reason why not. Personally I think RPH, with a callback namespace,= could also work for the bypassing, but there seems to be some issues about= whether that is correct usage of RPH. Regards, Christer > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, November 30, 2011 3:40 PM > To: 'Paul Kyzivat'; Dwight, Timothy M (Tim) > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] PSAP Callback indication:=20 > Resrouce-Priority instead of eGRUU >=20 >=20 > Hi, >=20 > >> "call barring" is a standard GSM service. You can invoke > it yourself with a "star code" or "hash code".=20 > >> It's also possible to bar incoming calls only when > roaming. Similarly there are various flavors of call > >> diversion (aka call forwarding) that can be set similarly.=20 > This is what I meant. Services the user > >> invokes or to which he is subscribed, that have the effect > of preventing delivery of a call. > > > > OK. These examples are much more helpful. >=20 > Yes, this is a good example of where the service logic would be=20 > different. >=20 > But, in general, the idea is to not forward requests to application=20 > servers at all (even if the call would eventually still reach the=20 > correct device), e.g. due to the the risk of congestion etc (as=20 > indicated by James). >=20 > >> So it seems you are looking for another attribute that can > be input to a policy engine that makes such decisions. > > > > So, on one hand its desired to indicate that the caller > wants this call to receive special treatment, and then there is the=20 > issue of determining if the caller is entitled to ask for such=20 > treatment. >=20 > Correct. >=20 > > ISTM that Priority:emergency should be sufficient as an > indicator that the treatment is required. Its been stated that this is=20 > intended for use by the UAS. But the kinds of services we are=20 > discussing > > bypassing are in general provided on behalf of the UAS, so > I think it still applies. >=20 > Agree (I earlier indicated the same). >=20 > > The Resource-Priority header probably also has a role here > in cases where there are resource constraints in the network. > > > > Deciding if the caller is permitted to request this then > becomes the hard part. >=20 > Yes. There needs to be a way for the network, when it receives a=20 > request claiming to be a PSAP Callback, to determine that the call=20 > comes from a PSAP. There might be different ways of doing that,=20 > depending on networks, environments, operator agreements etc. >=20 > Regards, >=20 > Christer >=20 >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Wednesday, November 30, 2011 2:52 PM > >> To: Dwight, Timothy M (Tim) > >> Subject: Re: [Ecrit] PSAP Callback indication: > >> Resrouce-Priority instead of eGRUU > >> > >> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: > >>> Paul, > >>> > >>> I assume this "mumble mumble" refers to features in the > >> service provider network that might otherwise prevent the callback=20 > >> from being delivered. The subscriber might have incoming calls=20 > >> barred for example. > >> > >> Do you mean that the provider has barred calls because the > bill has > >> not been paid? I wouldn't consider this a "service" to the user of=20 > >> the phone, but its a reality to deal with. > >> > >> I guess that is a significant issue in the case where outgoing=20 > >> emergency calls are allowed. > >> > >> This needs to be mentioned on the list. > >> =09 > >> Thanks, > >> Paul > >> > >> > >> > >>> tim > >>> > >>>> -----Original Message----- > >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 > >>>> Behalf Of Paul Kyzivat > >>>> Sent: Wednesday, November 30, 2011 2:06 PM > >>>> To: Christer Holmberg > >>>> Cc: Adam Roach; ECRIT > >>>> Subject: Re: [Ecrit] PSAP Callback indication: > >>>> Resrouce-Priority instead of eGRUU > >>>> > >>>> On 12/1/11 3:57 AM, Christer Holmberg wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>>>>> ISTM that a callback to the Contact address of a prior > >>>> call should > >>>>>>>> typically bypass many treatments, regardless of who > it is from. > >>>>>>>> > >>>>>>>> In particular, it ought to go to the specific device > >>>> identified by the > >>>>>>>> contact address, not to some other device, VM server, etc. > >>>>>>>> > >>>>>>>> Perhaps that isn't what happens with IMS right now, but > >>>> then maybe that > >>>>>>>> ought to be re-thought. > >>>>>>>> > >>>>>>>> If that was normal behavior, then what else would be > >> required for > >>>>>>>> callbacks by a psap? > >>>>>>>> > >>>>>>>> There may need to be special treatment by the UA itself, but=20 > >>>>>>>> that can be handled by using a unique temp > >>>> gruu for the > >>>>>>>> emergency call and remembering it in order to detect > >>>> emergency callbacks > >>>>>>>> in the UA. > >>>>>>>> > >>>>>>>> What am I missing? What sort of disruptive services do > >>>> you expect will > >>>>>>>> be applied to calls to a gruu? > >>>>>>> > >>>>>>> I don't think one can assume that any type of call, > >>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same=20 > >>>> special treatment by the network, just because they are > addressed > >>>> using a Contact. > >>>>>>> > >>>>>>> And, it is not only about routing to another device, but > >>>> also other services that normally would be applied. > >>>>>> > >>>>>> Rather than talk generically about "services", can we get > >>>> tangible about > >>>>>> what sorts of things the network might do that would be > >>>> detrimental to a > >>>>>> psap callback? > >>>>>> > >>>>>> AFAIK about the only thing that the network can do > >>>> involves routing to > >>>>>> some device other than the one addressed by the r-uri. E.g. > >>>>>> - route to a VM server or message server that responds > >> in some way. > >>>>>> - forward to some other configured address > >>>>>> > >>>>>> IMO neither of those are appropriate if the URI is a gruu > >>>> for a specific > >>>>>> device and that device is reachable. They would be > >>>> appropriate even for > >>>>>> a psap callback if the device is not reachable. > >>>>> > >>>>> Again, it's not only about routing to a specific device. > >>>>> > >>>>> Before the request even reaches the device, it might e.g. > >>>> be routed to different application servers in the network,=20 > >>>> triggering different kind of non-routing related services. A=20 > >>>> "normal" gruu addressed call could still be routed to such=20 > >>>> application servers, while a PSAP callback wouldn't. > >>>> > >>>> Without some tangible examples, what you say is just so much=20 > >>>> "mumble,mumble" to me. > >>>> > >>>> Either it is routed to some alternative device that > terminates the > >>>> call instead of the intended device, or else it is > routed through > >>>> some device that simply acts as an intermediary, still > allowing the > >> call to reach > >>>> the intended device, or else it fails the call. > >>>> > >>>> Anything that acts as an intermediary, still allowing > the call to > >>>> reach the intended destination, is probably benign. (Do > you have a > >>>> counter-example?) > >>>> > >>>> Anything that routes to someplace other than the > intended device is > >>>> of dubious appropriateness when the r-uri is a GRUU.=20 > Again I'd be > >>>> interested to hear some examples. > >>>> > >>>> Thanks, > >>>> Paul > >>>> _______________________________________________ > >>>> Ecrit mailing list > >>>> Ecrit@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>> > >> > >> >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From timothy.dwight@verizon.com Wed Nov 30 14:12:15 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0135F21F8B50 for ; Wed, 30 Nov 2011 14:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPQjgbGe9+fd for ; Wed, 30 Nov 2011 14:12:14 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id CF3B421F8B4F for ; Wed, 30 Nov 2011 14:12:13 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 30 Nov 2011 22:12:11 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.71,273,1320624000"; d="scan'208";a="187037452" Received: from fhdp1lumxc7hb02.verizon.com (HELO FHDP1LUMXC7HB02.us.one.verizon.com) ([166.68.59.189]) by fldsmtpi02.verizon.com with ESMTP; 30 Nov 2011 22:12:11 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.197]) by FHDP1LUMXC7HB02.us.one.verizon.com ([166.68.59.189]) with mapi; Wed, 30 Nov 2011 17:12:11 -0500 To: Christer Holmberg , Paul Kyzivat Date: Wed, 30 Nov 2011 17:12:09 -0500 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AcyvpzJJO6MPQkjtTJmk5aENDzlDoAAAQxpgAADIp4AAAD4v4A== Message-ID: <2B0F677F0B95454297753F58D4A07FA3B397C3AB@FHDP1LUMXC7V31.us.one.verizon.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> <4ED68CAB.5080602@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C255@FHDP1LUMXC7V31.us.one.verizon.com> <4ED69757.708@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> <4ED6A04D.5000705@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C373@FHDP1LUMXC7V31.us.one.verizon.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFC@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFC@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:12:15 -0000 Thanks Christer. Maybe it's not easy to implement, but I'm uncomfortable that a device, once= used to place a 911 call, is permanently marked as accessible to an unlimi= ted number of calls from entities that pass the "I am a PSAP" test. tim > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > Sent: Wednesday, November 30, 2011 4:05 PM > To: Dwight, Timothy M (Tim); Paul Kyzivat > Cc: ecrit@ietf.org > Subject: RE: [Ecrit] PSAP Callback indication:=20 > Resrouce-Priority instead of eGRUU >=20 >=20 > Hi, >=20 > I'm not Paul, but I will reply anyway :) >=20 > I will double check, but I don think that there is any time=20 > limit (at least not a "relatively short" one) for a call to=20 > be considered and treated as a callback. The network entities=20 > that makes the prioritization may not even know when the=20 > associtaed emergency call was made (so, if there were some=20 > time limit I think the callback would need to contain timing=20 > information). >=20 > Regards, >=20 > Christer >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > On Behalf Of Dwight, Timothy M (Tim) > Sent: 30. marraskuuta 2011 23:55 > To: Paul Kyzivat > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback indication:=20 > Resrouce-Priority instead of eGRUU >=20 > Paul, >=20 > Does there need also to be some "time limit"? ISTM that=20 > after some [relatively short] period of time, a call from a=20 > PSAP is no longer a "call back" and needn't be prioritized. =20 >=20 > tim >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > Sent: Wednesday, November 30, 2011 3:30 PM > > To: Dwight, Timothy M (Tim) > > Cc: ecrit@ietf.org > > Subject: Re: [Ecrit] PSAP Callback indication:=20 > > Resrouce-Priority instead of eGRUU > >=20 > > On 12/1/11 5:08 AM, Dwight, Timothy M (Tim) wrote: > > > Paul, > > > > > > "call barring" is a standard GSM service. You can invoke > > it yourself with a "star code" or "hash code". It's also=20 > possible to=20 > > bar incoming calls only when roaming. Similarly there are various=20 > > flavors of call diversion (aka call > > forwarding) that can be set similarly. This is what I meant.=20 > > Services the user invokes or to which he is subscribed,=20 > that have the=20 > > effect of preventing delivery of a call. > >=20 > > OK. These examples are much more helpful. > > So it seems you are looking for another attribute that can=20 > be input to=20 > > a policy engine that makes such decisions. > >=20 > > So, on one hand its desired to indicate that the caller wants this=20 > > call to receive special treatment, and then there is the issue of=20 > > determining if the caller is entitled to ask for such treatment. > >=20 > > ISTM that Priority:emergency should be sufficient as an=20 > indicator that=20 > > the treatment is required. Its been stated that this is=20 > intended for=20 > > use by the UAS. But the kinds of services we are discussing=20 > bypassing=20 > > are in general provided on behalf of the UAS, so I think it still=20 > > applies. > >=20 > > The Resource-Priority header probably also has a role here in cases=20 > > where there are resource constraints in the network. > >=20 > > Deciding if the caller is permitted to request this then=20 > becomes the=20 > > hard part. > >=20 > > Thanks, > > Paul > >=20 > > > tim > > > > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > > >> Sent: Wednesday, November 30, 2011 2:52 PM > > >> To: Dwight, Timothy M (Tim) > > >> Subject: Re: [Ecrit] PSAP Callback indication: > > >> Resrouce-Priority instead of eGRUU > > >> > > >> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: > > >>> Paul, > > >>> > > >>> I assume this "mumble mumble" refers to features in the > > >> service provider network that might otherwise prevent=20 > the callback=20 > > >> from being delivered. The subscriber might have incoming calls=20 > > >> barred for example. > > >> > > >> Do you mean that the provider has barred calls because=20 > the bill has=20 > > >> not been paid? I wouldn't consider this a "service" to=20 > the user of=20 > > >> the phone, but its a reality to deal with. > > >> > > >> I guess that is a significant issue in the case where outgoing=20 > > >> emergency calls are allowed. > > >> > > >> This needs to be mentioned on the list. > > >> =09 > > >> Thanks, > > >> Paul > > >> > > >> > > >> > > >>> tim > > >>> > > >>>> -----Original Message----- > > >>>> From: ecrit-bounces@ietf.org=20 > [mailto:ecrit-bounces@ietf.org] On=20 > > >>>> Behalf Of Paul Kyzivat > > >>>> Sent: Wednesday, November 30, 2011 2:06 PM > > >>>> To: Christer Holmberg > > >>>> Cc: Adam Roach; ECRIT > > >>>> Subject: Re: [Ecrit] PSAP Callback indication: > > >>>> Resrouce-Priority instead of eGRUU > > >>>> > > >>>> On 12/1/11 3:57 AM, Christer Holmberg wrote: > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>>>>> ISTM that a callback to the Contact address of a prior > > >>>> call should > > >>>>>>>> typically bypass many treatments, regardless of who > > it is from. > > >>>>>>>> > > >>>>>>>> In particular, it ought to go to the specific device > > >>>> identified by the > > >>>>>>>> contact address, not to some other device, VM server, etc. > > >>>>>>>> > > >>>>>>>> Perhaps that isn't what happens with IMS right now, but > > >>>> then maybe that > > >>>>>>>> ought to be re-thought. > > >>>>>>>> > > >>>>>>>> If that was normal behavior, then what else would be > > >> required for > > >>>>>>>> callbacks by a psap? > > >>>>>>>> > > >>>>>>>> There may need to be special treatment by the UA=20 > itself, but=20 > > >>>>>>>> that can be handled by using a unique temp > > >>>> gruu for the > > >>>>>>>> emergency call and remembering it in order to detect > > >>>> emergency callbacks > > >>>>>>>> in the UA. > > >>>>>>>> > > >>>>>>>> What am I missing? What sort of disruptive services do > > >>>> you expect will > > >>>>>>>> be applied to calls to a gruu? > > >>>>>>> > > >>>>>>> I don't think one can assume that any type of call, > > >>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same=20 > > >>>> special treatment by the network, just because they=20 > are addressed=20 > > >>>> using a Contact. > > >>>>>>> > > >>>>>>> And, it is not only about routing to another device, but > > >>>> also other services that normally would be applied. > > >>>>>> > > >>>>>> Rather than talk generically about "services", can we get > > >>>> tangible about > > >>>>>> what sorts of things the network might do that would be > > >>>> detrimental to a > > >>>>>> psap callback? > > >>>>>> > > >>>>>> AFAIK about the only thing that the network can do > > >>>> involves routing to > > >>>>>> some device other than the one addressed by the r-uri. E.g. > > >>>>>> - route to a VM server or message server that responds > > >> in some way. > > >>>>>> - forward to some other configured address > > >>>>>> > > >>>>>> IMO neither of those are appropriate if the URI is a gruu > > >>>> for a specific > > >>>>>> device and that device is reachable. They would be > > >>>> appropriate even for > > >>>>>> a psap callback if the device is not reachable. > > >>>>> > > >>>>> Again, it's not only about routing to a specific device. > > >>>>> > > >>>>> Before the request even reaches the device, it might e.g. > > >>>> be routed to different application servers in the network,=20 > > >>>> triggering different kind of non-routing related services. A=20 > > >>>> "normal" gruu addressed call could still be routed to such=20 > > >>>> application servers, while a PSAP callback wouldn't. > > >>>> > > >>>> Without some tangible examples, what you say is just so much=20 > > >>>> "mumble,mumble" to me. > > >>>> > > >>>> Either it is routed to some alternative device that terminates=20 > > >>>> the call instead of the intended device, or else it is routed=20 > > >>>> through some device that simply acts as an intermediary, still=20 > > >>>> allowing the > > >> call to reach > > >>>> the intended device, or else it fails the call. > > >>>> > > >>>> Anything that acts as an intermediary, still allowing=20 > the call to=20 > > >>>> reach the intended destination, is probably benign.=20 > (Do you have=20 > > >>>> a > > >>>> counter-example?) > > >>>> > > >>>> Anything that routes to someplace other than the=20 > intended device=20 > > >>>> is of dubious appropriateness when the r-uri is a=20 > GRUU. Again I'd=20 > > >>>> be interested to hear some examples. > > >>>> > > >>>> Thanks, > > >>>> Paul > > >>>> _______________________________________________ > > >>>> Ecrit mailing list > > >>>> Ecrit@ietf.org > > >>>> https://www.ietf.org/mailman/listinfo/ecrit > > >>>> > > >> > > >> > >=20 > >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > = From pkyzivat@alum.mit.edu Wed Nov 30 14:22:55 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD9421F8BEC for ; Wed, 30 Nov 2011 14:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VI+lHDb3VEKn for ; Wed, 30 Nov 2011 14:22:53 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 72BA221F8BEB for ; Wed, 30 Nov 2011 14:22:53 -0800 (PST) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta12.westchester.pa.mail.comcast.net with comcast id 3aJg1i00227AodY5CaNsyD; Wed, 30 Nov 2011 22:22:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id 3aNr1i00x07duvL3faNseU; Wed, 30 Nov 2011 22:22:52 +0000 Message-ID: <4ED6ACB6.9020603@alum.mit.edu> Date: Thu, 01 Dec 2011 06:22:46 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> <4ED68CAB.5080602@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C255@FHDP1LUMXC7V31.us.one.verizon.com> <4ED69757.708@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> <4ED6A04D.5000705@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFA@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFA@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:22:55 -0000 On 12/1/11 5:40 AM, Christer Holmberg wrote: > Yes. There needs to be a way for the network, when it receives a request claiming to be a PSAP Callback, to determine that the call comes from a PSAP. There might be different ways of doing that, depending on networks, environments, operator agreements etc. I'm not happy with the idea of crafting special mechanisms just to indicate "this is a PSAP calling" or "this is an emergency callback". IMO it would be better to use *some* standard mechanism, together with policies driven off of it. E.g. use P-Asserted-ID with a special URI to indicate the caller is a PSAP, and then policies that allow/forbid use of Priority:emergency and RP based (in part) on whether the caller has this ID. Thanks, Paul From br@brianrosen.net Wed Nov 30 14:26:17 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8767311E80B5 for ; Wed, 30 Nov 2011 14:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfQF3qx1Pc8c for ; Wed, 30 Nov 2011 14:26:16 -0800 (PST) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 708B811E809D for ; Wed, 30 Nov 2011 14:26:16 -0800 (PST) X-ASG-Debug-ID: 1322691974-011a9f049208c80002-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id yLmd5KucicAPMDPb; Wed, 30 Nov 2011 14:26:14 -0800 (PST) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from [209.173.57.233] (helo=[192.168.130.29]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RVsUY-000FAi-De; Wed, 30 Nov 2011 14:19:02 -0800 X-Barracuda-BBL-IP: 209.173.57.233 X-Barracuda-RBL-IP: 209.173.57.233 Mime-Version: 1.0 (Apple Message framework v1251.1) X-ASG-Orig-Subj: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Content-Type: text/plain; charset=us-ascii From: Brian Rosen In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3B397C3AB@FHDP1LUMXC7V31.us.one.verizon.com> Date: Wed, 30 Nov 2011 17:18:57 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5CC30329-FADD-4A79-9549-E58B681EAD9D@brianrosen.net> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> <4ED68CAB.5080602@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C255@FHDP1LUMXC7V31.us.one.verizon.com> <4ED69757.708@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> <4ED6A04D.5000705@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C373@FHDP1LUMXC7V31.us.one.verizon.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFC@ESESSCMS0356.eemea.ericsson.se> <2B0F677F0B95454297753F58D4A07FA3B397C3AB@FHDP1LUMXC7V31.us.one.verizon.com> To: "Dwight, Timothy M (Tim)" X-Mailer: Apple Mail (2.1251.1) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1322691974 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.81766 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:26:17 -0000 phonebcp says: ED-64/SP-34 Devices device SHOULD have a globally routable URI in a Contact: header field which remains valid for several minutes past the time the original call containing the URI completes unless the device registration expires and is not renewed. On Nov 30, 2011, at 5:12 PM, Dwight, Timothy M (Tim) wrote: > Thanks Christer. >=20 > Maybe it's not easy to implement, but I'm uncomfortable that a device, = once used to place a 911 call, is permanently marked as accessible to an = unlimited number of calls from entities that pass the "I am a PSAP" = test. >=20 > tim >=20 >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 >> Sent: Wednesday, November 30, 2011 4:05 PM >> To: Dwight, Timothy M (Tim); Paul Kyzivat >> Cc: ecrit@ietf.org >> Subject: RE: [Ecrit] PSAP Callback indication:=20 >> Resrouce-Priority instead of eGRUU >>=20 >>=20 >> Hi, >>=20 >> I'm not Paul, but I will reply anyway :) >>=20 >> I will double check, but I don think that there is any time=20 >> limit (at least not a "relatively short" one) for a call to=20 >> be considered and treated as a callback. The network entities=20 >> that makes the prioritization may not even know when the=20 >> associtaed emergency call was made (so, if there were some=20 >> time limit I think the callback would need to contain timing=20 >> information). >>=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 >> On Behalf Of Dwight, Timothy M (Tim) >> Sent: 30. marraskuuta 2011 23:55 >> To: Paul Kyzivat >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback indication:=20 >> Resrouce-Priority instead of eGRUU >>=20 >> Paul, >>=20 >> Does there need also to be some "time limit"? ISTM that=20 >> after some [relatively short] period of time, a call from a=20 >> PSAP is no longer a "call back" and needn't be prioritized. =20 >>=20 >> tim >>=20 >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Wednesday, November 30, 2011 3:30 PM >>> To: Dwight, Timothy M (Tim) >>> Cc: ecrit@ietf.org >>> Subject: Re: [Ecrit] PSAP Callback indication:=20 >>> Resrouce-Priority instead of eGRUU >>>=20 >>> On 12/1/11 5:08 AM, Dwight, Timothy M (Tim) wrote: >>>> Paul, >>>>=20 >>>> "call barring" is a standard GSM service. You can invoke >>> it yourself with a "star code" or "hash code". It's also=20 >> possible to=20 >>> bar incoming calls only when roaming. Similarly there are various=20= >>> flavors of call diversion (aka call >>> forwarding) that can be set similarly. This is what I meant.=20 >>> Services the user invokes or to which he is subscribed,=20 >> that have the=20 >>> effect of preventing delivery of a call. >>>=20 >>> OK. These examples are much more helpful. >>> So it seems you are looking for another attribute that can=20 >> be input to=20 >>> a policy engine that makes such decisions. >>>=20 >>> So, on one hand its desired to indicate that the caller wants this=20= >>> call to receive special treatment, and then there is the issue of=20 >>> determining if the caller is entitled to ask for such treatment. >>>=20 >>> ISTM that Priority:emergency should be sufficient as an=20 >> indicator that=20 >>> the treatment is required. Its been stated that this is=20 >> intended for=20 >>> use by the UAS. But the kinds of services we are discussing=20 >> bypassing=20 >>> are in general provided on behalf of the UAS, so I think it still=20 >>> applies. >>>=20 >>> The Resource-Priority header probably also has a role here in cases=20= >>> where there are resource constraints in the network. >>>=20 >>> Deciding if the caller is permitted to request this then=20 >> becomes the=20 >>> hard part. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> tim >>>>=20 >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>> Sent: Wednesday, November 30, 2011 2:52 PM >>>>> To: Dwight, Timothy M (Tim) >>>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>>> Resrouce-Priority instead of eGRUU >>>>>=20 >>>>> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: >>>>>> Paul, >>>>>>=20 >>>>>> I assume this "mumble mumble" refers to features in the >>>>> service provider network that might otherwise prevent=20 >> the callback=20 >>>>> from being delivered. The subscriber might have incoming calls=20 >>>>> barred for example. >>>>>=20 >>>>> Do you mean that the provider has barred calls because=20 >> the bill has=20 >>>>> not been paid? I wouldn't consider this a "service" to=20 >> the user of=20 >>>>> the phone, but its a reality to deal with. >>>>>=20 >>>>> I guess that is a significant issue in the case where outgoing=20 >>>>> emergency calls are allowed. >>>>>=20 >>>>> This needs to be mentioned on the list. >>>>> =09 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> tim >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: ecrit-bounces@ietf.org=20 >> [mailto:ecrit-bounces@ietf.org] On=20 >>>>>>> Behalf Of Paul Kyzivat >>>>>>> Sent: Wednesday, November 30, 2011 2:06 PM >>>>>>> To: Christer Holmberg >>>>>>> Cc: Adam Roach; ECRIT >>>>>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>>>>> Resrouce-Priority instead of eGRUU >>>>>>>=20 >>>>>>> On 12/1/11 3:57 AM, Christer Holmberg wrote: >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>>>>> ISTM that a callback to the Contact address of a prior >>>>>>> call should >>>>>>>>>>> typically bypass many treatments, regardless of who >>> it is from. >>>>>>>>>>>=20 >>>>>>>>>>> In particular, it ought to go to the specific device >>>>>>> identified by the >>>>>>>>>>> contact address, not to some other device, VM server, etc. >>>>>>>>>>>=20 >>>>>>>>>>> Perhaps that isn't what happens with IMS right now, but >>>>>>> then maybe that >>>>>>>>>>> ought to be re-thought. >>>>>>>>>>>=20 >>>>>>>>>>> If that was normal behavior, then what else would be >>>>> required for >>>>>>>>>>> callbacks by a psap? >>>>>>>>>>>=20 >>>>>>>>>>> There may need to be special treatment by the UA=20 >> itself, but=20 >>>>>>>>>>> that can be handled by using a unique temp >>>>>>> gruu for the >>>>>>>>>>> emergency call and remembering it in order to detect >>>>>>> emergency callbacks >>>>>>>>>>> in the UA. >>>>>>>>>>>=20 >>>>>>>>>>> What am I missing? What sort of disruptive services do >>>>>>> you expect will >>>>>>>>>>> be applied to calls to a gruu? >>>>>>>>>>=20 >>>>>>>>>> I don't think one can assume that any type of call, >>>>>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same=20 >>>>>>> special treatment by the network, just because they=20 >> are addressed=20 >>>>>>> using a Contact. >>>>>>>>>>=20 >>>>>>>>>> And, it is not only about routing to another device, but >>>>>>> also other services that normally would be applied. >>>>>>>>>=20 >>>>>>>>> Rather than talk generically about "services", can we get >>>>>>> tangible about >>>>>>>>> what sorts of things the network might do that would be >>>>>>> detrimental to a >>>>>>>>> psap callback? >>>>>>>>>=20 >>>>>>>>> AFAIK about the only thing that the network can do >>>>>>> involves routing to >>>>>>>>> some device other than the one addressed by the r-uri. E.g. >>>>>>>>> - route to a VM server or message server that responds >>>>> in some way. >>>>>>>>> - forward to some other configured address >>>>>>>>>=20 >>>>>>>>> IMO neither of those are appropriate if the URI is a gruu >>>>>>> for a specific >>>>>>>>> device and that device is reachable. They would be >>>>>>> appropriate even for >>>>>>>>> a psap callback if the device is not reachable. >>>>>>>>=20 >>>>>>>> Again, it's not only about routing to a specific device. >>>>>>>>=20 >>>>>>>> Before the request even reaches the device, it might e.g. >>>>>>> be routed to different application servers in the network,=20 >>>>>>> triggering different kind of non-routing related services. A=20 >>>>>>> "normal" gruu addressed call could still be routed to such=20 >>>>>>> application servers, while a PSAP callback wouldn't. >>>>>>>=20 >>>>>>> Without some tangible examples, what you say is just so much=20 >>>>>>> "mumble,mumble" to me. >>>>>>>=20 >>>>>>> Either it is routed to some alternative device that terminates=20= >>>>>>> the call instead of the intended device, or else it is routed=20 >>>>>>> through some device that simply acts as an intermediary, still=20= >>>>>>> allowing the >>>>> call to reach >>>>>>> the intended device, or else it fails the call. >>>>>>>=20 >>>>>>> Anything that acts as an intermediary, still allowing=20 >> the call to=20 >>>>>>> reach the intended destination, is probably benign.=20 >> (Do you have=20 >>>>>>> a >>>>>>> counter-example?) >>>>>>>=20 >>>>>>> Anything that routes to someplace other than the=20 >> intended device=20 >>>>>>> is of dubious appropriateness when the r-uri is a=20 >> GRUU. Again I'd=20 >>>>>>> be interested to hear some examples. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Paul >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Wed Nov 30 14:40:21 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF55721F8B68 for ; Wed, 30 Nov 2011 14:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkR8ddTokyOb for ; Wed, 30 Nov 2011 14:40:21 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id A293F21F8B67 for ; Wed, 30 Nov 2011 14:40:20 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta08.westchester.pa.mail.comcast.net with comcast id 3Z8J1i0041vXlb858agMVp; Wed, 30 Nov 2011 22:40:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id 3agL1i00T07duvL3dagLci; Wed, 30 Nov 2011 22:40:21 +0000 Message-ID: <4ED6B0D3.5050509@alum.mit.edu> Date: Thu, 01 Dec 2011 06:40:19 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Dwight, Timothy M (Tim)" References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> <4ED68CAB.5080602@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C255@FHDP1LUMXC7V31.us.one.verizon.com> <4ED69757.708@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> <4ED6A04D.5000705@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C373@FHDP1LUMXC7V31.us.one.verizon.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFC@ESESSCMS0356.eemea.ericsson.se> <2B0F677F0B95454297753F58D4A07FA3B397C3AB@FHDP1LUMXC7V31.us.one.verizon.com> In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3B397C3AB@FHDP1LUMXC7V31.us.one.verizon.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:40:22 -0000 On 12/1/11 6:12 AM, Dwight, Timothy M (Tim) wrote: > Thanks Christer. > > Maybe it's not easy to implement, but I'm uncomfortable that a device, once used to place a 911 call, is permanently marked as accessible to an unlimited number of calls from entities that pass the "I am a PSAP" test. The phone can limit this by using a unique temp-gruu for its emergency calls, and remembering the temp-gruu for only as long as it wants to allow callbacks. Then if it gets a call to gruu remembered this way it can honor it, and otherwise not. This is independent of the mechanisms by which the call bypasses network "services" to reach the device. Done this way, the device can still be subject to undesired priority callbacks. But the only cost is detecting and rejecting them, which should not be a great burden. Thanks, Paul > tim > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Wednesday, November 30, 2011 4:05 PM >> To: Dwight, Timothy M (Tim); Paul Kyzivat >> Cc: ecrit@ietf.org >> Subject: RE: [Ecrit] PSAP Callback indication: >> Resrouce-Priority instead of eGRUU >> >> >> Hi, >> >> I'm not Paul, but I will reply anyway :) >> >> I will double check, but I don think that there is any time >> limit (at least not a "relatively short" one) for a call to >> be considered and treated as a callback. The network entities >> that makes the prioritization may not even know when the >> associtaed emergency call was made (so, if there were some >> time limit I think the callback would need to contain timing >> information). >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Dwight, Timothy M (Tim) >> Sent: 30. marraskuuta 2011 23:55 >> To: Paul Kyzivat >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback indication: >> Resrouce-Priority instead of eGRUU >> >> Paul, >> >> Does there need also to be some "time limit"? ISTM that >> after some [relatively short] period of time, a call from a >> PSAP is no longer a "call back" and needn't be prioritized. >> >> tim >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>> Sent: Wednesday, November 30, 2011 3:30 PM >>> To: Dwight, Timothy M (Tim) >>> Cc: ecrit@ietf.org >>> Subject: Re: [Ecrit] PSAP Callback indication: >>> Resrouce-Priority instead of eGRUU >>> >>> On 12/1/11 5:08 AM, Dwight, Timothy M (Tim) wrote: >>>> Paul, >>>> >>>> "call barring" is a standard GSM service. You can invoke >>> it yourself with a "star code" or "hash code". It's also >> possible to >>> bar incoming calls only when roaming. Similarly there are various >>> flavors of call diversion (aka call >>> forwarding) that can be set similarly. This is what I meant. >>> Services the user invokes or to which he is subscribed, >> that have the >>> effect of preventing delivery of a call. >>> >>> OK. These examples are much more helpful. >>> So it seems you are looking for another attribute that can >> be input to >>> a policy engine that makes such decisions. >>> >>> So, on one hand its desired to indicate that the caller wants this >>> call to receive special treatment, and then there is the issue of >>> determining if the caller is entitled to ask for such treatment. >>> >>> ISTM that Priority:emergency should be sufficient as an >> indicator that >>> the treatment is required. Its been stated that this is >> intended for >>> use by the UAS. But the kinds of services we are discussing >> bypassing >>> are in general provided on behalf of the UAS, so I think it still >>> applies. >>> >>> The Resource-Priority header probably also has a role here in cases >>> where there are resource constraints in the network. >>> >>> Deciding if the caller is permitted to request this then >> becomes the >>> hard part. >>> >>> Thanks, >>> Paul >>> >>>> tim >>>> >>>>> -----Original Message----- >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>>> Sent: Wednesday, November 30, 2011 2:52 PM >>>>> To: Dwight, Timothy M (Tim) >>>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>>> Resrouce-Priority instead of eGRUU >>>>> >>>>> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: >>>>>> Paul, >>>>>> >>>>>> I assume this "mumble mumble" refers to features in the >>>>> service provider network that might otherwise prevent >> the callback >>>>> from being delivered. The subscriber might have incoming calls >>>>> barred for example. >>>>> >>>>> Do you mean that the provider has barred calls because >> the bill has >>>>> not been paid? I wouldn't consider this a "service" to >> the user of >>>>> the phone, but its a reality to deal with. >>>>> >>>>> I guess that is a significant issue in the case where outgoing >>>>> emergency calls are allowed. >>>>> >>>>> This needs to be mentioned on the list. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> >>>>> >>>>>> tim >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] On >>>>>>> Behalf Of Paul Kyzivat >>>>>>> Sent: Wednesday, November 30, 2011 2:06 PM >>>>>>> To: Christer Holmberg >>>>>>> Cc: Adam Roach; ECRIT >>>>>>> Subject: Re: [Ecrit] PSAP Callback indication: >>>>>>> Resrouce-Priority instead of eGRUU >>>>>>> >>>>>>> On 12/1/11 3:57 AM, Christer Holmberg wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>>>>> ISTM that a callback to the Contact address of a prior >>>>>>> call should >>>>>>>>>>> typically bypass many treatments, regardless of who >>> it is from. >>>>>>>>>>> >>>>>>>>>>> In particular, it ought to go to the specific device >>>>>>> identified by the >>>>>>>>>>> contact address, not to some other device, VM server, etc. >>>>>>>>>>> >>>>>>>>>>> Perhaps that isn't what happens with IMS right now, but >>>>>>> then maybe that >>>>>>>>>>> ought to be re-thought. >>>>>>>>>>> >>>>>>>>>>> If that was normal behavior, then what else would be >>>>> required for >>>>>>>>>>> callbacks by a psap? >>>>>>>>>>> >>>>>>>>>>> There may need to be special treatment by the UA >> itself, but >>>>>>>>>>> that can be handled by using a unique temp >>>>>>> gruu for the >>>>>>>>>>> emergency call and remembering it in order to detect >>>>>>> emergency callbacks >>>>>>>>>>> in the UA. >>>>>>>>>>> >>>>>>>>>>> What am I missing? What sort of disruptive services do >>>>>>> you expect will >>>>>>>>>>> be applied to calls to a gruu? >>>>>>>>>> >>>>>>>>>> I don't think one can assume that any type of call, >>>>>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same >>>>>>> special treatment by the network, just because they >> are addressed >>>>>>> using a Contact. >>>>>>>>>> >>>>>>>>>> And, it is not only about routing to another device, but >>>>>>> also other services that normally would be applied. >>>>>>>>> >>>>>>>>> Rather than talk generically about "services", can we get >>>>>>> tangible about >>>>>>>>> what sorts of things the network might do that would be >>>>>>> detrimental to a >>>>>>>>> psap callback? >>>>>>>>> >>>>>>>>> AFAIK about the only thing that the network can do >>>>>>> involves routing to >>>>>>>>> some device other than the one addressed by the r-uri. E.g. >>>>>>>>> - route to a VM server or message server that responds >>>>> in some way. >>>>>>>>> - forward to some other configured address >>>>>>>>> >>>>>>>>> IMO neither of those are appropriate if the URI is a gruu >>>>>>> for a specific >>>>>>>>> device and that device is reachable. They would be >>>>>>> appropriate even for >>>>>>>>> a psap callback if the device is not reachable. >>>>>>>> >>>>>>>> Again, it's not only about routing to a specific device. >>>>>>>> >>>>>>>> Before the request even reaches the device, it might e.g. >>>>>>> be routed to different application servers in the network, >>>>>>> triggering different kind of non-routing related services. A >>>>>>> "normal" gruu addressed call could still be routed to such >>>>>>> application servers, while a PSAP callback wouldn't. >>>>>>> >>>>>>> Without some tangible examples, what you say is just so much >>>>>>> "mumble,mumble" to me. >>>>>>> >>>>>>> Either it is routed to some alternative device that terminates >>>>>>> the call instead of the intended device, or else it is routed >>>>>>> through some device that simply acts as an intermediary, still >>>>>>> allowing the >>>>> call to reach >>>>>>> the intended device, or else it fails the call. >>>>>>> >>>>>>> Anything that acts as an intermediary, still allowing >> the call to >>>>>>> reach the intended destination, is probably benign. >> (Do you have >>>>>>> a >>>>>>> counter-example?) >>>>>>> >>>>>>> Anything that routes to someplace other than the >> intended device >>>>>>> is of dubious appropriateness when the r-uri is a >> GRUU. Again I'd >>>>>>> be interested to hear some examples. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> _______________________________________________ >>>>>>> Ecrit mailing list >>>>>>> Ecrit@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>>>> >>>>> >>>>> >>> >>> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> From timothy.dwight@verizon.com Wed Nov 30 14:42:28 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D54E911E809C for ; Wed, 30 Nov 2011 14:42:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJ2yd5NVUJIu for ; Wed, 30 Nov 2011 14:42:28 -0800 (PST) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id A5D4411E809B for ; Wed, 30 Nov 2011 14:42:27 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 30 Nov 2011 22:42:26 +0000 From: "Dwight, Timothy M (Tim)" X-IronPort-AV: E=Sophos;i="4.71,273,1320624000"; d="scan'208";a="187164927" Received: from fhdp1lumxc7hb01.verizon.com (HELO FHDP1LUMXC7HB01.us.one.verizon.com) ([166.68.59.188]) by fldsmtpi01.verizon.com with ESMTP; 30 Nov 2011 22:42:26 +0000 Received: from FHDP1LUMXC7V31.us.one.verizon.com ([169.254.1.197]) by FHDP1LUMXC7HB01.us.one.verizon.com ([166.68.59.188]) with mapi; Wed, 30 Nov 2011 17:42:26 -0500 To: Brian Rosen Date: Wed, 30 Nov 2011 17:42:25 -0500 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: AcyvrxRif/bHuSqIQHiPmSzSSSPVTAAAjpWg Message-ID: <2B0F677F0B95454297753F58D4A07FA3B397C3E8@FHDP1LUMXC7V31.us.one.verizon.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se>, <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se>, <4ED68923.4060808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D2B@ESESSCMS0356.eemea.ericsson.se> <4ED68CAB.5080602@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C255@FHDP1LUMXC7V31.us.one.verizon.com> <4ED69757.708@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C2D1@FHDP1LUMXC7V31.us.one.verizon.com> <4ED6A04D.5000705@alum.mit.edu> <2B0F677F0B95454297753F58D4A07FA3B397C373@FHDP1LUMXC7V31.us.one.verizon.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFC@ESESSCMS0356.eemea.ericsson.se> <2B0F677F0B95454297753F58D4A07FA3B397C3AB@FHDP1LUMXC7V31.us.one.verizon.com> <5CC30329-FADD-4A79-9549-E58B681EAD9D@brianrosen.net> In-Reply-To: <5CC30329-FADD-4A79-9549-E58B681EAD9D@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:42:29 -0000 That'll work. Thanks, Brian. Tim =20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, November 30, 2011 4:19 PM > To: Dwight, Timothy M (Tim) > Cc: Christer Holmberg; Paul Kyzivat; ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback indication:=20 > Resrouce-Priority instead of eGRUU >=20 > phonebcp says: > ED-64/SP-34 Devices device SHOULD have a globally routable URI in a > Contact: header field which remains valid for several minutes past > the time the original call containing the URI completes unless the > device registration expires and is not renewed. >=20 >=20 >=20 > On Nov 30, 2011, at 5:12 PM, Dwight, Timothy M (Tim) wrote: >=20 > > Thanks Christer. > >=20 > > Maybe it's not easy to implement, but I'm uncomfortable=20 > that a device, once used to place a 911 call, is permanently=20 > marked as accessible to an unlimited number of calls from=20 > entities that pass the "I am a PSAP" test. > >=20 > > tim > >=20 > >> -----Original Message----- > >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 > >> Sent: Wednesday, November 30, 2011 4:05 PM > >> To: Dwight, Timothy M (Tim); Paul Kyzivat > >> Cc: ecrit@ietf.org > >> Subject: RE: [Ecrit] PSAP Callback indication:=20 > >> Resrouce-Priority instead of eGRUU > >>=20 > >>=20 > >> Hi, > >>=20 > >> I'm not Paul, but I will reply anyway :) > >>=20 > >> I will double check, but I don think that there is any time=20 > >> limit (at least not a "relatively short" one) for a call to=20 > >> be considered and treated as a callback. The network entities=20 > >> that makes the prioritization may not even know when the=20 > >> associtaed emergency call was made (so, if there were some=20 > >> time limit I think the callback would need to contain timing=20 > >> information). > >>=20 > >> Regards, > >>=20 > >> Christer > >>=20 > >> -----Original Message----- > >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org]=20 > >> On Behalf Of Dwight, Timothy M (Tim) > >> Sent: 30. marraskuuta 2011 23:55 > >> To: Paul Kyzivat > >> Cc: ecrit@ietf.org > >> Subject: Re: [Ecrit] PSAP Callback indication:=20 > >> Resrouce-Priority instead of eGRUU > >>=20 > >> Paul, > >>=20 > >> Does there need also to be some "time limit"? ISTM that=20 > >> after some [relatively short] period of time, a call from a=20 > >> PSAP is no longer a "call back" and needn't be prioritized. =20 > >>=20 > >> tim > >>=20 > >>> -----Original Message----- > >>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>> Sent: Wednesday, November 30, 2011 3:30 PM > >>> To: Dwight, Timothy M (Tim) > >>> Cc: ecrit@ietf.org > >>> Subject: Re: [Ecrit] PSAP Callback indication:=20 > >>> Resrouce-Priority instead of eGRUU > >>>=20 > >>> On 12/1/11 5:08 AM, Dwight, Timothy M (Tim) wrote: > >>>> Paul, > >>>>=20 > >>>> "call barring" is a standard GSM service. You can invoke > >>> it yourself with a "star code" or "hash code". It's also=20 > >> possible to=20 > >>> bar incoming calls only when roaming. Similarly there=20 > are various=20 > >>> flavors of call diversion (aka call > >>> forwarding) that can be set similarly. This is what I meant.=20 > >>> Services the user invokes or to which he is subscribed,=20 > >> that have the=20 > >>> effect of preventing delivery of a call. > >>>=20 > >>> OK. These examples are much more helpful. > >>> So it seems you are looking for another attribute that can=20 > >> be input to=20 > >>> a policy engine that makes such decisions. > >>>=20 > >>> So, on one hand its desired to indicate that the caller=20 > wants this=20 > >>> call to receive special treatment, and then there is the issue of=20 > >>> determining if the caller is entitled to ask for such treatment. > >>>=20 > >>> ISTM that Priority:emergency should be sufficient as an=20 > >> indicator that=20 > >>> the treatment is required. Its been stated that this is=20 > >> intended for=20 > >>> use by the UAS. But the kinds of services we are discussing=20 > >> bypassing=20 > >>> are in general provided on behalf of the UAS, so I think it still=20 > >>> applies. > >>>=20 > >>> The Resource-Priority header probably also has a role=20 > here in cases=20 > >>> where there are resource constraints in the network. > >>>=20 > >>> Deciding if the caller is permitted to request this then=20 > >> becomes the=20 > >>> hard part. > >>>=20 > >>> Thanks, > >>> Paul > >>>=20 > >>>> tim > >>>>=20 > >>>>> -----Original Message----- > >>>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >>>>> Sent: Wednesday, November 30, 2011 2:52 PM > >>>>> To: Dwight, Timothy M (Tim) > >>>>> Subject: Re: [Ecrit] PSAP Callback indication: > >>>>> Resrouce-Priority instead of eGRUU > >>>>>=20 > >>>>> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: > >>>>>> Paul, > >>>>>>=20 > >>>>>> I assume this "mumble mumble" refers to features in the > >>>>> service provider network that might otherwise prevent=20 > >> the callback=20 > >>>>> from being delivered. The subscriber might have incoming calls=20 > >>>>> barred for example. > >>>>>=20 > >>>>> Do you mean that the provider has barred calls because=20 > >> the bill has=20 > >>>>> not been paid? I wouldn't consider this a "service" to=20 > >> the user of=20 > >>>>> the phone, but its a reality to deal with. > >>>>>=20 > >>>>> I guess that is a significant issue in the case where outgoing=20 > >>>>> emergency calls are allowed. > >>>>>=20 > >>>>> This needs to be mentioned on the list. > >>>>> =09 > >>>>> Thanks, > >>>>> Paul > >>>>>=20 > >>>>>=20 > >>>>>=20 > >>>>>> tim > >>>>>>=20 > >>>>>>> -----Original Message----- > >>>>>>> From: ecrit-bounces@ietf.org=20 > >> [mailto:ecrit-bounces@ietf.org] On=20 > >>>>>>> Behalf Of Paul Kyzivat > >>>>>>> Sent: Wednesday, November 30, 2011 2:06 PM > >>>>>>> To: Christer Holmberg > >>>>>>> Cc: Adam Roach; ECRIT > >>>>>>> Subject: Re: [Ecrit] PSAP Callback indication: > >>>>>>> Resrouce-Priority instead of eGRUU > >>>>>>>=20 > >>>>>>> On 12/1/11 3:57 AM, Christer Holmberg wrote: > >>>>>>>>=20 > >>>>>>>> Hi, > >>>>>>>>=20 > >>>>>>>>>>> ISTM that a callback to the Contact address of a prior > >>>>>>> call should > >>>>>>>>>>> typically bypass many treatments, regardless of who > >>> it is from. > >>>>>>>>>>>=20 > >>>>>>>>>>> In particular, it ought to go to the specific device > >>>>>>> identified by the > >>>>>>>>>>> contact address, not to some other device, VM server, etc. > >>>>>>>>>>>=20 > >>>>>>>>>>> Perhaps that isn't what happens with IMS right now, but > >>>>>>> then maybe that > >>>>>>>>>>> ought to be re-thought. > >>>>>>>>>>>=20 > >>>>>>>>>>> If that was normal behavior, then what else would be > >>>>> required for > >>>>>>>>>>> callbacks by a psap? > >>>>>>>>>>>=20 > >>>>>>>>>>> There may need to be special treatment by the UA=20 > >> itself, but=20 > >>>>>>>>>>> that can be handled by using a unique temp > >>>>>>> gruu for the > >>>>>>>>>>> emergency call and remembering it in order to detect > >>>>>>> emergency callbacks > >>>>>>>>>>> in the UA. > >>>>>>>>>>>=20 > >>>>>>>>>>> What am I missing? What sort of disruptive services do > >>>>>>> you expect will > >>>>>>>>>>> be applied to calls to a gruu? > >>>>>>>>>>=20 > >>>>>>>>>> I don't think one can assume that any type of call, > >>>>>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same=20 > >>>>>>> special treatment by the network, just because they=20 > >> are addressed=20 > >>>>>>> using a Contact. > >>>>>>>>>>=20 > >>>>>>>>>> And, it is not only about routing to another device, but > >>>>>>> also other services that normally would be applied. > >>>>>>>>>=20 > >>>>>>>>> Rather than talk generically about "services", can we get > >>>>>>> tangible about > >>>>>>>>> what sorts of things the network might do that would be > >>>>>>> detrimental to a > >>>>>>>>> psap callback? > >>>>>>>>>=20 > >>>>>>>>> AFAIK about the only thing that the network can do > >>>>>>> involves routing to > >>>>>>>>> some device other than the one addressed by the r-uri. E.g. > >>>>>>>>> - route to a VM server or message server that responds > >>>>> in some way. > >>>>>>>>> - forward to some other configured address > >>>>>>>>>=20 > >>>>>>>>> IMO neither of those are appropriate if the URI is a gruu > >>>>>>> for a specific > >>>>>>>>> device and that device is reachable. They would be > >>>>>>> appropriate even for > >>>>>>>>> a psap callback if the device is not reachable. > >>>>>>>>=20 > >>>>>>>> Again, it's not only about routing to a specific device. > >>>>>>>>=20 > >>>>>>>> Before the request even reaches the device, it might e.g. > >>>>>>> be routed to different application servers in the network,=20 > >>>>>>> triggering different kind of non-routing related services. A=20 > >>>>>>> "normal" gruu addressed call could still be routed to such=20 > >>>>>>> application servers, while a PSAP callback wouldn't. > >>>>>>>=20 > >>>>>>> Without some tangible examples, what you say is just so much=20 > >>>>>>> "mumble,mumble" to me. > >>>>>>>=20 > >>>>>>> Either it is routed to some alternative device that=20 > terminates=20 > >>>>>>> the call instead of the intended device, or else it is routed=20 > >>>>>>> through some device that simply acts as an=20 > intermediary, still=20 > >>>>>>> allowing the > >>>>> call to reach > >>>>>>> the intended device, or else it fails the call. > >>>>>>>=20 > >>>>>>> Anything that acts as an intermediary, still allowing=20 > >> the call to=20 > >>>>>>> reach the intended destination, is probably benign.=20 > >> (Do you have=20 > >>>>>>> a > >>>>>>> counter-example?) > >>>>>>>=20 > >>>>>>> Anything that routes to someplace other than the=20 > >> intended device=20 > >>>>>>> is of dubious appropriateness when the r-uri is a=20 > >> GRUU. Again I'd=20 > >>>>>>> be interested to hear some examples. > >>>>>>>=20 > >>>>>>> Thanks, > >>>>>>> Paul > >>>>>>> _______________________________________________ > >>>>>>> Ecrit mailing list > >>>>>>> Ecrit@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/ecrit > >>>>>>>=20 > >>>>>=20 > >>>>>=20 > >>>=20 > >>>=20 > >> _______________________________________________ > >> Ecrit mailing list > >> Ecrit@ietf.org > >> https://www.ietf.org/mailman/listinfo/ecrit > >>=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www.ietf.org/mailman/listinfo/ecrit >=20 > = From mlinsner@cisco.com Wed Nov 30 15:14:50 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF91921F8C40 for ; Wed, 30 Nov 2011 15:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CghGcbSSWJjo for ; Wed, 30 Nov 2011 15:14:48 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B48A221F8C3F for ; Wed, 30 Nov 2011 15:14:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mlinsner@cisco.com; l=9881; q=dns/txt; s=iport; t=1322694888; x=1323904488; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=nSpwenaguKNzvHfiJ4e1sMsf/97txLFnZejn5g0PMHQ=; b=AftbL07gQExP/qybzsKBcbs8DeZLr7Aqo6DqhFc1fzXuXt6Vd7WJ+fZY jjIl4X77VuchQnfhq3PEfbCli2pDfzCOAqUi8vAkBqMqXVf/pVR1wp00v H+upjZvVuSAJsUf3i7H2pLAXsDyF6aLhacuHoU+KZ+KbyscQZYxaY141h Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgAAKa31k6tJV2Y/2dsb2JhbABEmnKQIoEFgXIBAQEEAQEBDwEnAgExCwwHCBEDAQEBAScuHwkIBg4FFA6HbZoXAZ4mBIsgBIgojC+FQ4xr X-IronPort-AV: E=Sophos;i="4.71,273,1320624000"; d="scan'208";a="40161064" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 30 Nov 2011 23:14:48 +0000 Received: from [10.116.195.123] (rtp-mlinsner-87110.cisco.com [10.116.195.123]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAUNEjiJ016722; Wed, 30 Nov 2011 23:14:47 GMT User-Agent: Microsoft-MacOutlook/14.10.0.110310 Date: Wed, 30 Nov 2011 18:14:44 -0500 From: Marc Linsner To: "Dwight, Timothy M (Tim)" Message-ID: Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU In-Reply-To: <2B0F677F0B95454297753F58D4A07FA3B397C3AB@FHDP1LUMXC7V31.us.one.verizon.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 23:14:50 -0000 Tim, If you ask the public safety community, they will ask for a 1 hour time period for special callback treatment. They don't expect special status beyond that time period. -Marc- -----Original Message----- From: "Dwight, Timothy M (Tim)" Date: Wed, 30 Nov 2011 17:12:09 -0500 To: Christer Holmberg , Paul Kyzivat Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU >Thanks Christer. > >Maybe it's not easy to implement, but I'm uncomfortable that a device, >once used to place a 911 call, is permanently marked as accessible to an >unlimited number of calls from entities that pass the "I am a PSAP" test. > >tim > >> -----Original Message----- >> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >> Sent: Wednesday, November 30, 2011 4:05 PM >> To: Dwight, Timothy M (Tim); Paul Kyzivat >> Cc: ecrit@ietf.org >> Subject: RE: [Ecrit] PSAP Callback indication: >> Resrouce-Priority instead of eGRUU >> >> >> Hi, >> >> I'm not Paul, but I will reply anyway :) >> >> I will double check, but I don think that there is any time >> limit (at least not a "relatively short" one) for a call to >> be considered and treated as a callback. The network entities >> that makes the prioritization may not even know when the >> associtaed emergency call was made (so, if there were some >> time limit I think the callback would need to contain timing >> information). >> >> Regards, >> >> Christer >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] >> On Behalf Of Dwight, Timothy M (Tim) >> Sent: 30. marraskuuta 2011 23:55 >> To: Paul Kyzivat >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback indication: >> Resrouce-Priority instead of eGRUU >> >> Paul, >> >> Does there need also to be some "time limit"? ISTM that >> after some [relatively short] period of time, a call from a >> PSAP is no longer a "call back" and needn't be prioritized. >> >> tim >> >> > -----Original Message----- >> > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> > Sent: Wednesday, November 30, 2011 3:30 PM >> > To: Dwight, Timothy M (Tim) >> > Cc: ecrit@ietf.org >> > Subject: Re: [Ecrit] PSAP Callback indication: >> > Resrouce-Priority instead of eGRUU >> > >> > On 12/1/11 5:08 AM, Dwight, Timothy M (Tim) wrote: >> > > Paul, >> > > >> > > "call barring" is a standard GSM service. You can invoke >> > it yourself with a "star code" or "hash code". It's also >> possible to >> > bar incoming calls only when roaming. Similarly there are various >> > flavors of call diversion (aka call >> > forwarding) that can be set similarly. This is what I meant. >> > Services the user invokes or to which he is subscribed, >> that have the >> > effect of preventing delivery of a call. >> > >> > OK. These examples are much more helpful. >> > So it seems you are looking for another attribute that can >> be input to >> > a policy engine that makes such decisions. >> > >> > So, on one hand its desired to indicate that the caller wants this >> > call to receive special treatment, and then there is the issue of >> > determining if the caller is entitled to ask for such treatment. >> > >> > ISTM that Priority:emergency should be sufficient as an >> indicator that >> > the treatment is required. Its been stated that this is >> intended for >> > use by the UAS. But the kinds of services we are discussing >> bypassing >> > are in general provided on behalf of the UAS, so I think it still >> > applies. >> > >> > The Resource-Priority header probably also has a role here in cases >> > where there are resource constraints in the network. >> > >> > Deciding if the caller is permitted to request this then >> becomes the >> > hard part. >> > >> > Thanks, >> > Paul >> > >> > > tim >> > > >> > >> -----Original Message----- >> > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> > >> Sent: Wednesday, November 30, 2011 2:52 PM >> > >> To: Dwight, Timothy M (Tim) >> > >> Subject: Re: [Ecrit] PSAP Callback indication: >> > >> Resrouce-Priority instead of eGRUU >> > >> >> > >> On 12/1/11 4:35 AM, Dwight, Timothy M (Tim) wrote: >> > >>> Paul, >> > >>> >> > >>> I assume this "mumble mumble" refers to features in the >> > >> service provider network that might otherwise prevent >> the callback >> > >> from being delivered. The subscriber might have incoming calls >> > >> barred for example. >> > >> >> > >> Do you mean that the provider has barred calls because >> the bill has >> > >> not been paid? I wouldn't consider this a "service" to >> the user of >> > >> the phone, but its a reality to deal with. >> > >> >> > >> I guess that is a significant issue in the case where outgoing >> > >> emergency calls are allowed. >> > >> >> > >> This needs to be mentioned on the list. >> > >> >> > >> Thanks, >> > >> Paul >> > >> >> > >> >> > >> >> > >>> tim >> > >>> >> > >>>> -----Original Message----- >> > >>>> From: ecrit-bounces@ietf.org >> [mailto:ecrit-bounces@ietf.org] On >> > >>>> Behalf Of Paul Kyzivat >> > >>>> Sent: Wednesday, November 30, 2011 2:06 PM >> > >>>> To: Christer Holmberg >> > >>>> Cc: Adam Roach; ECRIT >> > >>>> Subject: Re: [Ecrit] PSAP Callback indication: >> > >>>> Resrouce-Priority instead of eGRUU >> > >>>> >> > >>>> On 12/1/11 3:57 AM, Christer Holmberg wrote: >> > >>>>> >> > >>>>> Hi, >> > >>>>> >> > >>>>>>>> ISTM that a callback to the Contact address of a prior >> > >>>> call should >> > >>>>>>>> typically bypass many treatments, regardless of who >> > it is from. >> > >>>>>>>> >> > >>>>>>>> In particular, it ought to go to the specific device >> > >>>> identified by the >> > >>>>>>>> contact address, not to some other device, VM server, etc. >> > >>>>>>>> >> > >>>>>>>> Perhaps that isn't what happens with IMS right now, but >> > >>>> then maybe that >> > >>>>>>>> ought to be re-thought. >> > >>>>>>>> >> > >>>>>>>> If that was normal behavior, then what else would be >> > >> required for >> > >>>>>>>> callbacks by a psap? >> > >>>>>>>> >> > >>>>>>>> There may need to be special treatment by the UA >> itself, but >> > >>>>>>>> that can be handled by using a unique temp >> > >>>> gruu for the >> > >>>>>>>> emergency call and remembering it in order to detect >> > >>>> emergency callbacks >> > >>>>>>>> in the UA. >> > >>>>>>>> >> > >>>>>>>> What am I missing? What sort of disruptive services do >> > >>>> you expect will >> > >>>>>>>> be applied to calls to a gruu? >> > >>>>>>> >> > >>>>>>> I don't think one can assume that any type of call, >> > >>>> non-PSAP-callbacks and PSAP-callbacks, will be given the same >> > >>>> special treatment by the network, just because they >> are addressed >> > >>>> using a Contact. >> > >>>>>>> >> > >>>>>>> And, it is not only about routing to another device, but >> > >>>> also other services that normally would be applied. >> > >>>>>> >> > >>>>>> Rather than talk generically about "services", can we get >> > >>>> tangible about >> > >>>>>> what sorts of things the network might do that would be >> > >>>> detrimental to a >> > >>>>>> psap callback? >> > >>>>>> >> > >>>>>> AFAIK about the only thing that the network can do >> > >>>> involves routing to >> > >>>>>> some device other than the one addressed by the r-uri. E.g. >> > >>>>>> - route to a VM server or message server that responds >> > >> in some way. >> > >>>>>> - forward to some other configured address >> > >>>>>> >> > >>>>>> IMO neither of those are appropriate if the URI is a gruu >> > >>>> for a specific >> > >>>>>> device and that device is reachable. They would be >> > >>>> appropriate even for >> > >>>>>> a psap callback if the device is not reachable. >> > >>>>> >> > >>>>> Again, it's not only about routing to a specific device. >> > >>>>> >> > >>>>> Before the request even reaches the device, it might e.g. >> > >>>> be routed to different application servers in the network, >> > >>>> triggering different kind of non-routing related services. A >> > >>>> "normal" gruu addressed call could still be routed to such >> > >>>> application servers, while a PSAP callback wouldn't. >> > >>>> >> > >>>> Without some tangible examples, what you say is just so much >> > >>>> "mumble,mumble" to me. >> > >>>> >> > >>>> Either it is routed to some alternative device that terminates >> > >>>> the call instead of the intended device, or else it is routed >> > >>>> through some device that simply acts as an intermediary, still >> > >>>> allowing the >> > >> call to reach >> > >>>> the intended device, or else it fails the call. >> > >>>> >> > >>>> Anything that acts as an intermediary, still allowing >> the call to >> > >>>> reach the intended destination, is probably benign. >> (Do you have >> > >>>> a >> > >>>> counter-example?) >> > >>>> >> > >>>> Anything that routes to someplace other than the >> intended device >> > >>>> is of dubious appropriateness when the r-uri is a >> GRUU. Again I'd >> > >>>> be interested to hear some examples. >> > >>>> >> > >>>> Thanks, >> > >>>> Paul >> > >>>> _______________________________________________ >> > >>>> Ecrit mailing list >> > >>>> Ecrit@ietf.org >> > >>>> https://www.ietf.org/mailman/listinfo/ecrit >> > >>>> >> > >> >> > >> >> > >> > >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From hgs@cs.columbia.edu Wed Nov 30 17:32:43 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A3321F8BF9 for ; Wed, 30 Nov 2011 17:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m82ZwIgXYcj6 for ; Wed, 30 Nov 2011 17:32:43 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id ED58B21F8BF7 for ; Wed, 30 Nov 2011 17:32:42 -0800 (PST) Received: from upstairs-3.home (pool-96-242-116-37.nwrknj.fios.verizon.net [96.242.116.37]) (user=hgs10 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pB11Wbfd023589 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 Nov 2011 20:32:37 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFB@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 30 Nov 2011 20:32:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <501C9ECF-0559-45A4-A547-EBD987D14F8B@cs.columbia.edu> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se> <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se> <4ED68923.4060808@alum.mit.edu> <201111302100.pAUL0dBU010082@mtv-core-4.cisco.com> <4ED6A114.1060504@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFB@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 01:32:43 -0000 Here's a slightly different model: (1) The UA requests (or automatically gets) a special emergency (temp) = GRUU; we can request this in some way, probably using a Contact = parameter. sip.priority=3Demergency would probably work if we want to = re-use something. (2) The UA uses that GRUU in the emergency call. There is no need to = mark it - the PSAP has no control over call handling at the emergency = caller anyway, so it does the same thing whether the UA knows about = special handling or not. (3) The PSAP places a normal call-back. The proxy knows that this is a = special GRUU that will only be used for emergency calls, so it can do = all bypass actions it wants. Since the UA won't use this GRUU for = "normal" calls, there is no abuse risk. Henning On Nov 30, 2011, at 4:43 PM, Christer Holmberg wrote: >=20 > Hi, >=20 >>> I think you still need a GRUU (at least). >>=20 >> Maybe gruu helps here, maybe not. It seems that gruu isn't sufficient = to bypass call barring policies. If something else is needed for that = then gruu may be irrelevant. >=20 > The proposal was that the emergency gruu would contain a "psapcb" = token, which would have been used as an indicator for bypassing policies = etc. >=20 > (But, yes, the verification of the sender still applies also to the = egruu) >=20 > Regards, >=20 From pkyzivat@alum.mit.edu Wed Nov 30 18:54:01 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F3911E8097 for ; Wed, 30 Nov 2011 18:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uk533lckO980 for ; Wed, 30 Nov 2011 18:54:01 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 174A711E80AB for ; Wed, 30 Nov 2011 18:54:00 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta05.westchester.pa.mail.comcast.net with comcast id 3dpW1i0061ei1Bg55eu1LR; Thu, 01 Dec 2011 02:54:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta24.westchester.pa.mail.comcast.net with comcast id 3eu11i00807duvL3keu1Xs; Thu, 01 Dec 2011 02:54:01 +0000 Message-ID: <4ED6EC48.8050801@alum.mit.edu> Date: Thu, 01 Dec 2011 10:54:00 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Henning Schulzrinne References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se> <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se> <4ED68923.4060808@alum.mit.edu> <201111302100.pAUL0dBU010082@mtv-core-4.cisco.com> <4ED6A114.1060504@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFB@ESESSCMS0356.eemea.ericsson.se> <501C9ECF-0559-45A4-A547-EBD987D14F8B@cs.columbia.edu> In-Reply-To: <501C9ECF-0559-45A4-A547-EBD987D14F8B@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 02:54:01 -0000 On 12/1/11 9:32 AM, Henning Schulzrinne wrote: > Here's a slightly different model: > > (1) The UA requests (or automatically gets) a special emergency (temp) GRUU; we can request this in some way, probably using a Contact parameter. sip.priority=emergency would probably work if we want to re-use something. I'm *really* unhappy with the concept of special emergency temp gruus. The mechanism for temp gruus is already complicated and heavy weight. Lets not complicate it further. Thanks, Paul > (2) The UA uses that GRUU in the emergency call. There is no need to mark it - the PSAP has no control over call handling at the emergency caller anyway, so it does the same thing whether the UA knows about special handling or not. > > (3) The PSAP places a normal call-back. The proxy knows that this is a special GRUU that will only be used for emergency calls, so it can do all bypass actions it wants. Since the UA won't use this GRUU for "normal" calls, there is no abuse risk. > > Henning > > On Nov 30, 2011, at 4:43 PM, Christer Holmberg wrote: > >> >> Hi, >> >>>> I think you still need a GRUU (at least). >>> >>> Maybe gruu helps here, maybe not. It seems that gruu isn't sufficient to bypass call barring policies. If something else is needed for that then gruu may be irrelevant. >> >> The proposal was that the emergency gruu would contain a "psapcb" token, which would have been used as an indicator for bypassing policies etc. >> >> (But, yes, the verification of the sender still applies also to the egruu) >> >> Regards, >> > > From hgs@cs.columbia.edu Wed Nov 30 19:07:35 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3890D11E80AA for ; Wed, 30 Nov 2011 19:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2GpiuwiObg2 for ; Wed, 30 Nov 2011 19:07:34 -0800 (PST) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id A129E11E809F for ; Wed, 30 Nov 2011 19:07:34 -0800 (PST) Received: from upstairs-3.home (pool-96-242-116-37.nwrknj.fios.verizon.net [96.242.116.37]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pB137NIX011841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 Nov 2011 22:07:26 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Henning Schulzrinne In-Reply-To: <4ED6EC48.8050801@alum.mit.edu> Date: Wed, 30 Nov 2011 22:07:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se> <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se> <4ED68923.4060808@alum.mit.edu> <201111302100.pAUL0dBU010082@mtv-core-4.cisco.com> <4ED6A114.1060504@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFB@ESESSCMS0356.eemea.ericsson.se> <501C9ECF-0559-45A4-A547-EBD987D14F8B@cs.columbia.edu> <4ED6EC48.8050801@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 03:07:35 -0000 I'm all for not complicating things, but so far, all other proposed = solutions seem to fall short in one or more of: - can't deal with CallID-mangling SBCs - are subject to abuse attacks (various "plain" labels, such as RPH by = itself) - can't signal to the proxy to induce special (non-forwarding/blocking) = call handling One cop-out is that we just use temp-gruus and have the proxy recognize = them on the outbound emergency call path. This obviously has other = complications, but we seem to be running low on low-complexity = solutions. (I'm not worried that somebody will, within the REGISTER = refresh, call somebody with the same temp-gruu and then get this abused. = The probability seems pretty low. I'm also willing to tolerate that call = forwarding will fail within one hour of placing an emergency call if = somebody uses a temp-gruu.) Henning On Nov 30, 2011, at 9:54 PM, Paul Kyzivat wrote: > On 12/1/11 9:32 AM, Henning Schulzrinne wrote: >> Here's a slightly different model: >>=20 >> (1) The UA requests (or automatically gets) a special emergency = (temp) GRUU; we can request this in some way, probably using a Contact = parameter. sip.priority=3Demergency would probably work if we want to = re-use something. >=20 > I'm *really* unhappy with the concept of special emergency temp gruus. > The mechanism for temp gruus is already complicated and heavy weight. = Lets not complicate it further. From pkyzivat@alum.mit.edu Wed Nov 30 19:21:33 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAFF1F0C47 for ; Wed, 30 Nov 2011 19:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFBVPawuhx49 for ; Wed, 30 Nov 2011 19:21:31 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 026551F0C36 for ; Wed, 30 Nov 2011 19:21:29 -0800 (PST) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta08.westchester.pa.mail.comcast.net with comcast id 3be81i0051YDfWL58fMW6J; Thu, 01 Dec 2011 03:21:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta20.westchester.pa.mail.comcast.net with comcast id 3fMW1i00607duvL3gfMWni; Thu, 01 Dec 2011 03:21:30 +0000 Message-ID: <4ED6F2B9.3070407@alum.mit.edu> Date: Thu, 01 Dec 2011 11:21:29 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Henning Schulzrinne References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se> <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se> <4ED68923.4060808@alum.mit.edu> <201111302100.pAUL0dBU010082@mtv-core-4.cisco.com> <4ED6A114.1060504@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFB@ESESSCMS0356.eemea.ericsson.se> <501C9ECF-0559-45A4-A547-EBD987D14F8B@cs.columbia.edu> <4ED6EC48.8050801@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 03:21:33 -0000 On 12/1/11 11:07 AM, Henning Schulzrinne wrote: > I'm all for not complicating things, but so far, all other proposed solutions seem to fall short in one or more of: > > - can't deal with CallID-mangling SBCs > > - are subject to abuse attacks (various "plain" labels, such as RPH by itself) > > - can't signal to the proxy to induce special (non-forwarding/blocking) call handling > > One cop-out is that we just use temp-gruus and have the proxy recognize them on the outbound emergency call path. This obviously has other complications, but we seem to be running low on low-complexity solutions. (I'm not worried that somebody will, within the REGISTER refresh, call somebody with the same temp-gruu and then get this abused. The probability seems pretty low. I'm also willing to tolerate that call forwarding will fail within one hour of placing an emergency call if somebody uses a temp-gruu.) Are you assuming that the special temp gruu works because the entity that assigns the gruu is also the one that is responsible for all the special feature handling/disabling? That is a bit of a stretch, though it may be sufficient for IMS. This doesn't work for any element that isn't party to the gruu assignment and validity algorithms. Thanks, Paul > Henning > > On Nov 30, 2011, at 9:54 PM, Paul Kyzivat wrote: > >> On 12/1/11 9:32 AM, Henning Schulzrinne wrote: >>> Here's a slightly different model: >>> >>> (1) The UA requests (or automatically gets) a special emergency (temp) GRUU; we can request this in some way, probably using a Contact parameter. sip.priority=emergency would probably work if we want to re-use something. >> >> I'm *really* unhappy with the concept of special emergency temp gruus. >> The mechanism for temp gruus is already complicated and heavy weight. Lets not complicate it further. > > From hgs@cs.columbia.edu Wed Nov 30 19:33:40 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C871F0C52 for ; Wed, 30 Nov 2011 19:33:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FLG0M4NE+6Ix for ; Wed, 30 Nov 2011 19:33:40 -0800 (PST) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id 148141F0C36 for ; Wed, 30 Nov 2011 19:33:40 -0800 (PST) Received: from upstairs-3.home (pool-96-242-116-37.nwrknj.fios.verizon.net [96.242.116.37]) (user=hgs10 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id pB13XVwY013401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 Nov 2011 22:33:32 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Henning Schulzrinne In-Reply-To: <4ED6F2B9.3070407@alum.mit.edu> Date: Wed, 30 Nov 2011 22:33:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <57049AB2-9D6E-4D5A-84D5-ECFBB074EF2D@cs.columbia.edu> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se> <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se> <4ED68923.4060808@alum.mit.edu> <201111302100.pAUL0dBU010082@mtv-core-4.cisco.com> <4ED6A114.1060504@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFB@ESESSCMS0356.eemea.ericsson.se> <501C9ECF-0559-45A4-A547-EBD987D14F8B@cs.columbia.edu> <4ED6EC48.8050801@alum.mit.edu> <4ED6F2B9.3070407@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 03:33:40 -0000 On Nov 30, 2011, at 10:21 PM, Paul Kyzivat wrote: >>=20 >> One cop-out is that we just use temp-gruus and have the proxy = recognize them on the outbound emergency call path. This obviously has = other complications, but we seem to be running low on low-complexity = solutions. (I'm not worried that somebody will, within the REGISTER = refresh, call somebody with the same temp-gruu and then get this abused. = The probability seems pretty low. I'm also willing to tolerate that call = forwarding will fail within one hour of placing an emergency call if = somebody uses a temp-gruu.) >=20 > Are you assuming that the special temp gruu works because the entity = that assigns the gruu is also the one that is responsible for all the = special feature handling/disabling? Yes, or at least has some relationship with that element. For a GRUU to = work, the inbound proxy has to know about it, so this seems at least = plausible. (That's part of the "complications" I mentioned earlier.) >=20 > That is a bit of a stretch, though it may be sufficient for IMS. I suspect it would work in most simple enterprise environments where all = calls, in and out, traverse the same proxy. >=20 > This doesn't work for any element that isn't party to the gruu = assignment and validity algorithms. Indeed - the "complications"... Again, we seem to run short of magic of a simple solution that is = secure, requires no protocol extension anywhere and works in all = architectures. I suspect we can get, at best, two of those three... Henning From christer.holmberg@ericsson.com Wed Nov 30 23:44:26 2011 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BB211E80C2 for ; Wed, 30 Nov 2011 23:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1116VSSq7Xg for ; Wed, 30 Nov 2011 23:44:25 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 201DE11E80C1 for ; Wed, 30 Nov 2011 23:44:24 -0800 (PST) X-AuditID: c1b4fb3d-b7b5fae00000219a-26-4ed73057dd24 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F2.31.08602.75037DE4; Thu, 1 Dec 2011 08:44:23 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 1 Dec 2011 08:44:22 +0100 From: Christer Holmberg To: Henning Schulzrinne , Paul Kyzivat Date: Thu, 1 Dec 2011 08:44:21 +0100 Thread-Topic: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU Thread-Index: Acyv2gMuxu+WIUT4RaCMnnA26ObkxQAG6+zg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A91B481@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C3A578D1C@ESESSCMS0356.eemea.ericsson.se> <201111300226.pAU2QOeO016560@mtv-core-2.cisco.com> <7F2072F1E0DE894DA4B517B93C6A05852C3A91AF5F@ESESSCMS0356.eemea.ericsson.se> <4ED646F5.30300@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A578D25@ESESSCMS0356.eemea.ericsson.se> <4ED68923.4060808@alum.mit.edu> <201111302100.pAUL0dBU010082@mtv-core-4.cisco.com> <4ED6A114.1060504@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFFB@ESESSCMS0356.eemea.ericsson.se> <501C9ECF-0559-45A4-A547-EBD987D14F8B@cs.columbia.edu> <4ED6EC48.8050801@alum.mit.edu> <4ED6F2B9.3070407@alum.mit.edu> <57049AB2-9D6E-4D5A-84D5-ECFBB074EF2D@cs.columbia.edu> In-Reply-To: <57049AB2-9D6E-4D5A-84D5-ECFBB074EF2D@cs.columbia.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: Adam Roach , ECRIT Subject: Re: [Ecrit] PSAP Callback indication: Resrouce-Priority instead of eGRUU X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 07:44:26 -0000 Hi,=20 >(1) The UA requests (or automatically gets) a special emergency (temp) GRU= U; we can request this >in some way, probably using a Contact parameter. sip.priority=3Demergency = would probably work if=20 >we want to re-use something. > >(2) The UA uses that GRUU in the emergency call. There is no need to mark = it - the PSAP has no=20 >control over call handling at the emergency caller anyway, so it does the = same thing whether=20 >the UA knows about special handling or not. > >(3) The PSAP places a normal call-back. The proxy knows that this is a spe= cial GRUU that will >only be used for emergency calls, so it can do all bypass actions it wants= . Since the UA won't=20 >use this GRUU for "normal" calls, there is no abuse risk. That was exactly the original thinking behind the eGRUU. >> Are you assuming that the special temp gruu works because=20 >> the entity that assigns the gruu is also the one that is=20 >> responsible for all the special feature handling/disabling? >=20 > Yes, or at least has some relationship with that element. For=20 > a GRUU to work, the inbound proxy has to know about it, so=20 > this seems at least plausible. > >> That is a bit of a stretch, though it may be sufficient for IMS. In case of roaming, the callback might traverse a transit network, and the = visited network, so I guess the question is whether there is a need for suc= h networks to be aware of PSAP callbacks (e.g. when making interconnect poi= nt selection etc)?=20 NOTE: That question is not IMS specific :) > I suspect it would work in most simple enterprise=20 > environments where all calls, in and out, traverse the same proxy. At least in IMS (but I assume also in other environements) you can not make= such assumption. Again, in roaming scenarios, where the calling UA is in a visited network, = the emergency call might not traverse the home network, but the PSAP Callba= ck will. Regards, Christer