From christer.holmberg@ericsson.com Mon Jun 4 06:20: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 BFFD621F8691 for ; Mon, 4 Jun 2012 06:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fmfordh478z for ; Mon, 4 Jun 2012 06:20:56 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 86CF321F86B0 for ; Mon, 4 Jun 2012 06:20:55 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-86-4fccb636d970 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9B.AD.28636.636BCCF4; Mon, 4 Jun 2012 15:20:54 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 4 Jun 2012 15:20:54 +0200 From: Christer Holmberg To: Paul Kyzivat , "ecrit@ietf.org" Date: Mon, 4 Jun 2012 15:20:53 +0200 Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac0yrhVXB0NeM0KDTpys/aqK293wRAPpqJ7g Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> In-Reply-To: <4FB273EB.2080802@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+Jvra7ZtjP+Bsd6lSwaFz1ltVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJWxYvdCloKz0hVXe04zNjC+F+1i5OSQEDCR +HxpGRuELSZx4d56IJuLQ0jgFKPE7Dt/2SGcOYwSb282ATkcHGwCFhLd/7RBGkQEvCX+/P7G BhJmEVCRONpmDxIWFrCSuPLyGDtEibXE0xsroWwjid7VV5hBbF6BcIk3r5+wgNhCApUS53ff ZAWxOQV0JH6vWgNWwwh0z/dTa5hAbGYBcYlbT+YzQdwpILFkz3lmCFtU4uXjf6wQ9aISd9rX M0LU60gs2P2JDcLWlli28DXUXkGJkzOfsExgFJ2FZOwsJC2zkLTMQtKygJFlFaNwbmJmTnq5 oV5qUWZycXF+nl5x6iZGYIQc3PJbdwfjqXMihxilOViUxHm5kvb7CwmkJ5akZqemFqQWxReV 5qQWH2Jk4uCUamCMW5+afLUl5OcxiSfPXfa5rnpj9W6PZqxzf9/LqxkCoVdnxCiWbp7acq64 MTGdufNP7jJjW3X1UoeJv16ec7lvLNmU7ij2uYq3xSDGRO+HpNBf24Su2aeTtdvc3qzjyrk+ 10iJvSlSg+NlSPOLswqf7EqUrHRaPPg/lLbH3pV5dHTx802SlUosxRmJhlrMRcWJABo4IDte AgAA Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 04 Jun 2012 13:20:57 -0000 Hi, Assuming we would use Priority as callback indicator, is the "emergency" va= lue sufficient, or would be need an explicit "callback" value? Could a PSAP use Priority:emergency for non-callback calls? Regards, Christer -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of P= aul Kyzivat Sent: 15. toukokuuta 2012 18:19 To: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning I'll repeat my earlier arguments. Maybe I can make them more explicit this = time. I think we have sufficient mechanism already defined, if it is used a= ppropriately. Specifically: - the UA, when placing an emergency call, can use a temp gruu. Its possible to get as many temp gruus as you like, so the UA can reserve one for this purpose. This doesn't require any new capabilities in registrars. - when the UA receives a call addressed to a temp gruu that it had previously used for an emergency call, it can give it special treatment as an emergency callback. It can decide how long after the emergency call to grant this special treatment as a matter of policy. The special treatment can include dropping existing calls, special alerting, etc. - the PSAP, when placing the emergency callback, can indicate that *it* considers this call important using the Priority:emergency. If appropriate it can also use other existing headers, such as Resource-Priority. It call also use callerprefs to indicate that it prefers the real UA and does not wish an automaton. - middleboxes in the path of the callback can choose to honor the Priority:emergency, and use that to condition their behavior. For instance, a home proxy could decide that an emergency call to a temp gruu should not be diverted. (Though the fact that it is to a gruu should typically bypass that anyway.) - abuses of Priority:emergency by callers can be dealt with by the called UA, because it can reject such calls if not to a temp gruu previously used for an emergency call. This can cause *some* disruption, but only to the extent of handling an incoming INVITE and rejecting it. If the frequency of that rises to a level where it becomes a problem then it should be dealt with as a DOS attack. Thanks, Paul On 5/15/12 7:05 AM, Christer Holmberg wrote: > Hi, > > Once again, I would like to see whether there is a way for us to move=20 > forward on the callback indicator issue. > > There are two requirements: > > 1.Indicate the callback > > 2.Be able to route the callback to the user that made the emergency=20 > call > > Regarding the indication, it has been suggested that the indicator=20 > value is per user, and is provided to the user upon registration. > > We also discussed whether the value could change over time, but the=20 > problem was that the emg call may be done using an old value, and the=20 > callback using a new value (because there was some time between the=20 > emg call and the callback, during which the user was given a new value). > > To avoid that, the registrar would always provide the same value to a=20 > given user. > > 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 pkyzivat@alum.mit.edu Mon Jun 4 08:31:00 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 581DD21F87E9 for ; Mon, 4 Jun 2012 08:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anOagHiI-oz7 for ; Mon, 4 Jun 2012 08:30:59 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id 377EE21F87E2 for ; Mon, 4 Jun 2012 08:30:58 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta09.westchester.pa.mail.comcast.net with comcast id JCcC1j0061vXlb859FWyUE; Mon, 04 Jun 2012 15:30:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id JFWx1j01N07duvL3dFWybq; Mon, 04 Jun 2012 15:30:58 +0000 Message-ID: <4FCCD4B1.5010103@alum.mit.edu> Date: Mon, 04 Jun 2012 11:30:57 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 04 Jun 2012 15:31:00 -0000 On 6/4/12 9:20 AM, Christer Holmberg wrote: > Hi, > > Assuming we would use Priority as callback indicator, is the "emergency" value sufficient, or would be need an explicit "callback" value? > > Could a PSAP use Priority:emergency for non-callback calls? I suppose these questions may deserve further discussion. IMO Priority:emergency is appropriate for the callback, assuming it should be treated as an emergency. (OTOH, if the psap decides to call back the next day just as a followup, to see if all is well, then perhaps it isn't an emergency.) I don't understand what the use case might be, but if the psap felt a need to initiate a call that was not a callback to a prior emergency call, and it felt the call was indeed an emergency, then I see no reason why it should not tag it with Priority:emergency. In the latter case, the call might not get the same treatment on the receiving end. In this case the callee has nothing to help it distinguish a justified use of Priority:emergency from an unjustified one. So it might not give the call any priority treatment. But I think that is fine. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 15. toukokuuta 2012 18:19 > To: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > I'll repeat my earlier arguments. Maybe I can make them more explicit this time. I think we have sufficient mechanism already defined, if it is used appropriately. Specifically: > > - the UA, when placing an emergency call, can use a temp gruu. > Its possible to get as many temp gruus as you like, so the UA > can reserve one for this purpose. This doesn't require any > new capabilities in registrars. > > - when the UA receives a call addressed to a temp gruu that it > had previously used for an emergency call, it can give it > special treatment as an emergency callback. It can decide how > long after the emergency call to grant this special treatment > as a matter of policy. The special treatment can include dropping > existing calls, special alerting, etc. > > - the PSAP, when placing the emergency callback, can indicate that > *it* considers this call important using the Priority:emergency. > If appropriate it can also use other existing headers, such as > Resource-Priority. It call also use callerprefs to indicate that > it prefers the real UA and does not wish an automaton. > > - middleboxes in the path of the callback can choose to honor the > Priority:emergency, and use that to condition their behavior. > For instance, a home proxy could decide that an emergency call > to a temp gruu should not be diverted. (Though the fact that it is > to a gruu should typically bypass that anyway.) > > - abuses of Priority:emergency by callers can be dealt with by the > called UA, because it can reject such calls if not to a temp > gruu previously used for an emergency call. This can cause *some* > disruption, but only to the extent of handling an incoming INVITE > and rejecting it. If the frequency of that rises to a level where > it becomes a problem then it should be dealt with as a DOS attack. > > Thanks, > Paul > > On 5/15/12 7:05 AM, Christer Holmberg wrote: >> Hi, >> >> Once again, I would like to see whether there is a way for us to move >> forward on the callback indicator issue. >> >> There are two requirements: >> >> 1.Indicate the callback >> >> 2.Be able to route the callback to the user that made the emergency >> call >> >> Regarding the indication, it has been suggested that the indicator >> value is per user, and is provided to the user upon registration. >> >> We also discussed whether the value could change over time, but the >> problem was that the emg call may be done using an old value, and the >> callback using a new value (because there was some time between the >> emg call and the callback, during which the user was given a new value). >> >> To avoid that, the registrar would always provide the same value to a >> given user. >> >> 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 christer.holmberg@ericsson.com Mon Jun 4 10:36:04 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 4EE6A21F86E8 for ; Mon, 4 Jun 2012 10:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.214 X-Spam-Level: X-Spam-Status: No, score=-6.214 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muBmNyOY0POR for ; Mon, 4 Jun 2012 10:36:03 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1A56321F86E5 for ; Mon, 4 Jun 2012 10:36:02 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-6f-4fccf20203b3 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9C.78.28636.202FCCF4; Mon, 4 Jun 2012 19:36:02 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 4 Jun 2012 19:36:01 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Mon, 4 Jun 2012 19:33:00 +0200 Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac1CZwrExs7BGv+IQNqt4cTvbEMurAAEQvlq Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> In-Reply-To: <4FCCD4B1.5010103@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+JvrS7TpzP+Bq/n8Vs0LnrKarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj+cgBpoI9qhXT5nxmbmCcL9vFyMkhIWAi 0TbzODOELSZx4d56ti5GLg4hgVOMEptbn7FAOAsYJTYubGDtYuTgYBOwkOj+pw1iighoSEza qgbSyyygKnGu8TELiM0ioCJx+e4lVhBbWMBK4srLY+wgtoiAtcTTGyuhbCOJBw/vgtXzCoRL bNl/kxli1XNGiUcL2tlAEpwCOhJr3p5nBLEZgY77fmoNE8QycYlbT+YzQRwtILFkz3moB0Ql Xj7+xwpRLypxp309I0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERrFZSMbOQtIyC0nLLCQt CxhZVjEK5yZm5qSXG+qlFmUmFxfn5+kVp25iBMbOwS2/dXcwnjoncohRmoNFSZyXK2m/v5BA emJJanZqakFqUXxRaU5q8SFGJg5OqQZGQc4Gzeka+7IseBim+QReM2S6HdAjHj/rGfe0Sx+2 MDRrOWmXn1Qvi+KLYV3po3TS0lzWrY+lp+Ow4IHtTx2M34WeXpl9xmqp5qbO1Eb7monr8yXq A1cumBid292TwWKTdfvGC/3QK2FnvTaZxsffy7Zw/uBxcMK+qZMrLfgUOKe3mbaLb1JiKc5I NNRiLipOBAC+vz3sawIAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 04 Jun 2012 17:36:04 -0000 Hi, >> Assuming we would use Priority as callback indicator, is the "emergency"= value sufficient, or would be need an explicit "callback" value? >> >> Could a PSAP use Priority:emergency for non-callback calls? > > I suppose these questions may deserve further discussion. > > IMO Priority:emergency is appropriate for the callback, assuming it > should be treated as an emergency. (OTOH, if the psap decides to call > back the next day just as a followup, to see if all is well, then > perhaps it isn't an emergency.) > > I don't understand what the use case might be, but if the psap felt a > need to initiate a call that was not a callback to a prior emergency > call, and it felt the call was indeed an emergency, then I see no reason > why it should not tag it with Priority:emergency. > > In the latter case, the call might not get the same treatment on the > receiving end. In this case the callee has nothing to help it > distinguish a justified use of Priority:emergency from an unjustified > one. So it might not give the call any priority treatment. But I think > that is fine. OTOH, defining a new Priority value is not a very difficult task :)=20 Also, in this case I guess the semantics of a callback already exists, so w= e wouldn't need to work much on that. Regards, Christer > Regards, > > Christer > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Paul Kyzivat > Sent: 15. toukokuuta 2012 18:19 > To: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > I'll repeat my earlier arguments. Maybe I can make them more explicit thi= s time. I think we have sufficient mechanism already defined, if it is used= appropriately. Specifically: > > - the UA, when placing an emergency call, can use a temp gruu. > Its possible to get as many temp gruus as you like, so the UA > can reserve one for this purpose. This doesn't require any > new capabilities in registrars. > > - when the UA receives a call addressed to a temp gruu that it > had previously used for an emergency call, it can give it > special treatment as an emergency callback. It can decide how > long after the emergency call to grant this special treatment > as a matter of policy. The special treatment can include dropping > existing calls, special alerting, etc. > > - the PSAP, when placing the emergency callback, can indicate that > *it* considers this call important using the Priority:emergency. > If appropriate it can also use other existing headers, such as > Resource-Priority. It call also use callerprefs to indicate that > it prefers the real UA and does not wish an automaton. > > - middleboxes in the path of the callback can choose to honor the > Priority:emergency, and use that to condition their behavior. > For instance, a home proxy could decide that an emergency call > to a temp gruu should not be diverted. (Though the fact that it is > to a gruu should typically bypass that anyway.) > > - abuses of Priority:emergency by callers can be dealt with by the > called UA, because it can reject such calls if not to a temp > gruu previously used for an emergency call. This can cause *some* > disruption, but only to the extent of handling an incoming INVITE > and rejecting it. If the frequency of that rises to a level where > it becomes a problem then it should be dealt with as a DOS attack. > > Thanks, > Paul > > On 5/15/12 7:05 AM, Christer Holmberg wrote: >> Hi, >> >> Once again, I would like to see whether there is a way for us to move >> forward on the callback indicator issue. >> >> There are two requirements: >> >> 1.Indicate the callback >> >> 2.Be able to route the callback to the user that made the emergency >> call >> >> Regarding the indication, it has been suggested that the indicator >> value is per user, and is provided to the user upon registration. >> >> We also discussed whether the value could change over time, but the >> problem was that the emg call may be done using an old value, and the >> callback using a new value (because there was some time between the >> emg call and the callback, during which the user was given a new value). >> >> To avoid that, the registrar would always provide the same value to a >> given user. >> >> 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 pkyzivat@alum.mit.edu Mon Jun 4 10:48:19 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 B8C6C21F87DB for ; Mon, 4 Jun 2012 10:48:19 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIkx86g85Euw for ; Mon, 4 Jun 2012 10:48:19 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 135EA21F87D0 for ; Mon, 4 Jun 2012 10:48:18 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta03.westchester.pa.mail.comcast.net with comcast id JHkF1j0071HzFnQ53HoJiL; Mon, 04 Jun 2012 17:48:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta14.westchester.pa.mail.comcast.net with comcast id JHoH1j00J07duvL3aHoJpA; Mon, 04 Jun 2012 17:48:18 +0000 Message-ID: <4FCCF4E1.7010808@alum.mit.edu> Date: Mon, 04 Jun 2012 13:48:17 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 04 Jun 2012 17:48:19 -0000 On 6/4/12 1:33 PM, Christer Holmberg wrote: > Hi, > >>> Assuming we would use Priority as callback indicator, is the "emergency" value sufficient, or would be need an explicit "callback" value? >>> >>> Could a PSAP use Priority:emergency for non-callback calls? >> >> I suppose these questions may deserve further discussion. >> >> IMO Priority:emergency is appropriate for the callback, assuming it >> should be treated as an emergency. (OTOH, if the psap decides to call >> back the next day just as a followup, to see if all is well, then >> perhaps it isn't an emergency.) >> >> I don't understand what the use case might be, but if the psap felt a >> need to initiate a call that was not a callback to a prior emergency >> call, and it felt the call was indeed an emergency, then I see no reason >> why it should not tag it with Priority:emergency. >> >> In the latter case, the call might not get the same treatment on the >> receiving end. In this case the callee has nothing to help it >> distinguish a justified use of Priority:emergency from an unjustified >> one. So it might not give the call any priority treatment. But I think >> that is fine. > > OTOH, defining a new Priority value is not a very difficult task :) > > Also, in this case I guess the semantics of a callback already exists, so we wouldn't need to work much on that. My preference would be to use the existing values when they have the right semantics, which "emergency" seems to do right now. The fact that its a callback isn't really very interesting - that its an emergency *is*. The callback part of this is really a perspective of the callee - that it might be expecting an emergency call if it has lost the one it was in. The primary purpose there is simply as a screening device for fraudulent use of "emergency". Thanks, Paul From md3135@att.com Mon Jun 4 10:57:29 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 5D85711E808F for ; Mon, 4 Jun 2012 10:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3AGkD2LOHp1 for ; Mon, 4 Jun 2012 10:57:28 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2B011E8079 for ; Mon, 4 Jun 2012 10:57:25 -0700 (PDT) Received: from unknown [144.160.112.28] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 507fccf4.2aaad8a20940.633587.00-597.1736390.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 04 Jun 2012 17:57:25 +0000 (UTC) X-MXL-Hash: 4fccf705074f8fbb-064e31b14ad8e9d710e2ed5c218c651a28818406 Received: from unknown [144.160.112.28] (EHLO tlpi048.enaf.dadc.sbc.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id ef6fccf4.0.633536.00-354.1736234.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 04 Jun 2012 17:57:18 +0000 (UTC) X-MXL-Hash: 4fccf6fe5cdb6428-c9a050e26f1532e0bd1c5703280686bd344f905e Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id q54HvGkd010868; Mon, 4 Jun 2012 12:57:18 -0500 Received: from dalint02.pst.cso.att.com (dalint02.pst.cso.att.com [135.31.133.160]) by tlpi048.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id q54Hv61c010567; Mon, 4 Jun 2012 12:57:10 -0500 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by dalint02.pst.cso.att.com (RSA Interceptor); Mon, 4 Jun 2012 12:56:42 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.01.0355.002; Mon, 4 Jun 2012 13:56:32 -0400 From: "DOLLY, MARTIN C" To: Christer Holmberg , Paul Kyzivat Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac0yrhVXB0NeM0KDTpys/aqK293wRAPpqJ7gAAz2KIAABEM3AAAHq2+Q Date: Mon, 4 Jun 2012 17:56:31 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.81.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.112.28] X-AnalysisOut: [v=1.0 c=1 a=LiyzjbWjBN0A:10 a=QUyreDvST80A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=srMsL6ituuWTYe] X-AnalysisOut: [ky9Bs9mA==:17 a=48vgC7mUAAAA:8 a=8xbLBnFPGlBFZDp2IK4A:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=m-6fQbAZDkWxsXn_:21 a=] X-AnalysisOut: [7Rq9sVs-4xLJtHrt:21] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 04 Jun 2012 17:57:29 -0000 A new RPH=3DSOS (versus SOL) that is honored based on a trust model/relatio= nships=20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: Monday, June 04, 2012 1:33 PM To: Paul Kyzivat Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning Hi, >> Assuming we would use Priority as callback indicator, is the "emergency"= value sufficient, or would be need an explicit "callback" value? >> >> Could a PSAP use Priority:emergency for non-callback calls? > > I suppose these questions may deserve further discussion. > > IMO Priority:emergency is appropriate for the callback, assuming it > should be treated as an emergency. (OTOH, if the psap decides to call > back the next day just as a followup, to see if all is well, then > perhaps it isn't an emergency.) > > I don't understand what the use case might be, but if the psap felt a > need to initiate a call that was not a callback to a prior emergency > call, and it felt the call was indeed an emergency, then I see no reason > why it should not tag it with Priority:emergency. > > In the latter case, the call might not get the same treatment on the > receiving end. In this case the callee has nothing to help it > distinguish a justified use of Priority:emergency from an unjustified > one. So it might not give the call any priority treatment. But I think > that is fine. OTOH, defining a new Priority value is not a very difficult task :)=20 Also, in this case I guess the semantics of a callback already exists, so w= e wouldn't need to work much on that. Regards, Christer > Regards, > > Christer > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Paul Kyzivat > Sent: 15. toukokuuta 2012 18:19 > To: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > I'll repeat my earlier arguments. Maybe I can make them more explicit thi= s time. I think we have sufficient mechanism already defined, if it is used= appropriately. Specifically: > > - the UA, when placing an emergency call, can use a temp gruu. > Its possible to get as many temp gruus as you like, so the UA > can reserve one for this purpose. This doesn't require any > new capabilities in registrars. > > - when the UA receives a call addressed to a temp gruu that it > had previously used for an emergency call, it can give it > special treatment as an emergency callback. It can decide how > long after the emergency call to grant this special treatment > as a matter of policy. The special treatment can include dropping > existing calls, special alerting, etc. > > - the PSAP, when placing the emergency callback, can indicate that > *it* considers this call important using the Priority:emergency. > If appropriate it can also use other existing headers, such as > Resource-Priority. It call also use callerprefs to indicate that > it prefers the real UA and does not wish an automaton. > > - middleboxes in the path of the callback can choose to honor the > Priority:emergency, and use that to condition their behavior. > For instance, a home proxy could decide that an emergency call > to a temp gruu should not be diverted. (Though the fact that it is > to a gruu should typically bypass that anyway.) > > - abuses of Priority:emergency by callers can be dealt with by the > called UA, because it can reject such calls if not to a temp > gruu previously used for an emergency call. This can cause *some* > disruption, but only to the extent of handling an incoming INVITE > and rejecting it. If the frequency of that rises to a level where > it becomes a problem then it should be dealt with as a DOS attack. > > Thanks, > Paul > > On 5/15/12 7:05 AM, Christer Holmberg wrote: >> Hi, >> >> Once again, I would like to see whether there is a way for us to move >> forward on the callback indicator issue. >> >> There are two requirements: >> >> 1.Indicate the callback >> >> 2.Be able to route the callback to the user that made the emergency >> call >> >> Regarding the indication, it has been suggested that the indicator >> value is per user, and is provided to the user upon registration. >> >> We also discussed whether the value could change over time, but the >> problem was that the emg call may be done using an old value, and the >> callback using a new value (because there was some time between the >> emg call and the callback, during which the user was given a new value). >> >> To avoid that, the registrar would always provide the same value to a >> given user. >> >> 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 pkyzivat@alum.mit.edu Mon Jun 4 11:03:49 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 48E0F21F85A3 for ; Mon, 4 Jun 2012 11:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsMcR18NnagA for ; Mon, 4 Jun 2012 11:03:48 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 57FB221F85A1 for ; Mon, 4 Jun 2012 11:03:48 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta08.westchester.pa.mail.comcast.net with comcast id JEkp1j00227AodY58J3nhD; Mon, 04 Jun 2012 18:03:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id JJ3n1j00507duvL3fJ3nw7; Mon, 04 Jun 2012 18:03:47 +0000 Message-ID: <4FCCF882.6020906@alum.mit.edu> Date: Mon, 04 Jun 2012 14:03:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "DOLLY, MARTIN C" References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 04 Jun 2012 18:03:49 -0000 On 6/4/12 1:56 PM, DOLLY, MARTIN C wrote: > A new RPH=SOS (versus SOL) that is honored based on a trust model/relationships I had originally noted that we could use a number of existing indications. Resource-Priority would perhaps be good in environments that do something with it. This would be complementary to the Priority:emergency, which is an indication of how the caller perceives the call. The Resource-Priority, when used, may be subject to other controls, and mostly impact intermediaries, rather than the callee. Thanks, Paul > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Monday, June 04, 2012 1:33 PM > To: Paul Kyzivat > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > Hi, > >>> Assuming we would use Priority as callback indicator, is the "emergency" value sufficient, or would be need an explicit "callback" value? >>> >>> Could a PSAP use Priority:emergency for non-callback calls? >> >> I suppose these questions may deserve further discussion. >> >> IMO Priority:emergency is appropriate for the callback, assuming it >> should be treated as an emergency. (OTOH, if the psap decides to call >> back the next day just as a followup, to see if all is well, then >> perhaps it isn't an emergency.) >> >> I don't understand what the use case might be, but if the psap felt a >> need to initiate a call that was not a callback to a prior emergency >> call, and it felt the call was indeed an emergency, then I see no reason >> why it should not tag it with Priority:emergency. >> >> In the latter case, the call might not get the same treatment on the >> receiving end. In this case the callee has nothing to help it >> distinguish a justified use of Priority:emergency from an unjustified >> one. So it might not give the call any priority treatment. But I think >> that is fine. > > OTOH, defining a new Priority value is not a very difficult task :) > > Also, in this case I guess the semantics of a callback already exists, so we wouldn't need to work much on that. > > Regards, > > Christer > > >> Regards, >> >> Christer >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 15. toukokuuta 2012 18:19 >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >> >> I'll repeat my earlier arguments. Maybe I can make them more explicit this time. I think we have sufficient mechanism already defined, if it is used appropriately. Specifically: >> >> - the UA, when placing an emergency call, can use a temp gruu. >> Its possible to get as many temp gruus as you like, so the UA >> can reserve one for this purpose. This doesn't require any >> new capabilities in registrars. >> >> - when the UA receives a call addressed to a temp gruu that it >> had previously used for an emergency call, it can give it >> special treatment as an emergency callback. It can decide how >> long after the emergency call to grant this special treatment >> as a matter of policy. The special treatment can include dropping >> existing calls, special alerting, etc. >> >> - the PSAP, when placing the emergency callback, can indicate that >> *it* considers this call important using the Priority:emergency. >> If appropriate it can also use other existing headers, such as >> Resource-Priority. It call also use callerprefs to indicate that >> it prefers the real UA and does not wish an automaton. >> >> - middleboxes in the path of the callback can choose to honor the >> Priority:emergency, and use that to condition their behavior. >> For instance, a home proxy could decide that an emergency call >> to a temp gruu should not be diverted. (Though the fact that it is >> to a gruu should typically bypass that anyway.) >> >> - abuses of Priority:emergency by callers can be dealt with by the >> called UA, because it can reject such calls if not to a temp >> gruu previously used for an emergency call. This can cause *some* >> disruption, but only to the extent of handling an incoming INVITE >> and rejecting it. If the frequency of that rises to a level where >> it becomes a problem then it should be dealt with as a DOS attack. >> >> Thanks, >> Paul >> >> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>> Hi, >>> >>> Once again, I would like to see whether there is a way for us to move >>> forward on the callback indicator issue. >>> >>> There are two requirements: >>> >>> 1.Indicate the callback >>> >>> 2.Be able to route the callback to the user that made the emergency >>> call >>> >>> Regarding the indication, it has been suggested that the indicator >>> value is per user, and is provided to the user upon registration. >>> >>> We also discussed whether the value could change over time, but the >>> problem was that the emg call may be done using an old value, and the >>> callback using a new value (because there was some time between the >>> emg call and the callback, during which the user was given a new value). >>> >>> To avoid that, the registrar would always provide the same value to a >>> given user. >>> >>> 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 Mon Jun 4 11:06: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 E1C7021F861B for ; Mon, 4 Jun 2012 11:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.916 X-Spam-Level: X-Spam-Status: No, score=-5.916 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk1MzugGZce4 for ; Mon, 4 Jun 2012 11:06:55 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A1B9521F863F for ; Mon, 4 Jun 2012 11:06:54 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-bb-4fccf93d713e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BF.B9.00702.D39FCCF4; Mon, 4 Jun 2012 20:06:53 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 4 Jun 2012 20:06:53 +0200 From: Christer Holmberg To: Paul Kyzivat , "DOLLY, MARTIN C" Date: Mon, 4 Jun 2012 20:05:46 +0200 Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac1CfGQQJp6TI4lOSmOH+SdUpmZkawAAEaRD Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C457B13C8@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> , <4FCCF882.6020906@alum.mit.edu> In-Reply-To: <4FCCF882.6020906@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvra7tzzP+BpeXGFs0LnrKanHowVN2 ixUbDrA6MHv8ff+ByeNl/xxGjyVLfjIFMEdx2aSk5mSWpRbp2yVwZfT+/8hcMFO/YvpM1gbG GapdjJwcEgImEtPO3GaBsMUkLtxbz9bFyMUhJHCKUeLu/YvsEM4CRolnS04DZTg42AQsJLr/ aYM0iAj4SDzffoURxGYWUJU41/gYbBCLgIrEz9mH2UFsYQEriSsvj7FD1FtLPL2xEso2knh5 eR4TiM0rEC6x98FMRohdy5gl1rU+YAZJcAroSHTtaQNrYAS67vupNUwQy8Qlbj2ZzwRxtYDE kj3nmSFsUYmXj/+xQtSLStxpXw91nI7Egt2f2CBsbYllC18zQywWlDg58wnLBEaxWUjGzkLS MgtJyywkLQsYWVYxCucmZuakl5vrpRZlJhcX5+fpFaduYgTG08Etvw12MG66L3aIUZqDRUmc V091v7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRivhmPgzMgG//hjwiK469PDblqOvs5J6 TU5M/M+UfCPe2YdxgclrtsBAL3Wus/GVbluP6X4JUTn26lzdyb9HUxMs/tcy9hzhae9vEOD3 mXk0d9uNBwy7DOz/7zOOiuN75SOxy2xGwQbJwyJd3qse60eed01zrNv8Y5X9cq+lggXFG3Ov SKhHKbEUZyQaajEXFScCAIFwQwp1AgAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 04 Jun 2012 18:06:56 -0000 Hi, >> A new RPH=3DSOS (versus SOL) that is honored based on a trust model/rela= tionships > > I had originally noted that we could use a number of existing > indications. Resource-Priority would perhaps be good in environments > that do something with it. This would be complementary to the > Priority:emergency, which is an indication of how the caller perceives > the call. The Resource-Priority, when used, may be subject to other > controls, and mostly impact intermediaries, rather than the callee. Well, as we've discussed before, we DO need an indicator which is used by i= ntermediaries to give special treatment to the callback. Regards, Christer > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Christer Holmberg > Sent: Monday, June 04, 2012 1:33 PM > To: Paul Kyzivat > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > Hi, > >>> Assuming we would use Priority as callback indicator, is the "emergency= " value sufficient, or would be need an explicit "callback" value? >>> >>> Could a PSAP use Priority:emergency for non-callback calls? >> >> I suppose these questions may deserve further discussion. >> >> IMO Priority:emergency is appropriate for the callback, assuming it >> should be treated as an emergency. (OTOH, if the psap decides to call >> back the next day just as a followup, to see if all is well, then >> perhaps it isn't an emergency.) >> >> I don't understand what the use case might be, but if the psap felt a >> need to initiate a call that was not a callback to a prior emergency >> call, and it felt the call was indeed an emergency, then I see no reason >> why it should not tag it with Priority:emergency. >> >> In the latter case, the call might not get the same treatment on the >> receiving end. In this case the callee has nothing to help it >> distinguish a justified use of Priority:emergency from an unjustified >> one. So it might not give the call any priority treatment. But I think >> that is fine. > > OTOH, defining a new Priority value is not a very difficult task :) > > Also, in this case I guess the semantics of a callback already exists, so= we wouldn't need to work much on that. > > Regards, > > Christer > > >> Regards, >> >> Christer >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f Paul Kyzivat >> Sent: 15. toukokuuta 2012 18:19 >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >> >> I'll repeat my earlier arguments. Maybe I can make them more explicit th= is time. I think we have sufficient mechanism already defined, if it is use= d appropriately. Specifically: >> >> - the UA, when placing an emergency call, can use a temp gruu. >> Its possible to get as many temp gruus as you like, so the UA >> can reserve one for this purpose. This doesn't require any >> new capabilities in registrars. >> >> - when the UA receives a call addressed to a temp gruu that it >> had previously used for an emergency call, it can give it >> special treatment as an emergency callback. It can decide how >> long after the emergency call to grant this special treatment >> as a matter of policy. The special treatment can include dropping >> existing calls, special alerting, etc. >> >> - the PSAP, when placing the emergency callback, can indicate that >> *it* considers this call important using the Priority:emergency. >> If appropriate it can also use other existing headers, such as >> Resource-Priority. It call also use callerprefs to indicate that >> it prefers the real UA and does not wish an automaton. >> >> - middleboxes in the path of the callback can choose to honor the >> Priority:emergency, and use that to condition their behavior. >> For instance, a home proxy could decide that an emergency call >> to a temp gruu should not be diverted. (Though the fact that it is >> to a gruu should typically bypass that anyway.) >> >> - abuses of Priority:emergency by callers can be dealt with by the >> called UA, because it can reject such calls if not to a temp >> gruu previously used for an emergency call. This can cause *some* >> disruption, but only to the extent of handling an incoming INVITE >> and rejecting it. If the frequency of that rises to a level where >> it becomes a problem then it should be dealt with as a DOS attack. >> >> Thanks, >> Paul >> >> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>> Hi, >>> >>> Once again, I would like to see whether there is a way for us to move >>> forward on the callback indicator issue. >>> >>> There are two requirements: >>> >>> 1.Indicate the callback >>> >>> 2.Be able to route the callback to the user that made the emergency >>> call >>> >>> Regarding the indication, it has been suggested that the indicator >>> value is per user, and is provided to the user upon registration. >>> >>> We also discussed whether the value could change over time, but the >>> problem was that the emg call may be done using an old value, and the >>> callback using a new value (because there was some time between the >>> emg call and the callback, during which the user was given a new value)= . >>> >>> To avoid that, the registrar would always provide the same value to a >>> given user. >>> >>> 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 pkyzivat@alum.mit.edu Mon Jun 4 13:26: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 930E811E80FC for ; Mon, 4 Jun 2012 13:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1COGFW6YNuY for ; Mon, 4 Jun 2012 13:26:29 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8159711E80E6 for ; Mon, 4 Jun 2012 13:26:29 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id JBF31j00U1ap0As53LSVY9; Mon, 04 Jun 2012 20:26:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id JLSU1j00s07duvL3iLSUAZ; Mon, 04 Jun 2012 20:26:29 +0000 Message-ID: <4FCD19F4.9070704@alum.mit.edu> Date: Mon, 04 Jun 2012 16:26:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> , <4FCCF882.6020906@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C8@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C457B13C8@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 04 Jun 2012 20:26:30 -0000 On 6/4/12 2:05 PM, Christer Holmberg wrote: > Hi, > >>> A new RPH=SOS (versus SOL) that is honored based on a trust model/relationships >> >> I had originally noted that we could use a number of existing >> indications. Resource-Priority would perhaps be good in environments >> that do something with it. This would be complementary to the >> Priority:emergency, which is an indication of how the caller perceives >> the call. The Resource-Priority, when used, may be subject to other >> controls, and mostly impact intermediaries, rather than the callee. > > Well, as we've discussed before, we DO need an indicator which is used by intermediaries to give special treatment to the callback. Well, I guess it depends on what sorts of treatment you are talking about. If you are talking about resource prioritization, then the Resource-Priority header is probably what you want. If you are talking about bypassing various sorts of treatment, such as call diversion, then I don't think Resource-Priority is the right thing. Those are generally discretionary anyway. Honoring the caller's wishes, expressed via Priority and perhaps callerprefs, seems to make more sense. In such cases, there is a question of whether to honor the caller's preferences, or the callee's policies. It's my personal opinion that if the caller says he only wants to talk to a human, not an automaton, then one should honor that, and either let the human's phone ring or else simply reject the call. And I'm suggesting that from a provider perspective that means passing the call to the UA and letting it decide. Thanks, Paul > Regards, > > Christer > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: Monday, June 04, 2012 1:33 PM >> To: Paul Kyzivat >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >> >> Hi, >> >>>> Assuming we would use Priority as callback indicator, is the "emergency" value sufficient, or would be need an explicit "callback" value? >>>> >>>> Could a PSAP use Priority:emergency for non-callback calls? >>> >>> I suppose these questions may deserve further discussion. >>> >>> IMO Priority:emergency is appropriate for the callback, assuming it >>> should be treated as an emergency. (OTOH, if the psap decides to call >>> back the next day just as a followup, to see if all is well, then >>> perhaps it isn't an emergency.) >>> >>> I don't understand what the use case might be, but if the psap felt a >>> need to initiate a call that was not a callback to a prior emergency >>> call, and it felt the call was indeed an emergency, then I see no reason >>> why it should not tag it with Priority:emergency. >>> >>> In the latter case, the call might not get the same treatment on the >>> receiving end. In this case the callee has nothing to help it >>> distinguish a justified use of Priority:emergency from an unjustified >>> one. So it might not give the call any priority treatment. But I think >>> that is fine. >> >> OTOH, defining a new Priority value is not a very difficult task :) >> >> Also, in this case I guess the semantics of a callback already exists, so we wouldn't need to work much on that. >> >> Regards, >> >> Christer >> >> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: 15. toukokuuta 2012 18:19 >>> To: ecrit@ietf.org >>> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >>> >>> I'll repeat my earlier arguments. Maybe I can make them more explicit this time. I think we have sufficient mechanism already defined, if it is used appropriately. Specifically: >>> >>> - the UA, when placing an emergency call, can use a temp gruu. >>> Its possible to get as many temp gruus as you like, so the UA >>> can reserve one for this purpose. This doesn't require any >>> new capabilities in registrars. >>> >>> - when the UA receives a call addressed to a temp gruu that it >>> had previously used for an emergency call, it can give it >>> special treatment as an emergency callback. It can decide how >>> long after the emergency call to grant this special treatment >>> as a matter of policy. The special treatment can include dropping >>> existing calls, special alerting, etc. >>> >>> - the PSAP, when placing the emergency callback, can indicate that >>> *it* considers this call important using the Priority:emergency. >>> If appropriate it can also use other existing headers, such as >>> Resource-Priority. It call also use callerprefs to indicate that >>> it prefers the real UA and does not wish an automaton. >>> >>> - middleboxes in the path of the callback can choose to honor the >>> Priority:emergency, and use that to condition their behavior. >>> For instance, a home proxy could decide that an emergency call >>> to a temp gruu should not be diverted. (Though the fact that it is >>> to a gruu should typically bypass that anyway.) >>> >>> - abuses of Priority:emergency by callers can be dealt with by the >>> called UA, because it can reject such calls if not to a temp >>> gruu previously used for an emergency call. This can cause *some* >>> disruption, but only to the extent of handling an incoming INVITE >>> and rejecting it. If the frequency of that rises to a level where >>> it becomes a problem then it should be dealt with as a DOS attack. >>> >>> Thanks, >>> Paul >>> >>> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>>> Hi, >>>> >>>> Once again, I would like to see whether there is a way for us to move >>>> forward on the callback indicator issue. >>>> >>>> There are two requirements: >>>> >>>> 1.Indicate the callback >>>> >>>> 2.Be able to route the callback to the user that made the emergency >>>> call >>>> >>>> Regarding the indication, it has been suggested that the indicator >>>> value is per user, and is provided to the user upon registration. >>>> >>>> We also discussed whether the value could change over time, but the >>>> problem was that the emg call may be done using an old value, and the >>>> callback using a new value (because there was some time between the >>>> emg call and the callback, during which the user was given a new value). >>>> >>>> To avoid that, the registrar would always provide the same value to a >>>> given user. >>>> >>>> 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 md3135@att.com Mon Jun 4 13:32:17 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 62E1621F8735 for ; Mon, 4 Jun 2012 13:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rEHivYaCswx for ; Mon, 4 Jun 2012 13:32:16 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 38C2721F871C for ; Mon, 4 Jun 2012 13:32:16 -0700 (PDT) Received: from unknown [144.160.128.153] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) with ESMTP id 05b1dcf4.2aaafe04f940.372845.00-558.1036128.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 04 Jun 2012 20:32:16 +0000 (UTC) X-MXL-Hash: 4fcd1b50699b2b68-693eb9a8d06bab99f33e280426c21aeecd4b01cb Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 84b1dcf4.0.372806.00-443.1036015.nbfkord-smmo05.seg.att.com (envelope-from ); Mon, 04 Jun 2012 20:32:09 +0000 (UTC) X-MXL-Hash: 4fcd1b494a222555-9b9b7b3d3f186ed0e803ad7c5ed547c261b18303 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q54KW6U2017777; Mon, 4 Jun 2012 13:32:08 -0700 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id q54KVwVG017640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 4 Jun 2012 13:32:02 -0700 Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by fflint04.pst.cso.att.com (RSA Interceptor); Mon, 4 Jun 2012 13:31:33 -0700 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.01.0355.002; Mon, 4 Jun 2012 16:31:32 -0400 From: "DOLLY, MARTIN C" To: Paul Kyzivat , Christer Holmberg Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac0yrhVXB0NeM0KDTpys/aqK293wRAPpqJ7gAAz2KIAABEM3AAAHq2+Q///LPQCAAACPAIAAJ08AgABB4jA= Date: Mon, 4 Jun 2012 20:31:32 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> , <4FCCF882.6020906@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C8@ESESSCMS0356.eemea.ericsson.se> <4FCD19F4.9070704@alum.mit.edu> In-Reply-To: <4FCD19F4.9070704@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.81.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=1.0 c=1 a=LiyzjbWjBN0A:10 a=QUyreDvST80A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xwOvzTHDVLE4u4] X-AnalysisOut: [nGvK72ag==:17 a=48vgC7mUAAAA:8 a=27DCiJU3d_MvJWKck6IA:9 a=] X-AnalysisOut: [CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=LT0mWwAV6d_AcJH1:21 a=] X-AnalysisOut: [XLzHQ86HexugZkFz:21] Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 04 Jun 2012 20:32:17 -0000 Paul, I agree that this is not a priority service, and thereby RPH is likely not = appropriate. Martin -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Monday, June 04, 2012 4:26 PM To: Christer Holmberg Cc: DOLLY, MARTIN C; ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning On 6/4/12 2:05 PM, Christer Holmberg wrote: > Hi, > >>> A new RPH=3DSOS (versus SOL) that is honored based on a trust model/rel= ationships >> >> I had originally noted that we could use a number of existing >> indications. Resource-Priority would perhaps be good in environments >> that do something with it. This would be complementary to the >> Priority:emergency, which is an indication of how the caller perceives >> the call. The Resource-Priority, when used, may be subject to other >> controls, and mostly impact intermediaries, rather than the callee. > > Well, as we've discussed before, we DO need an indicator which is used by= intermediaries to give special treatment to the callback. Well, I guess it depends on what sorts of treatment you are talking=20 about. If you are talking about resource prioritization, then the=20 Resource-Priority header is probably what you want. If you are talking about bypassing various sorts of treatment, such as=20 call diversion, then I don't think Resource-Priority is the right thing.=20 Those are generally discretionary anyway. Honoring the caller's wishes,=20 expressed via Priority and perhaps callerprefs, seems to make more=20 sense. In such cases, there is a question of whether to honor the=20 caller's preferences, or the callee's policies. It's my personal opinion=20 that if the caller says he only wants to talk to a human, not an=20 automaton, then one should honor that, and either let the human's phone=20 ring or else simply reject the call. And I'm suggesting that from a=20 provider perspective that means passing the call to the UA and letting=20 it decide. Thanks, Paul > Regards, > > Christer > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f Christer Holmberg >> Sent: Monday, June 04, 2012 1:33 PM >> To: Paul Kyzivat >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >> >> Hi, >> >>>> Assuming we would use Priority as callback indicator, is the "emergenc= y" value sufficient, or would be need an explicit "callback" value? >>>> >>>> Could a PSAP use Priority:emergency for non-callback calls? >>> >>> I suppose these questions may deserve further discussion. >>> >>> IMO Priority:emergency is appropriate for the callback, assuming it >>> should be treated as an emergency. (OTOH, if the psap decides to call >>> back the next day just as a followup, to see if all is well, then >>> perhaps it isn't an emergency.) >>> >>> I don't understand what the use case might be, but if the psap felt a >>> need to initiate a call that was not a callback to a prior emergency >>> call, and it felt the call was indeed an emergency, then I see no reaso= n >>> why it should not tag it with Priority:emergency. >>> >>> In the latter case, the call might not get the same treatment on the >>> receiving end. In this case the callee has nothing to help it >>> distinguish a justified use of Priority:emergency from an unjustified >>> one. So it might not give the call any priority treatment. But I think >>> that is fine. >> >> OTOH, defining a new Priority value is not a very difficult task :) >> >> Also, in this case I guess the semantics of a callback already exists, s= o we wouldn't need to work much on that. >> >> Regards, >> >> Christer >> >> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Paul Kyzivat >>> Sent: 15. toukokuuta 2012 18:19 >>> To: ecrit@ietf.org >>> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >>> >>> I'll repeat my earlier arguments. Maybe I can make them more explicit t= his time. I think we have sufficient mechanism already defined, if it is us= ed appropriately. Specifically: >>> >>> - the UA, when placing an emergency call, can use a temp gruu. >>> Its possible to get as many temp gruus as you like, so the UA >>> can reserve one for this purpose. This doesn't require any >>> new capabilities in registrars. >>> >>> - when the UA receives a call addressed to a temp gruu that it >>> had previously used for an emergency call, it can give it >>> special treatment as an emergency callback. It can decide how >>> long after the emergency call to grant this special treatment >>> as a matter of policy. The special treatment can include dropping >>> existing calls, special alerting, etc. >>> >>> - the PSAP, when placing the emergency callback, can indicate that >>> *it* considers this call important using the Priority:emergency. >>> If appropriate it can also use other existing headers, such as >>> Resource-Priority. It call also use callerprefs to indicate that >>> it prefers the real UA and does not wish an automaton. >>> >>> - middleboxes in the path of the callback can choose to honor the >>> Priority:emergency, and use that to condition their behavior. >>> For instance, a home proxy could decide that an emergency call >>> to a temp gruu should not be diverted. (Though the fact that it i= s >>> to a gruu should typically bypass that anyway.) >>> >>> - abuses of Priority:emergency by callers can be dealt with by the >>> called UA, because it can reject such calls if not to a temp >>> gruu previously used for an emergency call. This can cause *some* >>> disruption, but only to the extent of handling an incoming INVITE >>> and rejecting it. If the frequency of that rises to a level where >>> it becomes a problem then it should be dealt with as a DOS attack= . >>> >>> Thanks, >>> Paul >>> >>> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>>> Hi, >>>> >>>> Once again, I would like to see whether there is a way for us to move >>>> forward on the callback indicator issue. >>>> >>>> There are two requirements: >>>> >>>> 1.Indicate the callback >>>> >>>> 2.Be able to route the callback to the user that made the emergency >>>> call >>>> >>>> Regarding the indication, it has been suggested that the indicator >>>> value is per user, and is provided to the user upon registration. >>>> >>>> We also discussed whether the value could change over time, but the >>>> problem was that the emg call may be done using an old value, and the >>>> callback using a new value (because there was some time between the >>>> emg call and the callback, during which the user was given a new value= ). >>>> >>>> To avoid that, the registrar would always provide the same value to a >>>> given user. >>>> >>>> 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 Tue Jun 5 02:39:29 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 A06FB21F86C5 for ; Tue, 5 Jun 2012 02:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKiT26CECqjp for ; Tue, 5 Jun 2012 02:39:28 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 866DD21F86A1 for ; Tue, 5 Jun 2012 02:39:27 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-dc-4fcdd3ce7f72 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 2D.26.00702.EC3DDCF4; Tue, 5 Jun 2012 11:39:26 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.250]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 5 Jun 2012 11:39:26 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 5 Jun 2012 11:39:25 +0200 Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac1CkFMFo4u1G2cjSMKFBLQUJVVzZwAbn2MQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C45A1CAA6@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> , <4FCCF882.6020906@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C8@ESESSCMS0356.eemea.ericsson.se> <4FCD19F4.9070704@alum.mit.edu> In-Reply-To: <4FCD19F4.9070704@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvre65y2f9DZrXq1s0LnrKanHowVN2 ixUbDrA6MHv8ff+ByeNl/xxGjyVLfjIFMEdx2aSk5mSWpRbp2yVwZRx5f5y14K5lxcn2NcwN jDd0uxg5OSQETCRWTFrHDmGLSVy4t56ti5GLQ0jgFKNE14tPrCAJIYEFjBJ3X+d0MXJwsAlY SHT/0wYxRQQ0JCZtVQMxmQU8JXa+sQYpZhFQkTjfOIENxBYWsJK48vIY2HQRAWuJpzdWQtlG Em+3PWUGsXkFwiU+P93OCrF1GotE56RpYEWcAjoSf5ZvBStiBDrt+6k1TCA2s4C4xK0n85kg ThaQWLLnPDOELSrx8vE/Voh6UYk77esZIep1JBbs/sQGYWtLLFv4GmqxoMTJmU9YJjCKzUIy dhaSlllIWmYhaVnAyLKKUTg3MTMnvdxcL7UoM7m4OD9Przh1EyMwlg5u+W2wg3HTfbFDjNIc LErivHqq+/2FBNITS1KzU1MLUovii0pzUosPMTJxcEo1MHavfnbx3XHlnXPrL81Kce1Wvnfx oN1TNY3wqQlaP/geqzD9UzEoCbxvt3ne9iTNqt423WVZ/8zqswMiutaumbTg7LVlz9tvcZVE iPa0PFdfMyH48wotNmt2n5NxbZePfT32/IWw9hLf+R0V722Ys5N2X0oMvzO57uupC2q/N4RY Z92O+v38sosSS3FGoqEWc1FxIgB0JmPEcwIAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 05 Jun 2012 09:39:29 -0000 Hi, >>>> A new RPH=3DSOS (versus SOL) that is honored based on a trust=20 >>>> model/relationships >>> >>> I had originally noted that we could use a number of existing=20 >>> indications. Resource-Priority would perhaps be good in environments=20 >>> that do something with it. This would be complementary to the=20 >>> Priority:emergency, which is an indication of how the caller=20 >>> perceives the call. The Resource-Priority, when used, may be subject=20 >>> to other controls, and mostly impact intermediaries, rather than the ca= llee. >> >> Well, as we've discussed before, we DO need an indicator which is used b= y intermediaries to give special treatment to the callback. > > Well, I guess it depends on what sorts of treatment you are talking about= . If you are talking about resource prioritization, then the Resource-Prior= ity header is probably what you want. > > If you are talking about bypassing various sorts of treatment, such as ca= ll diversion, then I don't think Resource-Priority is the right thing.=20 > Those are generally discretionary anyway. Honoring the caller's wishes, e= xpressed via Priority and perhaps callerprefs, seems to make more sense. In= such cases, there is a question of whether to honor the caller's preferenc= es, or the callee's policies. It's=20 > my personal opinion that if the caller says he only wants to talk to a hu= man, not an automaton, then one should honor that, and either let the human= 's phone ring or else simply reject the call. And I'm suggesting that from = a provider perspective that=20 > means passing the call to the UA and letting it decide. It's not only about bypassing diversion. Even if the call will reach the co= rrect human, one may still want to bypass services etc in the network. Regards, Christer > Regards, > > Christer > > >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf O= f Christer Holmberg >> Sent: Monday, June 04, 2012 1:33 PM >> To: Paul Kyzivat >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >> >> Hi, >> >>>> Assuming we would use Priority as callback indicator, is the "emergenc= y" value sufficient, or would be need an explicit "callback" value? >>>> >>>> Could a PSAP use Priority:emergency for non-callback calls? >>> >>> I suppose these questions may deserve further discussion. >>> >>> IMO Priority:emergency is appropriate for the callback, assuming it >>> should be treated as an emergency. (OTOH, if the psap decides to call >>> back the next day just as a followup, to see if all is well, then >>> perhaps it isn't an emergency.) >>> >>> I don't understand what the use case might be, but if the psap felt a >>> need to initiate a call that was not a callback to a prior emergency >>> call, and it felt the call was indeed an emergency, then I see no reaso= n >>> why it should not tag it with Priority:emergency. >>> >>> In the latter case, the call might not get the same treatment on the >>> receiving end. In this case the callee has nothing to help it >>> distinguish a justified use of Priority:emergency from an unjustified >>> one. So it might not give the call any priority treatment. But I think >>> that is fine. >> >> OTOH, defining a new Priority value is not a very difficult task :) >> >> Also, in this case I guess the semantics of a callback already exists, s= o we wouldn't need to work much on that. >> >> Regards, >> >> Christer >> >> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Paul Kyzivat >>> Sent: 15. toukokuuta 2012 18:19 >>> To: ecrit@ietf.org >>> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >>> >>> I'll repeat my earlier arguments. Maybe I can make them more explicit t= his time. I think we have sufficient mechanism already defined, if it is us= ed appropriately. Specifically: >>> >>> - the UA, when placing an emergency call, can use a temp gruu. >>> Its possible to get as many temp gruus as you like, so the UA >>> can reserve one for this purpose. This doesn't require any >>> new capabilities in registrars. >>> >>> - when the UA receives a call addressed to a temp gruu that it >>> had previously used for an emergency call, it can give it >>> special treatment as an emergency callback. It can decide how >>> long after the emergency call to grant this special treatment >>> as a matter of policy. The special treatment can include dropping >>> existing calls, special alerting, etc. >>> >>> - the PSAP, when placing the emergency callback, can indicate that >>> *it* considers this call important using the Priority:emergency. >>> If appropriate it can also use other existing headers, such as >>> Resource-Priority. It call also use callerprefs to indicate that >>> it prefers the real UA and does not wish an automaton. >>> >>> - middleboxes in the path of the callback can choose to honor the >>> Priority:emergency, and use that to condition their behavior. >>> For instance, a home proxy could decide that an emergency call >>> to a temp gruu should not be diverted. (Though the fact that it i= s >>> to a gruu should typically bypass that anyway.) >>> >>> - abuses of Priority:emergency by callers can be dealt with by the >>> called UA, because it can reject such calls if not to a temp >>> gruu previously used for an emergency call. This can cause *some* >>> disruption, but only to the extent of handling an incoming INVITE >>> and rejecting it. If the frequency of that rises to a level where >>> it becomes a problem then it should be dealt with as a DOS attack= . >>> >>> Thanks, >>> Paul >>> >>> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>>> Hi, >>>> >>>> Once again, I would like to see whether there is a way for us to move >>>> forward on the callback indicator issue. >>>> >>>> There are two requirements: >>>> >>>> 1.Indicate the callback >>>> >>>> 2.Be able to route the callback to the user that made the emergency >>>> call >>>> >>>> Regarding the indication, it has been suggested that the indicator >>>> value is per user, and is provided to the user upon registration. >>>> >>>> We also discussed whether the value could change over time, but the >>>> problem was that the emg call may be done using an old value, and the >>>> callback using a new value (because there was some time between the >>>> emg call and the callback, during which the user was given a new value= ). >>>> >>>> To avoid that, the registrar would always provide the same value to a >>>> given user. >>>> >>>> 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 pkyzivat@alum.mit.edu Tue Jun 5 06:38: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 AA35121F8665 for ; Tue, 5 Jun 2012 06:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfuZ1vvLh0OO for ; Tue, 5 Jun 2012 06:38:31 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 82C8C21F8670 for ; Tue, 5 Jun 2012 06:38:31 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta05.westchester.pa.mail.comcast.net with comcast id Jdbj1j00J1uE5Es55deSMY; Tue, 05 Jun 2012 13:38:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id JdeR1j00w07duvL3cdeRAP; Tue, 05 Jun 2012 13:38:26 +0000 Message-ID: <4FCE0BCF.7080709@alum.mit.edu> Date: Tue, 05 Jun 2012 09:38:23 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> , <4FCCF882.6020906@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C8@ESESSCMS0356.eemea.ericsson.se> <4FCD19F4.9070704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1CAA6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C45A1CAA6@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 05 Jun 2012 13:38:33 -0000 On 6/5/12 5:39 AM, Christer Holmberg wrote: > Hi, > >>>>> A new RPH=SOS (versus SOL) that is honored based on a trust >>>>> model/relationships >>>> >>>> I had originally noted that we could use a number of existing >>>> indications. Resource-Priority would perhaps be good in environments >>>> that do something with it. This would be complementary to the >>>> Priority:emergency, which is an indication of how the caller >>>> perceives the call. The Resource-Priority, when used, may be subject >>>> to other controls, and mostly impact intermediaries, rather than the callee. >>> >>> Well, as we've discussed before, we DO need an indicator which is used by intermediaries to give special treatment to the callback. >> >> Well, I guess it depends on what sorts of treatment you are talking about. If you are talking about resource prioritization, then the Resource-Priority header is probably what you want. >> >> If you are talking about bypassing various sorts of treatment, such as call diversion, then I don't think Resource-Priority is the right thing. >> Those are generally discretionary anyway. Honoring the caller's wishes, expressed via Priority and perhaps callerprefs, seems to make more sense. In such cases, there is a question of whether to honor the caller's preferences, or the callee's policies. It's >> my personal opinion that if the caller says he only wants to talk to a human, not an automaton, then one should honor that, and either let the human's phone ring or else simply reject the call. And I'm suggesting that from a provider perspective that >> means passing the call to the UA and letting it decide. > > It's not only about bypassing diversion. Even if the call will reach the correct human, one may still want to bypass services etc in the network. I find it hard to have this discussion in the abstract. Can we talk about the specific sorts of services you have in mind? I suspect that different sorts of treatment may need to be addressed in different ways. ISTM there is a fundamental issue here of whether it is expected that intermediaries must understand the purpose of the incoming call to decide how to handle it, or if the caller should simply indicate how he would like it handled (or not handled). Thanks, Paul > Regards, > > Christer > > > >> Regards, >> >> Christer >> >> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg >>> Sent: Monday, June 04, 2012 1:33 PM >>> To: Paul Kyzivat >>> Cc: ecrit@ietf.org >>> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >>> >>> Hi, >>> >>>>> Assuming we would use Priority as callback indicator, is the "emergency" value sufficient, or would be need an explicit "callback" value? >>>>> >>>>> Could a PSAP use Priority:emergency for non-callback calls? >>>> >>>> I suppose these questions may deserve further discussion. >>>> >>>> IMO Priority:emergency is appropriate for the callback, assuming it >>>> should be treated as an emergency. (OTOH, if the psap decides to call >>>> back the next day just as a followup, to see if all is well, then >>>> perhaps it isn't an emergency.) >>>> >>>> I don't understand what the use case might be, but if the psap felt a >>>> need to initiate a call that was not a callback to a prior emergency >>>> call, and it felt the call was indeed an emergency, then I see no reason >>>> why it should not tag it with Priority:emergency. >>>> >>>> In the latter case, the call might not get the same treatment on the >>>> receiving end. In this case the callee has nothing to help it >>>> distinguish a justified use of Priority:emergency from an unjustified >>>> one. So it might not give the call any priority treatment. But I think >>>> that is fine. >>> >>> OTOH, defining a new Priority value is not a very difficult task :) >>> >>> Also, in this case I guess the semantics of a callback already exists, so we wouldn't need to work much on that. >>> >>> Regards, >>> >>> Christer >>> >>> >>>> Regards, >>>> >>>> Christer >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: 15. toukokuuta 2012 18:19 >>>> To: ecrit@ietf.org >>>> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >>>> >>>> I'll repeat my earlier arguments. Maybe I can make them more explicit this time. I think we have sufficient mechanism already defined, if it is used appropriately. Specifically: >>>> >>>> - the UA, when placing an emergency call, can use a temp gruu. >>>> Its possible to get as many temp gruus as you like, so the UA >>>> can reserve one for this purpose. This doesn't require any >>>> new capabilities in registrars. >>>> >>>> - when the UA receives a call addressed to a temp gruu that it >>>> had previously used for an emergency call, it can give it >>>> special treatment as an emergency callback. It can decide how >>>> long after the emergency call to grant this special treatment >>>> as a matter of policy. The special treatment can include dropping >>>> existing calls, special alerting, etc. >>>> >>>> - the PSAP, when placing the emergency callback, can indicate that >>>> *it* considers this call important using the Priority:emergency. >>>> If appropriate it can also use other existing headers, such as >>>> Resource-Priority. It call also use callerprefs to indicate that >>>> it prefers the real UA and does not wish an automaton. >>>> >>>> - middleboxes in the path of the callback can choose to honor the >>>> Priority:emergency, and use that to condition their behavior. >>>> For instance, a home proxy could decide that an emergency call >>>> to a temp gruu should not be diverted. (Though the fact that it is >>>> to a gruu should typically bypass that anyway.) >>>> >>>> - abuses of Priority:emergency by callers can be dealt with by the >>>> called UA, because it can reject such calls if not to a temp >>>> gruu previously used for an emergency call. This can cause *some* >>>> disruption, but only to the extent of handling an incoming INVITE >>>> and rejecting it. If the frequency of that rises to a level where >>>> it becomes a problem then it should be dealt with as a DOS attack. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>> Once again, I would like to see whether there is a way for us to move >>>>> forward on the callback indicator issue. >>>>> >>>>> There are two requirements: >>>>> >>>>> 1.Indicate the callback >>>>> >>>>> 2.Be able to route the callback to the user that made the emergency >>>>> call >>>>> >>>>> Regarding the indication, it has been suggested that the indicator >>>>> value is per user, and is provided to the user upon registration. >>>>> >>>>> We also discussed whether the value could change over time, but the >>>>> problem was that the emg call may be done using an old value, and the >>>>> callback using a new value (because there was some time between the >>>>> emg call and the callback, during which the user was given a new value). >>>>> >>>>> To avoid that, the registrar would always provide the same value to a >>>>> given user. >>>>> >>>>> 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 john.medland@bt.com Wed Jun 6 03:37:21 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 F03F621F8552 for ; Wed, 6 Jun 2012 03:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+E0MVXTZKh3 for ; Wed, 6 Jun 2012 03:37:19 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id D2F5B21F87F8 for ; Wed, 6 Jun 2012 03:37:18 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.264.0; Wed, 6 Jun 2012 11:37:17 +0100 Received: from emv66-ukrd.domain1.systemhost.net ([169.254.1.211]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Wed, 6 Jun 2012 11:37:17 +0100 From: To: , Date: Wed, 6 Jun 2012 11:37:15 +0100 Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac1CZw1b9YyVSQ2VT7ObtxiRtrWVRABZ3VWg Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se> <4FCCD4B1.5010103@alum.mit.edu> In-Reply-To: <4FCCD4B1.5010103@alum.mit.edu> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 06 Jun 2012 10:37:21 -0000 Paul, Christer, 1 I inserted a use case below in Paul's email to hopefully assist with the= discussion about priority indicators. 2 PSAP callback is certainly an important subject for PSAPs in the UK, as = callbacks are used to help manage emergency calls in an appreciable number = of cases (though I don't currently have any stats for % of occasions, which= may in any case change when moving off TDM networks to IP networks........= ). Regards John John Medland | 999/112 Policy Manager| BT | Tel:+44 (0)1977 593408 | Email:= john.medland@bt.com | =A0 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of P= aul Kyzivat Sent: 04 June 2012 16:31 To: Christer Holmberg Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning On 6/4/12 9:20 AM, Christer Holmberg wrote: > Hi, > > Assuming we would use Priority as callback indicator, is the "emergency" = value sufficient, or would be need an explicit "callback" value? > > Could a PSAP use Priority:emergency for non-callback calls? I suppose these questions may deserve further discussion. IMO Priority:emergency is appropriate for the callback, assuming it should = be treated as an emergency. (OTOH, if the psap decides to call back the nex= t day just as a followup, to see if all is well, then perhaps it isn't an e= mergency.) I don't understand what the use case might be, but if the psap felt a need = to initiate a call that was not a callback to a prior emergency call, and i= t felt the call was indeed an emergency, then I see no reason why it should= not tag it with Priority:emergency. [John Medland] Another Use Case (separate from callback to the end user who= needs help) would be where one PSAP needs to pass incident details to a se= cond PSAP where the second PSAP is needed to provide additional assistance.= An example would be where first PSAP is the Police but second PSAP is the= Fire Service needed to free people trapped in a motor accident. =20 In the latter case, the call might not get the same treatment on the receiv= ing end. In this case the callee has nothing to help it distinguish a justi= fied use of Priority:emergency from an unjustified one. So it might not giv= e the call any priority treatment. But I think that is fine. Thanks, Paul > Regards, > > Christer > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: 15. toukokuuta 2012 18:19 > To: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > I'll repeat my earlier arguments. Maybe I can make them more explicit thi= s time. I think we have sufficient mechanism already defined, if it is used= appropriately. Specifically: > > - the UA, when placing an emergency call, can use a temp gruu. > Its possible to get as many temp gruus as you like, so the UA > can reserve one for this purpose. This doesn't require any > new capabilities in registrars. > > - when the UA receives a call addressed to a temp gruu that it > had previously used for an emergency call, it can give it > special treatment as an emergency callback. It can decide how > long after the emergency call to grant this special treatment > as a matter of policy. The special treatment can include dropping > existing calls, special alerting, etc. > > - the PSAP, when placing the emergency callback, can indicate that > *it* considers this call important using the Priority:emergency. > If appropriate it can also use other existing headers, such as > Resource-Priority. It call also use callerprefs to indicate that > it prefers the real UA and does not wish an automaton. > > - middleboxes in the path of the callback can choose to honor the > Priority:emergency, and use that to condition their behavior. > For instance, a home proxy could decide that an emergency call > to a temp gruu should not be diverted. (Though the fact that it is > to a gruu should typically bypass that anyway.) > > - abuses of Priority:emergency by callers can be dealt with by the > called UA, because it can reject such calls if not to a temp > gruu previously used for an emergency call. This can cause *some* > disruption, but only to the extent of handling an incoming INVITE > and rejecting it. If the frequency of that rises to a level where > it becomes a problem then it should be dealt with as a DOS attack. > > Thanks, > Paul > > On 5/15/12 7:05 AM, Christer Holmberg wrote: >> Hi, >> >> Once again, I would like to see whether there is a way for us to move=20 >> forward on the callback indicator issue. >> >> There are two requirements: >> >> 1.Indicate the callback >> >> 2.Be able to route the callback to the user that made the emergency=20 >> call >> >> Regarding the indication, it has been suggested that the indicator=20 >> value is per user, and is provided to the user upon registration. >> >> We also discussed whether the value could change over time, but the=20 >> problem was that the emg call may be done using an old value, and the=20 >> callback using a new value (because there was some time between the=20 >> emg call and the callback, during which the user was given a new value). >> >> To avoid that, the registrar would always provide the same value to a=20 >> given user. >> >> 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 br@brianrosen.net Wed Jun 6 10:25: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 94D5F21F8685 for ; Wed, 6 Jun 2012 10:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsTb+62TwnKm for ; Wed, 6 Jun 2012 10:25:22 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id A971E21F8675 for ; Wed, 6 Jun 2012 10:25:22 -0700 (PDT) X-ASG-Debug-ID: 1339003520-04d035103573ce0001-uVEBo8 Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id MqLy8XumB1vzHQZw; Wed, 06 Jun 2012 10:25:20 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from neustargw.va.neustar.com ([209.173.53.233]:35779 helo=[192.168.133.142]) by wwh1.winweblinux.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1ScJyy-002rcT-VQ; Wed, 06 Jun 2012 10:25:21 -0700 References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se> <4FCCD4B1.5010103@alum.mit.edu> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 Message-Id: <9E270186-31EE-4227-A2EF-C1FE533B18F8@brianrosen.net> Content-Transfer-Encoding: quoted-printable From: Brian Rosen Date: Wed, 6 Jun 2012 13:25:18 -0400 X-ASG-Orig-Subj: Re: [Ecrit] PSAP Callback - Yet Another Beginning To: X-Mailer: Apple Mail (2.1278) X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1339003520 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.99126 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 06 Jun 2012 17:25:23 -0000 We distinguish between two kinds of call back: 1. Call back to the device that placed the call. This happens within = minutes of the original call. 2. Call back to the caller. This happens later The former uses Contact, the latter uses AoR. The former may need some = services bypassed, the latter doesn't. Priority:Emergency is okay with me Just for reference, 3261 says: 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. =20 Brian On Jun 6, 2012, at 6:37 AM, = wrote: > Paul, Christer, >=20 >=20 > 1 I inserted a use case below in Paul's email to hopefully assist = with the discussion about priority indicators. >=20 >=20 > 2 PSAP callback is certainly an important subject for PSAPs in the = UK, as callbacks are used to help manage emergency calls in an = appreciable number of cases (though I don't currently have any stats for = % of occasions, which may in any case change when moving off TDM = networks to IP networks........). >=20 >=20 > Regards >=20 > John >=20 > John Medland | 999/112 Policy Manager| BT | Tel:+44 (0)1977 593408 | = Email: john.medland@bt.com | > =20 >=20 >=20 >=20 > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Paul Kyzivat > Sent: 04 June 2012 16:31 > To: Christer Holmberg > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >=20 > On 6/4/12 9:20 AM, Christer Holmberg wrote: >> Hi, >>=20 >> Assuming we would use Priority as callback indicator, is the = "emergency" value sufficient, or would be need an explicit "callback" = value? >>=20 >> Could a PSAP use Priority:emergency for non-callback calls? >=20 > I suppose these questions may deserve further discussion. >=20 > IMO Priority:emergency is appropriate for the callback, assuming it = should be treated as an emergency. (OTOH, if the psap decides to call = back the next day just as a followup, to see if all is well, then = perhaps it isn't an emergency.) >=20 > I don't understand what the use case might be, but if the psap felt a = need to initiate a call that was not a callback to a prior emergency = call, and it felt the call was indeed an emergency, then I see no reason = why it should not tag it with Priority:emergency. >=20 > [John Medland] Another Use Case (separate from callback to the end = user who needs help) would be where one PSAP needs to pass incident = details to a second PSAP where the second PSAP is needed to provide = additional assistance. An example would be where first PSAP is the = Police but second PSAP is the Fire Service needed to free people trapped = in a motor accident. =20 >=20 > In the latter case, the call might not get the same treatment on the = receiving end. In this case the callee has nothing to help it = distinguish a justified use of Priority:emergency from an unjustified = one. So it might not give the call any priority treatment. But I think = that is fine. >=20 > Thanks, > Paul >=20 >> Regards, >>=20 >> Christer >>=20 >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On = Behalf=20 >> Of Paul Kyzivat >> Sent: 15. toukokuuta 2012 18:19 >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >>=20 >> I'll repeat my earlier arguments. Maybe I can make them more explicit = this time. I think we have sufficient mechanism already defined, if it = is used appropriately. Specifically: >>=20 >> - the UA, when placing an emergency call, can use a temp gruu. >> Its possible to get as many temp gruus as you like, so the UA >> can reserve one for this purpose. This doesn't require any >> new capabilities in registrars. >>=20 >> - when the UA receives a call addressed to a temp gruu that it >> had previously used for an emergency call, it can give it >> special treatment as an emergency callback. It can decide how >> long after the emergency call to grant this special treatment >> as a matter of policy. The special treatment can include dropping >> existing calls, special alerting, etc. >>=20 >> - the PSAP, when placing the emergency callback, can indicate that >> *it* considers this call important using the Priority:emergency. >> If appropriate it can also use other existing headers, such as >> Resource-Priority. It call also use callerprefs to indicate that >> it prefers the real UA and does not wish an automaton. >>=20 >> - middleboxes in the path of the callback can choose to honor the >> Priority:emergency, and use that to condition their behavior. >> For instance, a home proxy could decide that an emergency call >> to a temp gruu should not be diverted. (Though the fact that it is >> to a gruu should typically bypass that anyway.) >>=20 >> - abuses of Priority:emergency by callers can be dealt with by the >> called UA, because it can reject such calls if not to a temp >> gruu previously used for an emergency call. This can cause *some* >> disruption, but only to the extent of handling an incoming INVITE >> and rejecting it. If the frequency of that rises to a level where >> it becomes a problem then it should be dealt with as a DOS attack. >>=20 >> Thanks, >> Paul >>=20 >> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>> Hi, >>>=20 >>> Once again, I would like to see whether there is a way for us to = move=20 >>> forward on the callback indicator issue. >>>=20 >>> There are two requirements: >>>=20 >>> 1.Indicate the callback >>>=20 >>> 2.Be able to route the callback to the user that made the emergency=20= >>> call >>>=20 >>> Regarding the indication, it has been suggested that the indicator=20= >>> value is per user, and is provided to the user upon registration. >>>=20 >>> We also discussed whether the value could change over time, but the=20= >>> problem was that the emg call may be done using an old value, and = the=20 >>> callback using a new value (because there was some time between the=20= >>> emg call and the callback, during which the user was given a new = value). >>>=20 >>> To avoid that, the registrar would always provide the same value to = a=20 >>> given user. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Sun Jun 10 12:00:48 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 50DFD21F852A for ; Sun, 10 Jun 2012 12:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuX-3RUUmsJO for ; Sun, 10 Jun 2012 12:00:47 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2A53621F8557 for ; Sun, 10 Jun 2012 12:00:46 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id Li4m1j0031c6gX853j0mpL; Sun, 10 Jun 2012 19:00:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([83.241.130.138]) by omta23.westchester.pa.mail.comcast.net with comcast id Lj0E1j00P2zJWM73jj0LGJ; Sun, 10 Jun 2012 19:00:41 +0000 Message-ID: <4FD4EEBE.7060206@alum.mit.edu> Date: Sun, 10 Jun 2012 21:00:14 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: john.medland@bt.com References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se> <4FCCD4B1.5010103@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 19:00:48 -0000 On 6/6/12 12:37 PM, john.medland@bt.com wrote: > Paul, Christer, > > > 1 I inserted a use case below in Paul's email to hopefully assist with the discussion about priority indicators. John - can you clarify your use case further? You say the first psap (police) calls a 2nd psap (fire) for help on the call. Did you mean the call from police to fire is the one to be tagged as an emergency? Or did you mean that subsequently the fire psap wants to call the original user? If the latter, then I guess it is a judgement call whether this is a callback or not. Also, this brings up some interesting issues. Suppose the user is still on the line with the police when the fire psap calls. What should happen? Should the user's phone hang up the call to police to answer the one from fire? Or reject the one from fire? Merge the calls? It sounds to me like it would be better for the police to treat this as a consult, followed by a consultative transfer. If so, then there would be no callback at all. Thanks, Paul > 2 PSAP callback is certainly an important subject for PSAPs in the UK, as callbacks are used to help manage emergency calls in an appreciable number of cases (though I don't currently have any stats for % of occasions, which may in any case change when moving off TDM networks to IP networks........). > > > Regards > > John > > John Medland | 999/112 Policy Manager| BT | Tel:+44 (0)1977 593408 | Email: john.medland@bt.com | > > > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 04 June 2012 16:31 > To: Christer Holmberg > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > On 6/4/12 9:20 AM, Christer Holmberg wrote: >> Hi, >> >> Assuming we would use Priority as callback indicator, is the "emergency" value sufficient, or would be need an explicit "callback" value? >> >> Could a PSAP use Priority:emergency for non-callback calls? > > I suppose these questions may deserve further discussion. > > IMO Priority:emergency is appropriate for the callback, assuming it should be treated as an emergency. (OTOH, if the psap decides to call back the next day just as a followup, to see if all is well, then perhaps it isn't an emergency.) > > I don't understand what the use case might be, but if the psap felt a need to initiate a call that was not a callback to a prior emergency call, and it felt the call was indeed an emergency, then I see no reason why it should not tag it with Priority:emergency. > > [John Medland] Another Use Case (separate from callback to the end user who needs help) would be where one PSAP needs to pass incident details to a second PSAP where the second PSAP is needed to provide additional assistance. An example would be where first PSAP is the Police but second PSAP is the Fire Service needed to free people trapped in a motor accident. > > In the latter case, the call might not get the same treatment on the receiving end. In this case the callee has nothing to help it distinguish a justified use of Priority:emergency from an unjustified one. So it might not give the call any priority treatment. But I think that is fine. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 15. toukokuuta 2012 18:19 >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >> >> I'll repeat my earlier arguments. Maybe I can make them more explicit this time. I think we have sufficient mechanism already defined, if it is used appropriately. Specifically: >> >> - the UA, when placing an emergency call, can use a temp gruu. >> Its possible to get as many temp gruus as you like, so the UA >> can reserve one for this purpose. This doesn't require any >> new capabilities in registrars. >> >> - when the UA receives a call addressed to a temp gruu that it >> had previously used for an emergency call, it can give it >> special treatment as an emergency callback. It can decide how >> long after the emergency call to grant this special treatment >> as a matter of policy. The special treatment can include dropping >> existing calls, special alerting, etc. >> >> - the PSAP, when placing the emergency callback, can indicate that >> *it* considers this call important using the Priority:emergency. >> If appropriate it can also use other existing headers, such as >> Resource-Priority. It call also use callerprefs to indicate that >> it prefers the real UA and does not wish an automaton. >> >> - middleboxes in the path of the callback can choose to honor the >> Priority:emergency, and use that to condition their behavior. >> For instance, a home proxy could decide that an emergency call >> to a temp gruu should not be diverted. (Though the fact that it is >> to a gruu should typically bypass that anyway.) >> >> - abuses of Priority:emergency by callers can be dealt with by the >> called UA, because it can reject such calls if not to a temp >> gruu previously used for an emergency call. This can cause *some* >> disruption, but only to the extent of handling an incoming INVITE >> and rejecting it. If the frequency of that rises to a level where >> it becomes a problem then it should be dealt with as a DOS attack. >> >> Thanks, >> Paul >> >> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>> Hi, >>> >>> Once again, I would like to see whether there is a way for us to move >>> forward on the callback indicator issue. >>> >>> There are two requirements: >>> >>> 1.Indicate the callback >>> >>> 2.Be able to route the callback to the user that made the emergency >>> call >>> >>> Regarding the indication, it has been suggested that the indicator >>> value is per user, and is provided to the user upon registration. >>> >>> We also discussed whether the value could change over time, but the >>> problem was that the emg call may be done using an old value, and the >>> callback using a new value (because there was some time between the >>> emg call and the callback, during which the user was given a new value). >>> >>> To avoid that, the registrar would always provide the same value to a >>> given user. >>> >>> 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 Mon Jun 11 11:59: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 3B65B21F846E for ; Mon, 11 Jun 2012 11:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SIGuH3vBzhr for ; Mon, 11 Jun 2012 11:59:06 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8F82B11E8083 for ; Mon, 11 Jun 2012 11:59:05 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-9c-4fd63ff8f25c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EF.C7.28636.8FF36DF4; Mon, 11 Jun 2012 20:59:04 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.62]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Mon, 11 Jun 2012 20:59:03 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Mon, 11 Jun 2012 20:55:00 +0200 Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac1DIH1+vHel2IAGR/eGKZO85UzAyQE4zZTg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C47149A67@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> , <4FCCF882.6020906@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C8@ESESSCMS0356.eemea.ericsson.se> <4FCD19F4.9070704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1CAA6@ESESSCMS0356.eemea.ericsson.se>, <4FCE0BCF.7080709@alum.mit.edu> In-Reply-To: <4FCE0BCF.7080709@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvre4P+2v+BifXKFk0LnrKanHowVN2 ixUbDrA6MHv8ff+ByeNl/xxGjyVLfjIFMEdx2aSk5mSWpRbp2yVwZSy7/5ulYKpjxaVPt1gb GG8ZdzFyckgImEg03znEDGGLSVy4t56ti5GLQ0jgFKPE984FzBDOAkaJg+tXM3YxcnCwCVhI dP/TBjFFBDQkJm1VAzGZBTwldr6xBhnDIqAqcXX3JXYQW1jASuLKy2NgtoiAtcTTGyuhbCOJ /10PWEBsXoFwic/nLzNCbGphlWg41AWW4BTQkdi49AQriM0IdNv3U2uYQGxmAXGJW0/mM0Hc LCCxZM95qPtFJV4+/gdVLypxp309I0S9jsSC3Z/YIGxtiWULXzNDLBaUODnzCcsERrFZSMbO QtIyC0nLLCQtCxhZVjEK5yZm5qSXG+qlFmUmFxfn5+kVp25iBEbTwS2/dXcwnjoncohRmoNF SZyXK2m/v5BAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGuJolNiYf1M52aD/51XylZmvt+8UF xanVt6Nb3n8y+PZFfbuVT90hzhcOyRb/o2U7vN596Z/yw6YpOcqqpfy0TXYf2zX9a2fN1wtv 1PPqu/7g4had5r1nnk65pDvR8pJZQZXQb7Yn+8zNZ4vk32C5+Fsn4z4DX6Xga0vpiEsFhyY/ fPFcZIegEktxRqKhFnNRcSIAftSJMnQCAAA= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 11 Jun 2012 18:59:07 -0000 Hi, >>>>>> A new RPH=3DSOS (versus SOL) that is honored based on a trust >>>>>> model/relationships >>>>> >>>>> I had originally noted that we could use a number of existing >>>>> indications. Resource-Priority would perhaps be good in environments >>>>> that do something with it. This would be complementary to the >>>>> Priority:emergency, which is an indication of how the caller >>>>> perceives the call. The Resource-Priority, when used, may be subject >>>>> to other controls, and mostly impact intermediaries, rather than the = callee. >>>> >>>> Well, as we've discussed before, we DO need an indicator which is used= by intermediaries to give special treatment to the callback. >>> >>> Well, I guess it depends on what sorts of treatment you are talking abo= ut. If you are talking about resource prioritization, then the Resource-Pri= ority header is probably what you want. >>> >>> If you are talking about bypassing various sorts of treatment, such as = call diversion, then I don't think Resource-Priority is the right thing. >>> Those are generally discretionary anyway. Honoring the caller's wishes,= expressed via Priority and perhaps callerprefs, seems to make more sense. = In such cases, there is a question of whether to honor the caller's prefere= nces, or the callee's policies. It's >>> my personal opinion that if the caller says he only wants to talk to a = human, not an automaton, then one should honor that, and either let the hum= an's phone ring or else simply reject the call. And I'm suggesting that fro= m a provider perspective that >>> means passing the call to the UA and letting it decide. >> >> It's not only about bypassing diversion. Even if the call will reach the= correct human, one may still want to bypass services etc in the network. > > I find it hard to have this discussion in the abstract. > Can we talk about the specific sorts of services you have in mind? I > suspect that different sorts of treatment may need to be addressed in > different ways. Any type of service (diversion is one example) that normally would be appli= ed to the called user. Typically, in IMS, the S-CSCF would not forward a te= rminating callback requests to Application Servers providing such services. > ISTM there is a fundamental issue here of whether it is expected that > intermediaries must understand the purpose of the incoming call to > decide how to handle it, or if the caller should simply indicate how he > would like it handled (or not handled). The intermediareis must understand the purpose of the incoming call. Regards, Christer >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf = Of Christer Holmberg >>> Sent: Monday, June 04, 2012 1:33 PM >>> To: Paul Kyzivat >>> Cc: ecrit@ietf.org >>> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >>> >>> Hi, >>> >>>>> Assuming we would use Priority as callback indicator, is the "emergen= cy" value sufficient, or would be need an explicit "callback" value? >>>>> >>>>> Could a PSAP use Priority:emergency for non-callback calls? >>>> >>>> I suppose these questions may deserve further discussion. >>>> >>>> IMO Priority:emergency is appropriate for the callback, assuming it >>>> should be treated as an emergency. (OTOH, if the psap decides to call >>>> back the next day just as a followup, to see if all is well, then >>>> perhaps it isn't an emergency.) >>>> >>>> I don't understand what the use case might be, but if the psap felt a >>>> need to initiate a call that was not a callback to a prior emergency >>>> call, and it felt the call was indeed an emergency, then I see no reas= on >>>> why it should not tag it with Priority:emergency. >>>> >>>> In the latter case, the call might not get the same treatment on the >>>> receiving end. In this case the callee has nothing to help it >>>> distinguish a justified use of Priority:emergency from an unjustified >>>> one. So it might not give the call any priority treatment. But I think >>>> that is fine. >>> >>> OTOH, defining a new Priority value is not a very difficult task :) >>> >>> Also, in this case I guess the semantics of a callback already exists, = so we wouldn't need to work much on that. >>> >>> Regards, >>> >>> Christer >>> >>> >>>> Regards, >>>> >>>> Christer >>>> >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf= Of Paul Kyzivat >>>> Sent: 15. toukokuuta 2012 18:19 >>>> To: ecrit@ietf.org >>>> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >>>> >>>> I'll repeat my earlier arguments. Maybe I can make them more explicit = this time. I think we have sufficient mechanism already defined, if it is u= sed appropriately. Specifically: >>>> >>>> - the UA, when placing an emergency call, can use a temp gruu. >>>> Its possible to get as many temp gruus as you like, so the UA >>>> can reserve one for this purpose. This doesn't require any >>>> new capabilities in registrars. >>>> >>>> - when the UA receives a call addressed to a temp gruu that it >>>> had previously used for an emergency call, it can give it >>>> special treatment as an emergency callback. It can decide how >>>> long after the emergency call to grant this special treatment >>>> as a matter of policy. The special treatment can include droppi= ng >>>> existing calls, special alerting, etc. >>>> >>>> - the PSAP, when placing the emergency callback, can indicate that >>>> *it* considers this call important using the Priority:emergency= . >>>> If appropriate it can also use other existing headers, such as >>>> Resource-Priority. It call also use callerprefs to indicate tha= t >>>> it prefers the real UA and does not wish an automaton. >>>> >>>> - middleboxes in the path of the callback can choose to honor the >>>> Priority:emergency, and use that to condition their behavior. >>>> For instance, a home proxy could decide that an emergency call >>>> to a temp gruu should not be diverted. (Though the fact that it= is >>>> to a gruu should typically bypass that anyway.) >>>> >>>> - abuses of Priority:emergency by callers can be dealt with by the >>>> called UA, because it can reject such calls if not to a temp >>>> gruu previously used for an emergency call. This can cause *som= e* >>>> disruption, but only to the extent of handling an incoming INVI= TE >>>> and rejecting it. If the frequency of that rises to a level whe= re >>>> it becomes a problem then it should be dealt with as a DOS atta= ck. >>>> >>>> Thanks, >>>> Paul >>>> >>>> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>> Once again, I would like to see whether there is a way for us to move >>>>> forward on the callback indicator issue. >>>>> >>>>> There are two requirements: >>>>> >>>>> 1.Indicate the callback >>>>> >>>>> 2.Be able to route the callback to the user that made the emergency >>>>> call >>>>> >>>>> Regarding the indication, it has been suggested that the indicator >>>>> value is per user, and is provided to the user upon registration. >>>>> >>>>> We also discussed whether the value could change over time, but the >>>>> problem was that the emg call may be done using an old value, and the >>>>> callback using a new value (because there was some time between the >>>>> emg call and the callback, during which the user was given a new valu= e). >>>>> >>>>> To avoid that, the registrar would always provide the same value to a >>>>> given user. >>>>> >>>>> 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 Mon Jun 11 12:04: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 2D1F321F85CD for ; Mon, 11 Jun 2012 12:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cCSYd1T5Xrk for ; Mon, 11 Jun 2012 12:04:22 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BD93021F8518 for ; Mon, 11 Jun 2012 12:04:21 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-e4-4fd64134e1fb Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 52.05.00702.43146DF4; Mon, 11 Jun 2012 21:04:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.62]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 11 Jun 2012 21:04:20 +0200 From: Christer Holmberg To: Brian Rosen , "john.medland@bt.com" Date: Mon, 11 Jun 2012 21:02:39 +0200 Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac1ECVuDE2MiiHydRxC76YNT05CaowD+2n0m Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C47149A69@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se> <4FCCD4B1.5010103@alum.mit.edu> , <9E270186-31EE-4227-A2EF-C1FE533B18F8@brianrosen.net> In-Reply-To: <9E270186-31EE-4227-A2EF-C1FE533B18F8@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+Jvra6J4zV/gynzTS2e3p/GZtG46Cmr xb1H85gsVmw4wOrA4vH3/Qcmj/vf/rJ7tH2ZzOSxZMlPpgCWKC6blNSczLLUIn27BK6Mnt0X 2AoarSoeLznG0sDYptfFyMkhIWAiceJcLwuELSZx4d56ti5GLg4hgVOMEifevGKGcBYwShza sgfI4eBgE7CQ6P6nDdIgIhAkMfHLNDaQMLNAhMS9faogYRYBVYmuxeuZQGxhASuJKy+PsUOU W0s8vbESyjaSODZ5ElgNr0C4xO15HxkhVn1gkjj38CcrSIJTwEni08wrzCA2I9Bx30+tAWtg FhCXuPVkPhPE0QISS/acZ4awRSVePv7HClEvKnGnfT0jRL2OxILdn9ggbG2JZQtfM0MsFpQ4 OfMJywRGsVlIxs5C0jILScssJC0LGFlWMQrnJmbmpJeb66UWZSYXF+fn6RWnbmIExtjBLb8N djBuui92iFGag0VJnFdPdb+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsaVmbv2xnl+l1K9 lxOWGOfz9e+vgjtGZuoTFLwvV6xak3bv430GZwEdI5Ofs0pat9u2dRTdUbkoN7Pq62XbM3fV c196XLXh2jphnTSPn1GBvTbLj1cWxqLJobWy67aL9OW8SIve3dYi9CWPa9fftXxLJm+RK7+6 LPygSdarfuNypd2NK44H/lBiKc5INNRiLipOBADb2pjufwIAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 11 Jun 2012 19:04:23 -0000 Hi, So, would anyone object to using Priority: Emergency? Regards, Christer ________________________________________ From: Brian Rosen [br@brianrosen.net] Sent: Wednesday, June 06, 2012 8:25 PM To: john.medland@bt.com Cc: pkyzivat@alum.mit.edu; Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning We distinguish between two kinds of call back: 1. Call back to the device that placed the call. This happens within minut= es of the original call. 2. Call back to the caller. This happens later The former uses Contact, the latter uses AoR. The former may need some ser= vices bypassed, the latter doesn't. Priority:Emergency is okay with me Just for reference, 3261 says: 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. Brian On Jun 6, 2012, at 6:37 AM, wro= te: > Paul, Christer, > > > 1 I inserted a use case below in Paul's email to hopefully assist with t= he discussion about priority indicators. > > > 2 PSAP callback is certainly an important subject for PSAPs in the UK, a= s callbacks are used to help manage emergency calls in an appreciable numbe= r of cases (though I don't currently have any stats for % of occasions, whi= ch may in any case change when moving off TDM networks to IP networks......= ..). > > > Regards > > John > > John Medland | 999/112 Policy Manager| BT | Tel:+44 (0)1977 593408 | Emai= l: john.medland@bt.com | > > > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Paul Kyzivat > Sent: 04 June 2012 16:31 > To: Christer Holmberg > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > On 6/4/12 9:20 AM, Christer Holmberg wrote: >> Hi, >> >> Assuming we would use Priority as callback indicator, is the "emergency"= value sufficient, or would be need an explicit "callback" value? >> >> Could a PSAP use Priority:emergency for non-callback calls? > > I suppose these questions may deserve further discussion. > > IMO Priority:emergency is appropriate for the callback, assuming it shoul= d be treated as an emergency. (OTOH, if the psap decides to call back the n= ext day just as a followup, to see if all is well, then perhaps it isn't an= emergency.) > > I don't understand what the use case might be, but if the psap felt a nee= d to initiate a call that was not a callback to a prior emergency call, and= it felt the call was indeed an emergency, then I see no reason why it shou= ld not tag it with Priority:emergency. > > [John Medland] Another Use Case (separate from callback to the end user w= ho needs help) would be where one PSAP needs to pass incident details to a = second PSAP where the second PSAP is needed to provide additional assistanc= e. An example would be where first PSAP is the Police but second PSAP is t= he Fire Service needed to free people trapped in a motor accident. > > In the latter case, the call might not get the same treatment on the rece= iving end. In this case the callee has nothing to help it distinguish a jus= tified use of Priority:emergency from an unjustified one. So it might not g= ive the call any priority treatment. But I think that is fine. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 15. toukokuuta 2012 18:19 >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >> >> I'll repeat my earlier arguments. Maybe I can make them more explicit th= is time. I think we have sufficient mechanism already defined, if it is use= d appropriately. Specifically: >> >> - the UA, when placing an emergency call, can use a temp gruu. >> Its possible to get as many temp gruus as you like, so the UA >> can reserve one for this purpose. This doesn't require any >> new capabilities in registrars. >> >> - when the UA receives a call addressed to a temp gruu that it >> had previously used for an emergency call, it can give it >> special treatment as an emergency callback. It can decide how >> long after the emergency call to grant this special treatment >> as a matter of policy. The special treatment can include dropping >> existing calls, special alerting, etc. >> >> - the PSAP, when placing the emergency callback, can indicate that >> *it* considers this call important using the Priority:emergency. >> If appropriate it can also use other existing headers, such as >> Resource-Priority. It call also use callerprefs to indicate that >> it prefers the real UA and does not wish an automaton. >> >> - middleboxes in the path of the callback can choose to honor the >> Priority:emergency, and use that to condition their behavior. >> For instance, a home proxy could decide that an emergency call >> to a temp gruu should not be diverted. (Though the fact that it is >> to a gruu should typically bypass that anyway.) >> >> - abuses of Priority:emergency by callers can be dealt with by the >> called UA, because it can reject such calls if not to a temp >> gruu previously used for an emergency call. This can cause *some* >> disruption, but only to the extent of handling an incoming INVITE >> and rejecting it. If the frequency of that rises to a level where >> it becomes a problem then it should be dealt with as a DOS attack. >> >> Thanks, >> Paul >> >> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>> Hi, >>> >>> Once again, I would like to see whether there is a way for us to move >>> forward on the callback indicator issue. >>> >>> There are two requirements: >>> >>> 1.Indicate the callback >>> >>> 2.Be able to route the callback to the user that made the emergency >>> call >>> >>> Regarding the indication, it has been suggested that the indicator >>> value is per user, and is provided to the user upon registration. >>> >>> We also discussed whether the value could change over time, but the >>> problem was that the emg call may be done using an old value, and the >>> callback using a new value (because there was some time between the >>> emg call and the callback, during which the user was given a new value)= . >>> >>> To avoid that, the registrar would always provide the same value to a >>> given user. >>> >>> 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 Mon Jun 11 13:27: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 2241421F85DF for ; Mon, 11 Jun 2012 13:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.949 X-Spam-Level: X-Spam-Status: No, score=-108.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kO5l9Z9RWRxX for ; Mon, 11 Jun 2012 13:27:04 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 018AF21F85CD for ; Mon, 11 Jun 2012 13:27:03 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q5BKQswi032370 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Jun 2012 22:26:56 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 11 Jun 2012 22:26:55 +0200 From: "DRAGE, Keith (Keith)" To: Christer Holmberg , Brian Rosen , "john.medland@bt.com" Date: Mon, 11 Jun 2012 22:26:54 +0200 Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac1ECVuDE2MiiHydRxC76YNT05CaowD+2n0mAALoMlA= Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se> <4FCCD4B1.5010103@alum.mit.edu> , <9E270186-31EE-4227-A2EF-C1FE533B18F8@brianrosen.net> <7F2072F1E0DE894DA4B517B93C6A05852C47149A69@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C47149A69@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 11 Jun 2012 20:27:05 -0000 Depends what for. For information to the end user, no problem. But as in my view it is an end-to-end header field, I do not envisage any p= rocessing in intermediate entities on it. Regards Keith -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: 11 June 2012 20:03 To: Brian Rosen; john.medland@bt.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning Hi, So, would anyone object to using Priority: Emergency? Regards, Christer ________________________________________ From: Brian Rosen [br@brianrosen.net] Sent: Wednesday, June 06, 2012 8:25 PM To: john.medland@bt.com Cc: pkyzivat@alum.mit.edu; Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning We distinguish between two kinds of call back: 1. Call back to the device that placed the call. This happens within minut= es of the original call. 2. Call back to the caller. This happens later The former uses Contact, the latter uses AoR. The former may need some ser= vices bypassed, the latter doesn't. Priority:Emergency is okay with me Just for reference, 3261 says: 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. Brian On Jun 6, 2012, at 6:37 AM, wro= te: > Paul, Christer, > > > 1 I inserted a use case below in Paul's email to hopefully assist with t= he discussion about priority indicators. > > > 2 PSAP callback is certainly an important subject for PSAPs in the UK, a= s callbacks are used to help manage emergency calls in an appreciable numbe= r of cases (though I don't currently have any stats for % of occasions, whi= ch may in any case change when moving off TDM networks to IP networks......= ..). > > > Regards > > John > > John Medland | 999/112 Policy Manager| BT | Tel:+44 (0)1977 593408 | Emai= l: john.medland@bt.com | > > > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of= Paul Kyzivat > Sent: 04 June 2012 16:31 > To: Christer Holmberg > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > On 6/4/12 9:20 AM, Christer Holmberg wrote: >> Hi, >> >> Assuming we would use Priority as callback indicator, is the "emergency"= value sufficient, or would be need an explicit "callback" value? >> >> Could a PSAP use Priority:emergency for non-callback calls? > > I suppose these questions may deserve further discussion. > > IMO Priority:emergency is appropriate for the callback, assuming it shoul= d be treated as an emergency. (OTOH, if the psap decides to call back the n= ext day just as a followup, to see if all is well, then perhaps it isn't an= emergency.) > > I don't understand what the use case might be, but if the psap felt a nee= d to initiate a call that was not a callback to a prior emergency call, and= it felt the call was indeed an emergency, then I see no reason why it shou= ld not tag it with Priority:emergency. > > [John Medland] Another Use Case (separate from callback to the end user w= ho needs help) would be where one PSAP needs to pass incident details to a = second PSAP where the second PSAP is needed to provide additional assistanc= e. An example would be where first PSAP is the Police but second PSAP is t= he Fire Service needed to free people trapped in a motor accident. > > In the latter case, the call might not get the same treatment on the rece= iving end. In this case the callee has nothing to help it distinguish a jus= tified use of Priority:emergency from an unjustified one. So it might not g= ive the call any priority treatment. But I think that is fine. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 15. toukokuuta 2012 18:19 >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >> >> I'll repeat my earlier arguments. Maybe I can make them more explicit th= is time. I think we have sufficient mechanism already defined, if it is use= d appropriately. Specifically: >> >> - the UA, when placing an emergency call, can use a temp gruu. >> Its possible to get as many temp gruus as you like, so the UA >> can reserve one for this purpose. This doesn't require any >> new capabilities in registrars. >> >> - when the UA receives a call addressed to a temp gruu that it >> had previously used for an emergency call, it can give it >> special treatment as an emergency callback. It can decide how >> long after the emergency call to grant this special treatment >> as a matter of policy. The special treatment can include dropping >> existing calls, special alerting, etc. >> >> - the PSAP, when placing the emergency callback, can indicate that >> *it* considers this call important using the Priority:emergency. >> If appropriate it can also use other existing headers, such as >> Resource-Priority. It call also use callerprefs to indicate that >> it prefers the real UA and does not wish an automaton. >> >> - middleboxes in the path of the callback can choose to honor the >> Priority:emergency, and use that to condition their behavior. >> For instance, a home proxy could decide that an emergency call >> to a temp gruu should not be diverted. (Though the fact that it is >> to a gruu should typically bypass that anyway.) >> >> - abuses of Priority:emergency by callers can be dealt with by the >> called UA, because it can reject such calls if not to a temp >> gruu previously used for an emergency call. This can cause *some* >> disruption, but only to the extent of handling an incoming INVITE >> and rejecting it. If the frequency of that rises to a level where >> it becomes a problem then it should be dealt with as a DOS attack. >> >> Thanks, >> Paul >> >> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>> Hi, >>> >>> Once again, I would like to see whether there is a way for us to move >>> forward on the callback indicator issue. >>> >>> There are two requirements: >>> >>> 1.Indicate the callback >>> >>> 2.Be able to route the callback to the user that made the emergency >>> call >>> >>> Regarding the indication, it has been suggested that the indicator >>> value is per user, and is provided to the user upon registration. >>> >>> We also discussed whether the value could change over time, but the >>> problem was that the emg call may be done using an old value, and the >>> callback using a new value (because there was some time between the >>> emg call and the callback, during which the user was given a new value)= . >>> >>> To avoid that, the registrar would always provide the same value to a >>> given user. >>> >>> 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From john.medland@bt.com Mon Jun 11 13:33:17 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 9B7A311E808C for ; Mon, 11 Jun 2012 13:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQVPJkUNRsE1 for ; Mon, 11 Jun 2012 13:33:16 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 33BD621F84FB for ; Mon, 11 Jun 2012 13:33:15 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.264.0; Mon, 11 Jun 2012 21:33:13 +0100 Received: from emv66-ukrd.domain1.systemhost.net ([169.254.1.211]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Mon, 11 Jun 2012 21:33:13 +0100 From: To: Date: Mon, 11 Jun 2012 21:33:11 +0100 Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac1HO1hyvQIHghy1Svi2FHSqGs1S9gA1H3RA Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se> <4FCCD4B1.5010103@alum.mit.edu> <4FD4EEBE.7060206@alum.mit.edu> In-Reply-To: <4FD4EEBE.7060206@alum.mit.edu> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 11 Jun 2012 20:33:17 -0000 Paul - I've tried to answer briefly below. Regards John=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 10 June 2012 20:00 To: Medland,JD,John,MLC12 R Cc: christer.holmberg@ericsson.com; ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning On 6/6/12 12:37 PM, john.medland@bt.com wrote: > Paul, Christer, > > > 1 I inserted a use case below in Paul's email to hopefully assist with t= he discussion about priority indicators. John - can you clarify your use case further? You say the first psap (police) calls a 2nd psap (fire) for help on the cal= l. Did you mean the call from police to fire is the one to be tagged as an eme= rgency?=20 [John Medland] Yes that was the scenario I had in mind. Or did you mean that subsequently the fire psap wants to call the original = user? If the latter, then I guess it is a judgement call whether this is a = callback or not. [John Medland] I'd not considered this but it could (more rarely) also be h= elpful. Also, this brings up some interesting issues. Suppose the user is still on = the line with the police when the fire psap calls. What should happen? Shou= ld the user's phone hang up the call to police to answer the one from fire?= Or reject the one from fire? Merge the calls? [John Medland] Possible, but unlikely scenario, as Police would most likely= tell Fire that they were still in contact with caller so Fire Service woul= d not try. It sounds to me like it would be better for the police to treat this as a c= onsult, followed by a consultative transfer. If so, then there would be no = callback at all. [John Medland] Sorry, but not sure what's meant by a "consult"? May be OK= but also needs priority treatment (to indicate dealing with arranging an e= mergency response). =20 Thanks, Paul > 2 PSAP callback is certainly an important subject for PSAPs in the UK, a= s callbacks are used to help manage emergency calls in an appreciable numbe= r of cases (though I don't currently have any stats for % of occasions, whi= ch may in any case change when moving off TDM networks to IP networks......= ..). > > > Regards > > John > > John Medland | 999/112 Policy Manager| BT | Tel:+44 (0)1977 593408 |=20 > Email: john.medland@bt.com | > > > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: 04 June 2012 16:31 > To: Christer Holmberg > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > On 6/4/12 9:20 AM, Christer Holmberg wrote: >> Hi, >> >> Assuming we would use Priority as callback indicator, is the "emergency"= value sufficient, or would be need an explicit "callback" value? >> >> Could a PSAP use Priority:emergency for non-callback calls? > > I suppose these questions may deserve further discussion. > > IMO Priority:emergency is appropriate for the callback, assuming it=20 > should be treated as an emergency. (OTOH, if the psap decides to call=20 > back the next day just as a followup, to see if all is well, then=20 > perhaps it isn't an emergency.) > > I don't understand what the use case might be, but if the psap felt a nee= d to initiate a call that was not a callback to a prior emergency call, and= it felt the call was indeed an emergency, then I see no reason why it shou= ld not tag it with Priority:emergency. > > [John Medland] Another Use Case (separate from callback to the end user w= ho needs help) would be where one PSAP needs to pass incident details to a = second PSAP where the second PSAP is needed to provide additional assistanc= e. An example would be where first PSAP is the Police but second PSAP is t= he Fire Service needed to free people trapped in a motor accident. > > In the latter case, the call might not get the same treatment on the rece= iving end. In this case the callee has nothing to help it distinguish a jus= tified use of Priority:emergency from an unjustified one. So it might not g= ive the call any priority treatment. But I think that is fine. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >> Behalf Of Paul Kyzivat >> Sent: 15. toukokuuta 2012 18:19 >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >> >> I'll repeat my earlier arguments. Maybe I can make them more explicit th= is time. I think we have sufficient mechanism already defined, if it is use= d appropriately. Specifically: >> >> - the UA, when placing an emergency call, can use a temp gruu. >> Its possible to get as many temp gruus as you like, so the UA >> can reserve one for this purpose. This doesn't require any >> new capabilities in registrars. >> >> - when the UA receives a call addressed to a temp gruu that it >> had previously used for an emergency call, it can give it >> special treatment as an emergency callback. It can decide how >> long after the emergency call to grant this special treatment >> as a matter of policy. The special treatment can include dropping >> existing calls, special alerting, etc. >> >> - the PSAP, when placing the emergency callback, can indicate that >> *it* considers this call important using the Priority:emergency. >> If appropriate it can also use other existing headers, such as >> Resource-Priority. It call also use callerprefs to indicate that >> it prefers the real UA and does not wish an automaton. >> >> - middleboxes in the path of the callback can choose to honor the >> Priority:emergency, and use that to condition their behavior. >> For instance, a home proxy could decide that an emergency call >> to a temp gruu should not be diverted. (Though the fact that it is >> to a gruu should typically bypass that anyway.) >> >> - abuses of Priority:emergency by callers can be dealt with by the >> called UA, because it can reject such calls if not to a temp >> gruu previously used for an emergency call. This can cause *some* >> disruption, but only to the extent of handling an incoming INVITE >> and rejecting it. If the frequency of that rises to a level where >> it becomes a problem then it should be dealt with as a DOS attack. >> >> Thanks, >> Paul >> >> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>> Hi, >>> >>> Once again, I would like to see whether there is a way for us to=20 >>> move forward on the callback indicator issue. >>> >>> There are two requirements: >>> >>> 1.Indicate the callback >>> >>> 2.Be able to route the callback to the user that made the emergency=20 >>> call >>> >>> Regarding the indication, it has been suggested that the indicator=20 >>> value is per user, and is provided to the user upon registration. >>> >>> We also discussed whether the value could change over time, but the=20 >>> problem was that the emg call may be done using an old value, and=20 >>> the callback using a new value (because there was some time between=20 >>> the emg call and the callback, during which the user was given a new va= lue). >>> >>> To avoid that, the registrar would always provide the same value to=20 >>> a given user. >>> >>> 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 Tue Jun 12 01:28:25 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 B7E6321F85DF for ; Tue, 12 Jun 2012 01:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.189 X-Spam-Level: X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyKB5DjDK1Tq for ; Tue, 12 Jun 2012 01:28:24 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2D03321F85CE for ; Tue, 12 Jun 2012 01:28:24 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-22-4fd6fda6f7cd Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F9.64.28636.6ADF6DF4; Tue, 12 Jun 2012 10:28:22 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.62]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 12 Jun 2012 10:28:22 +0200 From: Christer Holmberg To: "'DRAGE, Keith (Keith)'" , Brian Rosen , "john.medland@bt.com" Date: Tue, 12 Jun 2012 10:28:21 +0200 Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac1ECVuDE2MiiHydRxC76YNT05CaowD+2n0mAALoMlAAGSovIA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4735DDD9@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se> <4FCCD4B1.5010103@alum.mit.edu> , <9E270186-31EE-4227-A2EF-C1FE533B18F8@brianrosen.net> <7F2072F1E0DE894DA4B517B93C6A05852C47149A69@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvre6yv9f8DX4cM7N4en8am0Xjoqes FvcezWOyeNp4ltGBxaP12V5Wj/vf/rJ7tH2ZzOSxZMlPpgCWKC6blNSczLLUIn27BK6M92f3 MBdccKhomN3H3sB4yLiLkYNDQsBE4v8H5S5GTiBTTOLCvfVsXYxcHEICpxglNv39zgLhLGCU uLP5GhtIA5uAhUT3P22QuIhAL6PEi5+nmEC6mQVUJc41PmYBsVmA7Ct33zGD2MICVhJXXh5j B7FFBKwlnt5YCWU7Saz6v4oVxOYVCJdYPWMpO8SyqSwS05+fBCviFIiTuLr9D1gRI9B530+t gVomLnHryXwmiLMFJJbsOc8MYYtKvHz8D6peVOJO+3pGiHodiQW7P7FB2NoSyxa+ZoZYLChx cuYTlgmMYrOQjJ2FpGUWkpZZSFoWMLKsYhTOTczMSS831EstykwuLs7P0ytO3cQIjLKDW37r 7mA8dU7kEKM0B4uSOC9X0n5/IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxpc4MD3t6tXyfj cCU8dfo52wtb6mWVZ6ZOruiJ0Zvx9QJ/8/MHbxIDPj3JFLjt6COpnvQpfdb6t1X3I07cXv/s tMQR4ZXFsitKP7gfdo4VXyt+Kkz84DKlSW5f37uz9fjfbX1+I6L1TFJ72t7MlTPN5US5Fhfc 2b+6/HXJizMbElNmtZ6s/92uxFKckWioxVxUnAgA0x8qqIACAAA= Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 12 Jun 2012 08:28:26 -0000 Hi,=20 > Depends what for. > > For information to the end user, no problem. > > But as in my view it is an end-to-end header field, I do not envisage any= processing in intermediate entities on it. The text referenced by Brian talks about "agent of user", so one could clai= m that is a network function. If not, do you have another suggestion for intermediaries? Regards, Christer -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of C= hrister Holmberg Sent: 11 June 2012 20:03 To: Brian Rosen; john.medland@bt.com Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning Hi, So, would anyone object to using Priority: Emergency? Regards, Christer ________________________________________ From: Brian Rosen [br@brianrosen.net] Sent: Wednesday, June 06, 2012 8:25 PM To: john.medland@bt.com Cc: pkyzivat@alum.mit.edu; Christer Holmberg; ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning We distinguish between two kinds of call back: 1. Call back to the device that placed the call. This happens within minut= es of the original call. 2. Call back to the caller. This happens later The former uses Contact, the latter uses AoR. The former may need some ser= vices bypassed, the latter doesn't. Priority:Emergency is okay with me Just for reference, 3261 says: 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. Brian On Jun 6, 2012, at 6:37 AM, wro= te: > Paul, Christer, > > > 1 I inserted a use case below in Paul's email to hopefully assist with t= he discussion about priority indicators. > > > 2 PSAP callback is certainly an important subject for PSAPs in the UK, a= s callbacks are used to help manage emergency calls in an appreciable numbe= r of cases (though I don't currently have any stats for % of occasions, whi= ch may in any case change when moving off TDM networks to IP networks......= ..). > > > Regards > > John > > John Medland | 999/112 Policy Manager| BT | Tel:+44 (0)1977 593408 |=20 > Email: john.medland@bt.com | > > > > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: 04 June 2012 16:31 > To: Christer Holmberg > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > On 6/4/12 9:20 AM, Christer Holmberg wrote: >> Hi, >> >> Assuming we would use Priority as callback indicator, is the "emergency"= value sufficient, or would be need an explicit "callback" value? >> >> Could a PSAP use Priority:emergency for non-callback calls? > > I suppose these questions may deserve further discussion. > > IMO Priority:emergency is appropriate for the callback, assuming it=20 > should be treated as an emergency. (OTOH, if the psap decides to call=20 > back the next day just as a followup, to see if all is well, then=20 > perhaps it isn't an emergency.) > > I don't understand what the use case might be, but if the psap felt a nee= d to initiate a call that was not a callback to a prior emergency call, and= it felt the call was indeed an emergency, then I see no reason why it shou= ld not tag it with Priority:emergency. > > [John Medland] Another Use Case (separate from callback to the end user w= ho needs help) would be where one PSAP needs to pass incident details to a = second PSAP where the second PSAP is needed to provide additional assistanc= e. An example would be where first PSAP is the Police but second PSAP is t= he Fire Service needed to free people trapped in a motor accident. > > In the latter case, the call might not get the same treatment on the rece= iving end. In this case the callee has nothing to help it distinguish a jus= tified use of Priority:emergency from an unjustified one. So it might not g= ive the call any priority treatment. But I think that is fine. > > Thanks, > Paul > >> Regards, >> >> Christer >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >> Behalf Of Paul Kyzivat >> Sent: 15. toukokuuta 2012 18:19 >> To: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >> >> I'll repeat my earlier arguments. Maybe I can make them more explicit th= is time. I think we have sufficient mechanism already defined, if it is use= d appropriately. Specifically: >> >> - the UA, when placing an emergency call, can use a temp gruu. >> Its possible to get as many temp gruus as you like, so the UA >> can reserve one for this purpose. This doesn't require any >> new capabilities in registrars. >> >> - when the UA receives a call addressed to a temp gruu that it >> had previously used for an emergency call, it can give it >> special treatment as an emergency callback. It can decide how >> long after the emergency call to grant this special treatment >> as a matter of policy. The special treatment can include dropping >> existing calls, special alerting, etc. >> >> - the PSAP, when placing the emergency callback, can indicate that >> *it* considers this call important using the Priority:emergency. >> If appropriate it can also use other existing headers, such as >> Resource-Priority. It call also use callerprefs to indicate that >> it prefers the real UA and does not wish an automaton. >> >> - middleboxes in the path of the callback can choose to honor the >> Priority:emergency, and use that to condition their behavior. >> For instance, a home proxy could decide that an emergency call >> to a temp gruu should not be diverted. (Though the fact that it is >> to a gruu should typically bypass that anyway.) >> >> - abuses of Priority:emergency by callers can be dealt with by the >> called UA, because it can reject such calls if not to a temp >> gruu previously used for an emergency call. This can cause *some* >> disruption, but only to the extent of handling an incoming INVITE >> and rejecting it. If the frequency of that rises to a level where >> it becomes a problem then it should be dealt with as a DOS attack. >> >> Thanks, >> Paul >> >> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>> Hi, >>> >>> Once again, I would like to see whether there is a way for us to=20 >>> move forward on the callback indicator issue. >>> >>> There are two requirements: >>> >>> 1.Indicate the callback >>> >>> 2.Be able to route the callback to the user that made the emergency=20 >>> call >>> >>> Regarding the indication, it has been suggested that the indicator=20 >>> value is per user, and is provided to the user upon registration. >>> >>> We also discussed whether the value could change over time, but the=20 >>> problem was that the emg call may be done using an old value, and=20 >>> the callback using a new value (because there was some time between=20 >>> the emg call and the callback, during which the user was given a new va= lue). >>> >>> To avoid that, the registrar would always provide the same value to=20 >>> a given user. >>> >>> 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit From pkyzivat@alum.mit.edu Tue Jun 12 12:32: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 1BBE021F85C4 for ; Tue, 12 Jun 2012 12:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=0.966, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3B3saqA0dXw for ; Tue, 12 Jun 2012 12:32:49 -0700 (PDT) Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [76.96.30.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1131021F85AE for ; Tue, 12 Jun 2012 12:32:48 -0700 (PDT) Received: from omta18.emeryville.ca.mail.comcast.net ([76.96.30.74]) by qmta05.emeryville.ca.mail.comcast.net with comcast id MXQp1j0021bwxycA5XYoww; Tue, 12 Jun 2012 19:32:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([83.241.130.138]) by omta18.emeryville.ca.mail.comcast.net with comcast id MXYS1j0102zJWM78eXYYed; Tue, 12 Jun 2012 19:32:43 +0000 Message-ID: <4FD7994A.80709@alum.mit.edu> Date: Tue, 12 Jun 2012 21:32:26 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: ecrit@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se> <4FCCD4B1.5010103@alum.mit.edu> , <9E270186-31EE-4227-A2EF-C1FE533B18F8@brianrosen.net> <7F2072F1E0DE894DA4B517B93C6A05852C47149A69@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 12 Jun 2012 19:32:54 -0000 On 6/11/12 10:26 PM, DRAGE, Keith (Keith) wrote: > Depends what for. > > For information to the end user, no problem. > > But as in my view it is an end-to-end header field, I do not envisage any processing in intermediate entities on it. Here are some excerpts from the text from 3261: 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. Note "the receiving human *or its agent*". So this applies in some sense to all the infrastructure associated with the callee, such as the called party S-CSCF and APs, and the called party P-CSCF. For example, it may be factored into decisions about call routing and acceptance. The above seems to have direct bearing on this discussion. 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. We've already noted this. Resource-Priority would be applicable to these. It is RECOMMENDED that the value of "emergency" only be used when life, limb, or property are in imminent danger. Otherwise, there are no semantics defined for this header field. This certainly scopes its use in a suitable way. I'm not convinced that you *want* to bypass *all* services. But I do think every service should have a policy of whether and how it applies to emergency calls. And very likely many/most of them will have a policy of "do not apply" to emergency calls. The elephant in the room is: what if the caller lies, and tags a call as an emergency when it is not? (Since it can be coming from an unreliable source.) In large part, I think this is a risk to be tolerated, unless doing so can be demonstrated to cause great harm. So what sort of harm can come from this? - user defined policies, such as various sorts of call diversion, might not be honored. But I've suggested that the phone itself could have policies to deal with this. E.g. it could refuse the call, or treat it with lessened priority, if it isn't "expecting" an emergency callback. And conversely, it can give the call enhanced priority if it is expecting an emergency call. (E.g. it can bypass disabled ringing and use a special ring tone, plus vibrate, plus flash, etc.) Given these mitigating actions, this doesn't seem to cause great harm. - provider defined policies, carrying out the interests of the provider even if not in the interest of the user, might not be honored. The most obvious of these might be allowing calls to a user that has been "barred" for non-payment. I don't have a good answer to this one. Certainly it is a target for fraud. But perhaps the solution to this one is legal rather than technical. Such calls could be logged, and if a significant number of them are noted then action can be taken against the caller. - services that are "transparent" to the call, need not be bypassed at all if desired. Thanks, Paul > Regards > > Keith > > -----Original Message----- > From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 11 June 2012 20:03 > To: Brian Rosen; john.medland@bt.com > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > Hi, > > So, would anyone object to using Priority: Emergency? > > Regards, > > Christer > > ________________________________________ > From: Brian Rosen [br@brianrosen.net] > Sent: Wednesday, June 06, 2012 8:25 PM > To: john.medland@bt.com > Cc: pkyzivat@alum.mit.edu; Christer Holmberg; ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > We distinguish between two kinds of call back: > 1. Call back to the device that placed the call. This happens within minutes of the original call. > 2. Call back to the caller. This happens later > > The former uses Contact, the latter uses AoR. The former may need some services bypassed, the latter doesn't. > > Priority:Emergency is okay with me > Just for reference, 3261 says: > 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. > > Brian > > On Jun 6, 2012, at 6:37 AM, wrote: > >> Paul, Christer, >> >> >> 1 I inserted a use case below in Paul's email to hopefully assist with the discussion about priority indicators. >> >> >> 2 PSAP callback is certainly an important subject for PSAPs in the UK, as callbacks are used to help manage emergency calls in an appreciable number of cases (though I don't currently have any stats for % of occasions, which may in any case change when moving off TDM networks to IP networks........). >> >> >> Regards >> >> John >> >> John Medland | 999/112 Policy Manager| BT | Tel:+44 (0)1977 593408 | Email: john.medland@bt.com | >> >> >> >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 04 June 2012 16:31 >> To: Christer Holmberg >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >> >> On 6/4/12 9:20 AM, Christer Holmberg wrote: >>> Hi, >>> >>> Assuming we would use Priority as callback indicator, is the "emergency" value sufficient, or would be need an explicit "callback" value? >>> >>> Could a PSAP use Priority:emergency for non-callback calls? >> >> I suppose these questions may deserve further discussion. >> >> IMO Priority:emergency is appropriate for the callback, assuming it should be treated as an emergency. (OTOH, if the psap decides to call back the next day just as a followup, to see if all is well, then perhaps it isn't an emergency.) >> >> I don't understand what the use case might be, but if the psap felt a need to initiate a call that was not a callback to a prior emergency call, and it felt the call was indeed an emergency, then I see no reason why it should not tag it with Priority:emergency. >> >> [John Medland] Another Use Case (separate from callback to the end user who needs help) would be where one PSAP needs to pass incident details to a second PSAP where the second PSAP is needed to provide additional assistance. An example would be where first PSAP is the Police but second PSAP is the Fire Service needed to free people trapped in a motor accident. >> >> In the latter case, the call might not get the same treatment on the receiving end. In this case the callee has nothing to help it distinguish a justified use of Priority:emergency from an unjustified one. So it might not give the call any priority treatment. But I think that is fine. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat >>> Sent: 15. toukokuuta 2012 18:19 >>> To: ecrit@ietf.org >>> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >>> >>> I'll repeat my earlier arguments. Maybe I can make them more explicit this time. I think we have sufficient mechanism already defined, if it is used appropriately. Specifically: >>> >>> - the UA, when placing an emergency call, can use a temp gruu. >>> Its possible to get as many temp gruus as you like, so the UA >>> can reserve one for this purpose. This doesn't require any >>> new capabilities in registrars. >>> >>> - when the UA receives a call addressed to a temp gruu that it >>> had previously used for an emergency call, it can give it >>> special treatment as an emergency callback. It can decide how >>> long after the emergency call to grant this special treatment >>> as a matter of policy. The special treatment can include dropping >>> existing calls, special alerting, etc. >>> >>> - the PSAP, when placing the emergency callback, can indicate that >>> *it* considers this call important using the Priority:emergency. >>> If appropriate it can also use other existing headers, such as >>> Resource-Priority. It call also use callerprefs to indicate that >>> it prefers the real UA and does not wish an automaton. >>> >>> - middleboxes in the path of the callback can choose to honor the >>> Priority:emergency, and use that to condition their behavior. >>> For instance, a home proxy could decide that an emergency call >>> to a temp gruu should not be diverted. (Though the fact that it is >>> to a gruu should typically bypass that anyway.) >>> >>> - abuses of Priority:emergency by callers can be dealt with by the >>> called UA, because it can reject such calls if not to a temp >>> gruu previously used for an emergency call. This can cause *some* >>> disruption, but only to the extent of handling an incoming INVITE >>> and rejecting it. If the frequency of that rises to a level where >>> it becomes a problem then it should be dealt with as a DOS attack. >>> >>> Thanks, >>> Paul >>> >>> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>>> Hi, >>>> >>>> Once again, I would like to see whether there is a way for us to move >>>> forward on the callback indicator issue. >>>> >>>> There are two requirements: >>>> >>>> 1.Indicate the callback >>>> >>>> 2.Be able to route the callback to the user that made the emergency >>>> call >>>> >>>> Regarding the indication, it has been suggested that the indicator >>>> value is per user, and is provided to the user upon registration. >>>> >>>> We also discussed whether the value could change over time, but the >>>> problem was that the emg call may be done using an old value, and the >>>> callback using a new value (because there was some time between the >>>> emg call and the callback, during which the user was given a new value). >>>> >>>> To avoid that, the registrar would always provide the same value to a >>>> given user. >>>> >>>> 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 > _______________________________________________ > 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 Tue Jun 12 12:32: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 CE17721F86B7 for ; Tue, 12 Jun 2012 12:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.494 X-Spam-Level: X-Spam-Status: No, score=-1.494 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcBFVIkV2J3j for ; Tue, 12 Jun 2012 12:32:53 -0700 (PDT) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by ietfa.amsl.com (Postfix) with ESMTP id D416621F85A5 for ; Tue, 12 Jun 2012 12:32:53 -0700 (PDT) Received: from omta10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by qmta10.emeryville.ca.mail.comcast.net with comcast id MXQe1j0020cQ2SLAAXYtbl; Tue, 12 Jun 2012 19:32:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([83.241.130.138]) by omta10.emeryville.ca.mail.comcast.net with comcast id MXYM1j0162zJWM78WXYTlb; Tue, 12 Jun 2012 19:32:48 +0000 Message-ID: <4FD79945.5060803@alum.mit.edu> Date: Tue, 12 Jun 2012 21:32:21 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> , <4FCCF882.6020906@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C8@ESESSCMS0356.eemea.ericsson.se> <4FCD19F4.9070704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1CAA6@ESESSCMS0356.eemea.ericsson.se>, <4FCE0BCF.7080709@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C47149A67@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C47149A67@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 12 Jun 2012 19:32:54 -0000 On 6/11/12 8:55 PM, Christer Holmberg wrote: > Hi, > >>>>>>> A new RPH=SOS (versus SOL) that is honored based on a trust >>>>>>> model/relationships >>>>>> >>>>>> I had originally noted that we could use a number of existing >>>>>> indications. Resource-Priority would perhaps be good in environments >>>>>> that do something with it. This would be complementary to the >>>>>> Priority:emergency, which is an indication of how the caller >>>>>> perceives the call. The Resource-Priority, when used, may be subject >>>>>> to other controls, and mostly impact intermediaries, rather than the callee. >>>>> >>>>> Well, as we've discussed before, we DO need an indicator which is used by intermediaries to give special treatment to the callback. >>>> >>>> Well, I guess it depends on what sorts of treatment you are talking about. If you are talking about resource prioritization, then the Resource-Priority header is probably what you want. >>>> >>>> If you are talking about bypassing various sorts of treatment, such as call diversion, then I don't think Resource-Priority is the right thing. >>>> Those are generally discretionary anyway. Honoring the caller's wishes, expressed via Priority and perhaps callerprefs, seems to make more sense. In such cases, there is a question of whether to honor the caller's preferences, or the callee's policies. It's >>>> my personal opinion that if the caller says he only wants to talk to a human, not an automaton, then one should honor that, and either let the human's phone ring or else simply reject the call. And I'm suggesting that from a provider perspective that >>>> means passing the call to the UA and letting it decide. >>> >>> It's not only about bypassing diversion. Even if the call will reach the correct human, one may still want to bypass services etc in the network. >> >> I find it hard to have this discussion in the abstract. >> Can we talk about the specific sorts of services you have in mind? I >> suspect that different sorts of treatment may need to be addressed in >> different ways. > > Any type of service (diversion is one example) that normally would be applied to the called user. Typically, in IMS, the S-CSCF would not forward a terminating callback requests to Application Servers providing such services. "Any type of service" doesn't do it for me. Maybe it would if I had a list of the services that are typically offered. But I don't. >> ISTM there is a fundamental issue here of whether it is expected that >> intermediaries must understand the purpose of the incoming call to >> decide how to handle it, or if the caller should simply indicate how he >> would like it handled (or not handled). > > The intermediareis must understand the purpose of the incoming call. Well, if we use the Priority:emergency header, then we know the caller asserts its an emergency call. Do you need to know more about the purpose of than that? I'll say more in reply to one of the other messages in this thread. Thanks, Paul > Regards, > > Christer > > >>>> -----Original Message----- >>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Christer Holmberg >>>> Sent: Monday, June 04, 2012 1:33 PM >>>> To: Paul Kyzivat >>>> Cc: ecrit@ietf.org >>>> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >>>> >>>> Hi, >>>> >>>>>> Assuming we would use Priority as callback indicator, is the "emergency" value sufficient, or would be need an explicit "callback" value? >>>>>> >>>>>> Could a PSAP use Priority:emergency for non-callback calls? >>>>> >>>>> I suppose these questions may deserve further discussion. >>>>> >>>>> IMO Priority:emergency is appropriate for the callback, assuming it >>>>> should be treated as an emergency. (OTOH, if the psap decides to call >>>>> back the next day just as a followup, to see if all is well, then >>>>> perhaps it isn't an emergency.) >>>>> >>>>> I don't understand what the use case might be, but if the psap felt a >>>>> need to initiate a call that was not a callback to a prior emergency >>>>> call, and it felt the call was indeed an emergency, then I see no reason >>>>> why it should not tag it with Priority:emergency. >>>>> >>>>> In the latter case, the call might not get the same treatment on the >>>>> receiving end. In this case the callee has nothing to help it >>>>> distinguish a justified use of Priority:emergency from an unjustified >>>>> one. So it might not give the call any priority treatment. But I think >>>>> that is fine. >>>> >>>> OTOH, defining a new Priority value is not a very difficult task :) >>>> >>>> Also, in this case I guess the semantics of a callback already exists, so we wouldn't need to work much on that. >>>> >>>> Regards, >>>> >>>> Christer >>>> >>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> -----Original Message----- >>>>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>> Sent: 15. toukokuuta 2012 18:19 >>>>> To: ecrit@ietf.org >>>>> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >>>>> >>>>> I'll repeat my earlier arguments. Maybe I can make them more explicit this time. I think we have sufficient mechanism already defined, if it is used appropriately. Specifically: >>>>> >>>>> - the UA, when placing an emergency call, can use a temp gruu. >>>>> Its possible to get as many temp gruus as you like, so the UA >>>>> can reserve one for this purpose. This doesn't require any >>>>> new capabilities in registrars. >>>>> >>>>> - when the UA receives a call addressed to a temp gruu that it >>>>> had previously used for an emergency call, it can give it >>>>> special treatment as an emergency callback. It can decide how >>>>> long after the emergency call to grant this special treatment >>>>> as a matter of policy. The special treatment can include dropping >>>>> existing calls, special alerting, etc. >>>>> >>>>> - the PSAP, when placing the emergency callback, can indicate that >>>>> *it* considers this call important using the Priority:emergency. >>>>> If appropriate it can also use other existing headers, such as >>>>> Resource-Priority. It call also use callerprefs to indicate that >>>>> it prefers the real UA and does not wish an automaton. >>>>> >>>>> - middleboxes in the path of the callback can choose to honor the >>>>> Priority:emergency, and use that to condition their behavior. >>>>> For instance, a home proxy could decide that an emergency call >>>>> to a temp gruu should not be diverted. (Though the fact that it is >>>>> to a gruu should typically bypass that anyway.) >>>>> >>>>> - abuses of Priority:emergency by callers can be dealt with by the >>>>> called UA, because it can reject such calls if not to a temp >>>>> gruu previously used for an emergency call. This can cause *some* >>>>> disruption, but only to the extent of handling an incoming INVITE >>>>> and rejecting it. If the frequency of that rises to a level where >>>>> it becomes a problem then it should be dealt with as a DOS attack. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>>>>> Hi, >>>>>> >>>>>> Once again, I would like to see whether there is a way for us to move >>>>>> forward on the callback indicator issue. >>>>>> >>>>>> There are two requirements: >>>>>> >>>>>> 1.Indicate the callback >>>>>> >>>>>> 2.Be able to route the callback to the user that made the emergency >>>>>> call >>>>>> >>>>>> Regarding the indication, it has been suggested that the indicator >>>>>> value is per user, and is provided to the user upon registration. >>>>>> >>>>>> We also discussed whether the value could change over time, but the >>>>>> problem was that the emg call may be done using an old value, and the >>>>>> callback using a new value (because there was some time between the >>>>>> emg call and the callback, during which the user was given a new value). >>>>>> >>>>>> To avoid that, the registrar would always provide the same value to a >>>>>> given user. >>>>>> >>>>>> 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 pkyzivat@alum.mit.edu Tue Jun 12 12:43: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 BB93F11E8086 for ; Tue, 12 Jun 2012 12:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69d7FU6PS0on for ; Tue, 12 Jun 2012 12:43:26 -0700 (PDT) Received: from qmta07.emeryville.ca.mail.comcast.net (qmta07.emeryville.ca.mail.comcast.net [76.96.30.64]) by ietfa.amsl.com (Postfix) with ESMTP id A389111E8073 for ; Tue, 12 Jun 2012 12:43:26 -0700 (PDT) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta07.emeryville.ca.mail.comcast.net with comcast id MXaq1j0020b6N64A7XjSBt; Tue, 12 Jun 2012 19:43:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([83.241.130.138]) by omta03.emeryville.ca.mail.comcast.net with comcast id MXit1j00J2zJWM78PXizVT; Tue, 12 Jun 2012 19:43:21 +0000 Message-ID: <4FD79BBD.8020408@alum.mit.edu> Date: Tue, 12 Jun 2012 21:42:53 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: john.medland@bt.com References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se> <4FCCD4B1.5010103@alum.mit.edu> <4FD4EEBE.7060206@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 12 Jun 2012 19:43:27 -0000 On 6/11/12 10:33 PM, john.medland@bt.com wrote: > Paul - I've tried to answer briefly below. Regards > > John > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 10 June 2012 20:00 > To: Medland,JD,John,MLC12 R > Cc: christer.holmberg@ericsson.com; ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > On 6/6/12 12:37 PM, john.medland@bt.com wrote: >> Paul, Christer, >> >> >> 1 I inserted a use case below in Paul's email to hopefully assist with the discussion about priority indicators. > > John - can you clarify your use case further? > You say the first psap (police) calls a 2nd psap (fire) for help on the call. > > Did you mean the call from police to fire is the one to be tagged as an emergency? > [John Medland] Yes that was the scenario I had in mind. OK. Then I guessed wrong. If this is the case you have in mind, then it hardly seems "special" at all. How is it different from the police calling the fire department emergency number because the police station is on fire? > Or did you mean that subsequently the fire psap wants to call the original user? If the latter, then I guess it is a judgement call whether this is a callback or not. > [John Medland] I'd not considered this but it could (more rarely) also be helpful. > > Also, this brings up some interesting issues. Suppose the user is still on the line with the police when the fire psap calls. What should happen? Should the user's phone hang up the call to police to answer the one from fire? Or reject the one from fire? Merge the calls? > [John Medland] Possible, but unlikely scenario, as Police would most likely tell Fire that they were still in contact with caller so Fire Service would not try. > > It sounds to me like it would be better for the police to treat this as a consult, followed by a consultative transfer. If so, then there would be no callback at all. > [John Medland] Sorry, but not sure what's meant by a "consult"? May be OK but also needs priority treatment (to indicate dealing with arranging an emergency response). Well, this was based on a wrong guess by me about what you meant. I thought that was standard terminology. In a normal case that means you put one call on hold, and call somebody else for a "consultation" - to get info for your first call. Then you might decide to either: - transfer the original caller to the consultant, dropping yourself out of the call. - conference the caller, yourself, and the consultant together. But in the case of emergency calls I gather psap practices may require the original answerer to stay in the call, which would forbid forwarding. And forwarding without assuring that the handoff had been successfully accomplished would no doubt be forbidden. So establishing a conference might be the first step, and then *maybe* the police could drop out once it was established that the fire dept had fully taken responsibility for the call. In any case, none of this would require a callback. Thanks, Paul > > Thanks, > Paul > >> 2 PSAP callback is certainly an important subject for PSAPs in the UK, as callbacks are used to help manage emergency calls in an appreciable number of cases (though I don't currently have any stats for % of occasions, which may in any case change when moving off TDM networks to IP networks........). >> >> >> Regards >> >> John >> >> John Medland | 999/112 Policy Manager| BT | Tel:+44 (0)1977 593408 | >> Email: john.medland@bt.com | >> >> >> >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 04 June 2012 16:31 >> To: Christer Holmberg >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >> >> On 6/4/12 9:20 AM, Christer Holmberg wrote: >>> Hi, >>> >>> Assuming we would use Priority as callback indicator, is the "emergency" value sufficient, or would be need an explicit "callback" value? >>> >>> Could a PSAP use Priority:emergency for non-callback calls? >> >> I suppose these questions may deserve further discussion. >> >> IMO Priority:emergency is appropriate for the callback, assuming it >> should be treated as an emergency. (OTOH, if the psap decides to call >> back the next day just as a followup, to see if all is well, then >> perhaps it isn't an emergency.) >> >> I don't understand what the use case might be, but if the psap felt a need to initiate a call that was not a callback to a prior emergency call, and it felt the call was indeed an emergency, then I see no reason why it should not tag it with Priority:emergency. >> >> [John Medland] Another Use Case (separate from callback to the end user who needs help) would be where one PSAP needs to pass incident details to a second PSAP where the second PSAP is needed to provide additional assistance. An example would be where first PSAP is the Police but second PSAP is the Fire Service needed to free people trapped in a motor accident. >> >> In the latter case, the call might not get the same treatment on the receiving end. In this case the callee has nothing to help it distinguish a justified use of Priority:emergency from an unjustified one. So it might not give the call any priority treatment. But I think that is fine. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: 15. toukokuuta 2012 18:19 >>> To: ecrit@ietf.org >>> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >>> >>> I'll repeat my earlier arguments. Maybe I can make them more explicit this time. I think we have sufficient mechanism already defined, if it is used appropriately. Specifically: >>> >>> - the UA, when placing an emergency call, can use a temp gruu. >>> Its possible to get as many temp gruus as you like, so the UA >>> can reserve one for this purpose. This doesn't require any >>> new capabilities in registrars. >>> >>> - when the UA receives a call addressed to a temp gruu that it >>> had previously used for an emergency call, it can give it >>> special treatment as an emergency callback. It can decide how >>> long after the emergency call to grant this special treatment >>> as a matter of policy. The special treatment can include dropping >>> existing calls, special alerting, etc. >>> >>> - the PSAP, when placing the emergency callback, can indicate that >>> *it* considers this call important using the Priority:emergency. >>> If appropriate it can also use other existing headers, such as >>> Resource-Priority. It call also use callerprefs to indicate that >>> it prefers the real UA and does not wish an automaton. >>> >>> - middleboxes in the path of the callback can choose to honor the >>> Priority:emergency, and use that to condition their behavior. >>> For instance, a home proxy could decide that an emergency call >>> to a temp gruu should not be diverted. (Though the fact that it is >>> to a gruu should typically bypass that anyway.) >>> >>> - abuses of Priority:emergency by callers can be dealt with by the >>> called UA, because it can reject such calls if not to a temp >>> gruu previously used for an emergency call. This can cause *some* >>> disruption, but only to the extent of handling an incoming INVITE >>> and rejecting it. If the frequency of that rises to a level where >>> it becomes a problem then it should be dealt with as a DOS attack. >>> >>> Thanks, >>> Paul >>> >>> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>>> Hi, >>>> >>>> Once again, I would like to see whether there is a way for us to >>>> move forward on the callback indicator issue. >>>> >>>> There are two requirements: >>>> >>>> 1.Indicate the callback >>>> >>>> 2.Be able to route the callback to the user that made the emergency >>>> call >>>> >>>> Regarding the indication, it has been suggested that the indicator >>>> value is per user, and is provided to the user upon registration. >>>> >>>> We also discussed whether the value could change over time, but the >>>> problem was that the emg call may be done using an old value, and >>>> the callback using a new value (because there was some time between >>>> the emg call and the callback, during which the user was given a new value). >>>> >>>> To avoid that, the registrar would always provide the same value to >>>> a given user. >>>> >>>> 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 Wed Jun 13 01:43: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 E3C6F21F869F for ; Wed, 13 Jun 2012 01:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.906 X-Spam-Level: X-Spam-Status: No, score=-5.906 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSP1nAbfKkgS for ; Wed, 13 Jun 2012 01:43:28 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C12B021F8693 for ; Wed, 13 Jun 2012 01:43:27 -0700 (PDT) X-AuditID: c1b4fb30-b7f606d0000002be-ed-4fd852ad158b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 55.02.00702.DA258DF4; Wed, 13 Jun 2012 10:43:26 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.62]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Wed, 13 Jun 2012 10:43:25 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 13 Jun 2012 10:43:25 +0200 Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac1I0iorzJgLXtYpSFWNLCpabxpv7QAaDYtz Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C47149A70@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> , <4FCCF882.6020906@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C8@ESESSCMS0356.eemea.ericsson.se> <4FCD19F4.9070704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1CAA6@ESESSCMS0356.eemea.ericsson.se>, <4FCE0BCF.7080709@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C47149A67@ESESSCMS0356.eemea.ericsson.se>, <4FD79945.5060803@alum.mit.edu> In-Reply-To: <4FD79945.5060803@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvre66oBv+Bqe2M1o0LnrKanHowVN2 ixUbDrA6MHv8ff+ByeNl/xxGjyVLfjIFMEdx2aSk5mSWpRbp2yVwZZzccIe9YIJMxdr7rxkb GO+LdTFyckgImEgc2f6QBcIWk7hwbz0biC0kcIpR4tO74C5GLiB7AaPE/TVLmLoYOTjYBCwk uv9pg5giAhoSk7aqgZjMAp4SO99Yg3SyCKhKNL7/xQpiCwtYSVx5eYwdxBYRsJZ4emMllG0k sXBvOxOIzSsQLrHt6HcWiE2fWCX+XLsLdg6ngI5E787lYA2MQKd9P7UGrIFZQFzi1pP5TBAn C0gs2XOeGcIWlXj5+B8rRL2oxJ329YwQ9ToSC3Z/YoOwtSWWLXzNDLFYUOLkzCcsExjFZiEZ OwtJyywkLbOQtCxgZFnFKJybmJmTXm6ul1qUmVxcnJ+nV5y6iREYSwe3/DbYwbjpvtghRmkO FiVxXj3V/f5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGJnnvDwSYWnzpHa3Nwe/9Z928Rub Wnw1NU4efr2k1oRr1z7tYw162rHWJzz2b13eWvLpfXz2/+3C4h5Xlh9kmp1r3h+hejau+cmr grw/+Xe+VZlLHPM9/F0q4H9DHz/j1YMybNeacjeYlRQ/33CmMDVkQWTvVBeZZ+cU9we+sLr+ +Kaf8D1dcSWW4oxEQy3mouJEAOPWNxdzAgAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 13 Jun 2012 08:43:29 -0000 Hi, >>>>>>>> A new RPH=3DSOS (versus SOL) that is honored based on a trust >>>>>>>> model/relationships >>>>>>> >>>>>>> I had originally noted that we could use a number of existing >>>>>>> indications. Resource-Priority would perhaps be good in environment= s >>>>>>> that do something with it. This would be complementary to the >>>>>>> Priority:emergency, which is an indication of how the caller >>>>>>> perceives the call. The Resource-Priority, when used, may be subjec= t >>>>>>> to other controls, and mostly impact intermediaries, rather than th= e callee. >>>>>> >>>>>> Well, as we've discussed before, we DO need an indicator which is us= ed by intermediaries to give special treatment to the callback. >>>>> >>>>> Well, I guess it depends on what sorts of treatment you are talking a= bout. If you are talking about resource prioritization, then the Resource-P= riority header is probably what you want. >>>>> >>>>> If you are talking about bypassing various sorts of treatment, such a= s call diversion, then I don't think Resource-Priority is the right thing. >>>>> Those are generally discretionary anyway. Honoring the caller's wishe= s, expressed via Priority and perhaps callerprefs, seems to make more sense= . In such cases, there is a question of whether to honor the caller's prefe= rences, or the callee's policies. It's >>>>> my personal opinion that if the caller says he only wants to talk to = a human, not an automaton, then one should honor that, and either let the h= uman's phone ring or else simply reject the call. And I'm suggesting that f= rom a provider perspective that >>>>> means passing the call to the UA and letting it decide. >>>> >>>> It's not only about bypassing diversion. Even if the call will reach t= he correct human, one may still want to bypass services etc in the network. >>> >>> I find it hard to have this discussion in the abstract. >>> Can we talk about the specific sorts of services you have in mind? I >>> suspect that different sorts of treatment may need to be addressed in >>> different ways. >> >> Any type of service (diversion is one example) that normally would be ap= plied to the called user. Typically, in IMS, the S-CSCF would not forward a= terminating callback requests to Application Servers providing such servic= es. > > "Any type of service" doesn't do it for me. > Maybe it would if I had a list of the services that are typically > offered. But I don't. At the moment, diversion and call barring are typical examples. But, there are also services which are typically not enabled during call se= tup, but for which application servers are still inserted in the call path,= in case users would enable the service later. E.g. services that include m= id-call network provided anouncements. In the callback case, you want to by= pass those application servers. >>> ISTM there is a fundamental issue here of whether it is expected that >>> intermediaries must understand the purpose of the incoming call to >>> decide how to handle it, or if the caller should simply indicate how he >>> would like it handled (or not handled). >> >> The intermediareis must understand the purpose of the incoming call. > > Well, if we use the Priority:emergency header, then we know the caller > asserts its an emergency call. Do you need to know more about the > purpose of than that? I think Priority:emergency would be good enough, but Keith's issues seems t= o be whether the semantics of Priority "allows" intermediaries to use it. Regards, Christer= From pkyzivat@alum.mit.edu Wed Jun 13 20:19:53 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 2BC2111E80F7 for ; Wed, 13 Jun 2012 20:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cScTN6JSXFVC for ; Wed, 13 Jun 2012 20:19:52 -0700 (PDT) Received: from qmta14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by ietfa.amsl.com (Postfix) with ESMTP id 78CEE11E8073 for ; Wed, 13 Jun 2012 20:19:52 -0700 (PDT) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta14.emeryville.ca.mail.comcast.net with comcast id N2t41j0011afHeLAE3KsDB; Thu, 14 Jun 2012 03:19:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([83.241.130.138]) by omta17.emeryville.ca.mail.comcast.net with comcast id N3KL1j00K2zJWM78d3KRq4; Thu, 14 Jun 2012 03:19:47 +0000 Message-ID: <4FD95837.9090207@alum.mit.edu> Date: Thu, 14 Jun 2012 05:19:19 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> , <4FCCF882.6020906@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C8@ESESSCMS0356.eemea.ericsson.se> <4FCD19F4.9070704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1CAA6@ESESSCMS0356.eemea.ericsson.se>, <4FCE0BCF.7080709@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C47149A67@ESESSCMS0356.eemea.ericsson.se>, <4FD79945.5060803@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C47149A70@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C47149A70@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 14 Jun 2012 03:19:53 -0000 On 6/13/12 10:43 AM, Christer Holmberg wrote: >>>> I find it hard to have this discussion in the abstract. >>>> Can we talk about the specific sorts of services you have in mind? I >>>> suspect that different sorts of treatment may need to be addressed in >>>> different ways. >>> >>> Any type of service (diversion is one example) that normally would be applied to the called user. Typically, in IMS, the S-CSCF would not forward a terminating callback requests to Application Servers providing such services. >> >> "Any type of service" doesn't do it for me. >> Maybe it would if I had a list of the services that are typically >> offered. But I don't. > > At the moment, diversion and call barring are typical examples. > > But, there are also services which are typically not enabled during call setup, but for which application servers are still inserted in the call path, in case users would enable the service later. E.g. services that include mid-call network provided anouncements. In the callback case, you want to bypass those application servers. I guess that's your business. I would think it to be relatively harmless to leave them in the path. But as I posted elsewhere, ISTM that this should probably be a per-service policy. Thanks, Paul >>>> ISTM there is a fundamental issue here of whether it is expected that >>>> intermediaries must understand the purpose of the incoming call to >>>> decide how to handle it, or if the caller should simply indicate how he >>>> would like it handled (or not handled). >>> >>> The intermediareis must understand the purpose of the incoming call. >> >> Well, if we use the Priority:emergency header, then we know the caller >> asserts its an emergency call. Do you need to know more about the >> purpose of than that? > > I think Priority:emergency would be good enough, but Keith's issues seems to be whether the semantics of Priority "allows" intermediaries to use it. > > Regards, > > Christer From christer.holmberg@ericsson.com Wed Jun 13 23:53:15 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 CFD7C21F8671 for ; Wed, 13 Jun 2012 23:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP1pJeEeizEQ for ; Wed, 13 Jun 2012 23:53:15 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id C191021F864A for ; Wed, 13 Jun 2012 23:53:14 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-d2-4fd98a598b54 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A1.56.11869.95A89DF4; Thu, 14 Jun 2012 08:53:13 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.62]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 14 Jun 2012 08:53:13 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Thu, 14 Jun 2012 08:50:37 +0200 Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac1J3JEG9y2uy7aYS/imul+szS/AiAAHPt9Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4740EAF6@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> , <4FCCF882.6020906@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C8@ESESSCMS0356.eemea.ericsson.se> <4FCD19F4.9070704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1CAA6@ESESSCMS0356.eemea.ericsson.se>, <4FCE0BCF.7080709@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C47149A67@ESESSCMS0356.eemea.ericsson.se>, <4FD79945.5060803@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C47149A70@ESESSCMS0356.eemea.ericsson.se> <4FD95837.9090207@alum.mit.edu> In-Reply-To: <4FD95837.9090207@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvrW5k101/g4cPLSwaFz1ltTj04Cm7 xYoNB1gdmD3+vv/A5PGyfw6jx5IlP5kCmKO4bFJSczLLUov07RK4MlZf2spaMJOnYs7NXrYG xkecXYycHBICJhItlz4zQdhiEhfurWfrYuTiEBI4xShx7ettJghnDqPEsYY3QA4HB5uAhUT3 P20QU0RAQ2LSVjUQk1nAU2LnG2uQMSwCqhJLpv1jA7GFBawkrrw8xg5iiwhYSzy9sRLKNpLY +OQsI4jNKxAuMW3OeWaITY/YJBpuHQRLcAroSBw9MgHMZgS67fupNWB3MguIS9x6Mh/qZgGJ JXtAmkFsUYmXj/+xQtSLStxpX88IUa8jsWD3JzYIW1ti2cLXzBCLBSVOznzCMoFRbBaSsbOQ tMxC0jILScsCRpZVjMK5iZk56eVGeqlFmcnFxfl5esWpmxiB0XRwy2/VHYx3zokcYpTmYFES 57XeusdfSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6NJssXC8uxnE6PcOaI/CC1XYfFxCxCU 26Ry7+YVzdes82bGLOg6dMVuDQsH87k3upZmsxK/mipP3LO7R/FPft0ku4P71P5/5u70eqGR Y+dveWduWfn3c2zpn+OOuu4+e0kodp6nt+VvjuQv004u9XEPcb2jkV+9eE/PTZXtQpyXVl3e s7Ws+oUSS3FGoqEWc1FxIgChssdddAIAAA== Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 14 Jun 2012 06:53:15 -0000 Hi, >>>>> I find it hard to have this discussion in the abstract. >>>>> Can we talk about the specific sorts of services you have in mind?=20 >>>>> I suspect that different sorts of treatment may need to be=20 >>>>> addressed in different ways. >>>> >>>> Any type of service (diversion is one example) that normally would be = applied to the called user. Typically, in IMS, the S-CSCF would not forward= a terminating callback requests to Application Servers providing such serv= ices. >>> >>> "Any type of service" doesn't do it for me. >>> Maybe it would if I had a list of the services that are typically=20 >>> offered. But I don't. >> >> At the moment, diversion and call barring are typical examples. >> >> But, there are also services which are typically not enabled during call= setup, but for which application servers are still inserted in the call pa= th, in case=20 >> users would enable the service later. E.g. services that include mid-cal= l network provided anouncements. In the callback case, you want to bypass t= hose application servers. > > I guess that's your business. I would think it to be relatively harmless = to leave them in the path. But as I posted elsewhere, ISTM that this should= probably be a per-service policy. Yes. And, that's the reason why the caller (the PSAP in this case) doesn't = tell how to handle the call. It simply includes the callback indicator, and= networks then handle the request (read: give special treatment) based on w= hatever policies. Regards, Christer From pkyzivat@alum.mit.edu Thu Jun 14 13:11: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 600B021F877A for ; Thu, 14 Jun 2012 13:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtkljq5JA8bX for ; Thu, 14 Jun 2012 13:11:23 -0700 (PDT) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by ietfa.amsl.com (Postfix) with ESMTP id 91BBB21F873A for ; Thu, 14 Jun 2012 13:11:23 -0700 (PDT) Received: from omta21.emeryville.ca.mail.comcast.net ([76.96.30.88]) by qmta09.emeryville.ca.mail.comcast.net with comcast id NKqk1j0011u4NiLA9LBPZs; Thu, 14 Jun 2012 20:11:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([192.36.80.8]) by omta21.emeryville.ca.mail.comcast.net with comcast id NLB91j0050AlhgG8hLBBam; Thu, 14 Jun 2012 20:11:21 +0000 Message-ID: <4FDA4557.4090005@alum.mit.edu> Date: Thu, 14 Jun 2012 22:11:03 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> , <4FCCF882.6020906@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C8@ESESSCMS0356.eemea.ericsson.se> <4FCD19F4.9070704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1CAA6@ESESSCMS0356.eemea.ericsson.se>, <4FCE0BCF.7080709@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C47149A67@ESESSCMS0356.eemea.ericsson.se>, <4FD79945.5060803@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C47149A70@ESESSCMS0356.eemea.ericsson.se> <4FD95837.9090207@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C4740EAF6@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4740EAF6@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 14 Jun 2012 20:11:24 -0000 On 6/14/12 8:50 AM, Christer Holmberg wrote: > Hi, > >>>>>> I find it hard to have this discussion in the abstract. >>>>>> Can we talk about the specific sorts of services you have in mind? >>>>>> I suspect that different sorts of treatment may need to be >>>>>> addressed in different ways. >>>>> >>>>> Any type of service (diversion is one example) that normally would be applied to the called user. Typically, in IMS, the S-CSCF would not forward a terminating callback requests to Application Servers providing such services. >>>> >>>> "Any type of service" doesn't do it for me. >>>> Maybe it would if I had a list of the services that are typically >>>> offered. But I don't. >>> >>> At the moment, diversion and call barring are typical examples. >>> >>> But, there are also services which are typically not enabled during call setup, but for which application servers are still inserted in the call path, in case >>> users would enable the service later. E.g. services that include mid-call network provided anouncements. In the callback case, you want to bypass those application servers. >> >> I guess that's your business. I would think it to be relatively harmless to leave them in the path. But as I posted elsewhere, ISTM that this should probably be a per-service policy. > > Yes. And, that's the reason why the caller (the PSAP in this case) doesn't tell how to handle the call. It simply includes the callback indicator, and networks then handle the request (read: give special treatment) based on whatever policies. Well, clearly a Priority:emergency header isn't a *callback* indicator. Its an indicator that the caller considers this an emergency call, whether or not its a callback. But its still reasonable to think that each service has a policy for what to do in that case. Thanks, Paul From christer.holmberg@ericsson.com Thu Jun 14 13:21:49 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 AE78521F8629 for ; Thu, 14 Jun 2012 13:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfsLJAZfeZgM for ; Thu, 14 Jun 2012 13:21:48 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B268F21F8623 for ; Thu, 14 Jun 2012 13:21:47 -0700 (PDT) X-AuditID: c1b4fb25-b7fbf6d000002e5d-c8-4fda47dab29a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FD.A2.11869.AD74ADF4; Thu, 14 Jun 2012 22:21:46 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.62]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 14 Jun 2012 22:21:46 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Thu, 14 Jun 2012 22:20:14 +0200 Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac1Kad+8cfnC8uBBSjq3qH4ZrrcdUQAATtxh Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C47149A78@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se>, <4FCCD4B1.5010103@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C7@ESESSCMS0356.eemea.ericsson.se> , <4FCCF882.6020906@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C457B13C8@ESESSCMS0356.eemea.ericsson.se> <4FCD19F4.9070704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1CAA6@ESESSCMS0356.eemea.ericsson.se>, <4FCE0BCF.7080709@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C47149A67@ESESSCMS0356.eemea.ericsson.se>, <4FD79945.5060803@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C47149A70@ESESSCMS0356.eemea.ericsson.se> <4FD95837.9090207@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C4740EAF6@ESESSCMS0356.eemea.ericsson.se>, <4FDA4557.4090005@alum.mit.edu> In-Reply-To: <4FDA4557.4090005@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvre4t91v+BncPqlk0LnrKanHowVN2 ixUbDrA6MHv8ff+ByeNl/xxGjyVLfjIFMEdx2aSk5mSWpRbp2yVwZfxbsJet4BpfxYuzTg2M T7m7GDk5JARMJPat+MkEYYtJXLi3nq2LkYtDSOAUo8Trzb8YQRJCAgsYJXauD+ti5OBgE7CQ 6P6nDWKKCGhITNqqBmIyC3hK7HxjDVLMIqAq8XvzUbBGYQEriSsvj7GD2CIC1hJPb6yEso0k nm3+DLaVVyBc4uGK4+wQiy6wSzRPUQQZySmgI/FtXghImBHosO+n1oCVMwuIS9x6Mh/qYAGJ JXvOM0PYohIvH/9jhagXlbjTvp4Rol5HYsHuT2wQtrbEsoWvmSHWCkqcnPmEZQKj2CwkY2ch aZmFpGUWkpYFjCyrGIVzEzNz0suN9FKLMpOLi/Pz9IpTNzECo+jglt+qOxjvnBM5xCjNwaIk zmu9dY+/kEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkaLxtTVwUXKky5amfiunLPS8qC6U8cv 1o6HiU8/pPXLXXPUX3Aj8bq3affXU3uZIjtMP+m94NbSmaHw+fUaJkbOXZaTzAyPzf96seJ/ 4TXfgInMYj+//Tsazne0i/2mcNcynsNt/1+37SyVOqb0ekNzSBBrrFukZUv9FafiNVG50fl3 FfMZpZVYijMSDbWYi4oTAT6kp6pwAgAA Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning 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, 14 Jun 2012 20:21:49 -0000 Hi, >>>>>>> I find it hard to have this discussion in the abstract. >>>>>>> Can we talk about the specific sorts of services you have in mind? >>>>>>> I suspect that different sorts of treatment may need to be >>>>>>> addressed in different ways. >>>>>> >>>>>> Any type of service (diversion is one example) that normally would b= e applied to the called user. Typically, in IMS, the S-CSCF would not forwa= rd a terminating callback requests to Application Servers providing such se= rvices. >>>>> >>>>> "Any type of service" doesn't do it for me. >>>>> Maybe it would if I had a list of the services that are typically >>>>> offered. But I don't. >>>> >>>> At the moment, diversion and call barring are typical examples. >>>> >>>> But, there are also services which are typically not enabled during ca= ll setup, but for which application servers are still inserted in the call = path, in case >>>> users would enable the service later. E.g. services that include mid-c= all network provided anouncements. In the callback case, you want to bypass= those application servers. >>> >>> I guess that's your business. I would think it to be relatively harmles= s to leave them in the path. But as I posted elsewhere, ISTM that this shou= ld probably be a per-service policy. >> >> Yes. And, that's the reason why the caller (the PSAP in this case) doesn= 't tell how to handle the call. It simply includes the callback indicator, = and networks then handle the request (read: give special treatment) based o= n whatever policies. > > Well, clearly a Priority:emergency header isn't a *callback* indicator. > Its an indicator that the caller considers this an emergency call, > whether or not its a callback. But its still reasonable to think that > each service has a policy for what to do in that case. Correct. Regards, Christer= From john.medland@bt.com Sat Jun 16 12:53: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 78EB121F8522 for ; Sat, 16 Jun 2012 12:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oriZ2JxPt4v4 for ; Sat, 16 Jun 2012 12:53:54 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 1748621F851A for ; Sat, 16 Jun 2012 12:53:54 -0700 (PDT) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.264.0; Sat, 16 Jun 2012 20:53:53 +0100 Received: from emv66-ukrd.domain1.systemhost.net ([169.254.1.211]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Sat, 16 Jun 2012 20:53:52 +0100 From: To: Date: Sat, 16 Jun 2012 20:53:50 +0100 Thread-Topic: [Ecrit] PSAP Callback - Yet Another Beginning Thread-Index: Ac1I06N1YYdFerP1QxagroZ4nFeIUwDJHO+A Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852C444A0E16@ESESSCMS0356.eemea.ericsson.se> <4FB273EB.2080802@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C45A1C695@ESESSCMS0356.eemea.ericsson.se> <4FCCD4B1.5010103@alum.mit.edu> <4FD4EEBE.7060206@alum.mit.edu> <4FD79BBD.8020408@alum.mit.edu> In-Reply-To: <4FD79BBD.8020408@alum.mit.edu> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Jun 2012 19:53:55 -0000 Paul - a few more clarifications inserted below. Best regards John -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 12 June 2012 20:43 To: Medland,JD,John,MLC12 R Cc: christer.holmberg@ericsson.com; ecrit@ietf.org Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning On 6/11/12 10:33 PM, john.medland@bt.com wrote: > Paul - I've tried to answer briefly below. Regards > > John > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 10 June 2012 20:00 > To: Medland,JD,John,MLC12 R > Cc: christer.holmberg@ericsson.com; ecrit@ietf.org > Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning > > On 6/6/12 12:37 PM, john.medland@bt.com wrote: >> Paul, Christer, >> >> >> 1 I inserted a use case below in Paul's email to hopefully assist with = the discussion about priority indicators. > > John - can you clarify your use case further? > You say the first psap (police) calls a 2nd psap (fire) for help on the c= all. > > Did you mean the call from police to fire is the one to be tagged as an e= mergency? > [John Medland] Yes that was the scenario I had in mind. OK. Then I guessed wrong. If this is the case you have in mind, then it hardly seems "special" at all= . How is it different from the police calling the fire department emergency= number because the police station is on fire?[John Medland]=20 [John Medland] Both cases are dealing with an emergency : I'm concerned to = make sure there's a way of indicating this to be so without making another = 911/112 call, which invokes other facilities that would not be appropriate = (like providing location of the Police PSAP rather than end caller)=20 > Or did you mean that subsequently the fire psap wants to call the origina= l user? If the latter, then I guess it is a judgement call whether this is = a callback or not. > [John Medland] I'd not considered this but it could (more rarely) also be= helpful. > > Also, this brings up some interesting issues. Suppose the user is still o= n the line with the police when the fire psap calls. What should happen? Sh= ould the user's phone hang up the call to police to answer the one from fir= e? Or reject the one from fire? Merge the calls? > [John Medland] Possible, but unlikely scenario, as Police would most like= ly tell Fire that they were still in contact with caller so Fire Service wo= uld not try. > > It sounds to me like it would be better for the police to treat this as a= consult, followed by a consultative transfer. If so, then there would be n= o callback at all. > [John Medland] Sorry, but not sure what's meant by a "consult"? May be = OK but also needs priority treatment (to indicate dealing with arranging an= emergency response). Well, this was based on a wrong guess by me about what you meant. I thought that was standard terminology. In a normal case that means you put one call on hold, and call somebody els= e for a "consultation" - to get info for your first call. Then you might de= cide to either: - transfer the original caller to the consultant, dropping yourself out of the call. - conference the caller, yourself, and the consultant together. But in the case of emergency calls I gather psap practices may require the = original answerer to stay in the call, which would forbid forwarding. And f= orwarding without assuring that the handoff had been successfully accomplis= hed would no doubt be forbidden. So establishing a conference might be the = first step, and then *maybe* the police could drop out once it was establis= hed that the fire dept had fully taken responsibility for the call. In any = case, none of this would require a callback. [John Medland] Agreed, and as you say, PSAPs do not put callers on hold, bu= t handoff in such a way that caller has reassurance of hearing what is happ= ening. Thanks, Paul > > Thanks, > Paul > >> 2 PSAP callback is certainly an important subject for PSAPs in the UK, = as callbacks are used to help manage emergency calls in an appreciable numb= er of cases (though I don't currently have any stats for % of occasions, wh= ich may in any case change when moving off TDM networks to IP networks.....= ...). >> >> >> Regards >> >> John >> >> John Medland | 999/112 Policy Manager| BT | Tel:+44 (0)1977 593408 | >> Email: john.medland@bt.com | >> >> >> >> >> -----Original Message----- >> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >> Behalf Of Paul Kyzivat >> Sent: 04 June 2012 16:31 >> To: Christer Holmberg >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >> >> On 6/4/12 9:20 AM, Christer Holmberg wrote: >>> Hi, >>> >>> Assuming we would use Priority as callback indicator, is the "emergency= " value sufficient, or would be need an explicit "callback" value? >>> >>> Could a PSAP use Priority:emergency for non-callback calls? >> >> I suppose these questions may deserve further discussion. >> >> IMO Priority:emergency is appropriate for the callback, assuming it=20 >> should be treated as an emergency. (OTOH, if the psap decides to call=20 >> back the next day just as a followup, to see if all is well, then=20 >> perhaps it isn't an emergency.) >> >> I don't understand what the use case might be, but if the psap felt a ne= ed to initiate a call that was not a callback to a prior emergency call, an= d it felt the call was indeed an emergency, then I see no reason why it sho= uld not tag it with Priority:emergency. >> >> [John Medland] Another Use Case (separate from callback to the end user = who needs help) would be where one PSAP needs to pass incident details to a= second PSAP where the second PSAP is needed to provide additional assistan= ce. An example would be where first PSAP is the Police but second PSAP is = the Fire Service needed to free people trapped in a motor accident. >> >> In the latter case, the call might not get the same treatment on the rec= eiving end. In this case the callee has nothing to help it distinguish a ju= stified use of Priority:emergency from an unjustified one. So it might not = give the call any priority treatment. But I think that is fine. >> >> Thanks, >> Paul >> >>> Regards, >>> >>> Christer >>> >>> -----Original Message----- >>> From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On=20 >>> Behalf Of Paul Kyzivat >>> Sent: 15. toukokuuta 2012 18:19 >>> To: ecrit@ietf.org >>> Subject: Re: [Ecrit] PSAP Callback - Yet Another Beginning >>> >>> I'll repeat my earlier arguments. Maybe I can make them more explicit t= his time. I think we have sufficient mechanism already defined, if it is us= ed appropriately. Specifically: >>> >>> - the UA, when placing an emergency call, can use a temp gruu. >>> Its possible to get as many temp gruus as you like, so the UA >>> can reserve one for this purpose. This doesn't require any >>> new capabilities in registrars. >>> >>> - when the UA receives a call addressed to a temp gruu that it >>> had previously used for an emergency call, it can give it >>> special treatment as an emergency callback. It can decide how >>> long after the emergency call to grant this special treatment >>> as a matter of policy. The special treatment can include dropping >>> existing calls, special alerting, etc. >>> >>> - the PSAP, when placing the emergency callback, can indicate that >>> *it* considers this call important using the Priority:emergency. >>> If appropriate it can also use other existing headers, such as >>> Resource-Priority. It call also use callerprefs to indicate that >>> it prefers the real UA and does not wish an automaton. >>> >>> - middleboxes in the path of the callback can choose to honor the >>> Priority:emergency, and use that to condition their behavior. >>> For instance, a home proxy could decide that an emergency call >>> to a temp gruu should not be diverted. (Though the fact that it i= s >>> to a gruu should typically bypass that anyway.) >>> >>> - abuses of Priority:emergency by callers can be dealt with by the >>> called UA, because it can reject such calls if not to a temp >>> gruu previously used for an emergency call. This can cause *some* >>> disruption, but only to the extent of handling an incoming INVITE >>> and rejecting it. If the frequency of that rises to a level where >>> it becomes a problem then it should be dealt with as a DOS attack= . >>> >>> Thanks, >>> Paul >>> >>> On 5/15/12 7:05 AM, Christer Holmberg wrote: >>>> Hi, >>>> >>>> Once again, I would like to see whether there is a way for us to=20 >>>> move forward on the callback indicator issue. >>>> >>>> There are two requirements: >>>> >>>> 1.Indicate the callback >>>> >>>> 2.Be able to route the callback to the user that made the emergency=20 >>>> call >>>> >>>> Regarding the indication, it has been suggested that the indicator=20 >>>> value is per user, and is provided to the user upon registration. >>>> >>>> We also discussed whether the value could change over time, but the=20 >>>> problem was that the emg call may be done using an old value, and=20 >>>> the callback using a new value (because there was some time between=20 >>>> the emg call and the callback, during which the user was given a new v= alue). >>>> >>>> To avoid that, the registrar would always provide the same value to=20 >>>> a given user. >>>> >>>> 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 Internet-Drafts@ietf.org Tue Jun 19 15:04: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 430A211E814F; Tue, 19 Jun 2012 15:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+IT++R93RjO; Tue, 19 Jun 2012 15:04:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58BE11E80D3; Tue, 19 Jun 2012 15:04:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.20 Message-ID: <20120619220426.23093.86978.idtracker@ietfa.amsl.com> Date: Tue, 19 Jun 2012 15:04:26 -0700 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-service-urn-policy-00.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: Tue, 19 Jun 2012 22:04:27 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Policy for defining new service-identifying lables Author(s) : A. Forte Filename : draft-ietf-ecrit-service-urn-policy Pages : 4 Date : June 19, 2012 In order to provide location-based services, descriptive terms for services need to be defined. This document updates the policy for defining new service-identifying labels. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-policy-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ecrit-service-urn-policy"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-06-19150425.I-D@ietf.org> --NextPart-- From forte@att.com Tue Jun 19 15:22: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 CCCCE11E80BF for ; Tue, 19 Jun 2012 15:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.541 X-Spam-Level: X-Spam-Status: No, score=-105.541 tagged_above=-999 required=5 tests=[AWL=1.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4g1Llo4j422 for ; Tue, 19 Jun 2012 15:22:13 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id CFD8011E8072 for ; Tue, 19 Jun 2012 15:22:12 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-10) over TLS secured channel with ESMTP id 49bf0ef4.0.2521630.00-477.6929936.nbfkord-smmo08.seg.att.com (envelope-from ); Tue, 19 Jun 2012 22:22:12 +0000 (UTC) X-MXL-Hash: 4fe0fb94348c938f-26b3a309e8e6ede54e924352167b25930f34e06d Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5JMMCZE030671 for ; Tue, 19 Jun 2012 18:22:12 -0400 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q5JMM9Q1030651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jun 2012 18:22:09 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor) for ; Tue, 19 Jun 2012 18:21:55 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q5JMLtcQ011444 for ; Tue, 19 Jun 2012 18:21:55 -0400 Received: from [151.109.8.174] (dn151-109-8-174.dhcpn.ugn.att.com [151.109.8.174]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q5JMLkX0011166 for ; Tue, 19 Jun 2012 18:21:47 -0400 User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Tue, 19 Jun 2012 18:21:48 -0400 From: "Andrea G. Forte" To: "ecrit@ietf.org Org" Message-ID: Thread-Topic: [Ecrit] I-D ACTION:draft-ietf-ecrit-service-urn-policy-00.txt In-Reply-To: <20120619220426.23093.86978.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: multipart/mixed; boundary="B_3422974910_16338892" X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=29ETTmVuT1UA:10 a=0PjafdH9H3sA:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a=zQ] X-AnalysisOut: [P7CpKOAAAA:8 a=48vgC7mUAAAA:8 a=TmULlHKY-d8pS6pP1rwA:9 a=C] X-AnalysisOut: [juIK1q_8ugA:10 a=lYt1auA75VYA:10 a=lZB815dzVvQA:10 a=wvesM] X-AnalysisOut: [vG2D_RMtBpVq0MA:9] Subject: [Ecrit] FW: I-D ACTION:draft-ietf-ecrit-service-urn-policy-00.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: Tue, 19 Jun 2012 22:22:14 -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_3422974910_16338892 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit The new draft has been submitted. Regards, -- Andrea G. Forte http://src.att.com/people/forte.html On 6/19/12 6:04 PM, "Internet-Drafts@ietf.org" wrote: >A new Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Emergency Context Resolution with >Internet Technologies Working Group of the IETF. > > Title : Policy for defining new service-identifying lables > Author(s) : A. Forte > Filename : draft-ietf-ecrit-service-urn-policy > Pages : 4 > Date : June 19, 2012 > > In order to provide location-based services, descriptive terms for > services need to be defined. This document updates the policy for > defining new service-identifying labels. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-policy-00 >.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit --B_3422974910_16338892 Content-type: message/external-body; name="draft-ietf-ecrit-service-urn-policy" Content-disposition: inline; filename="draft-ietf-ecrit-service-urn-policy" Content-transfer-encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluDUNvbnRlbnQtSUQ6IDwyMDEyLTA2LTE5MTUwNDI1 LkktREBpZXRmLm9yZz4NDQ== --B_3422974910_16338892--