Premature Disconnect (feedback from the meeting)

[Hannes Tschofenig]

Here is a copy-and-paste from the meeting minutes regarding the
draft-rosen-ecrit-premature-disconnect-rqmts-00 based on the slide
presentation:
http://www3.ietf.org/proceedings/08jul/slides/ecrit-0.ppt

--------------------------------------------------------------

Open issue was raised surrounding UA
unable to send BYE in the draft.

There are 2 problems
Premature Disconnect and Abandoned Call

Problem 1: Premature Disconnect
- Caller hangs up before call-taker wants to terminate the call.

Explained Current Implementaiton of CPH(Called Party Hold):
 >> Refer to Slide 8

Baseline Requirement is for PSAP to rapidly re-establish
the connection to the user.

In jurisdiction where there is no CPH and PSAP calls back the originator,
is CPH and call-back perceived different?(Ted)

Yes it's different. Real problem is you can get Voicemail.. Instead of
the originator.
Originator can also make a call, with CPH, originator can't make another
call. (Brian)

Call-back is not a replacement of CPH.

There is nothing that can be done when the device is mechanically
disconnected. (Henning)

Current text on the Phone BCP is not adequate. (Brian)
There is a negotiation mechanism necessary and that's a requirement. (Ted)

Requirements:
 >> refer to Slide 9
PD-5
1. Problem when phone has multiple line presence, risk is
if user is subscribed to multiple providers and phone is disabled to make
a call because it's bricked by CPH even though the call failed due to
external cause such as network trouble, user can't attempt to make another
emergency call although it has a capability to do so. (Henning)

 >> Needs ML discussion.

2. May be a concern if there is a massive emergency and there are overload
happening.. (Problem with the network). (Andrew)
- There is a deployment experience around this. (Brian)
- Don't have experience of doing this in network. (Ted)
- We can still learn from what they have done. (Brian)


PD-6
- Sounds like it's asking spy capability (listening in even when the
phone is hanged up).
- No requirement is saying there needs to be an active media path
available for
when user picks up the phone.(brian)
- This is very difficult to resolve on the IP network (NAT binding etc.)
(ted)

- Will feel comfortable if we can add PD-8 to add text to not send media,
while its in premature disconnect state. (Henning)

Suggestion: Add another requirement which explicitly prevents any media to
go through the media path retained when CPH is enabled.

- PD-1 may be a concern >> The probability of DoS is differnt in VoIP.(Ted)
 >> Causing many CPH so resources on PSAP is non-existent to make
any out-going call impossible.

- PD-5/PD-7 are almost impossible in Wireless > resource
preservation/release . (Hannu).

- BYE control from the protocol is not good enough, especially with
cellular,
out of boundry problem etc will not prevent..

- We need a cognitive VoIP requirements. Needs to be 2 ways. (Henning)

- Agree, need to make the text to make the requirements more reasonable
in VoIP. (Henning)

- Some solution in the area of using modern UI rather than network
oriented solution
may be much better/far more effective. (Henning)

- Concern because there is no way to know what the calling device is,
the reason of
the disconnect can't be known (Run out of battery, broken wire etc.).

- Why are we adding another 14months to phone-bcp/frameworks.

Problem 2: Abandoned Call
 >> Refer to slide 11:
- Caller hangs up before the call-taker picks up the phone.

- Until call-taker picks up the phone. It's not a CPH.(Marc)
- Requirements is that PSAP wants to control abandoned call. (Brian)

- How do they define abandoned call? (Ted)
 > They take a log. (Brian)

Requirements
 >> Refer to slide 12:
- UI can resolve this.. Don't think network needs to be involved. (Ted)

Documentation/Process debate
How can we finish BCP/Framework (Hannes)?
- They don't want to lose the capabilities.(Brian)
- Can't even agree on the requirements right now. (Henning)
- There are two approach discussed and both has its consequences,
but two proposals are in polar opposite and it will not be a trivial effort
to come to any consensus. It will hinder the progress of these
documents. (Henning)

- Propose to separate the document.. (Hannes)

- There is a new protocol requirements necessary because of
negotiation.(Ted)

- Propose to define a new draft, which will update the phone-bcp. Remove
the
text form the phone-bcp.(Ted)

Conclusion: Continue the discussion on the list.

-----------------------------------------------------------------------------
------Below is another copy of the meeting minutes from the 2nd scribe------
-----------------------------------------------------------------------------

One open issue: Calling UA should not send BYE.
Need requirements first before deciding on course of implementation.
Doc is available on this issue.
Requirment is to rapidly reestablish connection to user.
Call Party Hold is the mechanism used in some jurisdictions.

Steve Norris: Requirement is to attempt to reestablish call.
Brian: Everything within reason

Ted Hardy: Clarification about the PSAP being the party not willing to release the call.
Brian: Yes.
Ted: Were not required, does the PSAP calling the party back serve the same NENA function.
Brian: Does not serve same function because of time.  And you can get voicemail. And user can start another call.
Ted: Where this was given up, it was replaced with nothing?
Brian: yes.

