From adam@nostrum.com Tue Nov 6 07:53:51 2012 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 3B7D821F89B5; Tue, 6 Nov 2012 07:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0Q7BlKJoV70; Tue, 6 Nov 2012 07:53:50 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 14B3821F89A1; Tue, 6 Nov 2012 07:53:48 -0800 (PST) Received: from dhcp-5037.meeting.ietf.org (dhcp-5037.meeting.ietf.org [130.129.80.55]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA6FrfdN005493 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Nov 2012 09:53:47 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50993285.4020408@nostrum.com> Date: Tue, 06 Nov 2012 10:53:41 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: sipcore@ietf.org, ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.80.55 is authenticated by a trusted mechanism) Subject: [Ecrit] Establishing a "Priority" header field registry X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sipcore@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 15:53:51 -0000 [as an individual] The document draft-ietf-ecrit-psap-callback has identified a desire to add a new value to the "Priority" header field for SIP. While RFC 3261 clearly intended the values in this header field to be extensible, it did not define a registry of such values. To address this oversight, I have put together a small draft that defines such a registry and populates it with the values defined by RFC 3261. Because this is a correction to the core SIP specification, it is my belief that it falls within the charter of the SIPCORE working group. The only real open issue, in my opinion, is the IANA registration policy that should apply to new "Priority" header field values. To avoid blocking any work in ECRIT, we need to move this work (or something equivalent) forward very quickly. If you have any interest in the topic, please review and comment with some urgency. http://www.ietf.org/id/draft-roach-sipcore-priority-00.txt [The following request is being made in my WG chair role] As this is a SIPCORE matter, please discuss it on the SIPCORE list rather than the ECRIT list. Thanks! /a From brian.rosen@neustar.biz Tue Nov 6 10:22:26 2012 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 0F9D621F8A89; Tue, 6 Nov 2012 10:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsQo0HZWixd8; Tue, 6 Nov 2012 10:22:25 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id BE19A21F8A8A; Tue, 6 Nov 2012 10:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1352226460; x=1667576447; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=oo1fyiTw+bfADwJEEqvW1 FANUAoI6xzRyFIvBc+KiVs=; b=dbRiUfG4Ylv1OQYuYhkiYehpfem90kqu3AAzd rdplDisIRJFNs/UomzrYhAyVsx+4UnLJc5hmhaHPG7keaL/pQ== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.16362994; Tue, 06 Nov 2012 13:27:39 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Tue, 6 Nov 2012 13:22:21 -0500 From: "Rosen, Brian" To: "sipcore@ietf.org" Date: Tue, 6 Nov 2012 13:22:19 -0500 Thread-Topic: [sipcore] Establishing a "Priority" header field registry Thread-Index: Ac28S6kxIv8b1cKGTcmMUjtYiz7Z8Q== Message-ID: <7D126AA8-CCA4-4D88-82FA-796ADC0FFEB0@neustar.biz> References: <50993285.4020408@nostrum.com> In-Reply-To: <50993285.4020408@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: TRPIsVikd83p4UwBx0GENA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [sipcore] Establishing a "Priority" header field registry 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, 06 Nov 2012 18:22:26 -0000 I support this work. I agree with Christer about a registration template. = While it is obvious what is requested, I think it's better to have it. I am happy with "IETF Review" as the management policy. Brian On Nov 6, 2012, at 10:53 AM, Adam Roach wrote: > [as an individual] >=20 > The document draft-ietf-ecrit-psap-callback has identified a desire to ad= d a new value to the "Priority" header field for SIP. While RFC 3261 clearl= y intended the values in this header field to be extensible, it did not def= ine a registry of such values. >=20 > To address this oversight, I have put together a small draft that defines= such a registry and populates it with the values defined by RFC 3261. Beca= use this is a correction to the core SIP specification, it is my belief tha= t it falls within the charter of the SIPCORE working group. >=20 > The only real open issue, in my opinion, is the IANA registration policy = that should apply to new "Priority" header field values. To avoid blocking = any work in ECRIT, we need to move this work (or something equivalent) forw= ard very quickly. If you have any interest in the topic, please review and = comment with some urgency. >=20 > http://www.ietf.org/id/draft-roach-sipcore-priority-00.txt >=20 >=20 > [The following request is being made in my WG chair role] > As this is a SIPCORE matter, please discuss it on the SIPCORE list rather= than the ECRIT list. >=20 > Thanks! >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Tue Nov 6 20:05:22 2012 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 AA00E21F8A60; Tue, 6 Nov 2012 20:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.565 X-Spam-Level: X-Spam-Status: No, score=-110.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Re1DGoYAwIQ; Tue, 6 Nov 2012 20:05:22 -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 CBA4021F889D; Tue, 6 Nov 2012 20:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1903; q=dns/txt; s=iport; t=1352261122; x=1353470722; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=aItKMiivrTUKw4XfSAlTlY605Qscm1y6Rxve5sEo2Uc=; b=cX83ETqkW5edXH5s65+7CgqjR/Z+fExmKYk8RSk+kA5AjRyv2mXeFG4/ gHpTmnvmAxflMzKktE7p7U9teiSysDjs/3xjFH11Cu0PAf93eICFFyOyC mySsJ4B4rPIBwOO89yUv3pWAMuzW6OWv0EHeyLGg/PJytJa6GgRjNT/yv c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGTcmVCtJXG9/2dsb2JhbABEw2CBCIIeAQEBBAEBAQ8BJQI0CxAHBBgeEBkOMAYBEgkZh2gLmy+PYpA+jAOGVQOIWpt6gWuDDg X-IronPort-AV: E=Sophos;i="4.80,725,1344211200"; d="scan'208";a="139572912" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 07 Nov 2012 04:05:21 +0000 Received: from jmpolk-WS.cisco.com (rtp-vpn5-873.cisco.com [10.82.235.108]) (authenticated bits=0) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA745JVS004352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Nov 2012 04:05:21 GMT Message-Id: <201211070405.qA745JVS004352@rcdn-core2-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 06 Nov 2012 22:05:20 -0600 To: "Rosen, Brian" , "sipcore@ietf.org" From: James Polk In-Reply-To: <7D126AA8-CCA4-4D88-82FA-796ADC0FFEB0@neustar.biz> References: <50993285.4020408@nostrum.com> <7D126AA8-CCA4-4D88-82FA-796ADC0FFEB0@neustar.biz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] [sipcore] Establishing a "Priority" header field registry 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, 07 Nov 2012 04:05:22 -0000 I support this work James At 12:22 PM 11/6/2012, Rosen, Brian wrote: >I support this work. I agree with Christer about a registration >template. While it is obvious what is requested, I think it's >better to have it. > >I am happy with "IETF Review" as the management policy. > >Brian > >On Nov 6, 2012, at 10:53 AM, Adam Roach wrote: > > > [as an individual] > > > > The document draft-ietf-ecrit-psap-callback has identified a > desire to add a new value to the "Priority" header field for SIP. > While RFC 3261 clearly intended the values in this header field to > be extensible, it did not define a registry of such values. > > > > To address this oversight, I have put together a small draft that > defines such a registry and populates it with the values defined by > RFC 3261. Because this is a correction to the core SIP > specification, it is my belief that it falls within the charter of > the SIPCORE working group. > > > > The only real open issue, in my opinion, is the IANA registration > policy that should apply to new "Priority" header field values. To > avoid blocking any work in ECRIT, we need to move this work (or > something equivalent) forward very quickly. If you have any > interest in the topic, please review and comment with some urgency. > > > > http://www.ietf.org/id/draft-roach-sipcore-priority-00.txt > > > > > > [The following request is being made in my WG chair role] > > As this is a SIPCORE matter, please discuss it on the SIPCORE > list rather than the ECRIT list. > > > > Thanks! > > > > /a > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From jgunn6@csc.com Wed Nov 7 06:07:58 2012 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 B1B7821F875C; Wed, 7 Nov 2012 06:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z13fEEH50r0U; Wed, 7 Nov 2012 06:07:57 -0800 (PST) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by ietfa.amsl.com (Postfix) with ESMTP id 784CF21F8742; Wed, 7 Nov 2012 06:07:57 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-14.tower-85.messagelabs.com!1352297276!36749630!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 595 invoked from network); 7 Nov 2012 14:07:56 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-14.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Nov 2012 14:07:56 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA7E7sc0025836; Wed, 7 Nov 2012 09:07:54 -0500 In-Reply-To: <201211070405.qA745JVS004352@rcdn-core2-2.cisco.com> References: <50993285.4020408@nostrum.com> <7D126AA8-CCA4-4D88-82FA-796ADC0FFEB0@neustar.biz> <201211070405.qA745JVS004352@rcdn-core2-2.cisco.com> To: James Polk MIME-Version: 1.0 X-KeepSent: B909FEAE:A277906E-85257AAF:004D90C7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Wed, 7 Nov 2012 09:07:50 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 11/07/2012 09:03:22 AM, Serialize complete at 11/07/2012 09:03:22 AM Content-Type: multipart/alternative; boundary="=_alternative 004DA15685257AAF_=" Cc: "Rosen, Brian" , "sipcore@ietf.org" , "ecrit@ietf.org" , ecrit-bounces@ietf.org Subject: Re: [Ecrit] [sipcore] Establishing a "Priority" header field registry 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, 07 Nov 2012 14:07:58 -0000 This is a multipart message in MIME format. --=_alternative 004DA15685257AAF_= Content-Type: text/plain; charset="US-ASCII" I also support this work 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: James Polk To: "Rosen, Brian" , "sipcore@ietf.org" Cc: "ecrit@ietf.org" Date: 11/06/2012 11:05 PM Subject: Re: [Ecrit] [sipcore] Establishing a "Priority" header field registry Sent by: ecrit-bounces@ietf.org I support this work James At 12:22 PM 11/6/2012, Rosen, Brian wrote: >I support this work. I agree with Christer about a registration >template. While it is obvious what is requested, I think it's >better to have it. > >I am happy with "IETF Review" as the management policy. > >Brian > >On Nov 6, 2012, at 10:53 AM, Adam Roach wrote: > > > [as an individual] > > > > The document draft-ietf-ecrit-psap-callback has identified a > desire to add a new value to the "Priority" header field for SIP. > While RFC 3261 clearly intended the values in this header field to > be extensible, it did not define a registry of such values. > > > > To address this oversight, I have put together a small draft that > defines such a registry and populates it with the values defined by > RFC 3261. Because this is a correction to the core SIP > specification, it is my belief that it falls within the charter of > the SIPCORE working group. > > > > The only real open issue, in my opinion, is the IANA registration > policy that should apply to new "Priority" header field values. To > avoid blocking any work in ECRIT, we need to move this work (or > something equivalent) forward very quickly. If you have any > interest in the topic, please review and comment with some urgency. > > > > http://www.ietf.org/id/draft-roach-sipcore-priority-00.txt > > > > > > [The following request is being made in my WG chair role] > > As this is a SIPCORE matter, please discuss it on the SIPCORE > list rather than the ECRIT list. > > > > Thanks! > > > > /a > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >_______________________________________________ >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 004DA15685257AAF_= Content-Type: text/html; charset="US-ASCII" I also support this work
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:        James Polk <jmpolk@cisco.com>
To:        "Rosen, Brian" <Brian.Rosen@neustar.biz>, "sipcore@ietf.org" <sipcore@ietf.org>
Cc:        "ecrit@ietf.org" <ecrit@ietf.org>
Date:        11/06/2012 11:05 PM
Subject:        Re: [Ecrit] [sipcore] Establishing a "Priority" header field registry
Sent by:        ecrit-bounces@ietf.org



I support this work

James

At 12:22 PM 11/6/2012, Rosen, Brian wrote:
>I support this work.  I agree with Christer about a registration
>template.  While it is obvious what is requested, I think it's
>better to have it.
>
>I am happy with "IETF Review" as the management policy.
>
>Brian
>
>On Nov 6, 2012, at 10:53 AM, Adam Roach <adam@nostrum.com> wrote:
>
> > [as an individual]
> >
> > The document draft-ietf-ecrit-psap-callback has identified a
> desire to add a new value to the "Priority" header field for SIP.
> While RFC 3261 clearly intended the values in this header field to
> be extensible, it did not define a registry of such values.
> >
> > To address this oversight, I have put together a small draft that
> defines such a registry and populates it with the values defined by
> RFC 3261. Because this is a correction to the core SIP
> specification, it is my belief that it falls within the charter of
> the SIPCORE working group.
> >
> > The only real open issue, in my opinion, is the IANA registration
> policy that should apply to new "Priority" header field values. To
> avoid blocking any work in ECRIT, we need to move this work (or
> something equivalent) forward very quickly. If you have any
> interest in the topic, please review and comment with some urgency.
> >
> > http://www.ietf.org/id/draft-roach-sipcore-priority-00.txt
> >
> >
> > [The following request is being made in my WG chair role]
> > As this is a SIPCORE matter, please discuss it on the SIPCORE
> list rather than the ECRIT list.
> >
> > Thanks!
> >
> > /a
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://www.ietf.org/mailman/listinfo/sipcore
>
>_______________________________________________
>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 004DA15685257AAF_=-- From rg+ietf@qualcomm.com Wed Nov 7 14:57:30 2012 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 B1A7721F8582 for ; Wed, 7 Nov 2012 14:57:30 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -100.918 X-Spam-Level: X-Spam-Status: No, score=-100.918 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, SARE_RAND_1=2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibBJLx8dXYLk for ; Wed, 7 Nov 2012 14:57:26 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id B669321F853B for ; Wed, 7 Nov 2012 14:57:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=@qualcomm.com; q=dns/txt; s=qcdkim; t=1352327640; x=1383863640; h=message-id:x-mailer:date:to:from:subject:content-type; bh=7wywE0NgmQjbwyd1nuY62i1GM8dG2+lMpkMzuhtQepU=; b=l/wkuA9nYOMsSxYvWl81FD+wYIlf71JIpy4EzQzMuaDLlEMtyObDhyYY LjimWGX9pg5EmDpCUipfNszVr4qyFlsRehLRBhGG1sYxuUYsLsmVIFaJc /sD8pXLQctN0EpMuVFszpqCRpDOZVfS2MogyaP7jZBeiBMCNAyTWHfTd3 M=; X-IronPort-AV: E=McAfee;i="5400,1158,6889"; a="5036215" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 07 Nov 2012 14:34:00 -0800 X-IronPort-AV: E=Sophos;i="4.80,732,1344236400"; d="scan'208";a="421571236" Received: from warlock.qualcomm.com ([129.46.50.49]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Nov 2012 14:57:26 -0800 Received: from dhcp-4049.meeting.ietf.org (vpn-10-50-0-37.qualcomm.com [10.50.0.37]) by warlock.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id qA7MvOgX003479; Wed, 7 Nov 2012 14:57:25 -0800 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Wed, 7 Nov 2012 14:57:23 -0800 To: From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Mailman-Approved-At: Wed, 07 Nov 2012 14:59:40 -0800 Subject: Re: [Ecrit] Fwd: I-D Action: draft-ietf-ecrit-additional-data-05.txt 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, 07 Nov 2012 22:57:30 -0000 [[ resending from a subscribed email address ]] A few comments: (1) In Section 1, there is confusion over how many types of data exist and which are discussed/described/specified here, varying between three and four. I think this stems from an incomplete deletion of the category for PSAP data. (2) The text in Sections 1 and 3 is confusing and, to me, fuzzy on "the data structure," the blocks, the categories, the MIME types, and how they are used and identified. Consider the text: 'data is defined as a series of "blocks" that represent a class of information' and 'an extensible set of these types constitute the data structure' and 'The data structure contains an element which itself is a URI that has device or service dependent data' -- I think this is confusing and unclear as to what is a block, a class, and 'the' data structure, and the role of the URI field within these (if there still is such). My understanding from the discussions previously is that we have a set of MIME types, each of which is a data block belonging to one of the categories (call, caller, location). Any set of blocks can be included by reference or by value. For each block that is included by value, there is a URL pointing to it in a Call-Info header, with a tag indicating which block is being pointed at. We discussed using a sub-part to 'purpose' or other mechanisms to indicate which block is being pointed at (e.g., 'purpose=emergencyCallData.addDataProviderInfo'). The idea is that a system can examine the headers and determine if there are any data blocks that it is interested in, and if so, locate them. I'm not sure if we discussed if this extends to blocks included by reference; the draft says no, but I can see a good case for doing so (e.g., so an entity can know if it wants the data before it fetches it). To make things more clear, I think we need text explaining how to send data, for both the HTTPS and CID cases. We probably also need a few more examples showing multiple data blocks, especially some added by different entities. (3) I also think we agreed in email and at the Vancouver meeting to indicate in the MIME type that the data is for emergency calls, e.g., At 2:21 PM -0700 7/31/12, I wrote: > 'application/emergencyCall-addDataProviderInfo+xml' > 'application/emergencyCall-addCallSvcInfo+xml' > 'application/emergencyCall-addDataDevInfo+xml' > 'application/emergencyCall-addCallSub+xml' Or something along these lines. This applies to the individual sections defining these blocks and Section 13.1.3 and Section 13.4. (4) Section 3 is titled "Call-Info Specification" and so would seem to be about the Call-Info header field, but it starts out saying "The Additional Data about a Call" and then discussing this class of data. Is the intent to be limited to this class, or is the intent to be a mechanism for any of the three (or four) classes of data? I think this is another case where the document is really hard to follow. (5) Sections 4-8 seem to each discuss one of the three (or four) classes of data plus the 'comment' field, with subsections for each data block. If so, it would be helpful to say this somewhere, perhaps at the end of Section 3, assuming that section is about how to use the Call-Info header to point to blocks of those types. Or, what may be far more clear, add a new section between Sections 3 and 4 that gives a brief overview of each type/class/category of data and the MIME types for the blocks within that category. Then, the sections that follow which give details will make more sense, having some context. I think this will make the document flow better and easier for the reader to follow (the sections can then be thought of as explaining the overall system, then the details of the Call-Info header use, then an overview of the different blocks, then the details of each block; examples could then be placed after all this). (6) In 13.1.3, what is the job of the expert reviewer, given that Specification Required is the rule? I think probably only Specification Required is needed here. (7) Minor editorial in Section 1: change "would provide" to "provides" (8) Typo in Section 1: "services providers" instead of "service providers" (9) Typo in Section 3: "the CID URL points one" should be "the CID URL points to one" (10) Some of the edits sent in my review in November 2011, resent in July 2012, were skipped, and I'm not sure if this was deliberate or an oversight. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- #Random Tag -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- #Random Tag -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Rocky's Lemma of Innovation Prevention: Unless the results are known in advance, funding agencies will reject the proposal. From shida@ntt-at.com Wed Nov 7 23:25:51 2012 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 89EB721F88F8 for ; Wed, 7 Nov 2012 23:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPxXHaG0hA6Y for ; Wed, 7 Nov 2012 23:25:51 -0800 (PST) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id EEA2021F88EF for ; Wed, 7 Nov 2012 23:25:50 -0800 (PST) Received: from [216.138.103.10] (port=61251 helo=[10.71.15.125]) by gator465.hostgator.com with esmtpa (Exim 4.80) (envelope-from ) id 1TWMUo-00022F-60 for ecrit@ietf.org; Thu, 08 Nov 2012 01:25:50 -0600 From: Shida Schubert Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_76B70ED7-FAC5-4637-8A63-56F6C2C6F59D" Date: Thu, 8 Nov 2012 16:25:48 +0900 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B016BF0@ESESSMB209.ericsson.se> To: ecrit@ietf.org References: <7594FB04B1934943A5C02806D1A2204B016BF0@ESESSMB209.ericsson.se> Message-Id: <069F35AF-97A6-409F-AC1F-40C5DA8B71FE@ntt-at.com> X-Mailer: Apple Mail (2.1283) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.71.15.125]) [216.138.103.10]:61251 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Subject: [Ecrit] 'emergency-callback' instead of '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: Thu, 08 Nov 2012 07:25:51 -0000 --Apple-Mail=_76B70ED7-FAC5-4637-8A63-56F6C2C6F59D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Just found out two days ago that we may need to implement=20 what ever that comes out of this..=20 "psap" seems to be a very regional specific name, it definitely=20 doesn't mean anything in Japan and probably in many other=20 countries in the world..=20 Considering this may need to be implemented in Countries where=20 "PSAP" has no meaning, can we come up with more generic name=20 that is acceptable around the world like "emergency-callback"?? Regards Shida On Oct 16, 2012, at 8:57 PM, Christer Holmberg wrote: > Hi, > =20 > I drafted some initial text regarding the new SIP Priority header = field =92psap-callback=92 value. > =20 > Feel free to comment :) > =20 > ----------------------- > =20 > X. PSAP Callback Indicator. > =20 > X.1 General > =20 > This section defines a new header field value, "psap-callback", for = the SIP Priority header field [RFC3261]. > The value is used by a SIP entity to inform downstream entities that = the request is associated with a PSAP callback > SIP session. > =20 > x.2 Usage > =20 > SIP entities that receive the header field value within an initial = request for a SIP session, or within a standalone > SIP request, can, depending on local policies, apply PSAP callback = specific procedures for the session or request. > =20 > PSAP callback specific procedures might be applied both by network = entities and by the callee. The specific procedures > are outside the scope of this document, but typically include = bypassing services and barring procedures. > =20 > x.3 Syntax > =20 > x.3.1 General > =20 > This Section defines the ABNF for the new SIP Priority header field = value, "psap-callback". > =20 > x.3.2 ABNF > =20 > priority-value /=3D "psap-callback" > =20 > ----------------------- > =20 > Regards, > =20 > Christer > =20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --Apple-Mail=_76B70ED7-FAC5-4637-8A63-56F6C2C6F59D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

 Just found out two days = ago that we may need to implement 
what ever that comes = out of this.. 

 "psap" seems to be a = very regional specific name, it definitely 
doesn't mean = anything in Japan and probably in many = other 
countries in the = world.. 

 Considering this may need = to be implemented in Countries where 
"PSAP" has no = meaning, can we come up with more generic name 
that is = acceptable around the world like = "emergency-callback"??

  = Regards
   Shida

On Oct 16, 2012, = at 8:57 PM, Christer Holmberg wrote:

Hi,
 
I drafted some initial text = regarding the new SIP Priority header field =92psap-callback=92 = value.
 
Feel free to = comment :)
 
-----------------------
 
 
X.1          = General
 
This section defines a new header field value, = "psap-callback", for the SIP Priority header field = [RFC3261].
The value is used by a SIP entity to = inform downstream entities that the request is associated with a PSAP = callback
SIP session.
 
 
SIP entities that = receive the header field value within an initial request for a SIP = session, or within a standalone
SIP request, can, = depending on local policies, apply PSAP callback specific procedures for = the session or request.
 
PSAP callback specific procedures might be applied both by = network entities and by the callee. The specific = procedures
are outside the scope of this = document, but typically include bypassing services and barring = procedures.
 
x.3          = Syntax
 
x.3.1  =     General
   This Section defines = the ABNF for the new SIP Priority header field value, = "psap-callback".
 
x.3.2      = ABNF
 
 
 
Regards,
 
