Closed Bug 1007681 Opened 12 years ago Closed 11 years ago

[User Story] As a user I would like to be notified about the progress of a call that is attempted to be established

Categories

(Firefox OS Graveyard :: Gaia::Loop, defect, P1)

Product:
Firefox OS Graveyard
Component:
Gaia::Loop
Platform:
ARM
Gonk (Firefox OS)
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: oteo, Unassigned)

References

Details

(Whiteboard: [ucid:WebRTC28,2.0, ft:webrtc])

User Story

- When the server tries to call a Loop user, I want to receive feedback (visual or audible) about the progress of the call (i.e. that I am calling (dialling tone and "calling" message), that the other user is being notified of the call (ringback sound and “calling" message) and that the other user has accepted the call and the call is being connected (no sound is played and “connecting” message))

- During the establishment process I can cancel (sending a “cancel” terminate reason) the call before the callee answers or the call is terminated by any other reason.

- The following reasons may lead to an unsuccessful call establishment:
    - The other user is on a call (user busy): Callee sends a “busy” terminate reason (Message “Busy” is shown an “busy tone” is played)
    - The other user rejected my call. Callee sends a “reject” terminate reason (Message “Declined" is shown and a failed tone (need to be confirmed) is played.
    - The other user was unreachable (e.g. no connection at that time or a server timeout occur without alerting the user). Call does not reach alerting state or server sends a “connection-failure” terminate reason or callee sends a “media-fail” one. In any of these cases I will be notified that the other user can’t be reached and message "Unavailable" and Call failed tone will be played. User has also the opportunity to share a callback URL with him
    - The other user has been alerted but does not reply to the call. In this case the call finishes without any special treatment.

- A Call Log entry will be added to reflect this call in the Call Log History.
No description provided.
Blocks: loop_start_call
User Story: (updated)
User Story: (updated)
Summary: As a user I would like to be notified about the progress of a call that is attempted to be established → [User Story] As a user I would like to be notified about the progress of a call that is attempted to be established
Priority: -- → P1
The client should receive an event from the Loop server when the other party gets notified of an incoming call so that the client can start an audio notification.
Whiteboard: [ucid:WebRTC28,2.0, ft:webrtc]
Depends on: 1025872
Updated the US with the termination reasons in https://wiki.mozilla.org/Loop/Architecture/MVP#Termination_Reasons
User Story: (updated)
Depends on: 1057850
Depends on: 1050132
One question Rafa: in case device A starts a Loop call to device B, and when B is ringing device A cancels the call, should we show "Call ended" status on Device B call screen? I would say that it's not necessary, just only show a Loop missed call in the Device B Call Log but after checking how it's implemented in GSM calls I am seeing that "Call ended" status is shown too in similar scenario... so perhaps for consistency we should do the same, let me know what you think :) Thanks a lot!!
Flags: needinfo?(hello)
User Story: (updated)
User Story: (updated)
I would agree with you that it is not necessary, but I also believe that —at least for now— we should strive for consistency with GSM if possible, so let's add it.
Flags: needinfo?(hello)
User Story: (updated)
Rafa, could you have a look at the ACs in the User Story field to confirm that the strings and the content are correct? Besides, if we include the "answered-elsewhere" termination, when the call is answered in other device ¿which string should we show in the call screen?
Flags: needinfo?(hello)
> Could you have a look at the ACs in the User Story field to confirm > that the strings and the content are correct? I think the "connecting" phase should have the same sound as "dialling", until a connection actually exists (both parties receive each other's streams). Other than that, they look fine :) > Besides, if we include the "answered-elsewhere" termination, when the call > is answered in other device ¿which string should we show in the call screen? If the called is answered I don't think we should have any special strings anywhere, as both parties know what happened. We just have to make sure all devices stop ringing once the call is either picked up or rejected.
Flags: needinfo?(hello)
(In reply to Rafael Rebolleda from comment #6) > I think the "connecting" phase should have the same sound as "dialling", > until a connection actually exists (both parties receive each other's > streams). Other than that, they look fine :) ok, I think you mean that in connecting phase the sound played should be the "ringback" tone instead of the mute, does it right? > > > Besides, if we include the "answered-elsewhere" termination, when the call > > is answered in other device ¿which string should we show in the call screen? > > If the called is answered I don't think we should have any special strings > anywhere, as both parties know what happened. We just have to make sure all > devices stop ringing once the call is either picked up or rejected. Agree,and a missed call should be shown in the call log of the devices that have not answered the call. Thanks a lot!
Agreed with Rafa that in connecting status, ringback tone continues being played, updating the US according to it.
User Story: (updated)
User Story: (updated)
For the time being, in the "connecting" state, no sound will be played. Later we will check with Product team (depending on the device performance and set up time) if it makes sound including the ring back tone in that state or not.
User Story: (updated)
Depends on: 1067389
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.