Henning: Difference between POTS mechanical switch and more advanced digital systems.
Brian: You are talking about implementaiton, not requirments
Henning: PSAP could still have microphone engaged.
Brian: They aren't asking for spy capabilities.
Henning: What happens on both sides when BYE is sent to PSAP.
Brian: That is implementation, not requirements.

Ted: This is a behavior that may need negotiation.
Brian: Yes.

Stu Goldman: This capablity disappeared with SS7, but that calling number which gave PSAP ability to reestablish.
Marc: That happened with E911, not SS7.
Brian: PSAPs don't consider that to be true.

Brian - going over NENA requirements in slides

Ted: Call not established?
Brian: Different.

Brian - continues with NENA requirements from slides

Henning: Advanced phones have multi line pressence.  PD5 says that none should be able to place a call.
Brian:  Probably true.
Henning: Could cause problems with failures not being able to talke to PSAPs.

Martin: Jabber room wants to know about slides.
Brain: yes, we know.  network problems

Brian - going back to PD7 requirement

Steve: PD5 is concerning.  You have disconnected and this can cause more problems,
Brain: requires list discussion

Ted: PD6?  You told Henning not spy capability.  But all media flows seems to say that.
Brian: That is not what it is suppose to do.
Ted: What about NAT bindins.
Brian: You are into solutions.
Ted: The network as deployed now makes it difficult to not leak info.
Brain: We can have requirements on the phone that might solve this.

Henning: More comfortable about PD8 must not send unintentional signals.
Brian: sure

Andrew Allen: Concern with PD5.  Mass emergency situation, where getting disconnected to PSAP due to overload, if you cannot call anybody else, then this causes problems.
Brian: We can deployment experience with this issue, we don't have to talk about theoritcal situations of overload.

Henning: Something about shooting himself with a large calibre weapon.

Ted: You don't have pracitcal experience because everything so far has been circumspect with VoIP.  circuit switch vs. voip is not the same thing.
Brian: But we can ask about their experiences.

Hannes: PD6 Not transmit audio any more?
Brian: you are talking about solutions, not requirements

Ted: PD2 - thinking about congestive load on the network.  thinking about PSAP DoS attack.  The BYE state may never reach the PSAP, so how does that affect this.
Brian: That is a legitmate concern.  But this is not all or nothing.
Ted: But circuit switch with DoS is different for VoIP.  This could result in that they don't reach anybody, not just the PSAP.

Andrew A.: In VoIP it is very easy to accept the new incoming stream from teh PSAP.
Brain: Solution again, not requirement.
microphone scuffle on the underlying requirements

Hannu: Even if we don't like thise requirements, we will see this stuff from various places and different nations. Valid concern about premature disconnection, we should keep in mind that cellular the user can always say bye but removing the battery.  Then, combining PD5 & PD7 lead to a dangerous situation in cell environments.

Henning: In some circumstances, there may not be any need for solutions.  We are forcing mechanisms which can be placed on the user interfaces.
Brian:  Feature negotiaiton.
Henning: Better to consider doing this all on the user interfaces.
Brian:  But these are two endpoints.
Henning: I'm talking about protocols.

Keith: Which resource are we protecting.  Handset, user, PSAP?

Steve: PSAP could cut in to streams and determine information just from listening and determine that way.

James P.: We don't know the type of endpoint the caller is calling from.  We will never be able to solve this, because of the multiple environments.  This will just delay these 2 documents for 18 months.
Brain: I don't think it is that bad.

Brain- goes on with slides on abandoned call

Ted: Does this happen today?  How do they know about an abandoned call?
Brian: it gets logged.

Brian - goes back to slides on abandoned call requirements

Marc: When is a called abandoned, SIP wise?
Brian: This wording could be improved, because VoIP changes this a bit.

Keith: Resource reservation with AC1, continue it?
Brian: yes.

Ted: Underlying requirement is that the emergency system determine that the use really intended to abandon the call.  Could al be done on the UI?

Hannes: Stops the discussion, and asks would should we do about these requirements?  Would like to finissh our documents today.  How do we do that?
Brian: People want to do this today.
Henning: The notion that these documents will be correct is hard to believe, and we will revise them.
Brian:  Not trying to lose capabilities to do this now, since it is already deployed.
Hannes: But implementation experience later on will help.
Brian: But we know now this will be lost functionality.
Henning: We cannot agree on requirements done in short amount of time.  Unless you want to delay by 6 months, we need to find another way forward.
Hannes: Remove MUST NOT send BYE, and then we can deal with this like unauthenticated emergency calls.
Brian: But you are taking a feature away.
James P: Not taking a feature away, because vendors can add above and beyond.
Brian: But what about interoperability.
Brian: We are in a new world and therefore we should not deploy this feature is not a good reason.
Brian: This is straightforward, and I think we could do this.
Hannes: Would phone-bcp reference this stuff.
Brian: yes.
Hannes: I don't get the impression that this would work.
Ted: There is new protocol negotiation mechanism, which is not soemthing we have done in the past.  What about wording to have PSAP will always send the BYE, and the phones know to rely on the PSAP.
Brian: Undeployable.
Ted: You can deploy what you have either.  You can do what I just said, though.
Ted: Move to a new document, have new doc point to phone bcp.
Hannes: Sending proposal to the list.



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