Christer
X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 08 Nov 2012 13:40:39 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/9#comment:1 Message-ID: <080.e42df35e6b28147e8d23f2d468c4e7bb@trac.tools.ietf.org> References: <065.c0b237b6a3acfb6124e1635e9c46707f@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <065.c0b237b6a3acfb6124e1635e9c46707f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: ecrit@ietf.org Subject: Re: [Ecrit] [ecrit] #9: Definition of Trustworthy X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:40:52 -0000 #9: Definition of Trustworthy Comment (by bernard_aboba@…): In -04, there is modified text relating to the importance of audit: In Section 1: It should be kept in mind that issues of location trust and attribution are closely linked. In situations where tracing of an emergency call back to the originator is more difficult, experience has shown that the frequency of nuisance calls can rise dramatically. For example, where emergency calls have been allowed from handsets lacking a SIM card, or where ownership of the SIM card cannot be determined, the frequency of nuisance calls has often been unacceptably high [TASMANIA][UK][SA]. Conversely, where the ability exists enable an investigator to determine the originator of a prank emergency call after the fact, the trustworthiness of location is likely to improve, even without the introduction of measures to limit location spoofing. Under a court order, an investigator can have access to additional information beyond the messages conveyed in the emergency call. For example, in such a situation, audit logs will often be made available and in addition, information relating to the owner of an unlinked pseudonym could be provided to investigators, enabling them to unravel the chain of events that lead to the attack. -- ----------------------------------+------------------------------ Reporter: bernard_aboba@… | Owner: bernard_aboba@… Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | ----------------------------------+------------------------------ Ticket URL: ecrit From trac+ecrit@trac.tools.ietf.org Thu Nov 8 05:46:23 2012 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 63A0F21F8B71 for ; Thu, 8 Nov 2012 05:46:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nOb6PlNueWg for ; Thu, 8 Nov 2012 05:46:21 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id F23CA21F8AEF for ; Thu, 8 Nov 2012 05:46:14 -0800 (PST) Received: from localhost ([127.0.0.1]:53339 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWSQl-0008PP-HJ; Thu, 08 Nov 2012 14:46:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "ecrit issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: ecrit Date: Thu, 08 Nov 2012 13:46:03 -0000 X-URL: http://tools.ietf.org/ecrit/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/ecrit/trac/ticket/10 Message-ID: <065.1b52482104271a8066bcf9a9f5f1b8f3@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, ecrit@ietf.org X-SA-Exim-Mail-From: trac+ecrit@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: ecrit@ietf.org Subject: [Ecrit] [ecrit] #10: Section 5 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Reply-To: ecrit@ietf.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 13:46:23 -0000 #10: Section 5 This section currently includes a variety of operational considerations whose relationship to the solutions is unclear. Please consider re- organizing the portion of the material that relates to the solutions into Section 4, with the rest going either into security considerations or the bit bucket. -- ----------------------------------+----------------------------- Reporter: bernard_aboba@… | Owner: bernard_aboba@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: trustworthy-location | Version: 1.0 Severity: Active WG Document | Keywords: ----------------------------------+----------------------------- Ticket URL: ecrit From jmpolk@cisco.com Thu Nov 8 07:31:44 2012 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 1784121F8A78 for ; Thu, 8 Nov 2012 07:31:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.572 X-Spam-Level: X-Spam-Status: No, score=-110.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3f4YVUeNssfF for ; Thu, 8 Nov 2012 07:31:41 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 78D7021F859A for ; Thu, 8 Nov 2012 07:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3448; q=dns/txt; s=iport; t=1352388699; x=1353598299; h=message-id:date:to:from:subject:in-reply-to:references: mime-version; bh=C19o9J9ZpZ2DTwoANs1tYsUzwNe8x2vdQ8YbtEKaiXE=; b=m7kA9K20RMxItJVr17lfp1mXEFH+hV+pt1DSsDi4b01S0jCIjDGBlH8m JvS0J2ZqvNJJQclLz7erfUh2dPi+TEZXnJGsEQv5eF0XORsoG9FqMcLHM 176Hr9h2JibzuUBa9XdkrjuEAcZPZ53Z/M+Du2NW0Cxubcvu80ahkCRTg E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABvQm1CtJXG9/2dsb2JhbABEw2uBCIIeAQEBAwEBAQEPASUCNBALBwQYHgkHGQ4fEQYBEiKHYgYLm3igLwSMEoZHA4haiW+SCoFrgw4 X-IronPort-AV: E=Sophos;i="4.80,738,1344211200"; d="scan'208";a="140177508" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 08 Nov 2012 15:31:25 +0000 Received: from jmpolk-WS.cisco.com (rtp-vpn3-666.cisco.com [10.82.218.157]) (authenticated bits=0) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA8FVOvc019009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2012 15:31:25 GMT Message-Id: <201211081531.qA8FVOvc019009@rcdn-core2-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 08 Nov 2012 09:31:24 -0600 To: Shida Schubert , From: James Polk In-Reply-To: <069F35AF-97A6-409F-AC1F-40C5DA8B71FE@ntt-at.com> References: <7594FB04B1934943A5C02806D1A2204B016BF0@ESESSMB209.ericsson.se> <069F35AF-97A6-409F-AC1F-40C5DA8B71FE@ntt-at.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Subject: Re: [Ecrit] 'emergency-callback' instead of '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: Thu, 08 Nov 2012 15:31:44 -0000 While I appreciate your intent, I need to fall back to the idea that there are many many different types of emergencies, and many of them are based on the perspective of the person having the emergency, and not by how a local, regional or national determines what is and what is not an emergency. While I understand that 'psap' might not be know, 'emergency' or 'emergency-' is just too broad and can be either misused or misunderstood. For example, is the fact that I really need to make a point to someone who just hung up on my fall into the 'emergency-callback' realm we're specifying in ECRIT? I don't believe so, especially if that someone is my ex-spouse, who has a restraining order against me (she doesn't, but I'm just using that as an example. I could use a ex-boyfriend or ex-girlfriend example, or a (unreasonable) daughter/son example, or a boss/subordinate example, or even a telemarketer example that everyone probably can relate to. I mean, we're talking about turning off DNR and call forward services that I probably otherwise want to have enabled in nearly or every case except the 911/112 case. my 2.25 cents (before taxation - which is coming soon) James At 01:25 AM 11/8/2012, Shida Schubert wrote: > Just found out two days ago that we may need to implement >what ever that comes out of this.. > > "psap" seems to be a very regional specific name, it definitely >doesn't mean anything in Japan and probably in many other >countries in the world.. > > Considering this may need to be implemented in Countries where >"PSAP" has no meaning, can we come up with more generic name >that is acceptable around the world like "emergency-callback"?? > > Regards > Shida > >On Oct 16, 2012, at 8:57 PM, Christer Holmberg wrote: > >>Hi, >> >>I drafted some initial text regarding the new SIP Priority header >>field 'psap-callback' value. >> >>Feel free to comment :) >> >>----------------------- >> >>X. PSAP Callback Indicator. >> >>X.1 General >> >>This section defines a new header field value, "psap-callback", for >>the SIP Priority header field [RFC3261]. >>The value is used by a SIP entity to inform downstream entities >>that the request is associated with a PSAP callback >>SIP session. >> >>x.2 Usage >> >>SIP entities that receive the header field value within an initial >>request for a SIP session, or within a standalone >>SIP request, can, depending on local policies, apply PSAP callback >>specific procedures for the session or request. >> >>PSAP callback specific procedures might be applied both by network >>entities and by the callee. The specific procedures >>are outside the scope of this document, but typically include >>bypassing services and barring procedures. >> >>x.3 Syntax >> >>x.3.1 General >> >> This Section defines the ABNF for the new SIP Priority header >> field value, "psap-callback". >> >>x.3.2 ABNF >> >>priority-value /= "psap-callback" >> >>----------------------- >> >>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 From James.Winterbottom@commscope.com Thu Nov 8 07:37:58 2012 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 DA60C21F851C for ; Thu, 8 Nov 2012 07:37:58 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJLZKl4y1p2y for ; Thu, 8 Nov 2012 07:37:58 -0800 (PST) Received: from cdcsmgw02.commscope.com (cdcsmgw02.commscope.com [198.135.207.233]) by ietfa.amsl.com (Postfix) with ESMTP id 1906321F8450 for ; Thu, 8 Nov 2012 07:37:58 -0800 (PST) X-AuditID: 0a0404e9-b7f6c6d00000085c-a7-509bd1d5d731 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Messaging Gateway) with SMTP id F5.57.02140.5D1DB905; Thu, 8 Nov 2012 09:37:57 -0600 (CST) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.279.5; Thu, 8 Nov 2012 09:37:56 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Thu, 8 Nov 2012 23:37:54 +0800 From: "Winterbottom, James" To: James Polk , Shida Schubert , "ecrit@ietf.org" Date: Thu, 8 Nov 2012 23:37:51 +0800 Thread-Topic: [Ecrit] 'emergency-callback' instead of 'psap-callback' ?? Thread-Index: Ac29xiuVd40jfPKWTzuOoo09EvVROQAAGqag Message-ID: <5A55A45AE77F5941B18E5457ECAC818801213316F21C@SISPE7MB1.commscope.com> References: <7594FB04B1934943A5C02806D1A2204B016BF0@ESESSMB209.ericsson.se> <069F35AF-97A6-409F-AC1F-40C5DA8B71FE@ntt-at.com> <201211081531.qA8FVOvc019009@rcdn-core2-2.cisco.com> In-Reply-To: <201211081531.qA8FVOvc019009@rcdn-core2-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: H4sIAAAAAAAAA+NgFjrIKsWRmVeSWpSXmKPExsXCFSaSpnv14uwAg61LJSwaFz1ltdixptDi 96F5rA7MHlN+b2T1WLLkJ5NHz6XZjAHMUVw2Kak5mWWpRfp2CVwZP97uZy7Yrlixf59HA2Of dBcjJ4eEgInEx+dXWCFsMYkL99azdTFycQgJ7GaUOD1jO5SzHshp38gC4axllHi+ciIzSAub gJ3E4fU3wGwRgUyJey0vwWwWARWJDy+XsoDYwgLuEq9PN7NA1HhIdC97wAphG0ns/7kfLM4r ECQx/cIuqAXbGCX65xwGcjg4OAUcJQ7crwWpYQQ67/upNUwgNrOAuMStJ/OZIM4WkFiy5zwz hC0q8fLxP1aIelGJO+3rGSHqdSQW7P7EBmFrSyxb+JoZYq+gxMmZT8BuEBLQlWja+ZV1AqP4 LCQrZiFpn4WkfRaS9gWMLKsYxZNTkotz08sNjPSS83Nzi5PzC1JBrE2MoHhjYXm5g/HsBu1D jAIcjEo8vAIsswOEWBPLiitzDzFKcjApifKKXQAK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuEN OgqU401JrKxKLcqHSWlwcAicfnL/FKMUS15+XqqSBO8DkBGCRanpqRVpmTnAZANTysTBCTKK B2jUO5Aa3uKCxNzizHSI/ClGVY7GnkUPGYXABkmJ8xafByoSACnKKM2Dm/OKURzoeGHe1SAj eIDpEm7CK6DhTEDDi6/NABlekoiQkmpgzEr67e/WH3dHu7H1oEJ79TK92wfKv9T/rfyXsr5e 9+TUqbKuf554+TwIPiB547vv2QsvZ96aLJf+5ZzPDs/A939NJqzZ5JYs011dpVM4m4vnze3+ LxLP1yVN2+Zt6vdA5evfSZP5tLd/mG78oe7EjYa9sxY4S1wvn8uyIWl3gPmlPaK7z6s+XKnE UpyRaKjFXFScCACUDjTSVAMAAA== Subject: Re: [Ecrit] 'emergency-callback' instead of '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: Thu, 08 Nov 2012 15:37:59 -0000 I don't understand how having psap-callback addresses the examples below si= nce if the ex can mark her call as emergency-callback she can just as easil= y mark it as psap-callback. The term PSAP certainly isn't universal though its understanding is certain= ly growing. I think that Shida's proposal is perfectly reasonable and would be my prefe= rred option. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of J= ames Polk Sent: Friday, 9 November 2012 2:31 AM To: Shida Schubert; ecrit@ietf.org Subject: Re: [Ecrit] 'emergency-callback' instead of 'psap-callback' ?? While I appreciate your intent, I need to fall back to the idea that there = are many many different types of emergencies, and many of them are based on= the perspective of the person having the emergency, and not by how a local= , regional or national determines what is and what is not an emergency. While I understand that 'psap' might not be know, 'emergency' or 'emergency= -' is just too broad and can be either misused or misunderstood. For example, is the fact that I really need to make a point to someone who = just hung up on my fall into the 'emergency-callback'=20 realm we're specifying in ECRIT? I don't believe so, especially if that som= eone is my ex-spouse, who has a restraining order against me (she doesn't, = but I'm just using that as an example. I could use a ex-boyfriend or ex-girlfriend example, or a (unreasonable) daughter/son example, or a boss/subordinate example, or even= a telemarketer example that everyone probably can relate to. I mean, we're talking about turning off DNR and call forward services that = I probably otherwise want to have enabled in nearly or every case except th= e 911/112 case. my 2.25 cents (before taxation - which is coming soon) James At 01:25 AM 11/8/2012, Shida Schubert wrote: > Just found out two days ago that we may need to implement what ever=20 >that comes out of this.. > > "psap" seems to be a very regional specific name, it definitely=20 >doesn't mean anything in Japan and probably in many other countries in=20 >the world.. > > Considering this may need to be implemented in Countries where "PSAP"=20 >has no meaning, can we come up with more generic name that is=20 >acceptable around the world like "emergency-callback"?? > > Regards > Shida > >On Oct 16, 2012, at 8:57 PM, Christer Holmberg wrote: > >>Hi, >> >>I drafted some initial text regarding the new SIP Priority header=20 >>field 'psap-callback' value. >> >>Feel free to comment :) >> >>----------------------- >> >>X. PSAP Callback Indicator. >> >>X.1 General >> >>This section defines a new header field value, "psap-callback", for=20 >>the SIP Priority header field [RFC3261]. >>The value is used by a SIP entity to inform downstream entities that=20 >>the request is associated with a PSAP callback SIP session. >> >>x.2 Usage >> >>SIP entities that receive the header field value within an initial=20 >>request for a SIP session, or within a standalone SIP request, can,=20 >>depending on local policies, apply PSAP callback specific procedures=20 >>for the session or request. >> >>PSAP callback specific procedures might be applied both by network=20 >>entities and by the callee. The specific procedures are outside the=20 >>scope of this document, but typically include bypassing services and=20 >>barring procedures. >> >>x.3 Syntax >> >>x.3.1 General >> >> This Section defines the ABNF for the new SIP Priority header=20 >> field value, "psap-callback". >> >>x.3.2 ABNF >> >>priority-value /=3D "psap-callback" >> >>----------------------- >> >>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 christer.holmberg@ericsson.com Thu Nov 8 08:01:55 2012 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 17FE521F8B73 for ; Thu, 8 Nov 2012 08:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dagb4sZfQAtn for ; Thu, 8 Nov 2012 08:01:54 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BDAF621F8B6B for ; Thu, 8 Nov 2012 08:01:49 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-22-509bd76cff10 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EF.AB.26143.C67DB905; Thu, 8 Nov 2012 17:01:48 +0100 (CET) Received: from ESESSHC009.ericsson.se (153.88.183.45) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 8 Nov 2012 17:01:48 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 17:01:47 +0100 From: Christer Holmberg To: "'Winterbottom, James'" , James Polk , Shida Schubert , "ecrit@ietf.org" Thread-Topic: [Ecrit] 'emergency-callback' instead of 'psap-callback' ?? Thread-Index: AQHNvYJggpoi863V+E6P6dvXNH9g5pfgAHAAgAABzYCAABawQA== Date: Thu, 8 Nov 2012 16:01:48 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B029832@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B016BF0@ESESSMB209.ericsson.se> <069F35AF-97A6-409F-AC1F-40C5DA8B71FE@ntt-at.com> <201211081531.qA8FVOvc019009@rcdn-core2-2.cisco.com> <5A55A45AE77F5941B18E5457ECAC818801213316F21C@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC818801213316F21C@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjW7O9dkBBp1vNCwaFz1ltbh+Tdti x5pCi9+H5rE6sHhM+b2R1ePV2jvsHkuW/GTy6Lk0mzGAJYrLJiU1J7MstUjfLoEr49rRm+wF j1Ur3j78xdzA+Fyui5GTQ0LAROLUvXdsELaYxIV764FsLg4hgZOMEpO3vYFydjBK3Oi+zw5S JSSwmFFix87cLkYODjYBC4nuf9ogNSICyxklPk1qYASpERZwl3h9upkFxBYR8JDoXvaAFcJ2 ktj+ZTVYDYuAisTyrbfANvMKeEv8mP2cBWL+f6BBB21AbE6BYImm2bPB6hmBrvt+ag0TiM0s IC5x68l8JoirBSSW7DnPDGGLSrx8/I8VwlaU+PhqHyNEvY7Egt2f2CBsbYllC18zQ+wVlDg5 8wnUXm2JlsUT2Ccwis9CsmIWkvZZSNpnIWlfwMiyipE9NzEzJ73caBMjMMIObvmtuoPxzjmR Q4zSHCxK4rzWW/f4CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamAMesu2qLlFXHgaP3e40Ub+ 17s/Tpmw+va8tTznL8sfv5Pu0n58+mTPo6G/fYK+JNxlcT6dKbPHzPilxo2jsxKNuNo/qp5K dttU/VCloscncn7B9DO/iu5r7v/3qHPfbpfWVdIPdlbWvvN30v2s0nX9cz3DFesp4n1pSrIn j0R8FNCq9666sThaiaU4I9FQi7moOBEAN3JZYX4CAAA= Subject: Re: [Ecrit] 'emergency-callback' instead of '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: Thu, 08 Nov 2012 16:01:55 -0000 Hi, Some time ago, there was a concensus call for the value on the list, and "p= sap-callback" was chosen.=20 Regards, Christer=20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of W= interbottom, James Sent: 8. marraskuuta 2012 17:38 To: James Polk; Shida Schubert; ecrit@ietf.org Subject: Re: [Ecrit] 'emergency-callback' instead of 'psap-callback' ?? I don't understand how having psap-callback addresses the examples below si= nce if the ex can mark her call as emergency-callback she can just as easil= y mark it as psap-callback. The term PSAP certainly isn't universal though its understanding is certain= ly growing. I think that Shida's proposal is perfectly reasonable and would be my prefe= rred option. Cheers James -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of J= ames Polk Sent: Friday, 9 November 2012 2:31 AM To: Shida Schubert; ecrit@ietf.org Subject: Re: [Ecrit] 'emergency-callback' instead of 'psap-callback' ?? While I appreciate your intent, I need to fall back to the idea that there = are many many different types of emergencies, and many of them are based on= the perspective of the person having the emergency, and not by how a local= , regional or national determines what is and what is not an emergency. While I understand that 'psap' might not be know, 'emergency' or 'emergency= -' is just too broad and can be either misused or misunderstood. For example, is the fact that I really need to make a point to someone who = just hung up on my fall into the 'emergency-callback'=20 realm we're specifying in ECRIT? I don't believe so, especially if that som= eone is my ex-spouse, who has a restraining order against me (she doesn't, = but I'm just using that as an example. I could use a ex-boyfriend or ex-girlfriend example, or a (unreasonable) daughter/son example, or a boss/subordinate example, or even= a telemarketer example that everyone probably can relate to. I mean, we're talking about turning off DNR and call forward services that = I probably otherwise want to have enabled in nearly or every case except th= e 911/112 case. my 2.25 cents (before taxation - which is coming soon) James At 01:25 AM 11/8/2012, Shida Schubert wrote: > Just found out two days ago that we may need to implement what ever=20 >that comes out of this.. > > "psap" seems to be a very regional specific name, it definitely=20 >doesn't mean anything in Japan and probably in many other countries in=20 >the world.. > > Considering this may need to be implemented in Countries where "PSAP"=20 >has no meaning, can we come up with more generic name that is=20 >acceptable around the world like "emergency-callback"?? > > Regards > Shida > >On Oct 16, 2012, at 8:57 PM, Christer Holmberg wrote: > >>Hi, >> >>I drafted some initial text regarding the new SIP Priority header=20 >>field 'psap-callback' value. >> >>Feel free to comment :) >> >>----------------------- >> >>X. PSAP Callback Indicator. >> >>X.1 General >> >>This section defines a new header field value, "psap-callback", for=20 >>the SIP Priority header field [RFC3261]. >>The value is used by a SIP entity to inform downstream entities that=20 >>the request is associated with a PSAP callback SIP session. >> >>x.2 Usage >> >>SIP entities that receive the header field value within an initial=20 >>request for a SIP session, or within a standalone SIP request, can,=20 >>depending on local policies, apply PSAP callback specific procedures=20 >>for the session or request. >> >>PSAP callback specific procedures might be applied both by network=20 >>entities and by the callee. The specific procedures are outside the=20 >>scope of this document, but typically include bypassing services and=20 >>barring procedures. >> >>x.3 Syntax >> >>x.3.1 General >> >> This Section defines the ABNF for the new SIP Priority header=20 >> field value, "psap-callback". >> >>x.3.2 ABNF >> >>priority-value /=3D "psap-callback" >> >>----------------------- >> >>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 keith.drage@alcatel-lucent.com Thu Nov 8 08:08:06 2012 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 DA71021F8B77 for ; Thu, 8 Nov 2012 08:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.982 X-Spam-Level: X-Spam-Status: No, score=-109.982 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiA74Uhybq6a for ; Thu, 8 Nov 2012 08:08:01 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 03B2921F8B9D for ; Thu, 8 Nov 2012 08:07:18 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA8G6ElE008955 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Nov 2012 17:07:12 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 8 Nov 2012 17:06:29 +0100 From: "DRAGE, Keith (Keith)" To: "Winterbottom, James" , James Polk , Shida Schubert , "ecrit@ietf.org" Date: Thu, 8 Nov 2012 17:06:27 +0100 Thread-Topic: [Ecrit] 'emergency-callback' instead of 'psap-callback' ?? Thread-Index: Ac29xiuVd40jfPKWTzuOoo09EvVROQAAGqagAAEK4OA= Message-ID: References: <7594FB04B1934943A5C02806D1A2204B016BF0@ESESSMB209.ericsson.se> <069F35AF-97A6-409F-AC1F-40C5DA8B71FE@ntt-at.com> <201211081531.qA8FVOvc019009@rcdn-core2-2.cisco.com> <5A55A45AE77F5941B18E5457ECAC818801213316F21C@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC818801213316F21C@SISPE7MB1.commscope.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.83 Subject: Re: [Ecrit] 'emergency-callback' instead of '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: Thu, 08 Nov 2012 16:08:06 -0000 I would prefer to just stick with what we have currently agreed, and just m= ake sure we have adequately defined the term PSAP to encompass other countr= ies emergency call architectures to encompass it where the use is appropria= te, and certainly to exclude examples as proposed by James Polk. Regards Keith > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > Winterbottom, James > Sent: 08 November 2012 15:38 > To: James Polk; Shida Schubert; ecrit@ietf.org > Subject: Re: [Ecrit] 'emergency-callback' instead of 'psap-callback' ?? >=20 > I don't understand how having psap-callback addresses the examples below > since if the ex can mark her call as emergency-callback she can just as > easily mark it as psap-callback. > The term PSAP certainly isn't universal though its understanding is > certainly growing. > I think that Shida's proposal is perfectly reasonable and would be my > preferred option. >=20 > Cheers > James >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of > James Polk > Sent: Friday, 9 November 2012 2:31 AM > To: Shida Schubert; ecrit@ietf.org > Subject: Re: [Ecrit] 'emergency-callback' instead of 'psap-callback' ?? >=20 > While I appreciate your intent, I need to fall back to the idea that ther= e > are many many different types of emergencies, and many of them are based > on the perspective of the person having the emergency, and not by how a > local, regional or national determines what is and what is not an > emergency. >=20 > While I understand that 'psap' might not be know, 'emergency' or > 'emergency-' is just too broad and can be either misused or > misunderstood. >=20 > For example, is the fact that I really need to make a point to someone wh= o > just hung up on my fall into the 'emergency-callback' > realm we're specifying in ECRIT? I don't believe so, especially if that > someone is my ex-spouse, who has a restraining order against me (she > doesn't, but I'm just using that as an example. >=20 > I could use a ex-boyfriend or ex-girlfriend example, or a > (unreasonable) daughter/son example, or a boss/subordinate example, or > even a telemarketer example that everyone probably can relate to. >=20 > I mean, we're talking about turning off DNR and call forward services tha= t > I probably otherwise want to have enabled in nearly or every case except > the 911/112 case. >=20 > my 2.25 cents (before taxation - which is coming soon) >=20 > James >=20 > At 01:25 AM 11/8/2012, Shida Schubert wrote: >=20 > > Just found out two days ago that we may need to implement what ever > >that comes out of this.. > > > > "psap" seems to be a very regional specific name, it definitely > >doesn't mean anything in Japan and probably in many other countries in > >the world.. > > > > Considering this may need to be implemented in Countries where "PSAP" > >has no meaning, can we come up with more generic name that is > >acceptable around the world like "emergency-callback"?? > > > > Regards > > Shida > > > >On Oct 16, 2012, at 8:57 PM, Christer Holmberg wrote: > > > >>Hi, > >> > >>I drafted some initial text regarding the new SIP Priority header > >>field 'psap-callback' value. > >> > >>Feel free to comment :) > >> > >>----------------------- > >> > >>X. PSAP Callback Indicator. > >> > >>X.1 General > >> > >>This section defines a new header field value, "psap-callback", for > >>the SIP Priority header field [RFC3261]. > >>The value is used by a SIP entity to inform downstream entities that > >>the request is associated with a PSAP callback SIP session. > >> > >>x.2 Usage > >> > >>SIP entities that receive the header field value within an initial > >>request for a SIP session, or within a standalone SIP request, can, > >>depending on local policies, apply PSAP callback specific procedures > >>for the session or request. > >> > >>PSAP callback specific procedures might be applied both by network > >>entities and by the callee. The specific procedures are outside the > >>scope of this document, but typically include bypassing services and > >>barring procedures. > >> > >>x.3 Syntax > >> > >>x.3.1 General > >> > >> This Section defines the ABNF for the new SIP Priority header > >> field value, "psap-callback". > >> > >>x.3.2 ABNF > >> > >>priority-value /=3D "psap-callback" > >> > >>----------------------- > >> > >>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 >=20 > _______________________________________________ > 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 btv1==659fe4ddd09==HKaplan@acmepacket.com Thu Nov 8 11:24:47 2012 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 CE7B721F8533 for ; Thu, 8 Nov 2012 11:24:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fggBPMy70+Pb for ; Thu, 8 Nov 2012 11:24:47 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 56D2521F8878 for ; Thu, 8 Nov 2012 11:24:47 -0800 (PST) X-ASG-Debug-ID: 1352402686-03fc201610a9ee0001-uVEBo8 Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by barracuda1.acmepacket.com with ESMTP id ghCTw819vS0crYwO (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 08 Nov 2012 14:24:46 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.93]) by Mail1.acmepacket.com ([169.254.1.47]) with mapi id 14.02.0283.003; Thu, 8 Nov 2012 14:24:33 -0500 From: Hadriel Kaplan To: Ecrit Thread-Topic: Question on ecrit using Priority header X-ASG-Orig-Subj: Question on ecrit using Priority header Thread-Index: AQHNveauUfazPVGSvkqrEqRNe/2gOQ== Date: Thu, 8 Nov 2012 19:24:32 +0000 Message-ID: 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1352402686 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.113657 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Subject: [Ecrit] Question on ecrit using Priority header 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, 08 Nov 2012 19:25:58 -0000 I hate to raise this question, but apparently I don't hate it enough not to= go ahead and raise it anyway: Is the Priority header really sufficient for ECRIT's use, as described in d= raft-ietf-ecrit-psap-callback-06? =20 The Priority header was never meant to affect SIP processing... not even ro= uting decisions nor blocking/barring I believe. It's really more like the = important flag in email (i.e., it's like the Mail 'Importance' header, as o= pposed to the Mail 'Priority' header). So isn't this the wrong header? -hadriel From christer.holmberg@ericsson.com Thu Nov 8 11:30:55 2012 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 F273E21F894E for ; Thu, 8 Nov 2012 11:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2xAMzTCFsXv for ; Thu, 8 Nov 2012 11:30:54 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5756321F84DD for ; Thu, 8 Nov 2012 11:30:47 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-d7-509c0865dd45 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 95.42.06323.5680C905; Thu, 8 Nov 2012 20:30:46 +0100 (CET) Received: from ESESSHC008.ericsson.se (153.88.183.42) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 8 Nov 2012 20:30:45 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 20:30:45 +0100 From: Christer Holmberg To: 'Hadriel Kaplan' , Ecrit Thread-Topic: Question on ecrit using Priority header Thread-Index: AQHNveauUfazPVGSvkqrEqRNe/2gOZfgUu8g Date: Thu, 8 Nov 2012 19:30:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B029B2C@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+JvjW4ax5wAg10TeC0aFz1ltZh7+Tm7 A5PHpsmb2TyWLPnJFMAUxWWTkpqTWZZapG+XwJXx/Nha5oIdrBVfzhxjbWBcxdLFyMkhIWAi 0f30MCuELSZx4d56ti5GLg4hgZOMEtuPr2WFcHYwSqyZcAQqs5hR4tHhdYxdjBwcbAIWEt3/ tEG6RQRcJSZNOQw2VRhoasOvQ2wQcVOJfcd+s0LYRhLrLv9gB7FZBFQkWi4eYgSxeQW8JT5f O8AKMlJIwFHi289kkDCngJPE5KYjYOWMQMd9P7WGCcRmFhCXuPVkPhPE0QISS/acZ4awRSVe Pv4H9YyixM6z7cwQ9ToSC3Z/YoOwtSWWLXzNDLFWUOLkzCdgJwsBxVsWT2CfwCg+C8mKWUja ZyFpn4WkfQEjyypG9tzEzJz0cvNNjMDYObjlt8EOxk33xQ4xSnOwKInz6qnu9xcSSE8sSc1O TS1ILYovKs1JLT7EyMTBKdXAePzhwXnLLr5WemMtP2nNhK/H/bOOhzB9M7mQ8EP5gtHa7tUR bRsKFux7kNs1na3L6ZZPQ5LYstkHuOcp7JV1YpETXf6Xh4Vj0gKL58V2nBrPmdbe2hQewLdN 65pnuZdzZm2Z+0+nd9m3beusf+TbmkrejTn58kL8+Z9edq22/RsW3DJSdpu+X4mlOCPRUIu5 qDgRACugqbdrAgAA Subject: Re: [Ecrit] Question on ecrit using Priority header 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, 08 Nov 2012 19:30:55 -0000 Hi,=20 >I hate to raise this question, but apparently I don't hate it enough not t= o go ahead and raise it anyway: >Is the Priority header really sufficient for ECRIT's use, as described in = draft-ietf-ecrit-psap-callback-06? =20 > >The Priority header was never meant to affect SIP processing... not even r= outing decisions nor blocking/barring I believe. =20 >It's really more like the important flag in email (i.e., it's like the Mai= l 'Importance' header, as opposed to the Mail 'Priority' header). RFC 3261 says: "For example, it may be factored into decisions about call routing and acce= ptance." >So isn't this the wrong header? No. Regards, Christer From rjsparks@nostrum.com Thu Nov 8 11:31:54 2012 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 C1A4521F84E1 for ; Thu, 8 Nov 2012 11:31:54 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVQmnnzwTr3J for ; Thu, 8 Nov 2012 11:31:54 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C9DE421F84D2 for ; Thu, 8 Nov 2012 11:31:53 -0800 (PST) Received: from dhcp-6421.meeting.ietf.org (dhcp-6421.meeting.ietf.org [130.129.100.33]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA8JVpLF012516 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Nov 2012 13:31:51 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <509C08A9.7030304@nostrum.com> Date: Thu, 08 Nov 2012 14:31:53 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090308000206030506090703" Received-SPF: pass (nostrum.com: 130.129.100.33 is authenticated by a trusted mechanism) Cc: Ecrit Subject: Re: [Ecrit] Question on ecrit using Priority header 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, 08 Nov 2012 19:31:54 -0000 This is a multi-part message in MIME format. --------------090308000206030506090703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit From 3261: 20.26 Priority The Priority header field indicates the urgency of the request as perceived by the client. The Priority header field describes the priority that the SIP request should have to the receiving human or its agent. For example, it may be factored into decisions about call routing and acceptance. On 11/8/12 2:24 PM, Hadriel Kaplan wrote: > I hate to raise this question, but apparently I don't hate it enough not to go ahead and raise it anyway: > Is the Priority header really sufficient for ECRIT's use, as described in draft-ietf-ecrit-psap-callback-06? > > The Priority header was never meant to affect SIP processing... not even routing decisions nor blocking/barring I believe. It's really more like the important flag in email (i.e., it's like the Mail 'Importance' header, as opposed to the Mail 'Priority' header). > > So isn't this the wrong header? > > -hadriel > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --------------090308000206030506090703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
From 3261:
20.26 Priority

   The Priority header field indicates the urgency of the request as
   perceived by the client.  The Priority header field describes the
   priority that the SIP request should have to the receiving human or
   its agent.  For example, it may be factored into decisions about call
   routing and acceptance.

On 11/8/12 2:24 PM, Hadriel Kaplan wrote:
I hate to raise this question, but apparently I don't hate it enough not to go ahead and raise it anyway:
Is the Priority header really sufficient for ECRIT's use, as described in draft-ietf-ecrit-psap-callback-06?  

The Priority header was never meant to affect SIP processing... not even routing decisions nor blocking/barring I believe.  It's really more like the important flag in email (i.e., it's like the Mail 'Importance' header, as opposed to the Mail 'Priority' header).

So isn't this the wrong header?

-hadriel

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

--------------090308000206030506090703-- From brian.rosen@neustar.biz Thu Nov 8 11:34:10 2012 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 6F0B121F84E1 for ; Thu, 8 Nov 2012 11:34:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.044 X-Spam-Level: X-Spam-Status: No, score=-6.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3h+7vgEhKnYC for ; Thu, 8 Nov 2012 11:34:09 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA1021F8453 for ; Thu, 8 Nov 2012 11:34:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1352403565; x=1667761670; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=uvynghsvHoeX64h9bK9qX CClWFv868qAWS5Z1bNo6ow=; b=VK8LuQnezVzvKrfYyN4djeb0bznGQech7mmIK 0cvP+Zbzwn7gjx4MwtlTwgDZ7z1XG/+/xTG+YwsL+/e8BWHfQ== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.16467617; Thu, 08 Nov 2012 14:39:24 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 8 Nov 2012 14:34:04 -0500 From: "Rosen, Brian" To: Hadriel Kaplan Date: Thu, 8 Nov 2012 14:34:03 -0500 Thread-Topic: [Ecrit] Question on ecrit using Priority header Thread-Index: Ac296ALBauJDMQgzQGGpUCIhGejICA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: OqjkpTPGEe645nYo0p6lGw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ecrit Subject: Re: [Ecrit] Question on ecrit using Priority header 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, 08 Nov 2012 19:34:10 -0000 Ooh, ooh, am I first? >From 3261: The Priority header field describes the priority that the SIP request should have to the receiving human or its agent. For example, it may be factored into decisions about call routing and acceptance. =20 Did you catch the part about "decisions about call routing"? Brian On Nov 8, 2012, at 2:24 PM, Hadriel Kaplan wrote: > I hate to raise this question, but apparently I don't hate it enough not = to go ahead and raise it anyway: > Is the Priority header really sufficient for ECRIT's use, as described in= draft-ietf-ecrit-psap-callback-06? =20 >=20 > The Priority header was never meant to affect SIP processing... not even = routing decisions nor blocking/barring I believe. It's really more like th= e important flag in email (i.e., it's like the Mail 'Importance' header, as= opposed to the Mail 'Priority' header). >=20 > So isn't this the wrong header? >=20 > -hadriel >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From btv1==659fe4ddd09==HKaplan@acmepacket.com Thu Nov 8 11:38:39 2012 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 C786921F86DB for ; Thu, 8 Nov 2012 11:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAte-NmMBpGk for ; Thu, 8 Nov 2012 11:38:39 -0800 (PST) Received: from mx1.acmepacket.com (mx1.acmepacket.com [216.41.24.33]) by ietfa.amsl.com (Postfix) with ESMTP id 13EEF21F86D4 for ; Thu, 8 Nov 2012 11:38:39 -0800 (PST) X-ASG-Debug-ID: 1352403518-03fc201610ab510001-uVEBo8 Received: from Mail1.acmepacket.com (mail1.acmepacket.com [10.0.0.21]) by barracuda1.acmepacket.com with ESMTP id GSUK4tqwqu9xV0i5 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Thu, 08 Nov 2012 14:38:38 -0500 (EST) X-Barracuda-Envelope-From: HKaplan@acmepacket.com Received: from MAIL2.acmepacket.com ([169.254.2.93]) by Mail1.acmepacket.com ([169.254.1.47]) with mapi id 14.02.0283.003; Thu, 8 Nov 2012 14:38:38 -0500 From: Hadriel Kaplan To: "Rosen, Brian" Thread-Topic: [Ecrit] Question on ecrit using Priority header X-ASG-Orig-Subj: Re: [Ecrit] Question on ecrit using Priority header Thread-Index: AQHNveildAUsniFRM0Cs4oSnir/gOg== Date: Thu, 8 Nov 2012 19:38:37 +0000 Message-ID: <2A0CF6B4-6E74-4BC9-88E3-4555F095D2F7@acmepacket.com> References: 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Barracuda-Connect: mail1.acmepacket.com[10.0.0.21] X-Barracuda-Start-Time: 1352403518 X-Barracuda-Encrypted: AES128-SHA X-Barracuda-URL: http://spam.acmepacket.com:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at acmepacket.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.113659 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: Ecrit Subject: Re: [Ecrit] Question on ecrit using Priority header 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, 08 Nov 2012 19:38:39 -0000 Oh sure, point out the actual RFC text. How boring. Someone should have said RTFM. :) -hadriel On Nov 8, 2012, at 2:34 PM, "Rosen, Brian" wrote: > Ooh, ooh, am I first? >=20 > From 3261: > The Priority header field describes the > priority that the SIP request should have to the receiving human or > its agent. For example, it may be factored into decisions about call > routing and acceptance. =20 >=20 > Did you catch the part about "decisions about call routing"? >=20 > Brian >=20 > On Nov 8, 2012, at 2:24 PM, Hadriel Kaplan wrote= : >=20 >> I hate to raise this question, but apparently I don't hate it enough not= to go ahead and raise it anyway: >> Is the Priority header really sufficient for ECRIT's use, as described i= n draft-ietf-ecrit-psap-callback-06? =20 >>=20 >> The Priority header was never meant to affect SIP processing... not even= routing decisions nor blocking/barring I believe. It's really more like t= he important flag in email (i.e., it's like the Mail 'Importance' header, a= s opposed to the Mail 'Priority' header). >>=20 >> So isn't this the wrong header? >>=20 >> -hadriel >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 From jmpolk@cisco.com Thu Nov 8 11:47:59 2012 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 EB53E21F88A0 for ; Thu, 8 Nov 2012 11:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.574 X-Spam-Level: X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Frlh98D+85wq for ; Thu, 8 Nov 2012 11:47:59 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4483821F8893 for ; Thu, 8 Nov 2012 11:47:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2180; q=dns/txt; s=iport; t=1352404079; x=1353613679; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=e+rkxgZR4lxVYBYBcxGYhpn+IPOpQhd4JBLgzcOBZUI=; b=MOWYkl105TDFvpIVpFux/4QWdLRsQCbvqj+Tx1XceIgsNbrcO8TEGuMe n/9dUq3Z+pHSz9MTB2sO1QvlML2Qo6JCBIoc6tDJUWgYOimg0UzHAtQZ7 s61C/MAHXEQ8oRYZurIGU2DUJUh3HxrOrXag69SDIUJLgK2guB3BCO2Hp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EALILnFCtJXG9/2dsb2JhbABEw2SBCIIeAQEBBAEBAQ8BJQI0CxAHBBgeEBkOMAYBEiKHaAubfaAwBIwSGoYtA4ham3mBa4MOgUU X-IronPort-AV: E=Sophos;i="4.80,739,1344211200"; d="scan'208";a="137275273" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 08 Nov 2012 19:47:58 +0000 Received: from jmpolk-WS.cisco.com (rtp-vpn3-798.cisco.com [10.82.219.34]) (authenticated bits=0) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA8JluS2027357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2012 19:47:58 GMT Message-Id: <201211081947.qA8JluS2027357@rcdn-core2-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 08 Nov 2012 13:47:56 -0600 To: "Rosen, Brian" , Hadriel Kaplan From: James Polk In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: Ecrit Subject: Re: [Ecrit] Question on ecrit using Priority header 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, 08 Nov 2012 19:48:00 -0000 yeah - but you were there, if not the WG chair at the time, when SIP decided the Priority header was *not* enough for processing decisions within a SIP entity, meaning this flag does not affect the priority of the message or invoke certain behaviors. Many said that sending a request marked with a certain Priority value one way (i.e., next hop routing) and a message towards the same destination with a different Priority value another way is not inconsistent with how that SIP entity treats the request. IIRC Priority header values can affect routing, which is not affecting the priority of the message within any SIP entity (I think I said that more than once here). And to Hadriel's point, it's really pushing the use and/or intent of Priority:. Very few wanted to use RPH though, so that idea died... James At 01:34 PM 11/8/2012, Rosen, Brian wrote: >Ooh, ooh, am I first? > > From 3261: > The Priority header field describes the > priority that the SIP request should have to the receiving human or > its agent. For example, it may be factored into decisions about call > routing and acceptance. > >Did you catch the part about "decisions about call routing"? > >Brian > >On Nov 8, 2012, at 2:24 PM, Hadriel Kaplan wrote: > > > I hate to raise this question, but apparently I don't hate it > enough not to go ahead and raise it anyway: > > Is the Priority header really sufficient for ECRIT's use, as > described in draft-ietf-ecrit-psap-callback-06? > > > > The Priority header was never meant to affect SIP processing... > not even routing decisions nor blocking/barring I believe. It's > really more like the important flag in email (i.e., it's like the > Mail 'Importance' header, as opposed to the Mail 'Priority' header). > > > > So isn't this the wrong header? > > > > -hadriel > > > > _______________________________________________ > > 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 rjsparks@nostrum.com Thu Nov 8 11:59:05 2012 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 691FB21F8A69 for ; Thu, 8 Nov 2012 11:59:05 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1McbR1X9AKz1 for ; Thu, 8 Nov 2012 11:59:04 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7EE21F8549 for ; Thu, 8 Nov 2012 11:59:04 -0800 (PST) Received: from dhcp-6421.meeting.ietf.org (dhcp-6421.meeting.ietf.org [130.129.100.33]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA8Jx1Io015072 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Nov 2012 13:59:02 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <509C0F07.2030200@nostrum.com> Date: Thu, 08 Nov 2012 14:59:03 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: James Polk References: <201211081947.qA8JluS2027357@rcdn-core2-2.cisco.com> In-Reply-To: <201211081947.qA8JluS2027357@rcdn-core2-2.cisco.com> Content-Type: multipart/alternative; boundary="------------070007090305000004020006" Received-SPF: pass (nostrum.com: 130.129.100.33 is authenticated by a trusted mechanism) Cc: "Rosen, Brian" , Ecrit Subject: Re: [Ecrit] Question on ecrit using Priority header 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, 08 Nov 2012 19:59:05 -0000 This is a multi-part message in MIME format. --------------070007090305000004020006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit If you read two more sentences down from what several people have quoted now, you'll find: The Priority header field does not influence the use of communications resources such as packet forwarding priority in routers or access to circuits in PSTN gateways. RjS On 11/8/12 2:47 PM, James Polk wrote: > yeah - but you were there, if not the WG chair at the time, when SIP > decided the Priority header was *not* enough for processing decisions > within a SIP entity, meaning this flag does not affect the priority of > the message or invoke certain behaviors. Many said that sending a > request marked with a certain Priority value one way (i.e., next hop > routing) and a message towards the same destination with a different > Priority value another way is not inconsistent with how that SIP > entity treats the request. IIRC Priority header values can affect > routing, which is not affecting the priority of the message within any > SIP entity (I think I said that more than once here). > > And to Hadriel's point, it's really pushing the use and/or intent of > Priority:. Very few wanted to use RPH though, so that idea died... > > James > > At 01:34 PM 11/8/2012, Rosen, Brian wrote: >> Ooh, ooh, am I first? >> >> From 3261: >> The Priority header field describes the >> priority that the SIP request should have to the receiving human or >> its agent. For example, it may be factored into decisions about call >> routing and acceptance. >> >> Did you catch the part about "decisions about call routing"? >> >> Brian >> >> On Nov 8, 2012, at 2:24 PM, Hadriel Kaplan >> wrote: >> >> > I hate to raise this question, but apparently I don't hate it >> enough not to go ahead and raise it anyway: >> > Is the Priority header really sufficient for ECRIT's use, as >> described in draft-ietf-ecrit-psap-callback-06? >> > >> > The Priority header was never meant to affect SIP processing... not >> even routing decisions nor blocking/barring I believe. It's really >> more like the important flag in email (i.e., it's like the Mail >> 'Importance' header, as opposed to the Mail 'Priority' header). >> > >> > So isn't this the wrong header? >> > >> > -hadriel >> > >> > _______________________________________________ >> > 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 --------------070007090305000004020006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
If you read two more sentences down from what several people have quoted now, you'll find:
The Priority header field does not influence the use of
   communications resources such as packet forwarding priority in
   routers or access to circuits in PSTN gateways.
