[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] HUM regarding draft-rosen-ecrit-premature-disconnect-rqmts
I am NOT OK with turning this document into a WG document.
In general I believe the requirements are written too much round an existing PSTN capability, rather than getting to the root of any real requirement. It is also clear that there are jurisdictions that do not require this capability and that needs to be reflected in the document.
More specifically.
Section 1.1 and section 1.2: Both these sections imply that the PSTN solution is the solution in SIP, rather than providing an overal discussion of what the real objective is. I would understand that the real need of 1.1 is in ensuring that the media path between the caller and the call taker is reinstated if the caller takes any action to remove it (or indeed not removed at all).
At this point (section 1) there should also be a discussion of impacts of the user disconnecting just because they have made a mistake, and having realised that mistake - cleared down. There also needs to be a discussion of the phenomenum of certain parts of the world where they use the emergency call number to test the phone is working without a valid SIM or UICC.
PD-1: Not written as a requirement. User has essentially disabled the user interface of the UA - that cannot be prevented. PD-4 is about trying to get the user to reenable the user interface. Is the requirement that the existing media path must be retained between the UA and call taker, or that a media path must be provided is the user interface is reenabled?
PD-2: This is essentially two requirements. One of the user disabling the user interface. One of reenabling.
PD-5: This requirement is inadequately specified. The first and second sentences are contradictory. We don't know what the real requirement is as a result of the second sentence being there. If the user has more than one UA, what happens on the second UA. If the user is prepared to answer a call on the second UA, then why shouldn't the emergency call exist there?
Note that release 9 of 3GPP is looking at the ability to split the media of a single call between different UAs or a UA with two access technology interfaces so the text of all the requirements needs to encompass this idea as well.
PD-6: I like the idea of "converse roughly"! Typo "initialting".
PD-7: PD-7 is currently specified as the call taker requirement. Needs an additional requirement from the caller perspective, i.e. that in jurisdictions where the mechanism is not required, that the caller can clear the call normally with no impact. More importantly, this is a function of the jurisdiction, and as UAs can roam between jurisdictions, this cannot be prebuilt into the phone.
AC-1: There are several points in the sequence here which could be meant, and it is not clear which. For example, if the user has typed 911 into his user interface, but gets murdered by an assailant before hitting the send key, should an emergency call be made and completed?
AC-2: What is the real requirement here. Appears to be a caller requirement.
AC-3: Again the requirement is missing here. It would appear that the real requirement is that disconnect in not impacted in jurisdictions where the requirement is missing.
regards
Keith
> -----Original Message-----
> From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
> On Behalf Of Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Wednesday, December 31, 2008 9:51 AM
> To: ECRIT
> Subject: [Ecrit] HUM regarding
> draft-rosen-ecrit-premature-disconnect-rqmts
>
> Hi all,
>
> We had a fair amount of discussions regarding this item and,
> as mentioned in my status update, we would like to resolve
> the deadlock we currently have.
>
> We would like to get some feedback from the group.
>
> Are you OK with turning draft-rosen-ecrit-premature-disconnect-rqmts
> into a working group item (after rechartering) (under the
> assumption that the editor of the document is changed once
> the document is a WG item)?
>
> Deadline: 19. Jan. 2009
>
> Ciao
> Hannes & Marc
>
> _______________________________________________
> Ecrit mailing list
> Ecrit at ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit
>
_______________________________________________
Ecrit mailing list
Ecrit at ietf.org
https://www.ietf.org/mailman/listinfo/ecrit