Subject: [Ecrit] Let's make some decisions regarding draft-rosen-ecrit-premature-disconnect-rqmts-00

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Aug 2008 18:29:26 +0300

Hi all,

Brian has kindly captured requirements about handling abandoned calls 
and premature disconnects in emergency calls in the following document:
http://tools.ietf.org/id/draft-rosen-ecrit-premature-disconnect-rqmts-00.txt
The document essentially summarizes discussions that took place in the 
NENA i2.5 group. Thanks for the participants of that group for their input.

We had a fairly heated discussion at the IETF#72 ECRIT meeting. 
Unfortunately, we were not able to come to a conclusion during the 
meeting. Marc and I had to postpone the discussion to the list and here 
we are.

It would be good to hear your opinion about this issue so that WE CAN 
FINALLY FINISH the phone BCP & the framework drafts.

Ciao
Hannes

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 18 Aug 2008 17:38:53 +0200

There were a number of comments made in the meeting which I understood
would result in an update.

Is that available?

For example, I cannot judge the applicability of some of the
requirements without knowing whether "caller" refers to the caller as in
the human user or in the device belonging to that user.

Keith 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Hannes Tschofenig
> Sent: Monday, August 18, 2008 4:29 PM
> To: 'ECRIT'
> Subject: [Ecrit] Let's make some decisions 
> regardingdraft-rosen-ecrit-premature-disconnect-rqmts-00
> 
> Hi all,
> 
> Brian has kindly captured requirements about handling 
> abandoned calls and premature disconnects in emergency calls 
> in the following document:
> The document essentially summarizes discussions that took 
> place in the NENA i2.5 group. Thanks for the participants of 
> that group for their input.
> 
> Unfortunately, we were not able to come to a conclusion 
> during the meeting. Marc and I had to postpone the discussion 
> to the list and here we are.
> 
> It would be good to hear your opinion about this issue so 
> that WE CAN FINALLY FINISH the phone BCP & the framework drafts.
> 
> Ciao
> Hannes
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 18 Aug 2008 18:41:32 +0300

Hi Keith,

yep. These comments are available. I have just sent the meeting minutes 
to the list. This time even "unmodified"

Ciao
Hannes

---

From: "Hearty, John" <[email-masked]>
Date: Mon, 18 Aug 2008 16:06:27 -0600

Here are some thoughts on some of the issues raised:

1. Concern PD-5 will brick the phone.  Can we point to the session timer text in phonebcp or some new timer that returns the UA to normal operation (allowed to make calls) after it expires?  Can the requirement be relaxed for multi-line phones so it only applies to the line used for emergency call?

2. PD-6 privacy concerns over sending media.  I believe the intention of the requirement is to help facilitate rapid re-establishment of media as required by PD-1.  From a user's perspective I do not believe anyone had a need for media to continue flowing while in the premature disconnect state.  The requirement as written may be delving a bit into solution space, knowing about issues like NAT bindings and SBCs that would release resources when no media is flowing.  Perhaps the requirement should be deleted, and talk about keepalives etc. in a solutions document, or at least modify requirement to mute mic or otherwise encode nothing into RTP sent.

3. Concern over holding up phonebcp for CPH.  Is there consensus to do this?  Should current text on BYE simply be deleted, retained or modified in anticipation of CPH feature and issues it is bringing to light?  Perhaps some preliminary discussion on CPH would be needed to answer this question.

        a. If BYE text deleted, either end can terminate call until CPH feature defined.  Is this OK?  I cannot think of any problems this would cause defining the CPH feature later.

        b. If BYE text is retained, it will always be up to the PSAP to disconnect the call.  Can we rely on this?  It appears the policy for the length of time PSAPs in various jurisdictions wait will vary.

        c. Do we need to modify BYE text for realities like allowing it to be sent for example when device battery is critically low or a wireless device is leaving a coverage area?  Current phonebcp BYE text is silent on allowing calls to be made by device (PD-5).  Was this assumed?  Is it OK for UAs to make new calls?  Multi-line UAs?  Is consideration of any of the other CPH requirements critical when deciding what to do with current BYE text if we update phonebcp later for CPH?

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Monday, August 18, 2008 9:42 AM
To: DRAGE, Keith (Keith)
Cc: ECRIT
Subject: Re: [Ecrit] Let's make some decisions regardingdraft-rosen-ecrit-premature-disconnect-rqmts-00

Hi Keith,

Ciao
Hannes