RjS

On 11/8/12 2:47 PM, James Polk wrote:
yeah - but you were there, if not the WG chair at the time, when SIP decided the Priority header was *not* enough for processing decisions within a SIP entity, meaning this flag does not affect the priority of the message or invoke certain behaviors. Many said that sending a request marked with a certain Priority value one way (i.e., next hop routing) and a message towards the same destination with a different Priority value another way is not inconsistent with how that SIP entity treats the request. IIRC Priority header values can affect routing, which is not affecting the priority of the message within any SIP entity (I think I said that more than once here).

And to Hadriel's point, it's really pushing the use and/or intent of Priority:. Very few  wanted to use RPH though, so that idea died...

James

At 01:34 PM 11/8/2012, Rosen, Brian wrote:
Ooh, ooh, am I first?

From 3261:
  The Priority header field describes the
   priority that the SIP request should have to the receiving human or
   its agent.  For example, it may be factored into decisions about call
   routing and acceptance.

Did you catch the part about "decisions about call routing"?

Brian

On Nov 8, 2012, at 2:24 PM, Hadriel Kaplan <hkaplan@acmepacket.com> wrote:

> I hate to raise this question, but apparently I don't hate it enough not to go ahead and raise it anyway:
> Is the Priority header really sufficient for ECRIT's use, as described in draft-ietf-ecrit-psap-callback-06?
>
> The Priority header was never meant to affect SIP processing... not even routing decisions nor blocking/barring I believe.  It's really more like the important flag in email (i.e., it's like the Mail 'Importance' header, as opposed to the Mail 'Priority' header).
>
> So isn't this the wrong header?
>
> -hadriel
>
> _______________________________________________
> 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

--------------070007090305000004020006-- From keith.drage@alcatel-lucent.com Thu Nov 8 12:22:23 2012 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 A341121F8997 for ; Thu, 8 Nov 2012 12:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.998 X-Spam-Level: X-Spam-Status: No, score=-109.998 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N87R1jocJA-W for ; Thu, 8 Nov 2012 12:22:17 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 236EC21F890A for ; Thu, 8 Nov 2012 12:22:16 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA8KMD0j010980 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Nov 2012 21:22:13 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 8 Nov 2012 21:22:13 +0100 From: "DRAGE, Keith (Keith)" To: Robert Sparks , James Polk Date: Thu, 8 Nov 2012 21:22:11 +0100 Thread-Topic: [Ecrit] Question on ecrit using Priority header Thread-Index: Ac2964Vm4tKgXlybSz2HQQ9as69u1AAAkhAQ Message-ID: References: <201211081947.qA8JluS2027357@rcdn-core2-2.cisco.com> <509C0F07.2030200@nostrum.com> In-Reply-To: <509C0F07.2030200@nostrum.com> 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_EDC0A1AE77C57744B664A310A0B23AE202D30021F0FRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "Rosen, Brian" , Ecrit Subject: Re: [Ecrit] Question on ecrit using Priority header 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, 08 Nov 2012 20:22:23 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE202D30021F0FRMRSSXCHMBSC_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And there is no reason why one cannot use the Resource-Priority header fiel= d in conjunction with this to do the things that Resource-Prioirty is desig= ned to do, if you need those capabilities. Part of this depends on whether you need priority of the the signalling or = media on emergency callbacks. Not everyone needs it for emergency call, and= fewer still need it for the callbacks. Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of R= obert Sparks Sent: 08 November 2012 19:59 To: James Polk Cc: Rosen, Brian; Ecrit Subject: Re: [Ecrit] Question on ecrit using Priority header If you read two more sentences down from what several people have quoted no= w, you'll find: The Priority header field does not influence the use of communications resources such as packet forwarding priority in routers or access to circuits in PSTN gateways. RjS On 11/8/12 2:47 PM, James Polk wrote: yeah - but you were there, if not the WG chair at the time, when SIP decide= d the Priority header was *not* enough for processing decisions within a SI= P entity, meaning this flag does not affect the priority of the message or = invoke certain behaviors. Many said that sending a request marked with a ce= rtain Priority value one way (i.e., next hop routing) and a message towards= the same destination with a different Priority value another way is not in= consistent with how that SIP entity treats the request. IIRC Priority heade= r values can affect routing, which is not affecting the priority of the mes= sage within any SIP entity (I think I said that more than once here). And to Hadriel's point, it's really pushing the use and/or intent of Priori= ty:. Very few wanted to use RPH though, so that idea died... James At 01:34 PM 11/8/2012, Rosen, Brian wrote: Ooh, ooh, am I first? >From 3261: The Priority header field describes the priority that the SIP request should have to the receiving human or its agent. For example, it may be factored into decisions about call routing and acceptance. Did you catch the part about "decisions about call routing"? Brian On Nov 8, 2012, at 2:24 PM, Hadriel Kaplan wrote: > I hate to raise this question, but apparently I don't hate it enough not = to go ahead and raise it anyway: > Is the Priority header really sufficient for ECRIT's use, as described in= draft-ietf-ecrit-psap-callback-06? > > The Priority header was never meant to affect SIP processing... not even = routing decisions nor blocking/barring I believe. It's really more like th= e important flag in email (i.e., it's like the Mail 'Importance' header, as= opposed to the Mail 'Priority' header). > > So isn't this the wrong header? > > -hadriel > > _______________________________________________ > 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 --_000_EDC0A1AE77C57744B664A310A0B23AE202D30021F0FRMRSSXCHMBSC_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And there is no reason why one cannot = use the Resource-Priority header field in conjunction with this to do the thing= s that Resource-Prioirty is designed to do, if you need those capabilities.

 

Part of this depends on whether you ne= ed priority of the the signalling or media on emergency callbacks. Not everyon= e needs it for emergency call, and fewer still need it for the callbacks.

 

Keith

 

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beha= lf Of Robert Sparks
Sent: 08 November 2012 19:59=
To: James Polk
Cc: Rosen, Brian; Ecrit
Subject: Re: [Ecrit] Questio= n on ecrit using Priority header

=  

= If you read two more sentences down from what se= veral people have quoted now, you'll find:

The Priority header field does not influence the use of
   communications resources such as packet forwarding priority =
in
   routers or access to circuits in PSTN gateways. <=
/span>
 

= RjS

On 11= /8/12 2:47 PM, James P= olk wrote:

= yeah - but you were there, if not the WG chair a= t the time, when SIP decided the Priority header was *not* enough for processing decisions within a SIP entity, meaning this flag does not affect the priori= ty of the message or invoke certain behaviors. Many said that sending a reques= t marked with a certain Priority value one way (i.e., next hop routing) and a message towards the same destination with a different Priority value anothe= r way is not inconsistent with how that SIP entity treats the request. IIRC Priority header values can affect routing, which is not affecting the prior= ity of the message within any SIP entity (I think I said that more than once he= re).

And to Hadriel's point, it's really pushing the use and/or intent of Priori= ty:. Very few  wanted to use RPH though, so that idea died...

James

At 01:34 PM 11/8/2012, Rosen, Brian wrote:

= Ooh, ooh, am I first?

>From 3261:
  The Priority header field describes the
   priority that the SIP request should have to the receiving hum= an or
   its agent.  For example, it may be factored into decision= s about call
   routing and acceptance.

Did you catch the part about "decisions about call routing"?

Brian

On = Nov 8, 2012, at 2:24 PM, Hadr= iel Kaplan <hkaplan@acmepacket.com> wrote:

> I hate to raise this question, but apparently I don't hate it enough n= ot to go ahead and raise it anyway:
> Is the Priority header really sufficient for ECRIT's use, as described= in draft-ietf-ecrit-psap-callback-06?
>
> The Priority header was never meant to affect SIP processing... not ev= en routing decisions nor blocking/barring I believe.  It's really more li= ke the important flag in email (i.e., it's like the Mail 'Importance' header, = as opposed to the Mail 'Priority' header).
>
> So isn't this the wrong header?
>
> -hadriel
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ie= tf.org/mailman/listinfo/ecrit

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

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

=  

