Re: [Ecrit] review draft-gellens-ecrit-ecall-03.txt
Randall Gellens <randy@qti.qualcomm.com> Fri, 04 July 2014 05:06 UTC
Return-Path: <randy@qti.qualcomm.com>
X-Original-To: ecrit@ietfa.amsl.com
Delivered-To: ecrit@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724751B2BE1 for <ecrit@ietfa.amsl.com>; Thu, 3 Jul 2014 22:06:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.228
X-Spam-Level:
X-Spam-Status: No, score=-4.228 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkjOn_kIx0gU for <ecrit@ietfa.amsl.com>; Thu, 3 Jul 2014 22:06:49 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCD6C1B2BDB for <ecrit@ietf.org>; Thu, 3 Jul 2014 22:06:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1404450409; x=1435986409; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=pW6gcaRnK4rM4orR8dHUNttL5ZnsXLnNT/NHw+zwGwM=; b=NtHZHTEBp2gIIXxU1mfk2e7ZRrSqOYoHSpIlp9gnSDF5pO5fCPXN0sU+ Bo8/kydkrUH7mXgRUOnaz4tKkUabQb77lIHFF8BMAzEYbbxeM0cisTn7U xp4ATmZdB/7lCaqbbGKCX6LuBxoWsJRB3YX3vs7v5qBHfUkyEPsfRXXhm g=;
X-IronPort-AV: E=McAfee;i="5600,1067,7488"; a="47845015"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine01.qualcomm.com with ESMTP; 03 Jul 2014 22:06:28 -0700
X-IronPort-AV: E=Sophos;i="5.01,598,1400050800"; d="scan'208,217";a="706966308"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 03 Jul 2014 22:06:27 -0700
Received: from [99.111.97.136] (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.181.6; Thu, 3 Jul 2014 22:06:27 -0700
Message-ID: <p06240608cfda55f504db@[99.111.97.136]>
In-Reply-To: <058CE00BD4D6B94FAD033A2439EA1E4B01E1D8B92368@HE113667.emea1.cds.t-int ernal.com>
References: <058CE00BD4D6B94FAD033A2439EA1E4B01E1D8B92368@HE113667.emea1.cds.t-int ernal.com>
X-Mailer: Eudora for Mac OS X
Date: Thu, 03 Jul 2014 22:06:08 -0700
To: R.Jesske@telekom.de
From: Randall Gellens <randy@qti.qualcomm.com>
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: [172.30.39.5]
Archived-At: http://mailarchive.ietf.org/arch/msg/ecrit/nX51ryEWbPV4Z1YGF_grPpv0P3o
Cc: ecrit@ietf.org
Subject: Re: [Ecrit] review draft-gellens-ecrit-ecall-03.txt
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <ecrit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ecrit/>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Jul 2014 05:06:52 -0000
Dear all,
as discussed at the last IETF I have reviewed draft-gellens-ecrit-ecall-03.txt.
Here are my comments:
General:
1. ETSI has finalized the Technical Report on eCall and proposes solutions. Question is if it would be worth to mention onr reference it. The report is under http://webapp.etsi.org/ewp/copy_file.asp?wki_id=39297" rel="nofollow">http://webapp.etsi.org/ewp/copy_file.asp?wki_id=39297 downloadable.
2. I will point in some parts of the detailed review to backwards compatibility issues. So we have now implemented a eCall solution for our GSM. So this is an invest done. And PSAP invests are seen as a long term invest. These will be used for a long time so a SIP/IMS/NGN solution is needed where we can built new PSAP understanding the NG-eCall but also have the possibility to route the call towards the old" PSAP getting the inband information type eCall. But also the case will appear where we have still the old style end device which have to be interworked towards the new PSAP style.
I completely agree that migration/co-existence (behavior during the transition period when the UE, network, and PSAP may each support or not support NG) is extremely important. I think the issue is outside the current scope of the draft, which is limited to describing how eCall is handled in an NG environment.
Question is how this will be done? My opinion is that each PSAP has to understand the in-band information.
Detailed comments & questions:
1. Section 3 last paragraph:
...
An eCall
flag in the call setup marks the call as an eCall, and further
indicates if the call was automatically or manually triggered.
...
3GPP has more flags that only automatic and manual. (we have discussed this in Berlin)
the proposal is to add an sentence like:
"Note that 3GPP TS22.101 allows to combine the automatic and manual triggered ecall with the type of emergency guard like police or fire force. This is also uses in some countries."
3GPP describes the requirements in TS 22.101 as follows
Possible values in signalling:
o Police
o Ambulance
o Fire Brigade
o Marine Guard
o Mountain Rescue
o Manually Initiated eCall
o Automatically Initiated eCall
And the bind requirement:
It shall be possible to tie any emergency call number to any single
emergency call type or to any combination of emergency call types.
Editor's Note: [EMC1, CR#4068] How to fulfil the requirement in 3GPP TS 22.101 [1A] that it shall be possible to tie any emergency call number to any combination of emergency call types is FFS.
2. Section 3.
Also it would be worth to mention that backward compatibility is an requirement since we have already millions of cars with GSM Chips which will be in future interworked with SIP/IMS networks.
3.Section 4.
one requirement is the backwards compatibility. Since mobile networks will not have LTE coverage all over and old" ecall solutions will be interwokked to IMS there is the need when to have a backwards compatible solution. (i.e. Inband communication must be traversed to PSAP understanding in band and/or the PSAP is able to understand in- and out-band information.
I think this requirement is out of scope of the document.
4. Section 6. 1st Paragraph :
In circuit-switched eCall, the IVS places a special form of a 112
emergency call which carries the eCall flag (indicating that the call
is an eCall and also if the call was manually or automatically
triggered)...
As mentioned above there are more possible indications within the eCall Flag"
5. Section 6 2nd Paragraph: Perhaps mention a option to identify also inband information when available. Or note that inband information then should be routed towards an backwards compatible PSAP.
6. Section 6. last Paragraph: ...urn:service:sos.ecall.automatic and urn:service:sos.ecall.manual" >From the discussion we had in the past (i.e http://tools.ietf.org/html/draft-jesske-ecrit-ecall-urn-extension-01" rel="nofollow">http://tools.ietf.org/html/draft-jesske-ecrit-ecall-urn-extension-01 in Berlin) I had the understanding that also the extension of the urn:service:sos.ecall.automatic is still to long. So that only urn:service:sos.ecall would be more ort less acaptable. And we need an further extension to identity the additional information for routing.
7. Section 7. ... The routing rules for eCalls are likely to differ from those of other
emergency calls because eCalls are special types of emergency calls
(with implications for the types of response required) and need to be
handled by specially designated PSAPs.
What is meant by with implications for the types of response required" I do have slide problems to understand. Is this the fact that there could be diffrent responses like a call back or SMS back?
8. Section 7.1 mentions a interworking new to old. Is there also the possibility to interwork old to new? Would there be also an Section 7.2, 7.3 for other networks which are not EENA based?
9. Section 9. Will the same mechanism used or is this one out of a several possibilities? Is this mechanism such as open that each PSAP-operator can define it's own set? Or is it more seen as set to be aligned within RFC's?
10. Section 10. It would be worth if preconditions and the reliability of provisional responses will have a effect of the solution or if they are needed? This question reflects the issue that in many mobile IMS networks such mechanisms will be used.
11. A IVS provided location could be also manipulated. Independent on the trustworthiness. I think this should be mentioned explicitly. Question is what can provide security on such location. Perhaps a hint would we nice to be mentioned or to mandate the draft trustwothy-location more as an requirement.
12. Section 12. As commented above I would propose an additional URN parameter or an other SIP extension to point to the possible indications appearing within a eCall. Such a indication needs to be considered when routing towards the PSAP.
13. Within 3GPP we have the additional indications as mentioned above
From my (operators) point of view the most important points needed to be discussed are backwards compatible solution and the format of the URN and additional indication for PSAP routeing purposes.
My recommendation is also that we can start the work and push it towards work item within ecrit.
Thank you and Best Regards
Roland
Mit freundlichen Grüßen; With Best Regards
Roland Jesske
Deutsche Telekom Technik GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 58-12766 (Tel.)
+49 6151 58-13395 (Fax)
+49 171 8618-445 (Mobil)
http://www.telekom.com" rel="nofollow">http://www.telekom.com
Erleben, was verbindet.
Deutsche Telekom Technik GmbH
Aufsichtsrat: Dr. Thomas Knoll (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Carsten Müller
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262
Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--
Opinions are personal; facts are suspect; I speak for myself only
I have the simplest tastes. I am always satisfied with the best.
--Oscar Wilde
- [Ecrit] review draft-gellens-ecrit-ecall-03.txt R.Jesske
- Re: [Ecrit] review draft-gellens-ecrit-ecall-03.t… Randall Gellens