--_000_EDC0A1AE77C57744B664A310A0B23AE202D30021F0FRMRSSXCHMBSC_-- From internet-drafts@ietf.org Fri Nov 9 08:57:47 2012 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 A4C3521F8739; Fri, 9 Nov 2012 08:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJYgkInWNfnj; Fri, 9 Nov 2012 08:57:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7B721F8585; Fri, 9 Nov 2012 08:57:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121109165747.31043.36706.idtracker@ietfa.amsl.com> Date: Fri, 09 Nov 2012 08:57:47 -0800 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-04.txt 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: Fri, 09 Nov 2012 16:57:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Data-Only Emergency Calls Author(s) : Brian Rosen Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-ecrit-data-only-ea-04.txt Pages : 23 Date : 2012-11-09 Abstract: RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) can handle Internet multimedia emergency calls natively. The exchange of multimedia traffic typically involves a SIP session establishment starting with a SIP INVITE that negotiates various parameters for that session. In some cases, however, the transmission of application data is everything that is needed. Examples of such environments include a temperature sensors issuing alerts, or vehicles sending crash data. Often these alerts are conveyed as one-shot data transmissions and in some rare cases they may require a session to be established. These type of interactions are called 'data-only emergency calls'. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-data-only-ea-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mlinsner@cisco.com Fri Nov 9 09:35:56 2012 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 C6B5321F87BC for ; Fri, 9 Nov 2012 09:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.668 X-Spam-Level: X-Spam-Status: No, score=-9.668 tagged_above=-999 required=5 tests=[AWL=-0.466, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8QSYJ2g0xYK for ; Fri, 9 Nov 2012 09:35:55 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5402321F87B5 for ; Fri, 9 Nov 2012 09:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1363; q=dns/txt; s=iport; t=1352482555; x=1353692155; h=date:subject:from:to:message-id:mime-version; bh=XjZIrHLd84WNJ3Xsv0Croj5PCvtbXrRWNcKRtuhkecw=; b=MstRNeMiZzuIb66AIrAJ6vEdDtGCLp75ckHedeDEFtKlEpTETJnAWMoB RxRr/6VbF5m478OF5NOBm/HX3vYvNp10k3eD8fg1ry/zoxqIDGwxL8/wu NRcIC/+tV0iooTf5mrAiBCy6yviwCMtNcSf8QbRgM8NhQdhG1sX9yd9t1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArgLAOs9nVCtJV2b/2dsb2JhbABEgkmDCYFiuyNrgQEHghUQEgEqTwsBgR81h2gLnDiBK6ASBIwUhkoDiFqNIYVriG2Ba4MN X-IronPort-AV: E=McAfee;i="5400,1158,6891"; a="140424613" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 09 Nov 2012 17:35:55 +0000 Received: from [10.82.240.135] (rtp-vpn2-135.cisco.com [10.82.240.135]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA9HZrvE012409 for ; Fri, 9 Nov 2012 17:35:54 GMT User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Fri, 09 Nov 2012 12:35:53 -0500 From: Marc Linsner To: "ecrit@ietf.org" Message-ID: Thread-Topic: WGLC - Data-Only Emergency Calls Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3435309354_61354" Subject: [Ecrit] WGLC - Data-Only Emergency Calls 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: Fri, 09 Nov 2012 17:35:56 -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_3435309354_61354 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit This start the WGLC for draft Data-Only Emergency Calls The draft can be found at: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea Please review the draft and provide comments to the list before COB on November 23, 2012. Thanks, Marc & Roger --B_3435309354_61354 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
This start the WGLC for draf= t Data-Only Emergency Calls

The draft can be found = at:


Thanks,

Marc & Roger
--B_3435309354_61354-- From gunnar.hellstrom@omnitor.se Fri Nov 9 15:19:40 2012 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 D74A821F8554 for ; Fri, 9 Nov 2012 15:19:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO2UzQk7bxD9 for ; Fri, 9 Nov 2012 15:19:39 -0800 (PST) Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id E240221F8550 for ; Fri, 9 Nov 2012 15:19:37 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for ; Sat, 10 Nov 2012 00:19:01 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-10-01.atm.binero.net (Postfix) with ESMTPA id C621B3A140 for ; Sat, 10 Nov 2012 00:19:01 +0100 (CET) Message-ID: <509D8F66.9020306@omnitor.se> Date: Sat, 10 Nov 2012 00:19:02 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ecrit@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000607040406090603040800" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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: Fri, 09 Nov 2012 23:19:41 -0000 This is a multi-part message in MIME format. --------------000607040406090603040800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I see a slight protocol contradiction in section 4.1. There it is said: "To convey CAP payloads the SIP MESSAGE [RFC3428] is used for exchanges where no session establishment is needed, i.e.., one-shot message exchange, and the SIP INVITE [RFC3261] where the establishment of session is useful (e.g., when multiple independent messages have to be logically tied together). " I wonder if RFC 3261 and RFC3264 allows setting up a session without session description defined media. To me it seems that all session need to have media agreed through session descriptions. In RFC 3261 SIP, section 13.3.1.4, it is said: "If the INVITE did not contain an offer, the 2xx MUST contain an offer if the UAS had not yet sent an offer." So, it seems that an Offer/Answer sequence is required. And in RFC 3264 Offer/answer model, chapter 6.1, it is said: "If there are no media formats in common for all streams, the entire offered session is rejected." These rules taken together seem to result in that in order to set up a session to convey a series of CAP MESSAGES, then some (e.g. dummy) medium must be agreed also in a sessions description exchange. This would mean that a session cannot be set up for only CAP MESSAGE conveyance, but of course it is possible to have CAP messages and some other useful media in the same session. Do you agree in this conclusion? Gunnar ---- On 2012-11-09 18:35, Marc Linsner wrote: > This start the WGLC for draft Data-Only Emergency Calls > > The draft can be found at: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea > > Please review the draft and provide comments to the list before COB on > November 23, 2012. > > Thanks, > > Marc & Roger > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit --------------000607040406090603040800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I see a slight protocol contradiction in section 4.1.

There it is said: "To convey CAP payloads the SIP MESSAGE [RFC3428] is used for exchanges where no session establishment is needed, i.e.., one-shot message exchange, and the SIP INVITE [RFC3261] where the establishment of session is useful (e.g., when multiple independent messages have to be logically tied together). "

I wonder if RFC 3261 and RFC3264 allows setting up a session without session description defined media. To me it seems that all session need to have media agreed through session descriptions.

In RFC 3261 SIP, section 13.3.1.4, it is said:
"If the INVITE did
   not contain an offer, the 2xx MUST contain an offer if the UAS had
   not yet sent an offer."

So, it seems that an Offer/Answer sequence is required.

And in RFC 3264 Offer/answer model, chapter 6.1, it is said:
"If there are no media formats in common for all streams, the entire
   offered session is rejected."


These rules taken together seem to result in that in order to set up a session to convey a series of CAP MESSAGES, then some (e.g. dummy) medium must be agreed also in a sessions description exchange.

This would mean that a session cannot be set up for only CAP MESSAGE conveyance, but of course it is possible to have CAP messages and some other useful media in the same session.

Do you agree in this conclusion?

Gunnar
----

On 2012-11-09 18:35, Marc Linsner wrote:
This start the WGLC for draft Data-Only Emergency Calls

The draft can be found at:

Please review the draft and provide comments to the list before COB on November 23, 2012.

Thanks,

Marc & Roger


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

--------------000607040406090603040800-- From pkyzivat@alum.mit.edu Mon Nov 12 07:35:30 2012 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 9B3E321F8453 for ; Mon, 12 Nov 2012 07:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bq8ZNUzJ68Q for ; Mon, 12 Nov 2012 07:35:30 -0800 (PST) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id D4E4221F854B for ; Mon, 12 Nov 2012 07:35:28 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta09.westchester.pa.mail.comcast.net with comcast id Ndz21k00717dt5G59fbUYV; Mon, 12 Nov 2012 15:35:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id NfaS1k00T3ZTu2S3ZfaSRa; Mon, 12 Nov 2012 15:34:26 +0000 Message-ID: <50A1170B.6040405@alum.mit.edu> Date: Mon, 12 Nov 2012 10:34:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: ecrit@ietf.org References: <509D8F66.9020306@omnitor.se> In-Reply-To: <509D8F66.9020306@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 12 Nov 2012 15:35:30 -0000 Gunnar, On 11/9/12 6:19 PM, Gunnar Hellström wrote: > I see a slight protocol contradiction in section 4.1. > > There it is said: "To convey CAP payloads the SIP MESSAGE [RFC3428] is > used for exchanges where no session establishment is needed, i.e.., > one-shot message exchange, and the SIP INVITE [RFC3261] where the > establishment of session is useful (e.g., when multiple independent > messages have to be logically tied together). " > > I wonder if RFC 3261 and RFC3264 allows setting up a session without > session description defined media. To me it seems that all session need > to have media agreed through session descriptions. > > In RFC 3261 SIP, section 13.3.1.4, it is said: > > "If the INVITE did > not contain an offer, the 2xx MUST contain an offer if the UAS had > not yet sent an offer." > > So, it seems that an Offer/Answer sequence is required. Yes, to establish a session an O/A is required. > And in RFC 3264 Offer/answer model, chapter 6.1, it is said: > "If there are no media formats in common for all streams, the entire > offered session is rejected." The above statement is a bit ambiguous wrt the degenerate case where no streams are offered. (No m-lines in offer.) I would argue that there *are* media formats in common for every offered stream, so the "session is rejected" does not apply. In any case this statement is non-normative. I have always thought that an answerer is free to keep the session up with no media streams if that seems useful. I do think it would be useful to provide an example of a Data-Only Emergency call that establishes a session. Also, it would be helpful to have an explanation of *why* one might want that session established. I presume the idea is that there could then be a new O/A within the session to establish media, without the need for a psap-callback. Is that right? Has any concern been given for cases where UDP must be used and the messages are too big for that? It might be helpful in some cases to establish a session with an MSRP stream and send the data over that. That could also be helpful if the local sensors are capable of sending a sequence of data readings rather than just one. Thanks, Paul > These rules taken together seem to result in that in order to set up a session to convey a series of CAP MESSAGES, then some (e.g. dummy) medium must be agreed also in a sessions description exchange. > > This would mean that a session cannot be set up for only CAP MESSAGE conveyance, but of course it is possible to have CAP messages and some other useful media in the same session. > > Do you agree in this conclusion? > > Gunnar > > ---- > > On 2012-11-09 18:35, Marc Linsner wrote: >> This start the WGLC for draft Data-Only Emergency Calls >> >> The draft can be found at: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >> >> Please review the draft and provide comments to the list before COB on >> November 23, 2012. >> >> Thanks, >> >> Marc & Roger >> >> >> _______________________________________________ >> 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 brian.rosen@neustar.biz Mon Nov 12 08:01:20 2012 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 DC52621F85A8 for ; Mon, 12 Nov 2012 08:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-nKLpq43UJw for ; Mon, 12 Nov 2012 08:01:20 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id CEBF721F8654 for ; Mon, 12 Nov 2012 08:01:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1352736038; x=1668092154; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=RehEfZ/POPc7UBZzROxpx Vi21jgnqHipTg17dfFNBvE=; b=cq279mOLvyUwBm94EfTlMHL3x+1arTkxC+1nR amV3t/DCFlwoqoSTT5MT4xdVMfLDMJ+nKPtyvmNTSwzReqn2Q== Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.11736260; Mon, 12 Nov 2012 11:00:37 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Mon, 12 Nov 2012 11:01:15 -0500 From: "Rosen, Brian" To: Paul Kyzivat Date: Mon, 12 Nov 2012 11:01:14 -0500 Thread-Topic: [Ecrit] WGLC - Data-Only Emergency Calls Thread-Index: Ac3A7vEuZnyQSYWnQBKiZTzxeJ6CHQ== Message-ID: References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> In-Reply-To: <50A1170B.6040405@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: GRoHXSjm+G37CtmC+ZU7Dw== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 12 Nov 2012 16:01:21 -0000 The example is a sensor that detects some bad circumstance, but continues t= o take readings and wants to send updates at some reasonable rate. Brian On Nov 12, 2012, at 10:34 AM, Paul Kyzivat wrote: > Gunnar, >=20 > On 11/9/12 6:19 PM, Gunnar Hellstr=F6m wrote: >> I see a slight protocol contradiction in section 4.1. >>=20 >> There it is said: "To convey CAP payloads the SIP MESSAGE [RFC3428] is >> used for exchanges where no session establishment is needed, i.e.., >> one-shot message exchange, and the SIP INVITE [RFC3261] where the >> establishment of session is useful (e.g., when multiple independent >> messages have to be logically tied together). " >>=20 >> I wonder if RFC 3261 and RFC3264 allows setting up a session without >> session description defined media. To me it seems that all session need >> to have media agreed through session descriptions. >>=20 >> In RFC 3261 SIP, section 13.3.1.4, it is said: >>=20 >> "If the INVITE did >> not contain an offer, the 2xx MUST contain an offer if the UAS had >> not yet sent an offer." >>=20 >> So, it seems that an Offer/Answer sequence is required. >=20 > Yes, to establish a session an O/A is required. >=20 >> And in RFC 3264 Offer/answer model, chapter 6.1, it is said: >> "If there are no media formats in common for all streams, the entire >> offered session is rejected." >=20 > The above statement is a bit ambiguous wrt the degenerate case where no s= treams are offered. (No m-lines in offer.) I would argue that there *are* m= edia formats in common for every offered stream, so the "session is rejecte= d" does not apply. In any case this statement is non-normative. I have alwa= ys thought that an answerer is free to keep the session up with no media st= reams if that seems useful. >=20 > I do think it would be useful to provide an example of a Data-Only Emerge= ncy call that establishes a session. Also, it would be helpful to have an e= xplanation of *why* one might want that session established. >=20 > I presume the idea is that there could then be a new O/A within the sessi= on to establish media, without the need for a psap-callback. Is that right? >=20 > Has any concern been given for cases where UDP must be used and the messa= ges are too big for that? It might be helpful in some cases to establish a = session with an MSRP stream and send the data over that. That could also be= helpful if the local sensors are capable of sending a sequence of data rea= dings rather than just one. >=20 > Thanks, > Paul >=20 >> These rules taken together seem to result in that in order to set up a s= ession to convey a series of CAP MESSAGES, then some (e.g. dummy) medium mu= st be agreed also in a sessions description exchange. >>=20 >> This would mean that a session cannot be set up for only CAP MESSAGE con= veyance, but of course it is possible to have CAP messages and some other u= seful media in the same session. >>=20 >> Do you agree in this conclusion? >>=20 >> Gunnar >>=20 >> ---- >>=20 >> On 2012-11-09 18:35, Marc Linsner wrote: >>> This start the WGLC for draft Data-Only Emergency Calls >>>=20 >>> The draft can be found at: >>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >>>=20 >>> Please review the draft and provide comments to the list before COB on >>> November 23, 2012. >>>=20 >>> Thanks, >>>=20 >>> Marc & Roger >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >>=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 gunnar.hellstrom@omnitor.se Mon Nov 12 08:20:51 2012 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 95E8821F8618 for ; Mon, 12 Nov 2012 08:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyEJz9YREr0c for ; Mon, 12 Nov 2012 08:20:50 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 575A821F85CB for ; Mon, 12 Nov 2012 08:20:49 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 12 Nov 2012 17:20:41 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id A87F13A119 for ; Mon, 12 Nov 2012 17:20:41 +0100 (CET) Message-ID: <50A121DA.7090505@omnitor.se> Date: Mon, 12 Nov 2012 17:20:42 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ecrit@ietf.org References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 12 Nov 2012 16:20:51 -0000 I do not think an example is needed. I am just afraid that SIP stack implementors could have read SIP + SDP + O/A model as I did, and introduced automatic disconnection for a media-less session. The behavior Paul describes is a mutual agreement between implementers of the CAP alerting. What if there is a B2BUA in between, created by a careful implementer. How do you mean that a session with "m-lines for all 0 offered media" look like? Shall it be SDP exchange but with no m-lines? Gunnar On 2012-11-12 17:01, Rosen, Brian wrote: > The example is a sensor that detects some bad circumstance, but continues to take readings and wants to send updates at some reasonable rate. > > Brian > > On Nov 12, 2012, at 10:34 AM, Paul Kyzivat wrote: > >> Gunnar, >> >> On 11/9/12 6:19 PM, Gunnar Hellström wrote: >>> I see a slight protocol contradiction in section 4.1. >>> >>> There it is said: "To convey CAP payloads the SIP MESSAGE [RFC3428] is >>> used for exchanges where no session establishment is needed, i.e.., >>> one-shot message exchange, and the SIP INVITE [RFC3261] where the >>> establishment of session is useful (e.g., when multiple independent >>> messages have to be logically tied together). " >>> >>> I wonder if RFC 3261 and RFC3264 allows setting up a session without >>> session description defined media. To me it seems that all session need >>> to have media agreed through session descriptions. >>> >>> In RFC 3261 SIP, section 13.3.1.4, it is said: >>> >>> "If the INVITE did >>> not contain an offer, the 2xx MUST contain an offer if the UAS had >>> not yet sent an offer." >>> >>> So, it seems that an Offer/Answer sequence is required. >> Yes, to establish a session an O/A is required. >> >>> And in RFC 3264 Offer/answer model, chapter 6.1, it is said: >>> "If there are no media formats in common for all streams, the entire >>> offered session is rejected." >> The above statement is a bit ambiguous wrt the degenerate case where no streams are offered. (No m-lines in offer.) I would argue that there *are* media formats in common for every offered stream, so the "session is rejected" does not apply. In any case this statement is non-normative. I have always thought that an answerer is free to keep the session up with no media streams if that seems useful. >> >> I do think it would be useful to provide an example of a Data-Only Emergency call that establishes a session. Also, it would be helpful to have an explanation of *why* one might want that session established. >> >> I presume the idea is that there could then be a new O/A within the session to establish media, without the need for a psap-callback. Is that right? >> >> Has any concern been given for cases where UDP must be used and the messages are too big for that? It might be helpful in some cases to establish a session with an MSRP stream and send the data over that. That could also be helpful if the local sensors are capable of sending a sequence of data readings rather than just one. >> >> Thanks, >> Paul >> >>> These rules taken together seem to result in that in order to set up a session to convey a series of CAP MESSAGES, then some (e.g. dummy) medium must be agreed also in a sessions description exchange. >>> >>> This would mean that a session cannot be set up for only CAP MESSAGE conveyance, but of course it is possible to have CAP messages and some other useful media in the same session. >>> >>> Do you agree in this conclusion? >>> >>> Gunnar >>> >>> ---- >>> >>> On 2012-11-09 18:35, Marc Linsner wrote: >>>> This start the WGLC for draft Data-Only Emergency Calls >>>> >>>> The draft can be found at: >>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >>>> >>>> Please review the draft and provide comments to the list before COB on >>>> November 23, 2012. >>>> >>>> Thanks, >>>> >>>> Marc & Roger >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Nov 12 08:28:33 2012 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 9098C21F860D for ; Mon, 12 Nov 2012 08:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.378 X-Spam-Level: X-Spam-Status: No, score=-0.378 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLPdMgWizVQk for ; Mon, 12 Nov 2012 08:28:32 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADE821F85F0 for ; Mon, 12 Nov 2012 08:28:32 -0800 (PST) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta01.westchester.pa.mail.comcast.net with comcast id Nbc41k0031HzFnQ51gUYEC; Mon, 12 Nov 2012 16:28:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id NgUU1k0123ZTu2S3agUUsi; Mon, 12 Nov 2012 16:28:29 +0000 Message-ID: <50A123AC.5070802@alum.mit.edu> Date: Mon, 12 Nov 2012 11:28:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Rosen, Brian" References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 12 Nov 2012 16:28:33 -0000 On 11/12/12 11:01 AM, Rosen, Brian wrote: > The example is a sensor that detects some bad circumstance, but continues to take readings and wants to send updates at some reasonable rate. That is a good example, and it would be good to have it in the document. ISTM that it doesn't clearly fit the mechanisms included in the document. IIUC the doc includes two mechanisms: - send a MESSAGE with no dialog, with the data in the MESSAGE body. - send an INVITE with no media, with the data in the body of the INVITE. The session remains up for further use, but no mention of *what* use. In the case you describe above, how would the additional readings be transmitted? In a MESSAGE within the dialog? In the body of a reINVITE? This needs further explanation. ISTM that if the *intent* is to establish a session in order to send a sequence of data readings over time, then it would make sense to establish an MSRP session and send them all (including the first) over this channel. OTOH, if there is a *single* data reading to transmit but there is a desire to establish a session in order to facilitate later adding media streams, then the mechanism in the document makes sense. In that case it might be *better* to offer the media streams that *can be* supported, either in inactive state, or with port set to zero. Thanks, Paul > Brian > > On Nov 12, 2012, at 10:34 AM, Paul Kyzivat wrote: > >> Gunnar, >> >> On 11/9/12 6:19 PM, Gunnar Hellström wrote: >>> I see a slight protocol contradiction in section 4.1. >>> >>> There it is said: "To convey CAP payloads the SIP MESSAGE [RFC3428] is >>> used for exchanges where no session establishment is needed, i.e.., >>> one-shot message exchange, and the SIP INVITE [RFC3261] where the >>> establishment of session is useful (e.g., when multiple independent >>> messages have to be logically tied together). " >>> >>> I wonder if RFC 3261 and RFC3264 allows setting up a session without >>> session description defined media. To me it seems that all session need >>> to have media agreed through session descriptions. >>> >>> In RFC 3261 SIP, section 13.3.1.4, it is said: >>> >>> "If the INVITE did >>> not contain an offer, the 2xx MUST contain an offer if the UAS had >>> not yet sent an offer." >>> >>> So, it seems that an Offer/Answer sequence is required. >> >> Yes, to establish a session an O/A is required. >> >>> And in RFC 3264 Offer/answer model, chapter 6.1, it is said: >>> "If there are no media formats in common for all streams, the entire >>> offered session is rejected." >> >> The above statement is a bit ambiguous wrt the degenerate case where no streams are offered. (No m-lines in offer.) I would argue that there *are* media formats in common for every offered stream, so the "session is rejected" does not apply. In any case this statement is non-normative. I have always thought that an answerer is free to keep the session up with no media streams if that seems useful. >> >> I do think it would be useful to provide an example of a Data-Only Emergency call that establishes a session. Also, it would be helpful to have an explanation of *why* one might want that session established. >> >> I presume the idea is that there could then be a new O/A within the session to establish media, without the need for a psap-callback. Is that right? >> >> Has any concern been given for cases where UDP must be used and the messages are too big for that? It might be helpful in some cases to establish a session with an MSRP stream and send the data over that. That could also be helpful if the local sensors are capable of sending a sequence of data readings rather than just one. >> >> Thanks, >> Paul >> >>> These rules taken together seem to result in that in order to set up a session to convey a series of CAP MESSAGES, then some (e.g. dummy) medium must be agreed also in a sessions description exchange. >>> >>> This would mean that a session cannot be set up for only CAP MESSAGE conveyance, but of course it is possible to have CAP messages and some other useful media in the same session. >>> >>> Do you agree in this conclusion? >>> >>> Gunnar >>> >>> ---- >>> >>> On 2012-11-09 18:35, Marc Linsner wrote: >>>> This start the WGLC for draft Data-Only Emergency Calls >>>> >>>> The draft can be found at: >>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >>>> >>>> Please review the draft and provide comments to the list before COB on >>>> November 23, 2012. >>>> >>>> Thanks, >>>> >>>> Marc & Roger >>>> >>>> >>>> _______________________________________________ >>>> 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 Mon Nov 12 08:56:11 2012 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 F345F21F85A8 for ; Mon, 12 Nov 2012 08:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTkPNqaCzaVG for ; Mon, 12 Nov 2012 08:56:10 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 25F8E21F859C for ; Mon, 12 Nov 2012 08:56:09 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta10.westchester.pa.mail.comcast.net with comcast id Ng5l1k0051c6gX85Agw9tz; Mon, 12 Nov 2012 16:56:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id Ngw91k00l3ZTu2S3jgw9At; Mon, 12 Nov 2012 16:56:09 +0000 Message-ID: <50A12A28.8000205@alum.mit.edu> Date: Mon, 12 Nov 2012 11:56:08 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: ecrit@ietf.org References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A121DA.7090505@omnitor.se> In-Reply-To: <50A121DA.7090505@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 12 Nov 2012 16:56:11 -0000 On 11/12/12 11:20 AM, Gunnar Hellström wrote: > I do not think an example is needed. > > I am just afraid that SIP stack implementors could have read SIP + SDP + > O/A model as I did, and introduced automatic disconnection for a > media-less session. > > The behavior Paul describes is a mutual agreement between implementers > of the CAP alerting. What if there is a B2BUA in between, created by a > careful implementer. I explained my reasoning for why it is valid according to 3264. Others may believe otherwise. We can deal with it as it arises, or apply an errata to 3264 if need be. OR, different signaling that has higher likelihood of being accepted could be chosen. (Elsewhere I suggested m-lines with port=0, or inactive.) > How do you mean that a session with "m-lines for all 0 offered media" > look like? > Shall it be SDP exchange but with no m-lines? Yes. An INVITE with an SDP containing no m-lines is an offer - it is different from an INVITE with no SDP body at all. Thanks, Paul > Gunnar > > > > On 2012-11-12 17:01, Rosen, Brian wrote: >> The example is a sensor that detects some bad circumstance, but >> continues to take readings and wants to send updates at some >> reasonable rate. >> >> Brian >> >> On Nov 12, 2012, at 10:34 AM, Paul Kyzivat wrote: >> >>> Gunnar, >>> >>> On 11/9/12 6:19 PM, Gunnar Hellström wrote: >>>> I see a slight protocol contradiction in section 4.1. >>>> >>>> There it is said: "To convey CAP payloads the SIP MESSAGE [RFC3428] is >>>> used for exchanges where no session establishment is needed, i.e.., >>>> one-shot message exchange, and the SIP INVITE [RFC3261] where the >>>> establishment of session is useful (e.g., when multiple independent >>>> messages have to be logically tied together). " >>>> >>>> I wonder if RFC 3261 and RFC3264 allows setting up a session without >>>> session description defined media. To me it seems that all session need >>>> to have media agreed through session descriptions. >>>> >>>> In RFC 3261 SIP, section 13.3.1.4, it is said: >>>> >>>> "If the INVITE did >>>> not contain an offer, the 2xx MUST contain an offer if the UAS had >>>> not yet sent an offer." >>>> >>>> So, it seems that an Offer/Answer sequence is required. >>> Yes, to establish a session an O/A is required. >>> >>>> And in RFC 3264 Offer/answer model, chapter 6.1, it is said: >>>> "If there are no media formats in common for all streams, the entire >>>> offered session is rejected." >>> The above statement is a bit ambiguous wrt the degenerate case where >>> no streams are offered. (No m-lines in offer.) I would argue that >>> there *are* media formats in common for every offered stream, so the >>> "session is rejected" does not apply. In any case this statement is >>> non-normative. I have always thought that an answerer is free to keep >>> the session up with no media streams if that seems useful. >>> >>> I do think it would be useful to provide an example of a Data-Only >>> Emergency call that establishes a session. Also, it would be helpful >>> to have an explanation of *why* one might want that session established. >>> >>> I presume the idea is that there could then be a new O/A within the >>> session to establish media, without the need for a psap-callback. Is >>> that right? >>> >>> Has any concern been given for cases where UDP must be used and the >>> messages are too big for that? It might be helpful in some cases to >>> establish a session with an MSRP stream and send the data over that. >>> That could also be helpful if the local sensors are capable of >>> sending a sequence of data readings rather than just one. >>> >>> Thanks, >>> Paul >>> >>>> These rules taken together seem to result in that in order to set up >>>> a session to convey a series of CAP MESSAGES, then some (e.g. dummy) >>>> medium must be agreed also in a sessions description exchange. >>>> >>>> This would mean that a session cannot be set up for only CAP MESSAGE >>>> conveyance, but of course it is possible to have CAP messages and >>>> some other useful media in the same session. >>>> >>>> Do you agree in this conclusion? >>>> >>>> Gunnar >>>> >>>> ---- >>>> >>>> On 2012-11-09 18:35, Marc Linsner wrote: >>>>> This start the WGLC for draft Data-Only Emergency Calls >>>>> >>>>> The draft can be found at: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >>>>> >>>>> Please review the draft and provide comments to the list before COB on >>>>> November 23, 2012. >>>>> >>>>> Thanks, >>>>> >>>>> Marc & Roger >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From gunnar.hellstrom@omnitor.se Mon Nov 12 09:35:24 2012 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 14A3421F857C for ; Mon, 12 Nov 2012 09:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jrp1wYAd2rTr for ; Mon, 12 Nov 2012 09:35:23 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 07B7A21F8561 for ; Mon, 12 Nov 2012 09:35:21 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 12 Nov 2012 18:35:13 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id 1D2233A0F6 for ; Mon, 12 Nov 2012 18:35:13 +0100 (CET) Message-ID: <50A13352.2030801@omnitor.se> Date: Mon, 12 Nov 2012 18:35:14 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ecrit@ietf.org References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A121DA.7090505@omnitor.se> <50A12A28.8000205@alum.mit.edu> In-Reply-To: <50A12A28.8000205@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------080804090208010400030803" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 12 Nov 2012 17:35:24 -0000 This is a multi-part message in MIME format. --------------080804090208010400030803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit There is also a discussion in RFC 3428 SIP Message to consider. e.g in chapter 2: "implementations SHOULD NOT create dialogs for the primary purpose of associating MESSAGE requests with one another." So, it is no clean case to set up a session just for transmission of SIP Messages and nothing else, it is a composition of grey areas. I do not think we should complicate the issue by requiring MSRP or having the CAP as Body part in the INVITE. Maybe just some words of advice on how to create the kind of session you want with highest likelihood of success. Gunnar ___________________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2012-11-12 17:56, Paul Kyzivat wrote: > On 11/12/12 11:20 AM, Gunnar Hellström wrote: >> I do not think an example is needed. >> >> I am just afraid that SIP stack implementors could have read SIP + SDP + >> O/A model as I did, and introduced automatic disconnection for a >> media-less session. >> >> The behavior Paul describes is a mutual agreement between implementers >> of the CAP alerting. What if there is a B2BUA in between, created by a >> careful implementer. > > I explained my reasoning for why it is valid according to 3264. > Others may believe otherwise. We can deal with it as it arises, or > apply an errata to 3264 if need be. > > OR, different signaling that has higher likelihood of being accepted > could be chosen. (Elsewhere I suggested m-lines with port=0, or > inactive.) > >> How do you mean that a session with "m-lines for all 0 offered media" >> look like? >> Shall it be SDP exchange but with no m-lines? > > Yes. An INVITE with an SDP containing no m-lines is an offer - it is > different from an INVITE with no SDP body at all. > > Thanks, > Paul > >> Gunnar >> >> >> >> On 2012-11-12 17:01, Rosen, Brian wrote: >>> The example is a sensor that detects some bad circumstance, but >>> continues to take readings and wants to send updates at some >>> reasonable rate. >>> >>> Brian >>> >>> On Nov 12, 2012, at 10:34 AM, Paul Kyzivat >>> wrote: >>> >>>> Gunnar, >>>> >>>> On 11/9/12 6:19 PM, Gunnar Hellström wrote: >>>>> I see a slight protocol contradiction in section 4.1. >>>>> >>>>> There it is said: "To convey CAP payloads the SIP MESSAGE >>>>> [RFC3428] is >>>>> used for exchanges where no session establishment is needed, i.e.., >>>>> one-shot message exchange, and the SIP INVITE [RFC3261] where the >>>>> establishment of session is useful (e.g., when multiple independent >>>>> messages have to be logically tied together). " >>>>> >>>>> I wonder if RFC 3261 and RFC3264 allows setting up a session without >>>>> session description defined media. To me it seems that all session >>>>> need >>>>> to have media agreed through session descriptions. >>>>> >>>>> In RFC 3261 SIP, section 13.3.1.4, it is said: >>>>> >>>>> "If the INVITE did >>>>> not contain an offer, the 2xx MUST contain an offer if the UAS >>>>> had >>>>> not yet sent an offer." >>>>> >>>>> So, it seems that an Offer/Answer sequence is required. >>>> Yes, to establish a session an O/A is required. >>>> >>>>> And in RFC 3264 Offer/answer model, chapter 6.1, it is said: >>>>> "If there are no media formats in common for all streams, the entire >>>>> offered session is rejected." >>>> The above statement is a bit ambiguous wrt the degenerate case where >>>> no streams are offered. (No m-lines in offer.) I would argue that >>>> there *are* media formats in common for every offered stream, so the >>>> "session is rejected" does not apply. In any case this statement is >>>> non-normative. I have always thought that an answerer is free to keep >>>> the session up with no media streams if that seems useful. >>>> >>>> I do think it would be useful to provide an example of a Data-Only >>>> Emergency call that establishes a session. Also, it would be helpful >>>> to have an explanation of *why* one might want that session >>>> established. >>>> >>>> I presume the idea is that there could then be a new O/A within the >>>> session to establish media, without the need for a psap-callback. Is >>>> that right? >>>> >>>> Has any concern been given for cases where UDP must be used and the >>>> messages are too big for that? It might be helpful in some cases to >>>> establish a session with an MSRP stream and send the data over that. >>>> That could also be helpful if the local sensors are capable of >>>> sending a sequence of data readings rather than just one. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> These rules taken together seem to result in that in order to set up >>>>> a session to convey a series of CAP MESSAGES, then some (e.g. dummy) >>>>> medium must be agreed also in a sessions description exchange. >>>>> >>>>> This would mean that a session cannot be set up for only CAP MESSAGE >>>>> conveyance, but of course it is possible to have CAP messages and >>>>> some other useful media in the same session. >>>>> >>>>> Do you agree in this conclusion? >>>>> >>>>> Gunnar >>>>> >>>>> ---- >>>>> >>>>> On 2012-11-09 18:35, Marc Linsner wrote: >>>>>> This start the WGLC for draft Data-Only Emergency Calls >>>>>> >>>>>> The draft can be found at: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >>>>>> >>>>>> Please review the draft and provide comments to the list before >>>>>> COB on >>>>>> November 23, 2012. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Marc & Roger >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> _______________________________________________ >> 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 --------------080804090208010400030803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
There is also a discussion in RFC 3428 SIP Message to consider.

e.g in chapter 2:
"implementations SHOULD NOT create dialogs for the primary purpose of associating MESSAGE
   requests with one another."

So, it is no clean case to set up a session just for transmission of SIP Messages and nothing else, it is a composition of grey areas.


I do not think we should complicate the issue by requiring MSRP or having the CAP as Body part in the INVITE. Maybe just some words of advice on how to create the kind of session you want with highest likelihood of success.

Gunnar

___________________________________________________
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2012-11-12 17:56, Paul Kyzivat wrote:
On 11/12/12 11:20 AM, Gunnar Hellström wrote:
I do not think an example is needed.

I am just afraid that SIP stack implementors could have read SIP + SDP +
O/A model as I did, and introduced automatic disconnection for a
media-less session.

The behavior Paul describes is a mutual agreement between implementers
of the CAP alerting. What if there is a B2BUA in between, created by a
careful implementer.

I explained my reasoning for why it is valid according to 3264.
Others may believe otherwise. We can deal with it as it arises, or apply an errata to 3264 if need be.

OR, different signaling that has higher likelihood of being accepted could be chosen. (Elsewhere I suggested m-lines with port=0, or inactive.)

How do you mean that a session with "m-lines for all 0 offered media"
look like?
Shall it be SDP exchange but with no m-lines?

Yes. An INVITE with an SDP containing no m-lines is an offer - it is different from an INVITE with no SDP body at all.

    Thanks,
    Paul

Gunnar



On 2012-11-12 17:01, Rosen, Brian wrote:
The example is a sensor that detects some bad circumstance, but
continues to take readings and wants to send updates at some
reasonable rate.

Brian

On Nov 12, 2012, at 10:34 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Gunnar,

On 11/9/12 6:19 PM, Gunnar Hellström wrote:
I see a slight protocol contradiction in section 4.1.

There it is said: "To convey CAP payloads the SIP MESSAGE [RFC3428] is
used for exchanges where no session establishment is needed, i.e..,
one-shot message exchange, and the SIP INVITE [RFC3261] where the
establishment of session is useful (e.g., when multiple independent
messages have to be logically tied together). "

I wonder if RFC 3261 and RFC3264 allows setting up a session without
session description defined media. To me it seems that all session need
to have media agreed through session descriptions.

In RFC 3261 SIP, section 13.3.1.4, it is said:

"If the INVITE did
    not contain an offer, the 2xx MUST contain an offer if the UAS had
    not yet sent an offer."

So, it seems that an Offer/Answer sequence is required.
Yes, to establish a session an O/A is required.

And in RFC 3264 Offer/answer model, chapter 6.1, it is said:
"If there are no media formats in common for all streams, the entire
    offered session is rejected."
The above statement is a bit ambiguous wrt the degenerate case where
no streams are offered. (No m-lines in offer.) I would argue that
there *are* media formats in common for every offered stream, so the
"session is rejected" does not apply. In any case this statement is
non-normative. I have always thought that an answerer is free to keep
the session up with no media streams if that seems useful.

I do think it would be useful to provide an example of a Data-Only
Emergency call that establishes a session. Also, it would be helpful
to have an explanation of *why* one might want that session established.

I presume the idea is that there could then be a new O/A within the
session to establish media, without the need for a psap-callback. Is
that right?

Has any concern been given for cases where UDP must be used and the
messages are too big for that? It might be helpful in some cases to
establish a session with an MSRP stream and send the data over that.
That could also be helpful if the local sensors are capable of
sending a sequence of data readings rather than just one.

    Thanks,
    Paul

These rules taken together seem to result in that in order to set up
a session to convey a series of CAP MESSAGES, then some (e.g. dummy)
medium must be agreed also in a sessions description exchange.

This would mean that a session cannot be set up for only CAP MESSAGE
conveyance, but of course it is possible to have CAP messages and
some other useful media in the same session.

Do you agree in this conclusion?

Gunnar

----

On 2012-11-09 18:35, Marc Linsner wrote:
This start the WGLC for draft Data-Only Emergency Calls

The draft can be found at:
https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea

Please review the draft and provide comments to the list before COB on
November 23, 2012.

Thanks,

Marc & Roger


_______________________________________________
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

_______________________________________________
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

--------------080804090208010400030803-- From brian.rosen@neustar.biz Mon Nov 12 10:35:57 2012 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 1A7BF21F8674 for ; Mon, 12 Nov 2012 10:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mr9HFU6dFign for ; Mon, 12 Nov 2012 10:35:56 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id E2A4821F8652 for ; Mon, 12 Nov 2012 10:35:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1352745675; x=1668097927; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=6ysBkZ3Plu+quo8RezaIA NVMrqFoU5eQSELRuniQxXM=; b=F/qC0OXGjHRFkVAxFiHnVODK9s4ggWDXE6eIU 9TzmGcv58KxmUSxWE3LTBEG3BqK5NTO5IcWHLdrka2hSZByLw== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.16625622; Mon, 12 Nov 2012 13:41:14 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Mon, 12 Nov 2012 13:35:52 -0500 From: "Rosen, Brian" To: Paul Kyzivat Date: Mon, 12 Nov 2012 13:35:51 -0500 Thread-Topic: [Ecrit] WGLC - Data-Only Emergency Calls Thread-Index: Ac3BBIqsJ9fXQdKDTOqg64W9TgZH7A== Message-ID: References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> In-Reply-To: <50A123AC.5070802@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: AlbgoDdbzU7XDGydnqSCcw== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 12 Nov 2012 18:35:57 -0000 I should have expanded my answer, because I agree with you. Having talked it over with several SIP folks, the idea of multiple MESSAGES= in a session is a bad idea, and if we want to do updates to the CAP messag= e, MSRP is the right answer. =20 I don't see the value in a "maybe I'll send media later" session. I see no= use case for that. We do want to be able to include the CAP message in a regular (with media) = INVITE. That allows the sensor data AND the media ("Help I've fallen and c= an't get up"). So a CAP message in a Body with SDP in an INVITE or a CAP m= essage in a MESSAGE with no SDP is what we want to allow. =20 Brian On Nov 12, 2012, at 11:28 AM, Paul Kyzivat wrote: > On 11/12/12 11:01 AM, Rosen, Brian wrote: >> The example is a sensor that detects some bad circumstance, but continue= s to take readings and wants to send updates at some reasonable rate. >=20 > That is a good example, and it would be good to have it in the document. > ISTM that it doesn't clearly fit the mechanisms included in the document.= IIUC the doc includes two mechanisms: >=20 > - send a MESSAGE with no dialog, with the data in the MESSAGE body. >=20 > - send an INVITE with no media, with the data in the body of the INVITE. > The session remains up for further use, but no mention of *what* use. > In the case you describe above, how would the additional readings > be transmitted? In a MESSAGE within the dialog? In the body of a > reINVITE? This needs further explanation. >=20 > ISTM that if the *intent* is to establish a session in order to send a se= quence of data readings over time, then it would make sense to establish an= MSRP session and send them all (including the first) over this channel. >=20 > OTOH, if there is a *single* data reading to transmit but there is a desi= re to establish a session in order to facilitate later adding media streams= , then the mechanism in the document makes sense. In that case it might be = *better* to offer the media streams that *can be* supported, either in inac= tive state, or with port set to zero. >=20 > Thanks, > Paul >=20 >> Brian >>=20 >> On Nov 12, 2012, at 10:34 AM, Paul Kyzivat wrote= : >>=20 >>> Gunnar, >>>=20 >>> On 11/9/12 6:19 PM, Gunnar Hellstr=F6m wrote: >>>> I see a slight protocol contradiction in section 4.1. >>>>=20 >>>> There it is said: "To convey CAP payloads the SIP MESSAGE [RFC3428] is >>>> used for exchanges where no session establishment is needed, i.e.., >>>> one-shot message exchange, and the SIP INVITE [RFC3261] where the >>>> establishment of session is useful (e.g., when multiple independent >>>> messages have to be logically tied together). " >>>>=20 >>>> I wonder if RFC 3261 and RFC3264 allows setting up a session without >>>> session description defined media. To me it seems that all session nee= d >>>> to have media agreed through session descriptions. >>>>=20 >>>> In RFC 3261 SIP, section 13.3.1.4, it is said: >>>>=20 >>>> "If the INVITE did >>>> not contain an offer, the 2xx MUST contain an offer if the UAS had >>>> not yet sent an offer." >>>>=20 >>>> So, it seems that an Offer/Answer sequence is required. >>>=20 >>> Yes, to establish a session an O/A is required. >>>=20 >>>> And in RFC 3264 Offer/answer model, chapter 6.1, it is said: >>>> "If there are no media formats in common for all streams, the entire >>>> offered session is rejected." >>>=20 >>> The above statement is a bit ambiguous wrt the degenerate case where no= streams are offered. (No m-lines in offer.) I would argue that there *are*= media formats in common for every offered stream, so the "session is rejec= ted" does not apply. In any case this statement is non-normative. I have al= ways thought that an answerer is free to keep the session up with no media = streams if that seems useful. >>>=20 >>> I do think it would be useful to provide an example of a Data-Only Emer= gency call that establishes a session. Also, it would be helpful to have an= explanation of *why* one might want that session established. >>>=20 >>> I presume the idea is that there could then be a new O/A within the ses= sion to establish media, without the need for a psap-callback. Is that righ= t? >>>=20 >>> Has any concern been given for cases where UDP must be used and the mes= sages are too big for that? It might be helpful in some cases to establish = a session with an MSRP stream and send the data over that. That could also = be helpful if the local sensors are capable of sending a sequence of data r= eadings rather than just one. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> These rules taken together seem to result in that in order to set up a= session to convey a series of CAP MESSAGES, then some (e.g. dummy) medium = must be agreed also in a sessions description exchange. >>>>=20 >>>> This would mean that a session cannot be set up for only CAP MESSAGE c= onveyance, but of course it is possible to have CAP messages and some other= useful media in the same session. >>>>=20 >>>> Do you agree in this conclusion? >>>>=20 >>>> Gunnar >>>>=20 >>>> ---- >>>>=20 >>>> On 2012-11-09 18:35, Marc Linsner wrote: >>>>> This start the WGLC for draft Data-Only Emergency Calls >>>>>=20 >>>>> The draft can be found at: >>>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >>>>>=20 >>>>> Please review the draft and provide comments to the list before COB o= n >>>>> November 23, 2012. >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> Marc & Roger >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>>=20 >>>>=20 >>>>=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 >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From gunnar.hellstrom@omnitor.se Mon Nov 12 10:46:37 2012 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 26C5521F874A for ; Mon, 12 Nov 2012 10:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT1G2Qa8OJAJ for ; Mon, 12 Nov 2012 10:46:36 -0800 (PST) Received: from vsp-authed-03-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id BF65D21F870B for ; Mon, 12 Nov 2012 10:46:35 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-03-02.binero.net (Halon Mail Gateway) with ESMTP for ; Mon, 12 Nov 2012 19:46:27 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-02-01.atm.binero.net (Postfix) with ESMTPA id 89A333A214 for ; Mon, 12 Nov 2012 19:46:27 +0100 (CET) Message-ID: <50A14404.9080503@omnitor.se> Date: Mon, 12 Nov 2012 19:46:28 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ecrit@ietf.org References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 12 Nov 2012 18:46:37 -0000 Brian, you say: "We do want to be able to include the CAP message in a regular (with media) INVITE. That allows the sensor data AND the media ("Help I've fallen and can't get up"). So a CAP message in a Body with SDP in an INVITE or a CAP message in a MESSAGE with no SDP is what we want to allow." Good conclusion. Gunnar ___________________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 On 2012-11-12 19:35, Rosen, Brian wrote: > I should have expanded my answer, because I agree with you. > > Having talked it over with several SIP folks, the idea of multiple MESSAGES in a session is a bad idea, and if we want to do updates to the CAP message, MSRP is the right answer. > > I don't see the value in a "maybe I'll send media later" session. I see no use case for that. > > We do want to be able to include the CAP message in a regular (with media) INVITE. That allows the sensor data AND the media ("Help I've fallen and can't get up"). So a CAP message in a Body with SDP in an INVITE or a CAP message in a MESSAGE with no SDP is what we want to allow. > > Brian > > On Nov 12, 2012, at 11:28 AM, Paul Kyzivat wrote: > >> On 11/12/12 11:01 AM, Rosen, Brian wrote: >>> The example is a sensor that detects some bad circumstance, but continues to take readings and wants to send updates at some reasonable rate. >> That is a good example, and it would be good to have it in the document. >> ISTM that it doesn't clearly fit the mechanisms included in the document. IIUC the doc includes two mechanisms: >> >> - send a MESSAGE with no dialog, with the data in the MESSAGE body. >> >> - send an INVITE with no media, with the data in the body of the INVITE. >> The session remains up for further use, but no mention of *what* use. >> In the case you describe above, how would the additional readings >> be transmitted? In a MESSAGE within the dialog? In the body of a >> reINVITE? This needs further explanation. >> >> ISTM that if the *intent* is to establish a session in order to send a sequence of data readings over time, then it would make sense to establish an MSRP session and send them all (including the first) over this channel. >> >> OTOH, if there is a *single* data reading to transmit but there is a desire to establish a session in order to facilitate later adding media streams, then the mechanism in the document makes sense. In that case it might be *better* to offer the media streams that *can be* supported, either in inactive state, or with port set to zero. >> >> Thanks, >> Paul >> >>> Brian >>> >>> On Nov 12, 2012, at 10:34 AM, Paul Kyzivat wrote: >>> >>>> Gunnar, >>>> >>>> On 11/9/12 6:19 PM, Gunnar Hellström wrote: >>>>> I see a slight protocol contradiction in section 4.1. >>>>> >>>>> There it is said: "To convey CAP payloads the SIP MESSAGE [RFC3428] is >>>>> used for exchanges where no session establishment is needed, i.e.., >>>>> one-shot message exchange, and the SIP INVITE [RFC3261] where the >>>>> establishment of session is useful (e.g., when multiple independent >>>>> messages have to be logically tied together). " >>>>> >>>>> I wonder if RFC 3261 and RFC3264 allows setting up a session without >>>>> session description defined media. To me it seems that all session need >>>>> to have media agreed through session descriptions. >>>>> >>>>> In RFC 3261 SIP, section 13.3.1.4, it is said: >>>>> >>>>> "If the INVITE did >>>>> not contain an offer, the 2xx MUST contain an offer if the UAS had >>>>> not yet sent an offer." >>>>> >>>>> So, it seems that an Offer/Answer sequence is required. >>>> Yes, to establish a session an O/A is required. >>>> >>>>> And in RFC 3264 Offer/answer model, chapter 6.1, it is said: >>>>> "If there are no media formats in common for all streams, the entire >>>>> offered session is rejected." >>>> The above statement is a bit ambiguous wrt the degenerate case where no streams are offered. (No m-lines in offer.) I would argue that there *are* media formats in common for every offered stream, so the "session is rejected" does not apply. In any case this statement is non-normative. I have always thought that an answerer is free to keep the session up with no media streams if that seems useful. >>>> >>>> I do think it would be useful to provide an example of a Data-Only Emergency call that establishes a session. Also, it would be helpful to have an explanation of *why* one might want that session established. >>>> >>>> I presume the idea is that there could then be a new O/A within the session to establish media, without the need for a psap-callback. Is that right? >>>> >>>> Has any concern been given for cases where UDP must be used and the messages are too big for that? It might be helpful in some cases to establish a session with an MSRP stream and send the data over that. That could also be helpful if the local sensors are capable of sending a sequence of data readings rather than just one. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> These rules taken together seem to result in that in order to set up a session to convey a series of CAP MESSAGES, then some (e.g. dummy) medium must be agreed also in a sessions description exchange. >>>>> >>>>> This would mean that a session cannot be set up for only CAP MESSAGE conveyance, but of course it is possible to have CAP messages and some other useful media in the same session. >>>>> >>>>> Do you agree in this conclusion? >>>>> >>>>> Gunnar >>>>> >>>>> ---- >>>>> >>>>> On 2012-11-09 18:35, Marc Linsner wrote: >>>>>> This start the WGLC for draft Data-Only Emergency Calls >>>>>> >>>>>> The draft can be found at: >>>>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >>>>>> >>>>>> Please review the draft and provide comments to the list before COB on >>>>>> November 23, 2012. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Marc & Roger >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From hannes.tschofenig@gmx.net Tue Nov 13 09:58:31 2012 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 1633121F85D5 for ; Tue, 13 Nov 2012 09:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSGT05jhDJvA for ; Tue, 13 Nov 2012 09:58:30 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 99C7921F85BF for ; Tue, 13 Nov 2012 09:58:27 -0800 (PST) Received: (qmail invoked by alias); 13 Nov 2012 17:58:23 -0000 Received: from 31-35-51.wireless.csail.mit.edu (EHLO 31-35-51.wireless.csail.mit.edu) [128.31.35.51] by mail.gmx.net (mp030) with SMTP; 13 Nov 2012 18:58:23 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX185OO5waio5CJj0LnE3XM7C6nElEr4VPTMRBjj0xn sWGr0K+XNtQNjc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <50A14404.9080503@omnitor.se> Date: Tue, 13 Nov 2012 12:58:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <8CB17972-4677-4CA0-BFB5-26E96F7A1C37@gmx.net> References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50A14404.9080503@omnitor.se> To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 13 Nov 2012 17:58:31 -0000 Hi all,=20 In the data-only ES document we have two use cases: Use Case #1: a one-shot MESSAGE with a body that contains a CAP message. There is no session concept there. There does not seem to be a problem = with this approach.=20 Use Case #2: a sequence of MESSAGE msgs The example that Brian mentioned on the mailing list is a sensor that = detects some bad circumstance. It sends an alarm but continues to take = readings and wants to send updates. We would like to to avoid the = situation where messages end up at different places since they are = addressed to the SOS URN. For this reason we thought that it would be = good to use a session concept here.=20 As Gunnar had pointed out that our understanding of how this would work = contracts with existing specifications. Very good feedback, Gunnar.=20 So, how do we address this feedback? I see three options.=20 Option #1: Omit use case #2 from the document and just focus on the = individually routed SIP MESSAGE payloads.=20 Option #2: Include use case #2 by utilizing MSRP*, as suggested by Paul.=20= Option #3: Limit use case #2 by using a CAP payload in a regular SIP = INVITE (with media) With this case it is not possible to use the CAP payloads alone without = media. =20 I prefer option #3.=20 Ciao Hannes *: As we learned in discussions on a separate mailing list MSRP is = actually not that difficult to implement when only focusing on the = emergency services use case.=20 On Nov 12, 2012, at 1:46 PM, Gunnar Hellstr=F6m wrote: > Brian, you say: > "We do want to be able to include the CAP message in a regular (with = media) INVITE. That allows the sensor data AND the media ("Help I've = fallen and can't get up"). So a CAP message in a Body with SDP in an = INVITE or a CAP message in a MESSAGE with no SDP is what we want to = allow." >=20 > Good conclusion. >=20 > Gunnar >=20 > ___________________________________________________ > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > +46708204288 >=20 > On 2012-11-12 19:35, Rosen, Brian wrote: >> I should have expanded my answer, because I agree with you. >>=20 >> Having talked it over with several SIP folks, the idea of multiple = MESSAGES in a session is a bad idea, and if we want to do updates to the = CAP message, MSRP is the right answer. >>=20 >> I don't see the value in a "maybe I'll send media later" session. I = see no use case for that. >>=20 >> We do want to be able to include the CAP message in a regular (with = media) INVITE. That allows the sensor data AND the media ("Help I've = fallen and can't get up"). So a CAP message in a Body with SDP in an = INVITE or a CAP message in a MESSAGE with no SDP is what we want to = allow. >>=20 >> Brian >>=20 >> On Nov 12, 2012, at 11:28 AM, Paul Kyzivat = wrote: >>=20 >>> On 11/12/12 11:01 AM, Rosen, Brian wrote: >>>> The example is a sensor that detects some bad circumstance, but = continues to take readings and wants to send updates at some reasonable = rate. >>> That is a good example, and it would be good to have it in the = document. >>> ISTM that it doesn't clearly fit the mechanisms included in the = document. IIUC the doc includes two mechanisms: >>>=20 >>> - send a MESSAGE with no dialog, with the data in the MESSAGE body. >>>=20 >>> - send an INVITE with no media, with the data in the body of the = INVITE. >>> The session remains up for further use, but no mention of *what* = use. >>> In the case you describe above, how would the additional readings >>> be transmitted? In a MESSAGE within the dialog? In the body of a >>> reINVITE? This needs further explanation. >>>=20 >>> ISTM that if the *intent* is to establish a session in order to send = a sequence of data readings over time, then it would make sense to = establish an MSRP session and send them all (including the first) over = this channel. >>>=20 >>> OTOH, if there is a *single* data reading to transmit but there is a = desire to establish a session in order to facilitate later adding media = streams, then the mechanism in the document makes sense. In that case it = might be *better* to offer the media streams that *can be* supported, = either in inactive state, or with port set to zero. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> Brian >>>>=20 >>>> On Nov 12, 2012, at 10:34 AM, Paul Kyzivat = wrote: >>>>=20 >>>>> Gunnar, >>>>>=20 >>>>> On 11/9/12 6:19 PM, Gunnar Hellstr=F6m wrote: >>>>>> I see a slight protocol contradiction in section 4.1. >>>>>>=20 >>>>>> There it is said: "To convey CAP payloads the SIP MESSAGE = [RFC3428] is >>>>>> used for exchanges where no session establishment is needed, = i.e.., >>>>>> one-shot message exchange, and the SIP INVITE [RFC3261] where the >>>>>> establishment of session is useful (e.g., when multiple = independent >>>>>> messages have to be logically tied together). " >>>>>>=20 >>>>>> I wonder if RFC 3261 and RFC3264 allows setting up a session = without >>>>>> session description defined media. To me it seems that all = session need >>>>>> to have media agreed through session descriptions. >>>>>>=20 >>>>>> In RFC 3261 SIP, section 13.3.1.4, it is said: >>>>>>=20 >>>>>> "If the INVITE did >>>>>> not contain an offer, the 2xx MUST contain an offer if the UAS = had >>>>>> not yet sent an offer." >>>>>>=20 >>>>>> So, it seems that an Offer/Answer sequence is required. >>>>> Yes, to establish a session an O/A is required. >>>>>=20 >>>>>> And in RFC 3264 Offer/answer model, chapter 6.1, it is said: >>>>>> "If there are no media formats in common for all streams, the = entire >>>>>> offered session is rejected." >>>>> The above statement is a bit ambiguous wrt the degenerate case = where no streams are offered. (No m-lines in offer.) I would argue that = there *are* media formats in common for every offered stream, so the = "session is rejected" does not apply. In any case this statement is = non-normative. I have always thought that an answerer is free to keep = the session up with no media streams if that seems useful. >>>>>=20 >>>>> I do think it would be useful to provide an example of a Data-Only = Emergency call that establishes a session. Also, it would be helpful to = have an explanation of *why* one might want that session established. >>>>>=20 >>>>> I presume the idea is that there could then be a new O/A within = the session to establish media, without the need for a psap-callback. Is = that right? >>>>>=20 >>>>> Has any concern been given for cases where UDP must be used and = the messages are too big for that? It might be helpful in some cases to = establish a session with an MSRP stream and send the data over that. = That could also be helpful if the local sensors are capable of sending a = sequence of data readings rather than just one. >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>>> These rules taken together seem to result in that in order to set = up a session to convey a series of CAP MESSAGES, then some (e.g. dummy) = medium must be agreed also in a sessions description exchange. >>>>>>=20 >>>>>> This would mean that a session cannot be set up for only CAP = MESSAGE conveyance, but of course it is possible to have CAP messages = and some other useful media in the same session. >>>>>>=20 >>>>>> Do you agree in this conclusion? >>>>>>=20 >>>>>> Gunnar >>>>>>=20 >>>>>> ---- >>>>>>=20 >>>>>> On 2012-11-09 18:35, Marc Linsner wrote: >>>>>>> This start the WGLC for draft Data-Only Emergency Calls >>>>>>>=20 >>>>>>> The draft can be found at: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >>>>>>>=20 >>>>>>> Please review the draft and provide comments to the list before = COB on >>>>>>> November 23, 2012. >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> Marc & Roger >>>>>>>=20 >>>>>>>=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 >>>>> _______________________________________________ >>>>> 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 >> _______________________________________________ >> 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 Tue Nov 13 12:51:45 2012 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 F246021F8568 for ; Tue, 13 Nov 2012 12:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.385 X-Spam-Level: X-Spam-Status: No, score=-0.385 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyZ2RfzhInYd for ; Tue, 13 Nov 2012 12:51:44 -0800 (PST) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id E60B721F8564 for ; Tue, 13 Nov 2012 12:51:43 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta01.westchester.pa.mail.comcast.net with comcast id NzUi1k0040vyq2s518rjUa; Tue, 13 Nov 2012 20:51:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id P8rj1k0023ZTu2S3R8rjYU; Tue, 13 Nov 2012 20:51:43 +0000 Message-ID: <50A2B2DE.8000701@alum.mit.edu> Date: Tue, 13 Nov 2012 15:51:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: ecrit@ietf.org References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50A14404.9080503@omnitor.se> <8CB17972-4677-4CA0-BFB5-26E96F7A1C37@gmx.net> In-Reply-To: <8CB17972-4677-4CA0-BFB5-26E96F7A1C37@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 13 Nov 2012 20:51:45 -0000 On 11/13/12 12:58 PM, Hannes Tschofenig wrote: > Hi all, > > In the data-only ES document we have two use cases: > > Use Case #1: a one-shot MESSAGE with a body that contains a CAP message. > > There is no session concept there. There does not seem to be a problem with this approach. > > Use Case #2: a sequence of MESSAGE msgs > > The example that Brian mentioned on the mailing list is a sensor that detects some bad circumstance. It sends an alarm but continues to take readings and wants to send updates. We would like to to avoid the situation where messages end up at different places since they are addressed to the SOS URN. For this reason we thought that it would be good to use a session concept here. > > As Gunnar had pointed out that our understanding of how this would work contracts with existing specifications. Very good feedback, Gunnar. > > So, how do we address this feedback? I see three options. > > Option #1: Omit use case #2 from the document and just focus on the individually routed SIP MESSAGE payloads. > > Option #2: Include use case #2 by utilizing MSRP*, as suggested by Paul. > > Option #3: Limit use case #2 by using a CAP payload in a regular SIP INVITE (with media) > With this case it is not possible to use the CAP payloads alone without media. I'm not sure I understand what you are suggesting for #3. I think you are proposing to send subsequent CAP payloads in reINVITEs. I don't know what you mean "it is not possible to use the CAP payloads alone without media". Are you continuing the worry that some middlebox won't allow an INVITE without m-lines? I think that calls for more investigation before assuming. Option #4: Set up INVITE session (with or without media). Send subsequent CAP in INFO. (Maybe send first CAP in INFO too - your choice.) Thanks, Paul > I prefer option #3. > > Ciao > Hannes > > *: As we learned in discussions on a separate mailing list MSRP is actually not that difficult to implement when only focusing on the emergency services use case. > > On Nov 12, 2012, at 1:46 PM, Gunnar Hellström wrote: > >> Brian, you say: >> "We do want to be able to include the CAP message in a regular (with media) INVITE. That allows the sensor data AND the media ("Help I've fallen and can't get up"). So a CAP message in a Body with SDP in an INVITE or a CAP message in a MESSAGE with no SDP is what we want to allow." >> >> Good conclusion. >> >> Gunnar >> >> ___________________________________________________ >> Gunnar Hellström >> Omnitor >> gunnar.hellstrom@omnitor.se >> +46708204288 >> >> On 2012-11-12 19:35, Rosen, Brian wrote: >>> I should have expanded my answer, because I agree with you. >>> >>> Having talked it over with several SIP folks, the idea of multiple MESSAGES in a session is a bad idea, and if we want to do updates to the CAP message, MSRP is the right answer. >>> >>> I don't see the value in a "maybe I'll send media later" session. I see no use case for that. >>> >>> We do want to be able to include the CAP message in a regular (with media) INVITE. That allows the sensor data AND the media ("Help I've fallen and can't get up"). So a CAP message in a Body with SDP in an INVITE or a CAP message in a MESSAGE with no SDP is what we want to allow. >>> >>> Brian >>> >>> On Nov 12, 2012, at 11:28 AM, Paul Kyzivat wrote: >>> >>>> On 11/12/12 11:01 AM, Rosen, Brian wrote: >>>>> The example is a sensor that detects some bad circumstance, but continues to take readings and wants to send updates at some reasonable rate. >>>> That is a good example, and it would be good to have it in the document. >>>> ISTM that it doesn't clearly fit the mechanisms included in the document. IIUC the doc includes two mechanisms: >>>> >>>> - send a MESSAGE with no dialog, with the data in the MESSAGE body. >>>> >>>> - send an INVITE with no media, with the data in the body of the INVITE. >>>> The session remains up for further use, but no mention of *what* use. >>>> In the case you describe above, how would the additional readings >>>> be transmitted? In a MESSAGE within the dialog? In the body of a >>>> reINVITE? This needs further explanation. >>>> >>>> ISTM that if the *intent* is to establish a session in order to send a sequence of data readings over time, then it would make sense to establish an MSRP session and send them all (including the first) over this channel. >>>> >>>> OTOH, if there is a *single* data reading to transmit but there is a desire to establish a session in order to facilitate later adding media streams, then the mechanism in the document makes sense. In that case it might be *better* to offer the media streams that *can be* supported, either in inactive state, or with port set to zero. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Brian >>>>> >>>>> On Nov 12, 2012, at 10:34 AM, Paul Kyzivat wrote: >>>>> >>>>>> Gunnar, >>>>>> >>>>>> On 11/9/12 6:19 PM, Gunnar Hellström wrote: >>>>>>> I see a slight protocol contradiction in section 4.1. >>>>>>> >>>>>>> There it is said: "To convey CAP payloads the SIP MESSAGE [RFC3428] is >>>>>>> used for exchanges where no session establishment is needed, i.e.., >>>>>>> one-shot message exchange, and the SIP INVITE [RFC3261] where the >>>>>>> establishment of session is useful (e.g., when multiple independent >>>>>>> messages have to be logically tied together). " >>>>>>> >>>>>>> I wonder if RFC 3261 and RFC3264 allows setting up a session without >>>>>>> session description defined media. To me it seems that all session need >>>>>>> to have media agreed through session descriptions. >>>>>>> >>>>>>> In RFC 3261 SIP, section 13.3.1.4, it is said: >>>>>>> >>>>>>> "If the INVITE did >>>>>>> not contain an offer, the 2xx MUST contain an offer if the UAS had >>>>>>> not yet sent an offer." >>>>>>> >>>>>>> So, it seems that an Offer/Answer sequence is required. >>>>>> Yes, to establish a session an O/A is required. >>>>>> >>>>>>> And in RFC 3264 Offer/answer model, chapter 6.1, it is said: >>>>>>> "If there are no media formats in common for all streams, the entire >>>>>>> offered session is rejected." >>>>>> The above statement is a bit ambiguous wrt the degenerate case where no streams are offered. (No m-lines in offer.) I would argue that there *are* media formats in common for every offered stream, so the "session is rejected" does not apply. In any case this statement is non-normative. I have always thought that an answerer is free to keep the session up with no media streams if that seems useful. >>>>>> >>>>>> I do think it would be useful to provide an example of a Data-Only Emergency call that establishes a session. Also, it would be helpful to have an explanation of *why* one might want that session established. >>>>>> >>>>>> I presume the idea is that there could then be a new O/A within the session to establish media, without the need for a psap-callback. Is that right? >>>>>> >>>>>> Has any concern been given for cases where UDP must be used and the messages are too big for that? It might be helpful in some cases to establish a session with an MSRP stream and send the data over that. That could also be helpful if the local sensors are capable of sending a sequence of data readings rather than just one. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>>> These rules taken together seem to result in that in order to set up a session to convey a series of CAP MESSAGES, then some (e.g. dummy) medium must be agreed also in a sessions description exchange. >>>>>>> >>>>>>> This would mean that a session cannot be set up for only CAP MESSAGE conveyance, but of course it is possible to have CAP messages and some other useful media in the same session. >>>>>>> >>>>>>> Do you agree in this conclusion? >>>>>>> >>>>>>> Gunnar >>>>>>> >>>>>>> ---- >>>>>>> >>>>>>> On 2012-11-09 18:35, Marc Linsner wrote: >>>>>>>> This start the WGLC for draft Data-Only Emergency Calls >>>>>>>> >>>>>>>> The draft can be found at: >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >>>>>>>> >>>>>>>> Please review the draft and provide comments to the list before COB on >>>>>>>> November 23, 2012. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Marc & Roger >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>> _______________________________________________ >>> 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 RMarshall@telecomsys.com Tue Nov 13 15:34:28 2012 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 3835721F87BC for ; Tue, 13 Nov 2012 15:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.598 X-Spam-Level: X-Spam-Status: No, score=-104.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USOLS7iE9Du6 for ; Tue, 13 Nov 2012 15:34:26 -0800 (PST) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) by ietfa.amsl.com (Postfix) with ESMTP id F3F6521F8793 for ; Tue, 13 Nov 2012 15:34:25 -0800 (PST) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-02.telecomsys.com (8.14.1/8.14.1) with ESMTP id qADNYGBp000882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 13 Nov 2012 15:34:17 -0800 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.87]) by SEA-EXCAS-1.telecomsys.com ([::1]) with mapi id 14.01.0355.002; Tue, 13 Nov 2012 15:34:16 -0800 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: IETF85 - Atlanta: ECRIT Minutes for 11/08/2012 Thread-Index: Ac3B92RsZhoIC+vuSQi2H7wZhOn6EA== Date: Tue, 13 Nov 2012 23:34:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC17DBF7SEAEXMB2telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] IETF85 - Atlanta: ECRIT Minutes for 11/08/2012 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, 13 Nov 2012 23:34:28 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC17DBF7SEAEXMB2telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Minutes - ECRIT - IETF85, Atlanta Summary 1. Another revision to milestone dates will be posted, based on comments received in the working group meeting. It was agreed that a couple of milestone dates should be pulled in. 2. Brian Rosen agreed to update draft-ietf-ecrit-data-only-ea based on a quick review from Randy Gellens. ECRIT chairs agreed to submit draft-ietf-ecrit-data-only-ea for WGLC following above version update (done 11/09/2012). 3. Richard Barnes to draft a letter outlining two possible solutions, for Out of Jurisdiction Emergency Routing and rough-locaion draft, listing +/-'= s, with the intention to send it to ETSI as a contribution. 4. Individual ECRIT draft status as discussed in the meeting is available per Jean's well-captured notes below. -roger marshall. ECRIT Notes based on agenda at: http://www.ietf.org/proceedings/85/agenda/agenda-85-ecrit.txt Chairs: Marc Linsner, Roger Marshall Thursday, 13:00-15:00 Raw Notes from A. Jean Mahoney, ----------------------------------------------------- My notes are attached. Highlights below: WG Milestones: * draft-ietf-ecrit-data-only-ea - Brian will release a new draft. Randy can review it. Should be ready for wglc soon. * draft-ietf-ecrit-phonebcp - MISSREF issue has been resolved. * draft-ietf-ecrit-psap-callback - milestone should come before the trustworthy-location. * draft-ietf-ecrit-additional-data - milestone can be moved up, new version out soon and ready for wglc. Trustworthy location information * Clarify what "trustworthy" and "untrustworthy" mean. * Add more architecture info to section 2. * Expand discussion of bounding error (aka sanity check) * Improve the description of audit. * Cut section 5 to solution analysis only. * Describe that you don't know if headers are added by trusted proxies. * Abstract marking versus policy. PSAP Callbacks * The objection to the header field was retracted. * Read draft-roach-sipcore-priority - issues should be taken to the sipcore mailing list. Policy for defining new service-identifying labels * Should make this as quick and easy as possible using expert review rather than RFC. * Create a document to help the expert reviewer. * Provide guidance on how to use the registry * 2 classifications - general public and top-level domains. Extensions to the Emergency Services Architecture for dealing with Unauthe= nticated and Unauthorized Devices * Access network provides either a SIP proxy or registrar (current clients don't do discovery) Out of Jurisdiction Emergency Routing * LoST servers are not necessarily there. * Want the solution to be as close to LoST as possible to allow for interop and scalability. * Two approaches were discussed. * Present two approaches and their drawbacks to ETSI. * Too much in common with rough-loc to send rough-loc to WGLC. Jean CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC17DBF7SEAEXMB2telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Minutes - ECRIT - IETF85, Atlanta

 

Summary

 

1. Another revision to milestone dates will be poste= d, based on comments

received in the working group meeting. It was agreed= that a couple of

milestone dates should be pulled in.

 

2. Brian Rosen agreed to update draft-ietf-ecrit-dat= a-only-ea based on

a quick review from Randy Gellens.  ECRIT chair= s agreed to submit

draft-ietf-ecrit-data-only-ea for WGLC following abo= ve version update

(done 11/09/2012).

 

3. Richard Barnes to draft a letter outlining two po= ssible solutions, for

Out of Jurisdiction Emergency Routing and rough-loca= ion draft, listing +/-‘s,

with the intention to send it to ETSI as a contribut= ion.

 

4. Individual ECRIT draft status as discussed in the= meeting is available

per Jean's well-captured notes below.

 

-roger marshall.

 

 

ECRIT Notes based on agenda at:

http://www.ietf.org/proceedings/85/agenda/agenda-85-= ecrit.txt

 

Chairs: Marc Linsner, Roger Marshall

 

Thursday, 13:00-15:00

 

 

 

Raw Notes from A. Jean Mahoney, <mahoney@nostrum.= com>

----------------------------------------------------= -

 My notes are attached. Highlights below:<= /o:p>

 WG Milestones:

 * draft-ietf-ecrit-data-only-ea - Brian will r= elease a new draft.

   Randy can review it. Should be ready fo= r wglc soon.

* draft-ietf-ecrit-phonebcp - MISSREF issue has been= resolved.

* draft-ietf-ecrit-psap-callback - milestone should = come before the

   trustworthy-location.

* draft-ietf-ecrit-additional-data - milestone can b= e moved up, new

   version out soon and ready for wglc.

 

 Trustworthy location information

 * Clarify what "trustworthy" and &qu= ot;untrustworthy" mean.

* Add more architecture info to section 2.

* Expand discussion of bounding error (aka sanity ch= eck)

* Improve the description of audit.

* Cut section 5 to solution analysis only.

* Describe that you don't know if headers are added = by trusted proxies.

* Abstract marking versus policy.

 

 PSAP Callbacks

 * The objection to the header field was retrac= ted.

* Read draft-roach-sipcore-priority - issues should = be taken to the

   sipcore mailing list.

 

 Policy for defining new service-identifying la= bels

 * Should make this as quick and easy as possib= le using expert review

   rather than RFC.

* Create a document to help the expert reviewer.

* Provide guidance on how to use the registry

* 2 classifications - general public and top-level d= omains.

 

 Extensions to the Emergency Services Architect= ure for dealing with Unauthenticated and Unauthorized Devices

 * Access network provides either a SIP proxy o= r registrar (current

   clients don't do discovery)<= /p>

 

 Out of Jurisdiction Emergency Routing

 * LoST servers are not necessarily there.=

* Want the solution to be as close to LoST as possib= le to allow for

   interop and scalability.

* Two approaches were discussed.

* Present two approaches and their drawbacks to ETSI= .

* Too much in common with rough-loc to send rough-lo= c to WGLC.

 

 

 Jean

 <ecrit_session_notes.txt>

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC17DBF7SEAEXMB2telecomsy_-- From RMarshall@telecomsys.com Tue Nov 13 15:46:28 2012 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 2278221F87CD for ; Tue, 13 Nov 2012 15:46:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bUzDlpcOCyl for ; Tue, 13 Nov 2012 15:46:27 -0800 (PST) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) by ietfa.amsl.com (Postfix) with ESMTP id A17C321F84F6 for ; Tue, 13 Nov 2012 15:46:26 -0800 (PST) Received: from SEA-EXCAS-2.telecomsys.com (exc2010-local2.telecomsys.com [10.32.12.187]) by sea-mx-01.telecomsys.com (8.14.1/8.14.1) with ESMTP id qADNkETv026601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 13 Nov 2012 15:46:14 -0800 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.87]) by SEA-EXCAS-2.telecomsys.com ([10.32.12.187]) with mapi id 14.01.0355.002; Tue, 13 Nov 2012 15:46:14 -0800 From: Roger Marshall To: "ecrit@ietf.org" Thread-Topic: IETF85 - Atlanta: Updated Milestone dates Thread-Index: Ac3B+RBvuW/OMvffSIGnLQycZ9BB0w== Date: Tue, 13 Nov 2012 23:46:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC17DC3DSEAEXMB2telecomsy_" MIME-Version: 1.0 Subject: [Ecrit] IETF85 - Atlanta: Updated Milestone dates 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, 13 Nov 2012 23:46:28 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC17DC3DSEAEXMB2telecomsy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Based on IETF85 - Atlanta meeting minutes, the ECRIT chairs have updated milestone dates as below. Please make a note of each revised milestone date, and let us know of any errors or reasons otherwise that would warrant a change from these dates. MILESTONE updates as of 11/13/2012: Changed to: Done - Submit 'Synchronizing Location-to-Service Translation (LoST) Protocol based Service Boundaries and Mapping Elements' to the IESG for consideration as an Experimental RFC Changed to: Mar 2013 - Submit 'Using Imprecise Location for Emergency Call Routing' to the IESG for consideration as an Informational RFC Changed to: Jan 2013 - Submit 'Additional Data related to a Call for Emergency Call Purposes' to the IESG for consideration as a Standards Track RFC Changed to: Dec 2012 - Submit 'Common Alerting Protocol (CAP) based Data-Only Emergency Alerts using the Session Initiation Protocol (SIP)' to the IESG for consideration as an Experimental RFC Changed to: Dec 2013 - Submit 'Extensions to the Emergency Services Architecture for dealing with Unauthenticated and Unauthorized Devices' to the IESG for cons= ideration as a Standards Track RFC Changed to: Jun 2013 - Submit 'Trustworthy Location Information' to the IESG for consideration as an Informational RFC Changed to: Mar 2013 - Submit 'Public Safety Answering Point (PSAP) Callbacks' to the IESG for consideration as an Informational RFC Apr 2013 - Submit a draft 'Policy for defining new service identifying labels' to the IESG for consideration as BCP (no change) Roger Marshall & Marc Linsner ECRIT Chairs CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC17DC3DSEAEXMB2telecomsy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Based on IETF85 - Atlanta meeting minutes, the ECRIT= chairs have updated

milestone dates as below.

Please make a note of each revised milestone date, a= nd let us know of any

errors or reasons otherwise that would warrant a cha= nge from these dates.

 

MILESTONE updates as of 11/13/2012:

Changed to:

Done - Submit 'Synchronizing Location-to-Service Tra= nslation (LoST)

Protocol based Service Boundaries and Mapping Elemen= ts' to the IESG for

consideration as an Experimental RFC

Changed to:

Mar 2013 - Submit 'Using Imprecise Location for Emer= gency Call Routing'

to the IESG for consideration as an Informational RF= C

Changed to:

Jan 2013 - Submit 'Additional Data related to a Call= for Emergency Call

Purposes' to the IESG for consideration as a Standar= ds Track RFC

Changed to:

Dec 2012 - Submit 'Common Alerting Protocol (CAP) ba= sed Data-Only Emergency

Alerts using the Session Initiation Protocol (SIP)' = to the IESG for

consideration as an Experimental RFC

 

Changed to:

Dec 2013 - Submit 'Extensions to the Emergency Servi= ces Architecture for

dealing with Unauthenticated and Unauthorized Device= s' to the IESG for consideration as a Standards Track RFC

Changed to:

Jun 2013 - Submit 'Trustworthy Location Information'= to the IESG for

consideration as an Informational RFC

Changed to:

Mar 2013 - Submit 'Public Safety Answering Point (PS= AP) Callbacks' to the

IESG for consideration as an Informational RFC<= /o:p>

Apr 2013 - Submit a draft 'Policy for defining new s= ervice identifying

labels' to the IESG for consideration as BCP (no cha= nge)

 

Roger Marshall & Marc Linsner

ECRIT Chairs

CONFIDENTIALITY NOTIC= E: The information contained in this message may be privileged and/or confi= dential. If you are not the intended recipient, or responsible for deliveri= ng this message to the intended recipient, any review, forwarding, dissemin= ation, distribution or copying of this communication or any attachment(s) i= s strictly prohibited. If you have received this message in error, please n= otify the sender immediately, and delete it and all attachments from your c= omputer and network.

--_000_FBD5AAFFD0978846BF6D3FAB4C892ACC17DC3DSEAEXMB2telecomsy_-- From hannes.tschofenig@gmx.net Tue Nov 13 19:46:50 2012 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 CCE0321F86F8 for ; Tue, 13 Nov 2012 19:46: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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tti+oPFrQ7d4 for ; Tue, 13 Nov 2012 19:46: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 1412C21F8479 for ; Tue, 13 Nov 2012 19:46:47 -0800 (PST) Received: (qmail invoked by alias); 14 Nov 2012 03:46:43 -0000 Received: from 70-91-193-41-BusName-NewEngland.hfc.comcastbusiness.net (EHLO [192.168.2.103]) [70.91.193.41] by mail.gmx.net (mp028) with SMTP; 14 Nov 2012 04:46:43 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18yCkQ6nhgywn/Hv5hqlA0nX3VWoIACl0oErv4j7I 3XPPeruS4UYTQp Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: <50A2B2DE.8000701@alum.mit.edu> Date: Tue, 13 Nov 2012 22:46:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <565F197B-BA19-47D0-9C82-65889C35DFE3@gmx.net> References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50A14404.9080503@omnitor.se> <8CB17972-4677-4CA0-BFB5-26E96F7A1C37@gmx.net> <50A2B2DE.8000701@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 14 Nov 2012 03:46:50 -0000 Hi Paul,=20 see my response below.=20 On Nov 13, 2012, at 3:51 PM, Paul Kyzivat wrote: > On 11/13/12 12:58 PM, Hannes Tschofenig wrote: >> Hi all, >>=20 >> In the data-only ES document we have two use cases: >>=20 >> Use Case #1: a one-shot MESSAGE with a body that contains a CAP = message. >>=20 >> There is no session concept there. There does not seem to be a = problem with this approach. >>=20 >> Use Case #2: a sequence of MESSAGE msgs >>=20 >> The example that Brian mentioned on the mailing list is a sensor that = detects some bad circumstance. It sends an alarm but continues to take = readings and wants to send updates. We would like to to avoid the = situation where messages end up at different places since they are = addressed to the SOS URN. For this reason we thought that it would be = good to use a session concept here. >>=20 >> As Gunnar had pointed out that our understanding of how this would = work contracts with existing specifications. Very good feedback, Gunnar. >>=20 >> So, how do we address this feedback? I see three options. >>=20 >> Option #1: Omit use case #2 from the document and just focus on the = individually routed SIP MESSAGE payloads. >>=20 >> Option #2: Include use case #2 by utilizing MSRP*, as suggested by = Paul. >>=20 >> Option #3: Limit use case #2 by using a CAP payload in a regular SIP = INVITE (with media) >> With this case it is not possible to use the CAP payloads alone = without media. >=20 > I'm not sure I understand what you are suggesting for #3. I think you = are proposing to send subsequent CAP payloads in reINVITEs. I don't know = what you mean "it is not possible to use the CAP payloads alone without = media".=20 Actually, in option #3 there are no subsequent re-INVITEs. Option #3 = just documents that the CAP payload can also be used with an INVITE that = carries media.=20 > Are you continuing the worry that some middlebox won't allow an INVITE = without m-lines? I think that calls for more investigation before = assuming. I don't know whether the INVITE + CAP payload + SDP payload without = m-lines and using MESSAGE msgs for subsequent CAP messages within the = same dialog actually works in existing deployments.=20 >=20 > Option #4: Set up INVITE session (with or without media). Send = subsequent CAP in INFO. (Maybe send first CAP in INFO too - your = choice.) In this case I guess you are assuming that the SDP is again without = m-lines. Right?=20 Ciao Hannes >=20 > Thanks, > Paul >=20 >> I prefer option #3. >>=20 >> Ciao >> Hannes >>=20 >> *: As we learned in discussions on a separate mailing list MSRP is = actually not that difficult to implement when only focusing on the = emergency services use case. >>=20 >> On Nov 12, 2012, at 1:46 PM, Gunnar Hellstr=F6m wrote: >>=20 >>> Brian, you say: >>> "We do want to be able to include the CAP message in a regular (with = media) INVITE. That allows the sensor data AND the media ("Help I've = fallen and can't get up"). So a CAP message in a Body with SDP in an = INVITE or a CAP message in a MESSAGE with no SDP is what we want to = allow." >>>=20 >>> Good conclusion. >>>=20 >>> Gunnar >>>=20 >>> ___________________________________________________ >>> Gunnar Hellstr=F6m >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46708204288 >>>=20 >>> On 2012-11-12 19:35, Rosen, Brian wrote: >>>> I should have expanded my answer, because I agree with you. >>>>=20 >>>> Having talked it over with several SIP folks, the idea of multiple = MESSAGES in a session is a bad idea, and if we want to do updates to the = CAP message, MSRP is the right answer. >>>>=20 >>>> I don't see the value in a "maybe I'll send media later" session. = I see no use case for that. >>>>=20 >>>> We do want to be able to include the CAP message in a regular (with = media) INVITE. That allows the sensor data AND the media ("Help I've = fallen and can't get up"). So a CAP message in a Body with SDP in an = INVITE or a CAP message in a MESSAGE with no SDP is what we want to = allow. >>>>=20 >>>> Brian >>>>=20 >>>> On Nov 12, 2012, at 11:28 AM, Paul Kyzivat = wrote: >>>>=20 >>>>> On 11/12/12 11:01 AM, Rosen, Brian wrote: >>>>>> The example is a sensor that detects some bad circumstance, but = continues to take readings and wants to send updates at some reasonable = rate. >>>>> That is a good example, and it would be good to have it in the = document. >>>>> ISTM that it doesn't clearly fit the mechanisms included in the = document. IIUC the doc includes two mechanisms: >>>>>=20 >>>>> - send a MESSAGE with no dialog, with the data in the MESSAGE = body. >>>>>=20 >>>>> - send an INVITE with no media, with the data in the body of the = INVITE. >>>>> The session remains up for further use, but no mention of *what* = use. >>>>> In the case you describe above, how would the additional readings >>>>> be transmitted? In a MESSAGE within the dialog? In the body of a >>>>> reINVITE? This needs further explanation. >>>>>=20 >>>>> ISTM that if the *intent* is to establish a session in order to = send a sequence of data readings over time, then it would make sense to = establish an MSRP session and send them all (including the first) over = this channel. >>>>>=20 >>>>> OTOH, if there is a *single* data reading to transmit but there is = a desire to establish a session in order to facilitate later adding = media streams, then the mechanism in the document makes sense. In that = case it might be *better* to offer the media streams that *can be* = supported, either in inactive state, or with port set to zero. >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Nov 12, 2012, at 10:34 AM, Paul Kyzivat = wrote: >>>>>>=20 >>>>>>> Gunnar, >>>>>>>=20 >>>>>>> On 11/9/12 6:19 PM, Gunnar Hellstr=F6m wrote: >>>>>>>> I see a slight protocol contradiction in section 4.1. >>>>>>>>=20 >>>>>>>> There it is said: "To convey CAP payloads the SIP MESSAGE = [RFC3428] is >>>>>>>> used for exchanges where no session establishment is needed, = i.e.., >>>>>>>> one-shot message exchange, and the SIP INVITE [RFC3261] where = the >>>>>>>> establishment of session is useful (e.g., when multiple = independent >>>>>>>> messages have to be logically tied together). " >>>>>>>>=20 >>>>>>>> I wonder if RFC 3261 and RFC3264 allows setting up a session = without >>>>>>>> session description defined media. To me it seems that all = session need >>>>>>>> to have media agreed through session descriptions. >>>>>>>>=20 >>>>>>>> In RFC 3261 SIP, section 13.3.1.4, it is said: >>>>>>>>=20 >>>>>>>> "If the INVITE did >>>>>>>> not contain an offer, the 2xx MUST contain an offer if the = UAS had >>>>>>>> not yet sent an offer." >>>>>>>>=20 >>>>>>>> So, it seems that an Offer/Answer sequence is required. >>>>>>> Yes, to establish a session an O/A is required. >>>>>>>=20 >>>>>>>> And in RFC 3264 Offer/answer model, chapter 6.1, it is said: >>>>>>>> "If there are no media formats in common for all streams, the = entire >>>>>>>> offered session is rejected." >>>>>>> The above statement is a bit ambiguous wrt the degenerate case = where no streams are offered. (No m-lines in offer.) I would argue that = there *are* media formats in common for every offered stream, so the = "session is rejected" does not apply. In any case this statement is = non-normative. I have always thought that an answerer is free to keep = the session up with no media streams if that seems useful. >>>>>>>=20 >>>>>>> I do think it would be useful to provide an example of a = Data-Only Emergency call that establishes a session. Also, it would be = helpful to have an explanation of *why* one might want that session = established. >>>>>>>=20 >>>>>>> I presume the idea is that there could then be a new O/A within = the session to establish media, without the need for a psap-callback. Is = that right? >>>>>>>=20 >>>>>>> Has any concern been given for cases where UDP must be used and = the messages are too big for that? It might be helpful in some cases to = establish a session with an MSRP stream and send the data over that. = That could also be helpful if the local sensors are capable of sending a = sequence of data readings rather than just one. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Paul >>>>>>>=20 >>>>>>>> These rules taken together seem to result in that in order to = set up a session to convey a series of CAP MESSAGES, then some (e.g. = dummy) medium must be agreed also in a sessions description exchange. >>>>>>>>=20 >>>>>>>> This would mean that a session cannot be set up for only CAP = MESSAGE conveyance, but of course it is possible to have CAP messages = and some other useful media in the same session. >>>>>>>>=20 >>>>>>>> Do you agree in this conclusion? >>>>>>>>=20 >>>>>>>> Gunnar >>>>>>>>=20 >>>>>>>> ---- >>>>>>>>=20 >>>>>>>> On 2012-11-09 18:35, Marc Linsner wrote: >>>>>>>>> This start the WGLC for draft Data-Only Emergency Calls >>>>>>>>>=20 >>>>>>>>> The draft can be found at: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >>>>>>>>>=20 >>>>>>>>> Please review the draft and provide comments to the list = before COB on >>>>>>>>> November 23, 2012. >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>>=20 >>>>>>>>> Marc & Roger >>>>>>>>>=20 >>>>>>>>>=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 >>>>>>> _______________________________________________ >>>>>>> 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 >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 brian.rosen@neustar.biz Wed Nov 14 06:52:43 2012 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 531C921F85C7 for ; Wed, 14 Nov 2012 06:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RW2CsAe+qqyP for ; Wed, 14 Nov 2012 06:52:42 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7D39A21F85A5 for ; Wed, 14 Nov 2012 06:52:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1352904955; x=1668255501; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=A43Ci6Ai3x96og7RPYbKg JMCP/cMvpBChD1awnP5db0=; b=WRLEKbBawCt+472iKn5GoZX0R5zd5nD70X9nR OcCWpnIsXjV07fRzgm3cnmnuIJOnbDkoUIdYRxaIE/k0qTWnQ== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.16238849; Wed, 14 Nov 2012 09:55:54 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 14 Nov 2012 09:52:34 -0500 From: "Rosen, Brian" To: Hannes Tschofenig Date: Wed, 14 Nov 2012 09:52:33 -0500 Thread-Topic: [Ecrit] WGLC - Data-Only Emergency Calls Thread-Index: Ac3Cd62CB8qjk6slTcWvKRGirDfBOg== Message-ID: <64B36206-16D8-40C6-9073-C9DD5D94FEEA@neustar.biz> References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50A14404.9080503@omnitor.se> <8CB17972-4677-4CA0-BFB5-26E96F7A1C37@gmx.net> <50A2B2DE.8000701@alum.mit.edu> <565F197B-BA19-47D0-9C82-65889C35DFE3@gmx.net> In-Reply-To: <565F197B-BA19-47D0-9C82-65889C35DFE3@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: gVb2oDLMwsOJiq7etpC/Bw== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 14 Nov 2012 14:52:43 -0000 Option 4: both 2 and 3 We want to show how to do updates or stream of sensor data. We also want to show how you do the CAP + media. Brian On Nov 13, 2012, at 10:46 PM, Hannes Tschofenig = wrote: > Hi Paul,=20 >=20 > see my response below.=20 >=20 > On Nov 13, 2012, at 3:51 PM, Paul Kyzivat wrote: >=20 >> On 11/13/12 12:58 PM, Hannes Tschofenig wrote: >>> Hi all, >>>=20 >>> In the data-only ES document we have two use cases: >>>=20 >>> Use Case #1: a one-shot MESSAGE with a body that contains a CAP message= . >>>=20 >>> There is no session concept there. There does not seem to be a problem = with this approach. >>>=20 >>> Use Case #2: a sequence of MESSAGE msgs >>>=20 >>> The example that Brian mentioned on the mailing list is a sensor that d= etects some bad circumstance. It sends an alarm but continues to take readi= ngs and wants to send updates. We would like to to avoid the situation wher= e messages end up at different places since they are addressed to the SOS U= RN. For this reason we thought that it would be good to use a session conce= pt here. >>>=20 >>> As Gunnar had pointed out that our understanding of how this would work= contracts with existing specifications. Very good feedback, Gunnar. >>>=20 >>> So, how do we address this feedback? I see three options. >>>=20 >>> Option #1: Omit use case #2 from the document and just focus on the ind= ividually routed SIP MESSAGE payloads. >>>=20 >>> Option #2: Include use case #2 by utilizing MSRP*, as suggested by Paul= . >>>=20 >>> Option #3: Limit use case #2 by using a CAP payload in a regular SIP IN= VITE (with media) >>> With this case it is not possible to use the CAP payloads alone without= media. >>=20 >> I'm not sure I understand what you are suggesting for #3. I think you ar= e proposing to send subsequent CAP payloads in reINVITEs. I don't know what= you mean "it is not possible to use the CAP payloads alone without media".= =20 >=20 > Actually, in option #3 there are no subsequent re-INVITEs. Option #3 just= documents that the CAP payload can also be used with an INVITE that carrie= s media.=20 >=20 >> Are you continuing the worry that some middlebox won't allow an INVITE w= ithout m-lines? I think that calls for more investigation before assuming. >=20 > I don't know whether the INVITE + CAP payload + SDP payload without m-lin= es and using MESSAGE msgs for subsequent CAP messages within the same dialo= g actually works in existing deployments.=20 >=20 >>=20 >> Option #4: Set up INVITE session (with or without media). Send subsequen= t CAP in INFO. (Maybe send first CAP in INFO too - your choice.) >=20 >=20 > In this case I guess you are assuming that the SDP is again without m-lin= es. Right?=20 >=20 > Ciao > Hannes >=20 >>=20 >> Thanks, >> Paul >>=20 >>> I prefer option #3. >>>=20 >>> Ciao >>> Hannes >>>=20 >>> *: As we learned in discussions on a separate mailing list MSRP is actu= ally not that difficult to implement when only focusing on the emergency se= rvices use case. >>>=20 >>> On Nov 12, 2012, at 1:46 PM, Gunnar Hellstr=F6m wrote: >>>=20 >>>> Brian, you say: >>>> "We do want to be able to include the CAP message in a regular (with m= edia) INVITE. That allows the sensor data AND the media ("Help I've fallen = and can't get up"). So a CAP message in a Body with SDP in an INVITE or a C= AP message in a MESSAGE with no SDP is what we want to allow." >>>>=20 >>>> Good conclusion. >>>>=20 >>>> Gunnar >>>>=20 >>>> ___________________________________________________ >>>> Gunnar Hellstr=F6m >>>> Omnitor >>>> gunnar.hellstrom@omnitor.se >>>> +46708204288 >>>>=20 >>>> On 2012-11-12 19:35, Rosen, Brian wrote: >>>>> I should have expanded my answer, because I agree with you. >>>>>=20 >>>>> Having talked it over with several SIP folks, the idea of multiple ME= SSAGES in a session is a bad idea, and if we want to do updates to the CAP = message, MSRP is the right answer. >>>>>=20 >>>>> I don't see the value in a "maybe I'll send media later" session. I = see no use case for that. >>>>>=20 >>>>> We do want to be able to include the CAP message in a regular (with m= edia) INVITE. That allows the sensor data AND the media ("Help I've fallen= and can't get up"). So a CAP message in a Body with SDP in an INVITE or a= CAP message in a MESSAGE with no SDP is what we want to allow. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Nov 12, 2012, at 11:28 AM, Paul Kyzivat wr= ote: >>>>>=20 >>>>>> On 11/12/12 11:01 AM, Rosen, Brian wrote: >>>>>>> The example is a sensor that detects some bad circumstance, but con= tinues to take readings and wants to send updates at some reasonable rate. >>>>>> That is a good example, and it would be good to have it in the docum= ent. >>>>>> ISTM that it doesn't clearly fit the mechanisms included in the docu= ment. IIUC the doc includes two mechanisms: >>>>>>=20 >>>>>> - send a MESSAGE with no dialog, with the data in the MESSAGE body. >>>>>>=20 >>>>>> - send an INVITE with no media, with the data in the body of the INV= ITE. >>>>>> The session remains up for further use, but no mention of *what* use= . >>>>>> In the case you describe above, how would the additional readings >>>>>> be transmitted? In a MESSAGE within the dialog? In the body of a >>>>>> reINVITE? This needs further explanation. >>>>>>=20 >>>>>> ISTM that if the *intent* is to establish a session in order to send= a sequence of data readings over time, then it would make sense to establi= sh an MSRP session and send them all (including the first) over this channe= l. >>>>>>=20 >>>>>> OTOH, if there is a *single* data reading to transmit but there is a= desire to establish a session in order to facilitate later adding media st= reams, then the mechanism in the document makes sense. In that case it migh= t be *better* to offer the media streams that *can be* supported, either in= inactive state, or with port set to zero. >>>>>>=20 >>>>>> Thanks, >>>>>> Paul >>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Nov 12, 2012, at 10:34 AM, Paul Kyzivat = wrote: >>>>>>>=20 >>>>>>>> Gunnar, >>>>>>>>=20 >>>>>>>> On 11/9/12 6:19 PM, Gunnar Hellstr=F6m wrote: >>>>>>>>> I see a slight protocol contradiction in section 4.1. >>>>>>>>>=20 >>>>>>>>> There it is said: "To convey CAP payloads the SIP MESSAGE [RFC342= 8] is >>>>>>>>> used for exchanges where no session establishment is needed, i.e.= ., >>>>>>>>> one-shot message exchange, and the SIP INVITE [RFC3261] where the >>>>>>>>> establishment of session is useful (e.g., when multiple independe= nt >>>>>>>>> messages have to be logically tied together). " >>>>>>>>>=20 >>>>>>>>> I wonder if RFC 3261 and RFC3264 allows setting up a session with= out >>>>>>>>> session description defined media. To me it seems that all sessio= n need >>>>>>>>> to have media agreed through session descriptions. >>>>>>>>>=20 >>>>>>>>> In RFC 3261 SIP, section 13.3.1.4, it is said: >>>>>>>>>=20 >>>>>>>>> "If the INVITE did >>>>>>>>> not contain an offer, the 2xx MUST contain an offer if the UAS = had >>>>>>>>> not yet sent an offer." >>>>>>>>>=20 >>>>>>>>> So, it seems that an Offer/Answer sequence is required. >>>>>>>> Yes, to establish a session an O/A is required. >>>>>>>>=20 >>>>>>>>> And in RFC 3264 Offer/answer model, chapter 6.1, it is said: >>>>>>>>> "If there are no media formats in common for all streams, the ent= ire >>>>>>>>> offered session is rejected." >>>>>>>> The above statement is a bit ambiguous wrt the degenerate case whe= re no streams are offered. (No m-lines in offer.) I would argue that there = *are* media formats in common for every offered stream, so the "session is = rejected" does not apply. In any case this statement is non-normative. I ha= ve always thought that an answerer is free to keep the session up with no m= edia streams if that seems useful. >>>>>>>>=20 >>>>>>>> I do think it would be useful to provide an example of a Data-Only= Emergency call that establishes a session. Also, it would be helpful to ha= ve an explanation of *why* one might want that session established. >>>>>>>>=20 >>>>>>>> I presume the idea is that there could then be a new O/A within th= e session to establish media, without the need for a psap-callback. Is that= right? >>>>>>>>=20 >>>>>>>> Has any concern been given for cases where UDP must be used and th= e messages are too big for that? It might be helpful in some cases to estab= lish a session with an MSRP stream and send the data over that. That could = also be helpful if the local sensors are capable of sending a sequence of d= ata readings rather than just one. >>>>>>>>=20 >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>>=20 >>>>>>>>> These rules taken together seem to result in that in order to set= up a session to convey a series of CAP MESSAGES, then some (e.g. dummy) me= dium must be agreed also in a sessions description exchange. >>>>>>>>>=20 >>>>>>>>> This would mean that a session cannot be set up for only CAP MESS= AGE conveyance, but of course it is possible to have CAP messages and some = other useful media in the same session. >>>>>>>>>=20 >>>>>>>>> Do you agree in this conclusion? >>>>>>>>>=20 >>>>>>>>> Gunnar >>>>>>>>>=20 >>>>>>>>> ---- >>>>>>>>>=20 >>>>>>>>> On 2012-11-09 18:35, Marc Linsner wrote: >>>>>>>>>> This start the WGLC for draft Data-Only Emergency Calls >>>>>>>>>>=20 >>>>>>>>>> The draft can be found at: >>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >>>>>>>>>>=20 >>>>>>>>>> Please review the draft and provide comments to the list before = COB on >>>>>>>>>> November 23, 2012. >>>>>>>>>>=20 >>>>>>>>>> Thanks, >>>>>>>>>>=20 >>>>>>>>>> Marc & Roger >>>>>>>>>>=20 >>>>>>>>>>=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 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>> _______________________________________________ >>>>> 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 >>> _______________________________________________ >>> 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 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Wed Nov 14 07:38:35 2012 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 D56B921F87B7 for ; Wed, 14 Nov 2012 07:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1Ysa+z6-KCo for ; Wed, 14 Nov 2012 07:38:35 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 3F83A21F8651 for ; Wed, 14 Nov 2012 07:38:35 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta05.westchester.pa.mail.comcast.net with comcast id PPNr1k0071wpRvQ55Teajf; Wed, 14 Nov 2012 15:38:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id PTea1k00V3ZTu2S3eTeaqu; Wed, 14 Nov 2012 15:38:34 +0000 Message-ID: <50A3BAF9.9030706@alum.mit.edu> Date: Wed, 14 Nov 2012 10:38:33 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50A14404.9080503@omnitor.se> <8CB17972-4677-4CA0-BFB5-26E96F7A1C37@gmx.net> <50A2B2DE.8000701@alum.mit.edu> <565F197B-BA19-47D0-9C82-65889C35DFE3@gmx.net> In-Reply-To: <565F197B-BA19-47D0-9C82-65889C35DFE3@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 14 Nov 2012 15:38:35 -0000 On 11/13/12 10:46 PM, Hannes Tschofenig wrote: >> Option #4: Set up INVITE session (with or without media). Send subsequent CAP in INFO. (Maybe send first CAP in INFO too - your choice.) > > > In this case I guess you are assuming that the SDP is again without m-lines. Right? Yes. Thanks, Paul From bernard_aboba@hotmail.com Thu Nov 15 08:18:57 2012 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 9E80521F888C for ; Thu, 15 Nov 2012 08:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.097 X-Spam-Level: X-Spam-Status: No, score=-102.097 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8Fv7aLLaE8d for ; Thu, 15 Nov 2012 08:18:56 -0800 (PST) Received: from blu0-omc3-s4.blu0.hotmail.com (blu0-omc3-s4.blu0.hotmail.com [65.55.116.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0D721F85CD for ; Thu, 15 Nov 2012 08:18:56 -0800 (PST) Received: from BLU402-EAS193 ([65.55.116.74]) by blu0-omc3-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Nov 2012 08:18:54 -0800 X-Originating-IP: [24.16.96.166] X-EIP: [eBsIEKiveYiGNMIwLFRMZp8y+S1NW4XB] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50A14404.9080503@omnitor.se> <8CB17972-4677-4CA0-BFB5-26E96F7A1C37@gmx.net> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <8CB17972-4677-4CA0-BFB5-26E96F7A1C37@gmx.net> Date: Wed, 14 Nov 2012 10:51:17 -0800 To: Hannes Tschofenig X-OriginalArrivalTime: 15 Nov 2012 16:18:54.0742 (UTC) FILETIME=[E8642360:01CDC34C] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 15 Nov 2012 16:18:57 -0000 SWYgdGhlIHNjZW5hcmlvIGlzIHVwZGF0aW5nIHRoZSBQU0FQIG9uIGRldmVsb3BtZW50cywgY29u dGludWluZyBub3RpZmljYXRpb24gdmlhIGFueSBvcHRpb24gaXMgbm90IHRoZSBiZXN0IGNob2lj ZSwgYmVjYXVzZSBpdCBjYW4gYWRkIGxvYWQgd2l0aG91dCBuZWNlc3NhcmlseSBwcm92aWRpbmcg aW5mbyB0aGF0IHRoZSBQU0FQIG5lZWRzIG9yIGNhcmVzIGFib3V0LiBQcm92aWRpbmcgdGhlIFBT QVAgd2l0aCBhIGxpbmsgd2hpY2ggaXQgY2FuIGFjY2VzcyB0byBnZXQgbW9yZSBpbmZvIG1heSBt YWtlIG1vcmUgc2Vuc2UuDQoNCk9uIE5vdiAxMywgMjAxMiwgYXQgOTo1OCwgIkhhbm5lcyBUc2No b2ZlbmlnIiA8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4gd3JvdGU6DQoNCj4gSGkgYWxsLCAN Cj4gDQo+IEluIHRoZSBkYXRhLW9ubHkgRVMgZG9jdW1lbnQgd2UgaGF2ZSB0d28gdXNlIGNhc2Vz Og0KPiANCj4gVXNlIENhc2UgIzE6IGEgb25lLXNob3QgTUVTU0FHRSB3aXRoIGEgYm9keSB0aGF0 IGNvbnRhaW5zIGEgQ0FQIG1lc3NhZ2UuDQo+IA0KPiBUaGVyZSBpcyBubyBzZXNzaW9uIGNvbmNl cHQgdGhlcmUuIFRoZXJlIGRvZXMgbm90IHNlZW0gdG8gYmUgYSBwcm9ibGVtIHdpdGggdGhpcyBh cHByb2FjaC4gDQo+IA0KPiBVc2UgQ2FzZSAjMjogYSBzZXF1ZW5jZSBvZiBNRVNTQUdFIG1zZ3MN Cj4gDQo+IFRoZSBleGFtcGxlIHRoYXQgQnJpYW4gbWVudGlvbmVkIG9uIHRoZSBtYWlsaW5nIGxp c3QgaXMgYSBzZW5zb3IgdGhhdCBkZXRlY3RzIHNvbWUgYmFkIGNpcmN1bXN0YW5jZS4gSXQgc2Vu ZHMgYW4gYWxhcm0gYnV0IGNvbnRpbnVlcyB0byB0YWtlIHJlYWRpbmdzIGFuZCB3YW50cyB0byBz ZW5kIHVwZGF0ZXMuIFdlIHdvdWxkIGxpa2UgdG8gdG8gYXZvaWQgdGhlIHNpdHVhdGlvbiB3aGVy ZSBtZXNzYWdlcyBlbmQgdXAgYXQgZGlmZmVyZW50IHBsYWNlcyBzaW5jZSB0aGV5IGFyZSBhZGRy ZXNzZWQgdG8gdGhlIFNPUyBVUk4uIEZvciB0aGlzIHJlYXNvbiB3ZSB0aG91Z2h0IHRoYXQgaXQg d291bGQgYmUgZ29vZCB0byB1c2UgYSBzZXNzaW9uIGNvbmNlcHQgaGVyZS4gDQo+IA0KPiBBcyBH dW5uYXIgaGFkIHBvaW50ZWQgb3V0IHRoYXQgb3VyIHVuZGVyc3RhbmRpbmcgb2YgaG93IHRoaXMg d291bGQgd29yayBjb250cmFjdHMgd2l0aCBleGlzdGluZyBzcGVjaWZpY2F0aW9ucy4gVmVyeSBn b29kIGZlZWRiYWNrLCBHdW5uYXIuIA0KPiANCj4gU28sIGhvdyBkbyB3ZSBhZGRyZXNzIHRoaXMg ZmVlZGJhY2s/IEkgc2VlIHRocmVlIG9wdGlvbnMuIA0KPiANCj4gT3B0aW9uICMxOiBPbWl0IHVz ZSBjYXNlICMyIGZyb20gdGhlIGRvY3VtZW50IGFuZCBqdXN0IGZvY3VzIG9uIHRoZSBpbmRpdmlk dWFsbHkgcm91dGVkIFNJUCBNRVNTQUdFIHBheWxvYWRzLiANCj4gDQo+IE9wdGlvbiAjMjogSW5j bHVkZSB1c2UgY2FzZSAjMiBieSB1dGlsaXppbmcgTVNSUCosIGFzIHN1Z2dlc3RlZCBieSBQYXVs LiANCj4gDQo+IE9wdGlvbiAjMzogTGltaXQgdXNlIGNhc2UgIzIgYnkgdXNpbmcgYSBDQVAgcGF5 bG9hZCBpbiBhIHJlZ3VsYXIgU0lQIElOVklURSAod2l0aCBtZWRpYSkNCj4gV2l0aCB0aGlzIGNh c2UgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHVzZSB0aGUgQ0FQIHBheWxvYWRzIGFsb25lIHdpdGhv dXQgbWVkaWEuICANCj4gDQo+IEkgcHJlZmVyIG9wdGlvbiAjMy4gDQo+IA0KPiBDaWFvDQo+IEhh bm5lcw0KPiANCj4gKjogQXMgd2UgbGVhcm5lZCBpbiBkaXNjdXNzaW9ucyBvbiBhIHNlcGFyYXRl IG1haWxpbmcgbGlzdCBNU1JQIGlzIGFjdHVhbGx5IG5vdCB0aGF0IGRpZmZpY3VsdCB0byBpbXBs ZW1lbnQgd2hlbiBvbmx5IGZvY3VzaW5nIG9uIHRoZSBlbWVyZ2VuY3kgc2VydmljZXMgdXNlIGNh c2UuIA0KPiANCj4gT24gTm92IDEyLCAyMDEyLCBhdCAxOjQ2IFBNLCBHdW5uYXIgSGVsbHN0csO2 bSB3cm90ZToNCj4gDQo+PiBCcmlhbiwgeW91IHNheToNCj4+ICJXZSBkbyB3YW50IHRvIGJlIGFi bGUgdG8gaW5jbHVkZSB0aGUgQ0FQIG1lc3NhZ2UgaW4gYSByZWd1bGFyICh3aXRoIG1lZGlhKSBJ TlZJVEUuIFRoYXQgYWxsb3dzIHRoZSBzZW5zb3IgZGF0YSBBTkQgdGhlIG1lZGlhICgiSGVscCBJ J3ZlIGZhbGxlbiBhbmQgY2FuJ3QgZ2V0IHVwIikuIFNvIGEgQ0FQIG1lc3NhZ2UgaW4gYSBCb2R5 IHdpdGggU0RQIGluIGFuIElOVklURSBvciBhIENBUCBtZXNzYWdlIGluIGEgTUVTU0FHRSB3aXRo IG5vIFNEUCBpcyB3aGF0IHdlIHdhbnQgdG8gYWxsb3cuIg0KPj4gDQo+PiBHb29kIGNvbmNsdXNp b24uDQo+PiANCj4+IEd1bm5hcg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IEd1bm5hciBIZWxsc3Ryw7ZtDQo+PiBPbW5pdG9y DQo+PiBndW5uYXIuaGVsbHN0cm9tQG9tbml0b3Iuc2UNCj4+ICs0NjcwODIwNDI4OA0KPj4gDQo+ PiBPbiAyMDEyLTExLTEyIDE5OjM1LCBSb3NlbiwgQnJpYW4gd3JvdGU6DQo+Pj4gSSBzaG91bGQg aGF2ZSBleHBhbmRlZCBteSBhbnN3ZXIsIGJlY2F1c2UgSSBhZ3JlZSB3aXRoIHlvdS4NCj4+PiAN Cj4+PiBIYXZpbmcgdGFsa2VkIGl0IG92ZXIgd2l0aCBzZXZlcmFsIFNJUCBmb2xrcywgdGhlIGlk ZWEgb2YgbXVsdGlwbGUgTUVTU0FHRVMgaW4gYSBzZXNzaW9uIGlzIGEgYmFkIGlkZWEsIGFuZCBp ZiB3ZSB3YW50IHRvIGRvIHVwZGF0ZXMgdG8gdGhlIENBUCBtZXNzYWdlLCBNU1JQIGlzIHRoZSBy aWdodCBhbnN3ZXIuDQo+Pj4gDQo+Pj4gSSBkb24ndCBzZWUgdGhlIHZhbHVlIGluIGEgIm1heWJl IEknbGwgc2VuZCBtZWRpYSBsYXRlciIgc2Vzc2lvbi4gIEkgc2VlIG5vIHVzZSBjYXNlIGZvciB0 aGF0Lg0KPj4+IA0KPj4+IFdlIGRvIHdhbnQgdG8gYmUgYWJsZSB0byBpbmNsdWRlIHRoZSBDQVAg bWVzc2FnZSBpbiBhIHJlZ3VsYXIgKHdpdGggbWVkaWEpIElOVklURS4gIFRoYXQgYWxsb3dzIHRo ZSBzZW5zb3IgZGF0YSBBTkQgdGhlIG1lZGlhICgiSGVscCBJJ3ZlIGZhbGxlbiBhbmQgY2FuJ3Qg Z2V0IHVwIikuICBTbyBhIENBUCBtZXNzYWdlIGluIGEgQm9keSB3aXRoIFNEUCBpbiBhbiBJTlZJ VEUgb3IgYSBDQVAgbWVzc2FnZSBpbiBhIE1FU1NBR0Ugd2l0aCBubyBTRFAgaXMgd2hhdCB3ZSB3 YW50IHRvIGFsbG93Lg0KPj4+IA0KPj4+IEJyaWFuDQo+Pj4gDQo+Pj4gT24gTm92IDEyLCAyMDEy LCBhdCAxMToyOCBBTSwgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3Rl Og0KPj4+IA0KPj4+PiBPbiAxMS8xMi8xMiAxMTowMSBBTSwgUm9zZW4sIEJyaWFuIHdyb3RlOg0K Pj4+Pj4gVGhlIGV4YW1wbGUgaXMgYSBzZW5zb3IgdGhhdCBkZXRlY3RzIHNvbWUgYmFkIGNpcmN1 bXN0YW5jZSwgYnV0IGNvbnRpbnVlcyB0byB0YWtlIHJlYWRpbmdzIGFuZCB3YW50cyB0byBzZW5k IHVwZGF0ZXMgYXQgc29tZSByZWFzb25hYmxlIHJhdGUuDQo+Pj4+IFRoYXQgaXMgYSBnb29kIGV4 YW1wbGUsIGFuZCBpdCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgaXQgaW4gdGhlIGRvY3VtZW50Lg0K Pj4+PiBJU1RNIHRoYXQgaXQgZG9lc24ndCBjbGVhcmx5IGZpdCB0aGUgbWVjaGFuaXNtcyBpbmNs dWRlZCBpbiB0aGUgZG9jdW1lbnQuIElJVUMgdGhlIGRvYyBpbmNsdWRlcyB0d28gbWVjaGFuaXNt czoNCj4+Pj4gDQo+Pj4+IC0gc2VuZCBhIE1FU1NBR0Ugd2l0aCBubyBkaWFsb2csIHdpdGggdGhl IGRhdGEgaW4gdGhlIE1FU1NBR0UgYm9keS4NCj4+Pj4gDQo+Pj4+IC0gc2VuZCBhbiBJTlZJVEUg d2l0aCBubyBtZWRpYSwgd2l0aCB0aGUgZGF0YSBpbiB0aGUgYm9keSBvZiB0aGUgSU5WSVRFLg0K Pj4+PiBUaGUgc2Vzc2lvbiByZW1haW5zIHVwIGZvciBmdXJ0aGVyIHVzZSwgYnV0IG5vIG1lbnRp b24gb2YgKndoYXQqIHVzZS4NCj4+Pj4gSW4gdGhlIGNhc2UgeW91IGRlc2NyaWJlIGFib3ZlLCBo b3cgd291bGQgdGhlIGFkZGl0aW9uYWwgcmVhZGluZ3MNCj4+Pj4gYmUgdHJhbnNtaXR0ZWQ/IElu IGEgTUVTU0FHRSB3aXRoaW4gdGhlIGRpYWxvZz8gSW4gdGhlIGJvZHkgb2YgYQ0KPj4+PiByZUlO VklURT8gVGhpcyBuZWVkcyBmdXJ0aGVyIGV4cGxhbmF0aW9uLg0KPj4+PiANCj4+Pj4gSVNUTSB0 aGF0IGlmIHRoZSAqaW50ZW50KiBpcyB0byBlc3RhYmxpc2ggYSBzZXNzaW9uIGluIG9yZGVyIHRv IHNlbmQgYSBzZXF1ZW5jZSBvZiBkYXRhIHJlYWRpbmdzIG92ZXIgdGltZSwgdGhlbiBpdCB3b3Vs ZCBtYWtlIHNlbnNlIHRvIGVzdGFibGlzaCBhbiBNU1JQIHNlc3Npb24gYW5kIHNlbmQgdGhlbSBh bGwgKGluY2x1ZGluZyB0aGUgZmlyc3QpIG92ZXIgdGhpcyBjaGFubmVsLg0KPj4+PiANCj4+Pj4g T1RPSCwgaWYgdGhlcmUgaXMgYSAqc2luZ2xlKiBkYXRhIHJlYWRpbmcgdG8gdHJhbnNtaXQgYnV0 IHRoZXJlIGlzIGEgZGVzaXJlIHRvIGVzdGFibGlzaCBhIHNlc3Npb24gaW4gb3JkZXIgdG8gZmFj aWxpdGF0ZSBsYXRlciBhZGRpbmcgbWVkaWEgc3RyZWFtcywgdGhlbiB0aGUgbWVjaGFuaXNtIGlu IHRoZSBkb2N1bWVudCBtYWtlcyBzZW5zZS4gSW4gdGhhdCBjYXNlIGl0IG1pZ2h0IGJlICpiZXR0 ZXIqIHRvIG9mZmVyIHRoZSBtZWRpYSBzdHJlYW1zIHRoYXQgKmNhbiBiZSogc3VwcG9ydGVkLCBl aXRoZXIgaW4gaW5hY3RpdmUgc3RhdGUsIG9yIHdpdGggcG9ydCBzZXQgdG8gemVyby4NCj4+Pj4g DQo+Pj4+ICAgIFRoYW5rcywNCj4+Pj4gICAgUGF1bA0KPj4+PiANCj4+Pj4+IEJyaWFuDQo+Pj4+ PiANCj4+Pj4+IE9uIE5vdiAxMiwgMjAxMiwgYXQgMTA6MzQgQU0sIFBhdWwgS3l6aXZhdCA8cGt5 eml2YXRAYWx1bS5taXQuZWR1PiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4+IEd1bm5hciwNCj4+Pj4+ PiANCj4+Pj4+PiBPbiAxMS85LzEyIDY6MTkgUE0sIEd1bm5hciBIZWxsc3Ryw7ZtIHdyb3RlOg0K Pj4+Pj4+PiBJIHNlZSBhIHNsaWdodCBwcm90b2NvbCBjb250cmFkaWN0aW9uIGluIHNlY3Rpb24g NC4xLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhlcmUgaXQgaXMgc2FpZDogIlRvIGNvbnZleSBDQVAg cGF5bG9hZHMgdGhlIFNJUCBNRVNTQUdFIFtSRkMzNDI4XSBpcw0KPj4+Pj4+PiB1c2VkIGZvciBl eGNoYW5nZXMgd2hlcmUgbm8gc2Vzc2lvbiBlc3RhYmxpc2htZW50IGlzIG5lZWRlZCwgaS5lLi4s DQo+Pj4+Pj4+IG9uZS1zaG90IG1lc3NhZ2UgZXhjaGFuZ2UsIGFuZCB0aGUgU0lQIElOVklURSBb UkZDMzI2MV0gd2hlcmUgdGhlDQo+Pj4+Pj4+IGVzdGFibGlzaG1lbnQgb2Ygc2Vzc2lvbiBpcyB1 c2VmdWwgKGUuZy4sIHdoZW4gbXVsdGlwbGUgaW5kZXBlbmRlbnQNCj4+Pj4+Pj4gbWVzc2FnZXMg aGF2ZSB0byBiZSBsb2dpY2FsbHkgdGllZCB0b2dldGhlcikuICINCj4+Pj4+Pj4gDQo+Pj4+Pj4+ IEkgd29uZGVyIGlmIFJGQyAzMjYxIGFuZCBSRkMzMjY0IGFsbG93cyBzZXR0aW5nIHVwIGEgc2Vz c2lvbiB3aXRob3V0DQo+Pj4+Pj4+IHNlc3Npb24gZGVzY3JpcHRpb24gZGVmaW5lZCBtZWRpYS4g VG8gbWUgaXQgc2VlbXMgdGhhdCBhbGwgc2Vzc2lvbiBuZWVkDQo+Pj4+Pj4+IHRvIGhhdmUgbWVk aWEgYWdyZWVkIHRocm91Z2ggc2Vzc2lvbiBkZXNjcmlwdGlvbnMuDQo+Pj4+Pj4+IA0KPj4+Pj4+ PiBJbiBSRkMgMzI2MSBTSVAsIHNlY3Rpb24gMTMuMy4xLjQsIGl0IGlzIHNhaWQ6DQo+Pj4+Pj4+ IA0KPj4+Pj4+PiAiSWYgdGhlIElOVklURSBkaWQNCj4+Pj4+Pj4gICBub3QgY29udGFpbiBhbiBv ZmZlciwgdGhlIDJ4eCBNVVNUIGNvbnRhaW4gYW4gb2ZmZXIgaWYgdGhlIFVBUyBoYWQNCj4+Pj4+ Pj4gICBub3QgeWV0IHNlbnQgYW4gb2ZmZXIuIg0KPj4+Pj4+PiANCj4+Pj4+Pj4gU28sIGl0IHNl ZW1zIHRoYXQgYW4gT2ZmZXIvQW5zd2VyIHNlcXVlbmNlIGlzIHJlcXVpcmVkLg0KPj4+Pj4+IFll cywgdG8gZXN0YWJsaXNoIGEgc2Vzc2lvbiBhbiBPL0EgaXMgcmVxdWlyZWQuDQo+Pj4+Pj4gDQo+ Pj4+Pj4+IEFuZCBpbiBSRkMgMzI2NCBPZmZlci9hbnN3ZXIgbW9kZWwsIGNoYXB0ZXIgNi4xLCBp dCBpcyBzYWlkOg0KPj4+Pj4+PiAiSWYgdGhlcmUgYXJlIG5vIG1lZGlhIGZvcm1hdHMgaW4gY29t bW9uIGZvciBhbGwgc3RyZWFtcywgdGhlIGVudGlyZQ0KPj4+Pj4+PiAgIG9mZmVyZWQgc2Vzc2lv biBpcyByZWplY3RlZC4iDQo+Pj4+Pj4gVGhlIGFib3ZlIHN0YXRlbWVudCBpcyBhIGJpdCBhbWJp Z3VvdXMgd3J0IHRoZSBkZWdlbmVyYXRlIGNhc2Ugd2hlcmUgbm8gc3RyZWFtcyBhcmUgb2ZmZXJl ZC4gKE5vIG0tbGluZXMgaW4gb2ZmZXIuKSBJIHdvdWxkIGFyZ3VlIHRoYXQgdGhlcmUgKmFyZSog bWVkaWEgZm9ybWF0cyBpbiBjb21tb24gZm9yIGV2ZXJ5IG9mZmVyZWQgc3RyZWFtLCBzbyB0aGUg InNlc3Npb24gaXMgcmVqZWN0ZWQiIGRvZXMgbm90IGFwcGx5LiBJbiBhbnkgY2FzZSB0aGlzIHN0 YXRlbWVudCBpcyBub24tbm9ybWF0aXZlLiBJIGhhdmUgYWx3YXlzIHRob3VnaHQgdGhhdCBhbiBh bnN3ZXJlciBpcyBmcmVlIHRvIGtlZXAgdGhlIHNlc3Npb24gdXAgd2l0aCBubyBtZWRpYSBzdHJl YW1zIGlmIHRoYXQgc2VlbXMgdXNlZnVsLg0KPj4+Pj4+IA0KPj4+Pj4+IEkgZG8gdGhpbmsgaXQg d291bGQgYmUgdXNlZnVsIHRvIHByb3ZpZGUgYW4gZXhhbXBsZSBvZiBhIERhdGEtT25seSBFbWVy Z2VuY3kgY2FsbCB0aGF0IGVzdGFibGlzaGVzIGEgc2Vzc2lvbi4gQWxzbywgaXQgd291bGQgYmUg aGVscGZ1bCB0byBoYXZlIGFuIGV4cGxhbmF0aW9uIG9mICp3aHkqIG9uZSBtaWdodCB3YW50IHRo YXQgc2Vzc2lvbiBlc3RhYmxpc2hlZC4NCj4+Pj4+PiANCj4+Pj4+PiBJIHByZXN1bWUgdGhlIGlk ZWEgaXMgdGhhdCB0aGVyZSBjb3VsZCB0aGVuIGJlIGEgbmV3IE8vQSB3aXRoaW4gdGhlIHNlc3Np b24gdG8gZXN0YWJsaXNoIG1lZGlhLCB3aXRob3V0IHRoZSBuZWVkIGZvciBhIHBzYXAtY2FsbGJh Y2suIElzIHRoYXQgcmlnaHQ/DQo+Pj4+Pj4gDQo+Pj4+Pj4gSGFzIGFueSBjb25jZXJuIGJlZW4g Z2l2ZW4gZm9yIGNhc2VzIHdoZXJlIFVEUCBtdXN0IGJlIHVzZWQgYW5kIHRoZSBtZXNzYWdlcyBh cmUgdG9vIGJpZyBmb3IgdGhhdD8gSXQgbWlnaHQgYmUgaGVscGZ1bCBpbiBzb21lIGNhc2VzIHRv IGVzdGFibGlzaCBhIHNlc3Npb24gd2l0aCBhbiBNU1JQIHN0cmVhbSBhbmQgc2VuZCB0aGUgZGF0 YSBvdmVyIHRoYXQuIFRoYXQgY291bGQgYWxzbyBiZSBoZWxwZnVsIGlmIHRoZSBsb2NhbCBzZW5z b3JzIGFyZSBjYXBhYmxlIG9mIHNlbmRpbmcgYSBzZXF1ZW5jZSBvZiBkYXRhIHJlYWRpbmdzIHJh dGhlciB0aGFuIGp1c3Qgb25lLg0KPj4+Pj4+IA0KPj4+Pj4+ICAgIFRoYW5rcywNCj4+Pj4+PiAg ICBQYXVsDQo+Pj4+Pj4gDQo+Pj4+Pj4+IFRoZXNlIHJ1bGVzIHRha2VuIHRvZ2V0aGVyIHNlZW0g dG8gcmVzdWx0IGluIHRoYXQgaW4gb3JkZXIgdG8gc2V0IHVwIGEgc2Vzc2lvbiB0byBjb252ZXkg YSBzZXJpZXMgb2YgQ0FQIE1FU1NBR0VTLCB0aGVuIHNvbWUgKGUuZy4gZHVtbXkpIG1lZGl1bSBt dXN0IGJlIGFncmVlZCBhbHNvIGluIGEgc2Vzc2lvbnMgZGVzY3JpcHRpb24gZXhjaGFuZ2UuDQo+ Pj4+Pj4+IA0KPj4+Pj4+PiBUaGlzIHdvdWxkIG1lYW4gdGhhdCBhIHNlc3Npb24gY2Fubm90IGJl IHNldCB1cCBmb3Igb25seSBDQVAgTUVTU0FHRSBjb252ZXlhbmNlLCBidXQgb2YgY291cnNlIGl0 IGlzIHBvc3NpYmxlIHRvIGhhdmUgQ0FQIG1lc3NhZ2VzIGFuZCBzb21lIG90aGVyIHVzZWZ1bCBt ZWRpYSBpbiB0aGUgc2FtZSBzZXNzaW9uLg0KPj4+Pj4+PiANCj4+Pj4+Pj4gRG8geW91IGFncmVl IGluIHRoaXMgY29uY2x1c2lvbj8NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEd1bm5hcg0KPj4+Pj4+PiAN Cj4+Pj4+Pj4gLS0tLQ0KPj4+Pj4+PiANCj4+Pj4+Pj4gT24gMjAxMi0xMS0wOSAxODozNSwgTWFy YyBMaW5zbmVyIHdyb3RlOg0KPj4+Pj4+Pj4gVGhpcyBzdGFydCB0aGUgV0dMQyBmb3IgZHJhZnQg RGF0YS1Pbmx5IEVtZXJnZW5jeSBDYWxscw0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBUaGUgZHJhZnQg Y2FuIGJlIGZvdW5kIGF0Og0KPj4+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1lY3JpdC1kYXRhLW9ubHktZWENCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gUGxl YXNlIHJldmlldyB0aGUgZHJhZnQgYW5kIHByb3ZpZGUgY29tbWVudHMgdG8gdGhlIGxpc3QgYmVm b3JlIENPQiBvbg0KPj4+Pj4+Pj4gTm92ZW1iZXIgMjMsIDIwMTIuDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IFRoYW5rcywNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gTWFyYyAmIFJvZ2VyDQo+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4+Pj4+IEVjcml0IG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4gRWNyaXRA aWV0Zi5vcmcNCj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZWNyaXQNCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+PiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4+ Pj4+Pj4gRWNyaXRAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9lY3JpdA0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+Pj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gRWNyaXRA aWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vj cml0DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4+IEVjcml0IG1haWxpbmcgbGlzdA0KPj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQo+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBFY3JpdCBtYWlsaW5nIGxp c3QNCj4+PiBFY3JpdEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZWNyaXQNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IEVjcml0IG1haWxpbmcgbGlzdA0KPj4gRWNyaXRAaWV0Zi5vcmcN Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEVjcml0IG1h aWxpbmcgbGlzdA0KPiBFY3JpdEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Vjcml0DQo= From brian.rosen@neustar.biz Thu Nov 15 12:51:58 2012 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 76D0221F8510 for ; Thu, 15 Nov 2012 12:51:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.368 X-Spam-Level: X-Spam-Status: No, score=-6.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sW3ZeklTXA5h for ; Thu, 15 Nov 2012 12:51:57 -0800 (PST) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id CF5E121F8A55 for ; Thu, 15 Nov 2012 12:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1353012672; x=1668365936; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=Ig9bgec34J0/ZUpgKD5od 6uYmDVZT77r/SxVUvU0Jak=; b=KR8hc5PdC3fLZNF4xc9g92GZlT0sVRm/AzYOe GGU7wwQTA771Z6RJcH1lkXn2Ep7smxC20w+W5JTLtJQVRhLfg== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.11871344; Thu, 15 Nov 2012 15:51:11 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 15 Nov 2012 15:51:47 -0500 From: "Rosen, Brian" To: Bernard Aboba Date: Thu, 15 Nov 2012 15:51:46 -0500 Thread-Topic: [Ecrit] WGLC - Data-Only Emergency Calls Thread-Index: Ac3DcwbK0VMVqcvuRH66q3sniPf0iA== Message-ID: References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50A14404.9080503@omnitor.se> <8CB17972-4677-4CA0-BFB5-26E96F7A1C37@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: OfQj7K3VWpMJhN7uiy4LcQ== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 15 Nov 2012 20:51:58 -0000 Not sure I agree with that, but perhaps it would be better to do a subscrip= tion from the PSAP for updates. The only issue with THAT is how to indicate the subscription URI in the MES= SAGE or INVITE. Brian On Nov 14, 2012, at 1:51 PM, Bernard Aboba wrot= e: > If the scenario is updating the PSAP on developments, continuing notifica= tion via any option is not the best choice, because it can add load without= necessarily providing info that the PSAP needs or cares about. Providing t= he PSAP with a link which it can access to get more info may make more sens= e. >=20 > On Nov 13, 2012, at 9:58, "Hannes Tschofenig" = wrote: >=20 >> Hi all,=20 >>=20 >> In the data-only ES document we have two use cases: >>=20 >> Use Case #1: a one-shot MESSAGE with a body that contains a CAP message. >>=20 >> There is no session concept there. There does not seem to be a problem w= ith this approach.=20 >>=20 >> Use Case #2: a sequence of MESSAGE msgs >>=20 >> The example that Brian mentioned on the mailing list is a sensor that de= tects some bad circumstance. It sends an alarm but continues to take readin= gs and wants to send updates. We would like to to avoid the situation where= messages end up at different places since they are addressed to the SOS UR= N. For this reason we thought that it would be good to use a session concep= t here.=20 >>=20 >> As Gunnar had pointed out that our understanding of how this would work = contracts with existing specifications. Very good feedback, Gunnar.=20 >>=20 >> So, how do we address this feedback? I see three options.=20 >>=20 >> Option #1: Omit use case #2 from the document and just focus on the indi= vidually routed SIP MESSAGE payloads.=20 >>=20 >> Option #2: Include use case #2 by utilizing MSRP*, as suggested by Paul.= =20 >>=20 >> Option #3: Limit use case #2 by using a CAP payload in a regular SIP INV= ITE (with media) >> With this case it is not possible to use the CAP payloads alone without = media. =20 >>=20 >> I prefer option #3.=20 >>=20 >> Ciao >> Hannes >>=20 >> *: As we learned in discussions on a separate mailing list MSRP is actua= lly not that difficult to implement when only focusing on the emergency ser= vices use case.=20 >>=20 >> On Nov 12, 2012, at 1:46 PM, Gunnar Hellstr=F6m wrote: >>=20 >>> Brian, you say: >>> "We do want to be able to include the CAP message in a regular (with me= dia) INVITE. That allows the sensor data AND the media ("Help I've fallen a= nd can't get up"). So a CAP message in a Body with SDP in an INVITE or a CA= P message in a MESSAGE with no SDP is what we want to allow." >>>=20 >>> Good conclusion. >>>=20 >>> Gunnar >>>=20 >>> ___________________________________________________ >>> Gunnar Hellstr=F6m >>> Omnitor >>> gunnar.hellstrom@omnitor.se >>> +46708204288 >>>=20 >>> On 2012-11-12 19:35, Rosen, Brian wrote: >>>> I should have expanded my answer, because I agree with you. >>>>=20 >>>> Having talked it over with several SIP folks, the idea of multiple MES= SAGES in a session is a bad idea, and if we want to do updates to the CAP m= essage, MSRP is the right answer. >>>>=20 >>>> I don't see the value in a "maybe I'll send media later" session. I s= ee no use case for that. >>>>=20 >>>> We do want to be able to include the CAP message in a regular (with me= dia) INVITE. That allows the sensor data AND the media ("Help I've fallen = and can't get up"). So a CAP message in a Body with SDP in an INVITE or a = CAP message in a MESSAGE with no SDP is what we want to allow. >>>>=20 >>>> Brian >>>>=20 >>>> On Nov 12, 2012, at 11:28 AM, Paul Kyzivat wro= te: >>>>=20 >>>>> On 11/12/12 11:01 AM, Rosen, Brian wrote: >>>>>> The example is a sensor that detects some bad circumstance, but cont= inues to take readings and wants to send updates at some reasonable rate. >>>>> That is a good example, and it would be good to have it in the docume= nt. >>>>> ISTM that it doesn't clearly fit the mechanisms included in the docum= ent. IIUC the doc includes two mechanisms: >>>>>=20 >>>>> - send a MESSAGE with no dialog, with the data in the MESSAGE body. >>>>>=20 >>>>> - send an INVITE with no media, with the data in the body of the INVI= TE. >>>>> The session remains up for further use, but no mention of *what* use. >>>>> In the case you describe above, how would the additional readings >>>>> be transmitted? In a MESSAGE within the dialog? In the body of a >>>>> reINVITE? This needs further explanation. >>>>>=20 >>>>> ISTM that if the *intent* is to establish a session in order to send = a sequence of data readings over time, then it would make sense to establis= h an MSRP session and send them all (including the first) over this channel= . >>>>>=20 >>>>> OTOH, if there is a *single* data reading to transmit but there is a = desire to establish a session in order to facilitate later adding media str= eams, then the mechanism in the document makes sense. In that case it might= be *better* to offer the media streams that *can be* supported, either in = inactive state, or with port set to zero. >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Nov 12, 2012, at 10:34 AM, Paul Kyzivat w= rote: >>>>>>=20 >>>>>>> Gunnar, >>>>>>>=20 >>>>>>> On 11/9/12 6:19 PM, Gunnar Hellstr=F6m wrote: >>>>>>>> I see a slight protocol contradiction in section 4.1. >>>>>>>>=20 >>>>>>>> There it is said: "To convey CAP payloads the SIP MESSAGE [RFC3428= ] is >>>>>>>> used for exchanges where no session establishment is needed, i.e..= , >>>>>>>> one-shot message exchange, and the SIP INVITE [RFC3261] where the >>>>>>>> establishment of session is useful (e.g., when multiple independen= t >>>>>>>> messages have to be logically tied together). " >>>>>>>>=20 >>>>>>>> I wonder if RFC 3261 and RFC3264 allows setting up a session witho= ut >>>>>>>> session description defined media. To me it seems that all session= need >>>>>>>> to have media agreed through session descriptions. >>>>>>>>=20 >>>>>>>> In RFC 3261 SIP, section 13.3.1.4, it is said: >>>>>>>>=20 >>>>>>>> "If the INVITE did >>>>>>>> not contain an offer, the 2xx MUST contain an offer if the UAS ha= d >>>>>>>> not yet sent an offer." >>>>>>>>=20 >>>>>>>> So, it seems that an Offer/Answer sequence is required. >>>>>>> Yes, to establish a session an O/A is required. >>>>>>>=20 >>>>>>>> And in RFC 3264 Offer/answer model, chapter 6.1, it is said: >>>>>>>> "If there are no media formats in common for all streams, the enti= re >>>>>>>> offered session is rejected." >>>>>>> The above statement is a bit ambiguous wrt the degenerate case wher= e no streams are offered. (No m-lines in offer.) I would argue that there *= are* media formats in common for every offered stream, so the "session is r= ejected" does not apply. In any case this statement is non-normative. I hav= e always thought that an answerer is free to keep the session up with no me= dia streams if that seems useful. >>>>>>>=20 >>>>>>> I do think it would be useful to provide an example of a Data-Only = Emergency call that establishes a session. Also, it would be helpful to hav= e an explanation of *why* one might want that session established. >>>>>>>=20 >>>>>>> I presume the idea is that there could then be a new O/A within the= session to establish media, without the need for a psap-callback. Is that = right? >>>>>>>=20 >>>>>>> Has any concern been given for cases where UDP must be used and the= messages are too big for that? It might be helpful in some cases to establ= ish a session with an MSRP stream and send the data over that. That could a= lso be helpful if the local sensors are capable of sending a sequence of da= ta readings rather than just one. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Paul >>>>>>>=20 >>>>>>>> These rules taken together seem to result in that in order to set = up a session to convey a series of CAP MESSAGES, then some (e.g. dummy) med= ium must be agreed also in a sessions description exchange. >>>>>>>>=20 >>>>>>>> This would mean that a session cannot be set up for only CAP MESSA= GE conveyance, but of course it is possible to have CAP messages and some o= ther useful media in the same session. >>>>>>>>=20 >>>>>>>> Do you agree in this conclusion? >>>>>>>>=20 >>>>>>>> Gunnar >>>>>>>>=20 >>>>>>>> ---- >>>>>>>>=20 >>>>>>>> On 2012-11-09 18:35, Marc Linsner wrote: >>>>>>>>> This start the WGLC for draft Data-Only Emergency Calls >>>>>>>>>=20 >>>>>>>>> The draft can be found at: >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea >>>>>>>>>=20 >>>>>>>>> Please review the draft and provide comments to the list before C= OB on >>>>>>>>> November 23, 2012. >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>>=20 >>>>>>>>> Marc & Roger >>>>>>>>>=20 >>>>>>>>>=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 >>>>>>> _______________________________________________ >>>>>>> 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 >>>=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 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From g.caron@bell.ca Mon Nov 19 05:28:47 2012 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 B884E21F85AF for ; Mon, 19 Nov 2012 05:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ju3FL8zUEUAm for ; Mon, 19 Nov 2012 05:28:47 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id B44CB21F85C7 for ; Mon, 19 Nov 2012 05:28:46 -0800 (PST) Received: from [85.158.136.35:7420] by server-6.bemta-5.messagelabs.com id 04/7D-19321-D043AA05; Mon, 19 Nov 2012 13:28:45 +0000 X-Env-Sender: g.caron@bell.ca X-Msg-Ref: server-15.tower-125.messagelabs.com!1353331719!24778873!8 X-Originating-IP: [206.47.0.177] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26123 invoked from network); 19 Nov 2012 13:28:44 -0000 Received: from dm1c8e.bell.ca (HELO TLS.Exchange.Bell.ca) (206.47.0.177) by server-15.tower-125.messagelabs.com with RC4-SHA encrypted SMTP; 19 Nov 2012 13:28:44 -0000 Received: from hub02-wyn.bell.corp.bce.ca (142.182.199.50) by dm1c8e.exchange3.bell.ca (198.235.102.108) with Microsoft SMTP Server id 8.3.213.0; Mon, 19 Nov 2012 08:28:22 -0500 Received: from MBX02.bell.corp.bce.ca ([142.182.199.11]) by hub02-wyn.bell.corp.bce.ca ([142.182.199.50]) with mapi; Mon, 19 Nov 2012 08:28:29 -0500 From: "g.caron@bell.ca" To: "ecrit@ietf.org" Date: Mon, 19 Nov 2012 08:28:28 -0500 Thread-Topic: Comments on additional-data-05 SvcDelByProvider Thread-Index: Ac2wRnDEwWLzwrpzQQCS7HS/4YbeyQTwAxrA Message-ID: <0FEAC1C09868B34A982F4FB40254B37C293F9E1404@MBX02.bell.corp.bce.ca> References: <20121022111423.30549.14799.idtracker@ietfa.amsl.com> In-Reply-To: <20121022111423.30549.14799.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Ecrit] Comments on additional-data-05 SvcDelByProvider 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, 19 Nov 2012 13:28:47 -0000 Hi ECRIT, Please find the following comments for your consideration. In section 5.2, it states that the registry will reflect a list of initial = valid entries, including "Remote (off premise extension)" however, there is= no corresponding value in section 13.1.4. I suggest adding the value name = "OPX" and the corresponding description "off premise extension" in the tabl= e. There is a statement at the end of section 5.2 that says "There can be more= than one value returned. For example, a VoIP inmate telephone service is a= reasonable combination" however, I'm not sure the XML schema in section 5.= 4 allows this. One option would be to modify the schema for SvcDelByProvide= r to maxOccurs=3D"unbounded". Another option would be to make SvcDelByProvi= der a list type. There are several deployments of hosted voice services today, both in the P= STN (Centrex being one of them) and IP. In Section 13.1.4, there is no valu= e to capture hosted services. An option would be to create a value "HostedM= LTS". Another option, perhaps more flexible, would be to add a value "Hoste= d" that, combined with "MLTS" would cover these cases. Of course, there are= combinations that we wouldn't want to see such as "Hosted" and "Prison". P= erhaps some text in that regard would be required.=20 Regards, Guy From randy@qti.qualcomm.com Wed Nov 28 18:53:33 2012 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 CF04811E80A4 for ; Wed, 28 Nov 2012 18:53:33 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUAvE1PRtFiQ for ; Wed, 28 Nov 2012 18:53:33 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECCD11E809B for ; Wed, 28 Nov 2012 18:53:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1354156075; x=1385692075; h=message-id:in-reply-to:references:date:to:from:subject: mime-version; bh=sNSTAfhtN1nO/uiZ7yf6VpvfDaQ67yQp6p84RhIGAn0=; b=FfxFFVHGP1pAVIKvQj9xRV6wpr6LoZZoyC+2P9u698zOhh8kNeicEIq7 1F7UPc8sUR3thK3RGTTVUslToTayHrsL7WaeFAEL/uIoI6qvxcFVvXYBi ooIVdM2smGDdyQuyW3VAJRWffTSE12ABdStZfjz0iquuAiG5sMS0Y3JNl o=; X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="9591072" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth02.qualcomm.com with ESMTP; 28 Nov 2012 18:27:55 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="375777035" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 28 Nov 2012 18:53:32 -0800 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 28 Nov 2012 18:53:31 -0800 Message-ID: In-Reply-To: References: X-Mailer: Eudora for Mac OS X Date: Wed, 28 Nov 2012 17:29:03 -0800 To: Marc Linsner , "ecrit@ietf.org" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 29 Nov 2012 02:53:33 -0000 Sorry for the delay in sending this. In both the Abstract and Section 1, please delete the text regarding vehicles sending crash data, since that use case normally involves establishing an interactive media stream for voice communication between the vehicle occupants and the PSAP. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- You may be only one person in the world, but you may also be the world to one person. From randy@qti.qualcomm.com Wed Nov 28 18:53:45 2012 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 B599311E80AE for ; Wed, 28 Nov 2012 18:53:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g066ICkyFZ6l for ; Wed, 28 Nov 2012 18:53:45 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3E78D11E809B for ; Wed, 28 Nov 2012 18:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1354156672; x=1385692672; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=QpG1382fW97OYy7DmsD2/ykBZmI2z5foNZq8wjhChpc=; b=Bfhbzz887Z/N67i4pgU3IloH7TUjqIX9hbjLHPOFe2ynnpfnYgPh6zrl eecbjNnV5Yt1C2dK06lREcQZbc0bJICR92u139/m2kk7NfTTq9qbw/yE9 P30WdcQbpUhsBYCs6C4Q8iRL8WlNpre88jwZLr9ZXA6Qv5r+HoajJFDxw I=; X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="9593259" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 28 Nov 2012 18:37:42 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="349086837" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 28 Nov 2012 18:53:35 -0800 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 28 Nov 2012 18:53:34 -0800 Message-ID: In-Reply-To: References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> X-Mailer: Eudora for Mac OS X Date: Wed, 28 Nov 2012 17:37:45 -0800 To: "Rosen, Brian" , Paul Kyzivat From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 29 Nov 2012 02:53:45 -0000 At 1:35 PM -0500 11/12/12, Brian Rosen wrote: > Having talked it over with several SIP folks, the idea of multiple > MESSAGES in a session is a bad idea, and if we want to do updates > to the CAP message, MSRP is the right answer. What about INFO (with an info package specific to data-only emergency calls)? > I don't see the value in a "maybe I'll send media later" session. > I see no use case for that. > > We do want to be able to include the CAP message in a regular (with > media) INVITE. That allows the sensor data AND the media ("Help > I've fallen and can't get up"). So a CAP message in a Body with > SDP in an INVITE or a CAP message in a MESSAGE with no SDP is what > we want to allow. Is this a use case where a medical device establishes a normal emergency call with interactive voice media, or is it where a device wants to send non-interactive media (e.g., pre-recorded voice announcement)? The former seems outside the scope of this document, but the latter would fit, aside from the issue of how to send the media (perhaps as an attachment in the body and hence no session is needed). -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The first rule is, you must not fool yourself. And you are the easiest person to fool. --Richard Feynman From randy@qti.qualcomm.com Wed Nov 28 18:53:45 2012 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 C9AF811E809B for ; Wed, 28 Nov 2012 18:53:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gikf0syZI59I for ; Wed, 28 Nov 2012 18:53:45 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 651E711E80AD for ; Wed, 28 Nov 2012 18:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1354156672; x=1385692672; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=Tfe0/gb9YVMue5h4+877ESCxSX3Ps/EtODENaEoVPr0=; b=r+3IcjhpdQp03ljEcT4c+mAL1B491CH9u1ciCym97B3ohmJ3YrE3kzHX Tr/3JTCKLRsuJOvD/WcOwwRlrTL0VuUOcuq+5gP5KDH6I++nxhQUDRUSK jOrmit/IjUGf3C6T7j5GbiWt+61C7BxYaxU2tSkw/Gm5C05KfRZ7cWGB5 A=; X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="9593260" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 28 Nov 2012 18:37:45 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="2647954" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 28 Nov 2012 18:53:37 -0800 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 28 Nov 2012 18:53:36 -0800 Message-ID: In-Reply-To: References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50A14404.9080503@omnitor.se> <8CB17972-4677-4CA0-BFB5-26E96F7A1C37@gmx.net> X-Mailer: Eudora for Mac OS X Date: Wed, 28 Nov 2012 17:42:05 -0800 To: "Rosen, Brian" , Bernard Aboba From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 29 Nov 2012 02:53:45 -0000 At 3:51 PM -0500 11/15/12, Brian Rosen wrote: > perhaps it would be better to do a subscription from the PSAP for updates. > > The only issue with THAT is how to indicate the subscription URI in > the MESSAGE or INVITE. Call-Info with a new 'purpose' tag? -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- The Macintosh may only have 10% of the market, but it is clearly the top 10%. --Douglas Adams, 1996 WWDC. From gunnar.hellstrom@omnitor.se Wed Nov 28 22:03:01 2012 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 D924921F8A07 for ; Wed, 28 Nov 2012 22:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDd-2Sr+Qr2w for ; Wed, 28 Nov 2012 22:03:01 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 81EC921F8A05 for ; Wed, 28 Nov 2012 22:02:59 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 29 Nov 2012 07:02:50 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-01-01.atm.binero.net (Postfix) with ESMTPA id EE1203A1DF for ; Thu, 29 Nov 2012 07:02:49 +0100 (CET) Message-ID: <50B6FA8C.8000909@omnitor.se> Date: Thu, 29 Nov 2012 07:02:52 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ecrit@ietf.org References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 29 Nov 2012 06:03:02 -0000 On 2012-11-29 02:37, Randall Gellens wrote: > At 1:35 PM -0500 11/12/12, Brian Rosen wrote: > >> Having talked it over with several SIP folks, the idea of multiple >> MESSAGES in a session is a bad idea, and if we want to do updates to >> the CAP message, MSRP is the right answer. > > What about INFO (with an info package specific to data-only emergency > calls)? INFO would also need a session. I am sorry I started this by pointing at wording in SIP and Offer/Answer, together indicating that a session without SDP media shall not be accepted. Maybe few or no implementations have followed that logic so that it would be feasible with errata to SIP or Offer/Answer to allow such sessions. -- But that goes against Brian's finding declared above... It would be good to have the same mechanism for a series of CAP messages in a session with media as for a series of CAP messages without media. /Gunnar From brian.rosen@neustar.biz Thu Nov 29 06:21:01 2012 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 2284E21F888A for ; Thu, 29 Nov 2012 06:21:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooMPwk6O5-Nv for ; Thu, 29 Nov 2012 06:21:00 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2178C21F887F for ; Thu, 29 Nov 2012 06:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1354199189; x=1669535362; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=kaJxZ7z2K9ahal+dv/Bbs 1CL7CpwRsVbZOpKbz3wjZE=; b=B5/+yHiBsUvODtT8znifyGs0We9qwh7ehFC5+ 93zeISr+xykxk5kem/oPPztAn47P6ujU+G7thwv3d/CZ0QyiA== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.17324385; Thu, 29 Nov 2012 09:26:28 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 29 Nov 2012 09:20:57 -0500 From: "Rosen, Brian" To: Randall Gellens Date: Thu, 29 Nov 2012 09:20:56 -0500 Thread-Topic: [Ecrit] WGLC - Data-Only Emergency Calls Thread-Index: Ac3OPL88+53d8Mg5R0SIKHRGhHBM0Q== Message-ID: <418FA658-E959-4B37-93FD-5CBA638FE147@neustar.biz> References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: WdTeLpm4pdlCRVsLVEZnmQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 29 Nov 2012 14:21:01 -0000 On Nov 28, 2012, at 8:37 PM, Randall Gellens wrote= : > At 1:35 PM -0500 11/12/12, Brian Rosen wrote: >=20 >> Having talked it over with several SIP folks, the idea of multiple MESSA= GES in a session is a bad idea, and if we want to do updates to the CAP mes= sage, MSRP is the right answer. >=20 > What about INFO (with an info package specific to data-only emergency cal= ls)? Gunnar correctly pointed out the problem with this, INFO needs a session. >=20 >> I don't see the value in a "maybe I'll send media later" session. I see = no use case for that. >>=20 >> We do want to be able to include the CAP message in a regular (with medi= a) INVITE. That allows the sensor data AND the media ("Help I've fallen an= d can't get up"). So a CAP message in a Body with SDP in an INVITE or a CA= P message in a MESSAGE with no SDP is what we want to allow. >=20 > Is this a use case where a medical device establishes a normal emergency = call with interactive voice media, or is it where a device wants to send no= n-interactive media (e.g., pre-recorded voice announcement)? The former se= ems outside the scope of this document, but the latter would fit, aside fro= m the issue of how to send the media (perhaps as an attachment in the body = and hence no session is needed). The former. It may be "outside the scope", but that means we have the scop= e of the document (and maybe the title) wrong. You ought to be able to sen= d data with or without media the same way. Brian >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > The first rule is, you must not fool yourself. And you are the > easiest person to fool. --Richard Feynman > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From brian.rosen@neustar.biz Thu Nov 29 06:23:13 2012 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 EA88621F88E8 for ; Thu, 29 Nov 2012 06:23:13 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BQie8Y1bzJU for ; Thu, 29 Nov 2012 06:23:13 -0800 (PST) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id A2DC121F88DE for ; Thu, 29 Nov 2012 06:23:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1354198959; x=1669549401; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=r6wt0dJG/5eZA/fS6sSxS 8TRGf30hqneTQ+9Mosavyo=; b=nKhEylu+IJJvV1v+iLk0Rw53gvXjE5ySZXR/k DKChzb3hv6XHHpwsha7jnD6PdyPhjqfdWrxaQYSEAt8Bvl7Kg== Received: from ([10.31.13.242]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.12405260; Thu, 29 Nov 2012 09:22:38 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 29 Nov 2012 09:23:07 -0500 From: "Rosen, Brian" To: Randall Gellens Date: Thu, 29 Nov 2012 09:23:07 -0500 Thread-Topic: [Ecrit] WGLC - Data-Only Emergency Calls Thread-Index: Ac3OPQ1cYVXD0Yo4SNO3vNmlHEcZAA== Message-ID: <8B2790A7-C065-42C2-ADBF-1F9AB3DACB26@neustar.biz> References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50A14404.9080503@omnitor.se> <8CB17972-4677-4CA0-BFB5-26E96F7A1C37@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: levC6IYFg1noEDA2uxDN4g== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 29 Nov 2012 14:23:14 -0000 Yeah, possible. Another possible is a Type/Value in the CAP message. Brian On Nov 28, 2012, at 8:42 PM, Randall Gellens wrote= : > At 3:51 PM -0500 11/15/12, Brian Rosen wrote: >=20 >> perhaps it would be better to do a subscription from the PSAP for update= s. >>=20 >> The only issue with THAT is how to indicate the subscription URI in the = MESSAGE or INVITE. >=20 > Call-Info with a new 'purpose' tag? >=20 > --=20 > Randall Gellens > Opinions are personal; facts are suspect; I speak for myself only > -------------- Randomly selected tag: --------------- > The Macintosh may only have 10% of the market, but it is clearly > the top 10%. > --Douglas Adams, 1996 WWDC. > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From randy@qti.qualcomm.com Thu Nov 29 06:39:56 2012 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 C71A221F89E9 for ; Thu, 29 Nov 2012 06:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9YejFjWcPJZ for ; Thu, 29 Nov 2012 06:39:55 -0800 (PST) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB8021F88DE for ; Thu, 29 Nov 2012 06:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1354199035; x=1385735035; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=vCNfkZrCvh5PAnRVaCQC8bh27LwqyNO+CuWjZHNlCW8=; b=QEHdfcI5qoE4FU1UDWZaaL30jmFI1gKf5MQHet8BoMtfBSPlDW07ZokF /4ImXyUd2yMnQzMykdFvMP9z3R7iGGGP6p+yu4ZD+i9LVJyVofXc0WEJp 12yiDvRBrjk8Set/vQc9ufFXKOKpSvt/ySSZKfb1uRBH2PbNTkX+w7RbJ Y=; X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="9655439" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 29 Nov 2012 06:23:54 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="349394800" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Nov 2012 06:39:49 -0800 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 29 Nov 2012 06:39:48 -0800 Message-ID: In-Reply-To: <50B6FA8C.8000909@omnitor.se> References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50B6FA8C.8000909@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Thu, 29 Nov 2012 06:32:56 -0800 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 29 Nov 2012 14:39:56 -0000 At 7:02 AM +0100 11/29/12, Gunnar Hellstr=F6m wrote: > On 2012-11-29 02:37, Randall Gellens wrote: >> At 1:35 PM -0500 11/12/12, Brian Rosen wrote: >> >>> Having talked it over with several SIP=20 >>> folks, the idea of multiple MESSAGES in a=20 >>> session is a bad idea, and if we want to do=20 >>> updates to the CAP message, MSRP is the right=20 >>> answer. >> >> What about INFO (with an info package specific=20 >> to data-only emergency calls)? > > INFO would also need a session. Right, that's why I suggested INFO instead of=20 MESSAGE for use within a session. Brian said=20 multiple MESSAGE within a session was bad, so how=20 about multiple INFO, which is specifically=20 designed for a session. If however the problem=20 is the session and not the use of MESSAGE within=20 a session, then of course INFO doesn't help. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I find that a great part of the information I have was acquired by looking up something and finding something else on the way. --Franklin P. Adams (1881-1960) From randy@qti.qualcomm.com Thu Nov 29 06:39:56 2012 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 54A7121F88DE for ; Thu, 29 Nov 2012 06:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjnYohq1n6OL for ; Thu, 29 Nov 2012 06:39:55 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE8E21F89DD for ; Thu, 29 Nov 2012 06:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1354198454; x=1385734454; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=bI/dAkVi9Y1s1fZXWb+7VPJsssf02LGYy7n3uE7XrB4=; b=vilfDCqIP+fLx3B33Yagi/6tcTh2qm1htT6p6/1xAL1r3sj9sa78qKv8 /sqCCpn5Mmiy6fgTMwN6WGDYkmiIr+cPwpa0EYr+iazV8XOa1+kiHqwLc mPyYNzMm7KEQjD4EaDrBTq/45/dJOcqVWwgn/Z0b7wHWlaC/MTy8d6sdq s=; X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="9653256" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 29 Nov 2012 06:14:11 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,6910"; a="2685764" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Nov 2012 06:39:51 -0800 Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 29 Nov 2012 06:39:50 -0800 Message-ID: In-Reply-To: <418FA658-E959-4B37-93FD-5CBA638FE147@neustar.biz> References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <418FA658-E959-4B37-93FD-5CBA638FE147@neustar.biz> X-Mailer: Eudora for Mac OS X Date: Thu, 29 Nov 2012 06:37:17 -0800 To: "Rosen, Brian" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Cc: "Rosen, Brian" , "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 29 Nov 2012 14:39:56 -0000 At 9:20 AM -0500 11/29/12, Brian Rosen wrote: >> Is this a use case where a medical device establishes a normal >> emergency call with interactive voice media, or is it where a >> device wants to send non-interactive media (e.g., pre-recorded >> voice announcement)? The former seems outside the scope of this >> document, but the latter would fit, aside from the issue of how to >> send the media (perhaps as an attachment in the body and hence no >> session is needed). > The former. It may be "outside the scope", but that means we have > the scope of the document (and maybe the title) wrong. You ought > to be able to send data with or without media the same way. If there is an interactive media stream and a session, then it isn't a 'data-only' call, is it? If this document is handling both 'data-only' and 'normal' emergency calls with sensor data, then we need to pull it back out of WGLC, enlarge the scope, and work on the use cases and mechanisms more. It's not good to do significant redesign of technical work in a rush during WGLC. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Two things are infinite: the universe and human stupidity; and I'm not even sure about the universe. --Albert Einstein From pkyzivat@alum.mit.edu Thu Nov 29 08:34:57 2012 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 A0E5521F8AB1 for ; Thu, 29 Nov 2012 08:34:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrcjd2Hh0ur9 for ; Thu, 29 Nov 2012 08:34:51 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 6F07621F85E6 for ; Thu, 29 Nov 2012 08:34:50 -0800 (PST) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta03.westchester.pa.mail.comcast.net with comcast id VPND1k0011wpRvQ53UapRh; Thu, 29 Nov 2012 16:34:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta18.westchester.pa.mail.comcast.net with comcast id VUap1k0053ZTu2S3eUapk4; Thu, 29 Nov 2012 16:34:49 +0000 Message-ID: <50B78EA8.5030200@alum.mit.edu> Date: Thu, 29 Nov 2012 11:34:48 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: ecrit@ietf.org References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50B6FA8C.8000909@omnitor.se> In-Reply-To: <50B6FA8C.8000909@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354206889; bh=85vjva0YYfyclIiHIKRUOj2B8NWxOY5HdfczPTyf24E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=BmfArJBB3U4faQF1VmkdyztORa5oqpmh4d3GW58Dw0MR5E8jUAGu37cKMOhVLCMXg bp4oTAibDB9qLdCdr2DFczsjg9wG+HgAO9piZWSNiO6XOLwiWQOtMHbGdrd0NWpKq+ SFg0sKvavisVCmRIL6qW9f5pSbKhWteghT3aWuIxhRkrxKnxP+m+DgszRZy7MvmOmb +6EYixcKmDMmWmsIdtC4m3SMF6PyhTu1QiD6ZQIfFo6LYfRf7A1lHVH+ht0dr+RzL2 oNFOaSTz0hUeI/UdzbMwHHauqDUrkXmD27/aJNRuYVrfUsaF7t+FGYP6YVXuX8uqyw 4BUXsdOioDyPg== Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 29 Nov 2012 16:35:04 -0000 On 11/29/12 1:02 AM, Gunnar Hellström wrote: > On 2012-11-29 02:37, Randall Gellens wrote: >> At 1:35 PM -0500 11/12/12, Brian Rosen wrote: >> >>> Having talked it over with several SIP folks, the idea of multiple >>> MESSAGES in a session is a bad idea, and if we want to do updates to >>> the CAP message, MSRP is the right answer. >> >> What about INFO (with an info package specific to data-only emergency >> calls)? > > INFO would also need a session. > I am sorry I started this by pointing at wording in SIP and > Offer/Answer, together indicating that a session without SDP media shall > not be accepted. Maybe few or no implementations have followed that > logic so that it would be feasible with errata to SIP or Offer/Answer to > allow such sessions. > -- But that goes against Brian's finding declared above... > > It would be good to have the same mechanism for a series of CAP messages > in a session with media as for a series of CAP messages without media. How about making a list of all the possible mechanisms people can think of, with their pros/cons? Then picking the best one(s). Here is a candidate list based mostly on things already discussed here: 1) MESSAGE, out of dialog, to carry CAP data. Sequence of MESSAGEs for sequence of data readings. 2) CAP message body part in INVITE, reINVITE, and UPDATE. Use offer with no m-lines if no media is available. (Or, audio m-line with c=0.0.0.0 if that works better.) 3) INVITE to establish session. INFO to carry CAP messages. Use offer with no m-lines if no media is available. (Or, audio m-line with c=0.0.0.0 if that works better.) 4) INVITE to establish session. MSRP media session to carry CAP messages. 5) MESSAGE to send first CAP reading. SUBSCRIBE from PSAP back to emergency device with NOTIFYs to carry subsequent CAP data. (TBD: mechanism to convey support for subscribe and the URI.) (Note I have included things above that I consider bad ideas. That can be dealt with in the pros/cons.) Thanks, Paul From gunnar.hellstrom@omnitor.se Thu Nov 29 14:53:11 2012 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 12FF821F8AD6 for ; Thu, 29 Nov 2012 14:53:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkCPXz0qvjLZ for ; Thu, 29 Nov 2012 14:53:09 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id CCF9E21F8ACE for ; Thu, 29 Nov 2012 14:53:04 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Thu, 29 Nov 2012 23:52:54 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-04-01.atm.binero.net (Postfix) with ESMTPA id E218B3A0F5 for ; Thu, 29 Nov 2012 23:52:53 +0100 (CET) Message-ID: <50B7E748.8030106@omnitor.se> Date: Thu, 29 Nov 2012 23:52:56 +0100 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: ecrit@ietf.org References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50B6FA8C.8000909@omnitor.se> <50B78EA8.5030200@alum.mit.edu> In-Reply-To: <50B78EA8.5030200@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------000000070601050908030704" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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, 29 Nov 2012 22:53:11 -0000 This is a multi-part message in MIME format. --------------000000070601050908030704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2012-11-29 17:34, Paul Kyzivat wrote: > > How about making a list of all the possible mechanisms people can > think of, with their pros/cons? Then picking the best one(s). Here is > a candidate list based mostly on things already discussed here: > > 1) MESSAGE, out of dialog, to carry CAP data. > Sequence of MESSAGEs for sequence of data readings. > > 2) CAP message body part in INVITE, reINVITE, and UPDATE. > Use offer with no m-lines if no media is available. > (Or, audio m-line with c=0.0.0.0 if that works better.) > > 3) INVITE to establish session. INFO to carry CAP messages. > Use offer with no m-lines if no media is available. > (Or, audio m-line with c=0.0.0.0 if that works better.) > > 4) INVITE to establish session. MSRP media session to carry > CAP messages. > > 5) MESSAGE to send first CAP reading. SUBSCRIBE from PSAP back to > emergency device with NOTIFYs to carry subsequent CAP data. > (TBD: mechanism to convey support for subscribe and the URI.) > > (Note I have included things above that I consider bad ideas. That can > be dealt with in the pros/cons.) > > Thanks, > Paul Good move. It seems that also human texting with PSAPs would have the same need of a solution. EENA NG112 LTE and NENA NG911 i3 08-003 say about Instant messaging: " MESSAGEs received from the same caller within a configurable time (2-3 minutes nominally) should be considered part of the same "call", and must be routed to the same PSAP (and the same call taker), regardless of movement of the caller while texting. If the origination network/device supports non session mode IM to NG9-1-1, it must assure that all messages from the same caller within this time frame is sent to the same ESInet (same ECRF query results).If the network/device cannot guarantee this, it must use session mode. So the same question exists also for this case is: What kind of session, and how is it established? It seems that RFC 6443 and phonebcp do not bother to mention this detail, therefore I looked at how the usage was in NG112 and NG911. So, let us try to solve this the same way for both kinds of usage. /Gunnar --------------000000070601050908030704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2012-11-29 17:34, Paul Kyzivat wrote:

How about making a list of all the possible mechanisms people can think of, with their pros/cons? Then picking the best one(s). Here is a candidate list based mostly on things already discussed here:

1) MESSAGE, out of dialog, to carry CAP data.
   Sequence of MESSAGEs for sequence of data readings.

2) CAP message body part in INVITE, reINVITE, and UPDATE.
   Use offer with no m-lines if no media is available.
   (Or, audio m-line with c=0.0.0.0 if that works better.)

3) INVITE to establish session. INFO to carry CAP messages.
   Use offer with no m-lines if no media is available.
   (Or, audio m-line with c=0.0.0.0 if that works better.)

4) INVITE to establish session. MSRP media session to carry
   CAP messages.

5) MESSAGE to send first CAP reading. SUBSCRIBE from PSAP back to
   emergency device with NOTIFYs to carry subsequent CAP data.
   (TBD: mechanism to convey support for subscribe and the URI.)

(Note I have included things above that I consider bad ideas. That can be dealt with in the pros/cons.)

    Thanks,
    Paul
Good move.

It seems that also human texting with PSAPs would have the same need of a solution.

EENA NG112 LTE and NENA NG911 i3 08-003  say about Instant messaging:
" MESSAGEs received from the same caller within a configurable time (2-3 minutes nominally) should be considered part of the same “call”, and must be routed to the same PSAP (and the same call taker), regardless of movement of the caller while texting.  If the origination network/device supports non session mode IM to NG9-1-1, it must assure that all messages from the same caller within this time frame is sent to the same ESInet (same ECRF query results).  If the network/device cannot guarantee this, it must use session mode. 


So the same question exists also for this case is:  What kind of session, and how is it established?
It seems that RFC 6443 and phonebcp do not bother to mention this detail, therefore I looked at how the usage was in NG112 and NG911.

So, let us try to solve this the same way for both kinds of usage.

/Gunnar



 --------------000000070601050908030704-- From randy@qti.qualcomm.com Thu Nov 29 16:00:09 2012 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 CE3C421F8231 for ; Thu, 29 Nov 2012 16:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaviUP+PGnLL for ; Thu, 29 Nov 2012 16:00:09 -0800 (PST) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id DB54321F89A2 for ; Thu, 29 Nov 2012 16:00:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1354232066; x=1385768066; h=message-id:in-reply-to:references:date:to:from:subject: mime-version:content-transfer-encoding; bh=StgRvYGBnNiqZVZsplz94zf1qXObjrn7F8IAkLHPCww=; b=k12V3DjXxUSstNMkMB8hp3xB75M2BDgjkaR2x/9iNBjG3TmlIfq0Wlsz BPZSbkJJaoOhTyC6IdHvoAv8u+tdBGmhHrlmsojHfVtosoyqjREj07POM H93e+1mQi9zUUK9/TYqkwRJH+fP4IXJksorEspREbxEYjMOmoq6z179HQ o=; X-IronPort-AV: E=McAfee;i="5400,1158,6911"; a="9751708" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth02.qualcomm.com with ESMTP; 29 Nov 2012 15:34:25 -0800 X-IronPort-AV: E=McAfee;i="5400,1158,6911"; a="2741021" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 29 Nov 2012 16:00:07 -0800 Received: from dhcp184-48-45-14.hroa.orl.wayport.net (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 29 Nov 2012 16:00:06 -0800 Message-ID: In-Reply-To: <50B7E748.8030106@omnitor.se> References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50B6FA8C.8000909@omnitor.se> <50B78EA8.5030200@alum.mit.edu> <50B7E748.8030106@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Thu, 29 Nov 2012 16:00:04 -0800 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [172.30.39.5] Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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: Fri, 30 Nov 2012 00:00:09 -0000 At 11:52 PM +0100 11/29/12, Gunnar Hellstr=F6m wrote: > It seems that also human texting with PSAPs=20 > would have the same need of a solution. Yes, but that's already covered. NENA 08-003=20 wants session mode, and other SDOs have agreed=20 and specified MSRP within a session. > So, let us try to solve this the same way for both kinds of usage. Data-only is (at least up to now) a different use=20 case, since there is (up to now) no interactive=20 media stream. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Nice guys finish last, but we get to sleep in. --Evan Davis From brian.rosen@neustar.biz Thu Nov 29 16:00:56 2012 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 6DA1021F88F2 for ; Thu, 29 Nov 2012 16:00:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=-0.427, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orrvsWGjKlyo for ; Thu, 29 Nov 2012 16:00:55 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 19A8D21F8231 for ; Thu, 29 Nov 2012 16:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1354233852; x=1669593780; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=idfJoK0pK2SOPlewycpkaHdSy2Sf9Gx2zmw/Xx7ht8I=; b=Z6jr1VIlhj1JI3K5mjMRA2VyMlfjsjmdGO1V9qlGeG88VjzsFEpMcQBK2uoNn/ Q+6JdbHJiA5LNwVzysi28CBw== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.16927124; Thu, 29 Nov 2012 19:04:11 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Thu, 29 Nov 2012 19:00:52 -0500 From: "Rosen, Brian" To: =?Windows-1252?Q?Gunnar_Hellstr=F6m?= Date: Thu, 29 Nov 2012 19:00:50 -0500 Thread-Topic: [Ecrit] WGLC - Data-Only Emergency Calls Thread-Index: Ac3OjcLTkBD421fHR6OVcm/i4HXe3g== Message-ID: <24FC6645-569B-4847-BB69-02D14EBEAB86@neustar.biz> References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50B6FA8C.8000909@omnitor.se> <50B78EA8.5030200@alum.mit.edu> <50B7E748.8030106@omnitor.se> In-Reply-To: <50B7E748.8030106@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: 0M4m4HdOOJPYiiMPHSKzpA== Content-Type: multipart/alternative; boundary="_000_24FC6645569B4847BB6902D14EBEAB86neustarbiz_" MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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: Fri, 30 Nov 2012 00:00:56 -0000 --_000_24FC6645569B4847BB6902D14EBEAB86neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A message session is MSRP. So if we're using MESSAGE, we use MSRP if we ha= ve a sequence of them, but have no media. If there is media, you have an INVITE. ReINVITE or UPDATE could carry a CA= P message, but probably we would be better served by INFO for in-dialog upd= ate of the CAP alert assuming push. I believe I would be happiest with MESSAGE or INVITE for the first message,= and SUB/NOT for updates. That handles the case of MSRP for IM media, sinc= e the MSRP session is established with INVITE. Brian On Nov 29, 2012, at 5:52 PM, Gunnar Hellstr=F6m > wrote: On 2012-11-29 17:34, Paul Kyzivat wrote: How about making a list of all the possible mechanisms people can think of,= with their pros/cons? Then picking the best one(s). Here is a candidate li= st based mostly on things already discussed here: 1) MESSAGE, out of dialog, to carry CAP data. Sequence of MESSAGEs for sequence of data readings. 2) CAP message body part in INVITE, reINVITE, and UPDATE. Use offer with no m-lines if no media is available. (Or, audio m-line with c=3D0.0.0.0 if that works better.) 3) INVITE to establish session. INFO to carry CAP messages. Use offer with no m-lines if no media is available. (Or, audio m-line with c=3D0.0.0.0 if that works better.) 4) INVITE to establish session. MSRP media session to carry CAP messages. 5) MESSAGE to send first CAP reading. SUBSCRIBE from PSAP back to emergency device with NOTIFYs to carry subsequent CAP data. (TBD: mechanism to convey support for subscribe and the URI.) (Note I have included things above that I consider bad ideas. That can be d= ealt with in the pros/cons.) Thanks, Paul Good move. It seems that also human texting with PSAPs would have the same need of a s= olution. EENA NG112 LTE and NENA NG911 i3 08-003 say about Instant messaging: " MESSAGEs received from the same caller within a configurable time (2-3 mi= nutes nominally) should be considered part of the same =93call=94, and must= be routed to the same PSAP (and the same call taker), regardless of moveme= nt of the caller while texting. If the origination network/device supports= non session mode IM to NG9-1-1, it must assure that all messages from the = same caller within this time frame is sent to the same ESInet (same ECRF qu= ery results). If the network/device cannot guarantee this, it must use ses= sion mode. So the same question exists also for this case is: What kind of session, a= nd how is it established? It seems that RFC 6443 and phonebcp do not bother to mention this detail, t= herefore I looked at how the usage was in NG112 and NG911. So, let us try to solve this the same way for both kinds of usage. /Gunnar _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_24FC6645569B4847BB6902D14EBEAB86neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A message session is = MSRP.  So if we're using MESSAGE, we use MSRP if we have a sequence of= them, but have no media.

If there is media, you have an= INVITE.  ReINVITE or UPDATE could carry a CAP message, but probably w= e would be better served by INFO for in-dialog update of the CAP alert assu= ming push.

I believe I would be happiest with MESS= AGE or INVITE for the first message, and SUB/NOT for updates.  That ha= ndles the case of MSRP for IM media, since the MSRP session is established = with INVITE.

Brian


On Nov 29, 2012, at 5:52 PM, Gunnar Hellstr=F6m <gunnar.hellstrom@omnitor.se> wr= ote:

=20 =20
On 2012-11-29 17:34, Paul Kyzivat wrote:
How about making a list of all the possible mechanisms people can think of, with their pros/cons? Then picking the best one(s). Here is a candidate list based mostly on things already discussed here:

1) MESSAGE, out of dialog, to carry CAP data.
   Sequence of MESSAGEs for sequence of data readings.

2) CAP message body part in INVITE, reINVITE, and UPDATE.
   Use offer with no m-lines if no media is available.
   (Or, audio m-line with c=3D0.0.0.0 if that works better.= )

3) INVITE to establish session. INFO to carry CAP messages.
   Use offer with no m-lines if no media is available.
   (Or, audio m-line with c=3D0.0.0.0 if that works better.= )

4) INVITE to establish session. MSRP media session to carry
   CAP messages.

5) MESSAGE to send first CAP reading. SUBSCRIBE from PSAP back to
   emergency device with NOTIFYs to carry subsequent CAP da= ta.
   (TBD: mechanism to convey support for subscribe and the = URI.)

(Note I have included things above that I consider bad ideas. That can be dealt with in the pros/cons.)

    Thanks,
    Paul
Good move.

It seems that also human texting with PSAPs would have the same need of a solution.

EENA NG112 LTE and NENA NG911 i3 08-003  say about Instant messaging:
" MESSAGEs received from the same caller within a configurable time (2-3 minutes nominally) should be considered part of the same =93call=94, and must be routed to the same PSAP (and the same call taker), regardless of movement of the caller while texting.  If the origination network/device supports non session mode IM to NG9-1-1, it must assure that all messages from the same caller within this time frame is sent to the same ESInet (same ECRF query results).  If the network/device cannot guarantee this, it must use session mode. 


So the same question exists also for this case is:  What kind = of session, and how is it established?
It seems that RFC 6443 and phonebcp do not bother to mention this detail, therefore I looked at how the usage was in NG112 and NG911.

So, let us try to solve this the same way for both kinds of usage.

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

= --_000_24FC6645569B4847BB6902D14EBEAB86neustarbiz_-- From gunnar.hellstrom@omnitor.se Thu Nov 29 22:50:40 2012 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 D1F8821F89BE for ; Thu, 29 Nov 2012 22:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyYrn50xhMzl for ; Thu, 29 Nov 2012 22:50:40 -0800 (PST) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id D473A21F89BA for ; Thu, 29 Nov 2012 22:50:39 -0800 (PST) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Fri, 30 Nov 2012 07:50:31 +0100 (CET) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-06-01.atm.binero.net (Postfix) with ESMTPA id 3A2593A1F6; Fri, 30 Nov 2012 07:50:31 +0100 (CET) Message-ID: <50B8573A.703@omnitor.se> Date: Fri, 30 Nov 2012 07:50:34 +0100 From: =?windows-1252?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Rosen, Brian" References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50B6FA8C.8000909@omnitor.se> <50B78EA8.5030200@alum.mit.edu> <50B7E748.8030106@omnitor.se> <24FC6645-569B-4847-BB69-02D14EBEAB86@neustar.biz> In-Reply-To: <24FC6645-569B-4847-BB69-02D14EBEAB86@neustar.biz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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: Fri, 30 Nov 2012 06:50:41 -0000 On 2012-11-30 01:00, Rosen, Brian wrote: > A message session is MSRP. So if we're using MESSAGE, we use MSRP if > we have a sequence of them, but have no media. Right. That makes sense. > > If there is media, you have an INVITE. ReINVITE or UPDATE could carry > a CAP message, but probably we would be better served by INFO for > in-dialog update of the CAP alert assuming push. > > I believe I would be happiest with MESSAGE or INVITE for the first > message, and SUB/NOT for updates. That handles the case of MSRP for > IM media, since the MSRP session is established with INVITE. In case of SUB/NOT, it has been indicated in this thread that the PSAP would do the SUBSCRIBE after receiving the initial MESSAGE. - Then there would be a need for a way for the transmitting device to indicate that a SUBSCRIBE is wanted. How would that be indicated? -Also, there is a need for a way to guarantee that the SUBSCRIBE is addressed to the transmitting device and is answered only by the transmitting device. It seems as a GRUU may needed, and other considerations similar to an emergency service callback. Gunnar From keith.drage@alcatel-lucent.com Fri Nov 30 04:48:27 2012 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 25C8D21F86E5 for ; Fri, 30 Nov 2012 04:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.911 X-Spam-Level: X-Spam-Status: No, score=-109.911 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlOav4zjQLdR for ; Fri, 30 Nov 2012 04:48:25 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id B144A21F86E7 for ; Fri, 30 Nov 2012 04:48:24 -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 qAUChl0F011271 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 30 Nov 2012 13:48:18 +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; Fri, 30 Nov 2012 13:47:51 +0100 From: "DRAGE, Keith (Keith)" To: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= , "ecrit@ietf.org" Date: Fri, 30 Nov 2012 13:47:47 +0100 Thread-Topic: [Ecrit] WGLC - Data-Only Emergency Calls Thread-Index: Ac3OhFvfJEjJxO2dSLCk0xxWexXhpQAdBoyQ Message-ID: References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50B6FA8C.8000909@omnitor.se> <50B78EA8.5030200@alum.mit.edu> <50B7E748.8030106@omnitor.se> In-Reply-To: <50B7E748.8030106@omnitor.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_EDC0A1AE77C57744B664A310A0B23AE20ADA4CD73DFRMRSSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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: Fri, 30 Nov 2012 12:48:27 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE20ADA4CD73DFRMRSSXCHMBSC_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The conclusion I seem to come to on all these emergency call issues is that= a dialog is needed, because you need to deliver to the same PSAP who is ha= ndling this for possible emergency voice calls, and that PSAP needs to be a= ble to correlate all the input. While there are some ways round this, it al= ways seems so much easier to say a dialog must exist. That eliminates 1) an= d possibly 5). Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of G= unnar Hellstr=F6m Sent: 29 November 2012 22:53 To: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls On 2012-11-29 17:34, Paul Kyzivat wrote: How about making a list of all the possible mechanisms people can think of,= with their pros/cons? Then picking the best one(s). Here is a candidate li= st based mostly on things already discussed here: 1) MESSAGE, out of dialog, to carry CAP data. Sequence of MESSAGEs for sequence of data readings. 2) CAP message body part in INVITE, reINVITE, and UPDATE. Use offer with no m-lines if no media is available. (Or, audio m-line with c=3D0.0.0.0 if that works better.) 3) INVITE to establish session. INFO to carry CAP messages. Use offer with no m-lines if no media is available. (Or, audio m-line with c=3D0.0.0.0 if that works better.) 4) INVITE to establish session. MSRP media session to carry CAP messages. 5) MESSAGE to send first CAP reading. SUBSCRIBE from PSAP back to emergency device with NOTIFYs to carry subsequent CAP data. (TBD: mechanism to convey support for subscribe and the URI.) (Note I have included things above that I consider bad ideas. That can be d= ealt with in the pros/cons.) Thanks, Paul Good move. It seems that also human texting with PSAPs would have the same need of a s= olution. EENA NG112 LTE and NENA NG911 i3 08-003 say about Instant messaging: " MESSAGEs received from the same caller within a configurable time (2-3 mi= nutes nominally) should be considered part of the same "call", and must be = routed to the same PSAP (and the same call taker), regardless of movement o= f the caller while texting. If the origination network/device supports non= session mode IM to NG9-1-1, it must assure that all messages from the same= caller within this time frame is sent to the same ESInet (same ECRF query = results). If the network/device cannot guarantee this, it must use session= mode. So the same question exists also for this case is: What kind of session, a= nd how is it established? It seems that RFC 6443 and phonebcp do not bother to mention this detail, t= herefore I looked at how the usage was in NG112 and NG911. So, let us try to solve this the same way for both kinds of usage. /Gunnar --_000_EDC0A1AE77C57744B664A310A0B23AE20ADA4CD73DFRMRSSXCHMBSC_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The conclusion I se= em to come to on all these emergency call issues is that a dialog is needed, beca= use you need to deliver to the same PSAP who is handling this for possible emergency voice calls, and that PSAP needs to be able to correlate all the input. While there are some ways round this, it always seems so much easier= to say a dialog must exist. That eliminates 1) and possibly 5).

 

Regards<= /span>

 

Keith

 

<= font size=3D2 color=3Dblack face=3DTahoma>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Beha= lf Of Gunnar Hellstr=F6m
Sent: 29 November 2012 22:53=
To: ecrit@ietf.org
Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls

=  

= On 2012-11-29 17:34, Paul Kyzivat w= rote:

=
How about making a list of all the possible mechanisms people can think of, with their pros/cons? Then picking the best one(s). Here is a candidate lis= t based mostly on things already discussed here:

1) MESSAGE, out of dialog, to carry CAP data.
   Sequence of MESSAGEs for sequence of data readings.

2) CAP message body part in INVITE, reINVITE, and UPDATE.
   Use offer with no m-lines if no media is available.
   (Or, audio m-line with c=3D0.0.0.0 if that works better.)

3) INVITE to establish session. INFO to carry = CAP messages.
   Use offer with no m-lines if no media is available.
   (Or, audio m-line with c=3D0.0.0.0 if that works better.)

4) INVITE to establish session. MSRP media session to carry
   CAP messages. <= br>
5) MESSAGE to send first CAP reading. SUBSCRIBE from PSAP back to
   emergency device with NOTIFYs to carry subsequent CAP data.
   (TBD: mechanism to convey support for subscribe and the URI.)

(Note I have included things above that I consider bad ideas. That can be d= ealt with in the pros/cons.)

    Thanks,
    Paul

Good move.

It seems that also human texting with PSAPs would have the same need of a solution.

EENA NG112 LTE and NENA NG911 i3 08-003  say about Instant messaging:<= br> " MESSAGEs received from the same caller within a configurable time (2= -3 minutes nominally) should be considered part of the same “call”= , and must be routed to the same PSAP (and the same call taker), regardless of movement o= f the caller while texting.=A0 If the origination network/device supports non ses= sion mode IM to NG9-1-1, it must assure that all messages from the same caller within this time frame is sent to the same ESInet (same ECRF query results)= .=A0 If the network/device ca= nnot guarantee this, it must use session mode.= =A0


So the same question exists also for this case is:=A0 What kind of session,= and how is it established?
It seems that RFC 6443 and phonebcp do not bother to mention this detail, therefore I looked at how the usage was in NG112 and NG911.

So, let us try to solve this the same way for both kinds of usage.

/Gunnar




--_000_EDC0A1AE77C57744B664A310A0B23AE20ADA4CD73DFRMRSSXCHMBSC_-- From brian.rosen@neustar.biz Fri Nov 30 06:05:07 2012 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 8008B21F8A15 for ; Fri, 30 Nov 2012 06:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 092OS16OUMFc for ; Fri, 30 Nov 2012 06:05:06 -0800 (PST) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id CBCFE21F8A24 for ; Fri, 30 Nov 2012 06:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1354284128; x=1669632742; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=S/girgS1jDkFQMXr4o/aXMRnilbsxDun4gOBKQHS41o=; b=i97jwR5MKD9jdr9lg7I6tCJTwu9SIdLSNUy3zYu38oDYKTPi9kl8x8nUAHnjIn UUUTstwZKetz5c2T7aDNcQmQ== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.13862407; Fri, 30 Nov 2012 09:02:06 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Fri, 30 Nov 2012 09:04:57 -0500 From: "Rosen, Brian" To: "DRAGE, Keith (Keith)" Date: Fri, 30 Nov 2012 09:04:56 -0500 Thread-Topic: [Ecrit] WGLC - Data-Only Emergency Calls Thread-Index: Ac3PA62+toleLSqDRMKzN8NPctVzJw== Message-ID: References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50B6FA8C.8000909@omnitor.se> <50B78EA8.5030200@alum.mit.edu> <50B7E748.8030106@omnitor.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: +CIqrwsrV208wq32afNElQ== Content-Type: multipart/alternative; boundary="_000_E02A4067066F45C4ACF40031217A0F0Aneustarbiz_" MIME-Version: 1.0 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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: Fri, 30 Nov 2012 14:05:07 -0000 --_000_E02A4067066F45C4ACF40031217A0F0Aneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There are many situations where there is one, and only one message from dev= ice to PSAP. There is no dialog and no media. That's what started the ent= ire draft. We are now dealing with the case where there are updates to the= data, and we're trying to make sure that if there is media AND data, that = the data looks pretty much the same (i.e. a CAP message) If you created a "dialog" with SUBSCRIBE that has all the right characteris= tics for routing and correlation. It also lets the PSAP decide the rate of= updates using filters. I think "pull" via SUBSCRIBE is a better fit for t= he problem than PUSH with MESSAGE/INFO. There has to be a device generated= (push) trigger, so we need INVITE/MESSAGE for that. It's possible to just= say you always start with INVITE and do an immediate BYE if there is no me= dia, but that seems pretty lame. Brian On Nov 30, 2012, at 7:47 AM, "DRAGE, Keith (Keith)" > wrote: The conclusion I seem to come to on all these emergency call issues is that= a dialog is needed, because you need to deliver to the same PSAP who is ha= ndling this for possible emergency voice calls, and that PSAP needs to be a= ble to correlate all the input. While there are some ways round this, it al= ways seems so much easier to say a dialog must exist. That eliminates 1) an= d possibly 5). Regards Keith ________________________________ From: ecrit-bounces@ietf.org [mailto:ecrit-b= ounces@ietf.org] On Behalf Of Gunnar Hellstr=F6m Sent: 29 November 2012 22:53 To: ecrit@ietf.org Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls On 2012-11-29 17:34, Paul Kyzivat wrote: How about making a list of all the possible mechanisms people can think of,= with their pros/cons? Then picking the best one(s). Here is a candidate li= st based mostly on things already discussed here: 1) MESSAGE, out of dialog, to carry CAP data. Sequence of MESSAGEs for sequence of data readings. 2) CAP message body part in INVITE, reINVITE, and UPDATE. Use offer with no m-lines if no media is available. (Or, audio m-line with c=3D0.0.0.0 if that works better.) 3) INVITE to establish session. INFO to carry CAP messages. Use offer with no m-lines if no media is available. (Or, audio m-line with c=3D0.0.0.0 if that works better.) 4) INVITE to establish session. MSRP media session to carry CAP messages. 5) MESSAGE to send first CAP reading. SUBSCRIBE from PSAP back to emergency device with NOTIFYs to carry subsequent CAP data. (TBD: mechanism to convey support for subscribe and the URI.) (Note I have included things above that I consider bad ideas. That can be d= ealt with in the pros/cons.) Thanks, Paul Good move. It seems that also human texting with PSAPs would have the same need of a s= olution. EENA NG112 LTE and NENA NG911 i3 08-003 say about Instant messaging: " MESSAGEs received from the same caller within a configurable time (2-3 mi= nutes nominally) should be considered part of the same =93call=94, and must= be routed to the same PSAP (and the same call taker), regardless of moveme= nt of the caller while texting. If the origination network/device supports= non session mode IM to NG9-1-1, it must assure that all messages from the = same caller within this time frame is sent to the same ESInet (same ECRF qu= ery results). If the network/device cannot guarantee this, it must use ses= sion mode. So the same question exists also for this case is: What kind of session, a= nd how is it established? It seems that RFC 6443 and phonebcp do not bother to mention this detail, t= herefore I looked at how the usage was in NG112 and NG911. So, let us try to solve this the same way for both kinds of usage. /Gunnar _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --_000_E02A4067066F45C4ACF40031217A0F0Aneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There are many situat= ions where there is one, and only one message from device to PSAP.  Th= ere is no dialog and no media.  That's what started the entire draft. =  We are now dealing with the case where there are updates to the data,= and we're trying to make sure that if there is media AND data, that the da= ta looks pretty much the same (i.e. a CAP message)

= If you created a "dialog" with SUBSCRIBE that has all the right characteris= tics for routing and correlation.  It also lets the PSAP decide the ra= te of updates using filters.  I think "pull" via SUBSCRIBE is a better= fit for the problem than PUSH with MESSAGE/INFO.  There has to be a d= evice generated (push) trigger, so we need INVITE/MESSAGE for that.  I= t's possible to just say you always start with INVITE and do an immediate B= YE if there is no media, but that seems pretty lame.

Brian

On Nov 30, 2012, at 7:47 AM, "DRAGE, Keith= (Keith)" <keith.drage= @alcatel-lucent.com> wrote:

The conclusion I seem to come to on all these emergency call issues is that a dialog is needed, beca= use you need to deliver to the same PSAP who is handling this for possible emergency voice calls, and that PSAP needs to be able to correlate all the input. While there are some ways round this, it always seems so much easier= to say a dialog must exist. That eliminates 1) and possibly 5).

 

Regards

 

Keith

&nb= sp;

From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] = On Behalf Of Gunnar Hellstr=F6m
Sent: 29 November 2012 22:53=
To: ecrit@ietf.org
Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls

 =

On 2012-11-29 17:34, Paul Kyziva= t wrote:


How about making a list of all the possible mechanisms people can think of, with their pros/cons? Then picking the best one(s). Here is a candidate lis= t based mostly on things already discussed here:

1) MESSAGE, out of dialog, to carry CAP data.
   Sequence of MESSAGEs for sequence of data readings.

2) CAP message body part in INVITE, reINVITE, and UPDATE.
   Use offer with no m-lines if no media is available.
   (Or, audio m-line with c=3D0.0.0.0 if that works better.)

3) INVITE to establish session. INFO to carry = CAP messages.
   Use offer with no m-lines if no media is available.
   (Or, audio m-line with c=3D0.0.0.0 if that works better.)

4) INVITE to establish session. MSRP media session to carry
   CAP messages. <= br>
5) MESSAGE to send first CAP reading. SUBSCRIBE from PSAP back to
   emergency device with NOTIFYs to carry subsequent CAP data.
   (TBD: mechanism to convey support for subscribe and the URI.)

(Note I have included things above that I consider bad ideas. That can be d= ealt with in the pros/cons.)

    Thanks,
    Paul

Good move.

It seems that also human texting with PSAPs would have the same need of a solution.

EENA NG112 LTE and NENA NG911 i3 08-003  say about Instant messaging:<= br> " MESSAGEs received from the same caller within a configurable time (2-3 minutes nominally) should be considered part of the same =93call=94, and mu= st be routed to the same PSAP (and the same call taker), regardless of movement o= f the caller while texting.  If the origination network/device supports non = session mode IM to NG9-1-1, it must assure that all messages from the same caller within this time frame is sent to the same ESInet (same ECRF query results)= .  If the network/device cannot guarantee this, it must use session mode= . 


So the same question exists also for this case is:  What kind of sessi= on, and how is it established?
It seems that RFC 6443 and phonebcp do not bother to mention this detail, therefore I looked at how the usage was in NG112 and NG911.

So, let us try to solve this the same way for both kinds of usage.

/Gunnar




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

= --_000_E02A4067066F45C4ACF40031217A0F0Aneustarbiz_-- From pkyzivat@alum.mit.edu Fri Nov 30 09:33:07 2012 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 4593E21F8B25 for ; Fri, 30 Nov 2012 09:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZIOc8wpoSjPK for ; Fri, 30 Nov 2012 09:33:06 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id A765721F85A9 for ; Fri, 30 Nov 2012 09:33:06 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id Volv1k0011ZXKqc53tZ6Aq; Fri, 30 Nov 2012 17:33:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id VtZ51k00w3ZTu2S3htZ59r; Fri, 30 Nov 2012 17:33:05 +0000 Message-ID: <50B8EDD1.8090404@alum.mit.edu> Date: Fri, 30 Nov 2012 12:33:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: ecrit@ietf.org References: <509D8F66.9020306@omnitor.se> <50A1170B.6040405@alum.mit.edu> <50A123AC.5070802@alum.mit.edu> <50B6FA8C.8000909@omnitor.se> <50B78EA8.5030200@alum.mit.edu> <50B7E748.8030106@omnitor.se> <24FC6645-569B-4847-BB69-02D14EBEAB86@neustar.biz> <50B8573A.703@omnitor.se> In-Reply-To: <50B8573A.703@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354296786; bh=otkJBGZ9EQ3daCVjxtdhbKTtd0rb+7cblJGPWhVktFw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=KKTX3X9Esx3/Po3gnl6tLsO6ZGKrNyiHHAhFKtobS6FrTkv1WPTFgDIHukIsx9t30 ZkhIeR/J9j+6V26irFZo6XQ6r6ZJWBYwUfk2oGXQ8hCHDuWzRA+vnUn0ZTfWgyYQwT CKFNMK/wUJ2NCiMZWmcSgh43U2aQXIKNhetK367dbdRsyJX1JiW/yPaO9CtOsJJ2xu fHNN8APLkKDNi+NLOv9uWcsmKOXy563Re8MOUpKUVRXZticeZQLYxJLEJT9+moFfYn AOVZsDLiCJtQzutbBCDBTa5xN4GAECqhG4NTbxLwZJu90DLX4wQomHqmfBVM/mFhJ8 svwMOlneeNjTg== Subject: Re: [Ecrit] WGLC - Data-Only Emergency Calls 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: Fri, 30 Nov 2012 17:33:07 -0000 On 11/30/12 1:50 AM, Gunnar Hellström wrote: > On 2012-11-30 01:00, Rosen, Brian wrote: >> A message session is MSRP. So if we're using MESSAGE, we use MSRP if >> we have a sequence of them, but have no media. > Right. That makes sense. >> >> If there is media, you have an INVITE. ReINVITE or UPDATE could carry >> a CAP message, but probably we would be better served by INFO for >> in-dialog update of the CAP alert assuming push. >> >> I believe I would be happiest with MESSAGE or INVITE for the first >> message, and SUB/NOT for updates. That handles the case of MSRP for >> IM media, since the MSRP session is established with INVITE. > In case of SUB/NOT, it has been indicated in this thread that the PSAP > would do the SUBSCRIBE after receiving the initial MESSAGE. > - Then there would be a need for a way for the transmitting device to > indicate that a SUBSCRIBE is wanted. How would that be indicated? > -Also, there is a need for a way to guarantee that the SUBSCRIBE is > addressed to the transmitting device and is answered only by the > transmitting device. It seems as a GRUU may needed, and other > considerations similar to an emergency service callback. Yes, this should be quite analogous to emergency callback. Thanks, Paul