Concurrent voice and text (from clause 13.4.3 in TR 103 708)

added RTT label

marked this issue as related to #56 (closed)

changed the description

The normative part of the clause is:

Where ICT provides functionality that allows two-way voice communication, and ICT provides RTT,
the ICT shall allow concurrent voice and text through a single user connection.

is in fact two requirements and should maybe be split.

It is "allow concurrent voice and text"

And "through a single user connection"

The "through a single user connection" has historical reasons and may not be needed anymore, or be changed to a separate requirement, with something about "the user actions on a session shall by default act on all media included or wanted in a communication."

Yeah, the concept of "connection" is a legacy idea that has unfortunate possible mis-understandings. For example, since _every _voice call has the potential to _add _RTT later, it could be implied that every voice gateway needs to have it's own RTT bridge, which then implies an expensive retrofit of whole networks. In practice, it's probably far more efficient to route RTT through dedicated bridges even if added to a voice call that follows a different path. It doesn't affect the end-to-end user experience so long as the synchronisation (which is a protocol issue, not a connection one) is working correctly.

this one might be the toughest one for today -- suggest we do last.

but connection is both a problem (due to misunderstanding) and and a very important part. So we can't leave it -- and we can't drop it.

Why important: Several companies in the past have suggested that it not have to be a single connection. that it could be that a person makes a voice connection and then has to make a second 'call' or connection to add the RTT. this obviously won't work. How would you transfer the call? and emergency call?

But things are not always "calls' in the old sense -- so 'calls' was changed to connection. But now that gets confused with channel.

Let me take a stab at a solution to both - though it may need some wordsmithing.

=================================================================== Where ICT provides a means for bidirectional voice communication and for users to communicate by RTT, it shall allow concurrent voice and text through a single user-connection act.

Note: It is important that bidirectional communication with concurrent voice and text be as easy to initiate, answer, and transfer as bidirectional voice only.

It can certainly get complicated.

If a “normal” voice call gets initiated and routed through traditional gateways to the destination, then one party decides to add RTT to the call, the existing intervening gateways might not be RTT-capable. So that raises the question of whether the call has to be re-routed through different gateways (which always involves some risk of a call drop, or at least an interruption), or whether an additional RTT connection can be added to the original call via a different route (with synchronisation provided at the end points).

I don’t think we want to use any language that precludes either of these approaches (or possibly others), since that would be going beyond mere requirements and into dictating implementation/architecture choices. Especially, choices may be made differently depending on the underlying architecture (e.g. mobile vs Internet/web).

The discussion seem to focus on the added words about the organisation of the connection. The initially important part is the concurrent voice and RTT. That sounds obvious today, and it was required because of the awkward tradition from the majority of the textphones, where you needed to stop voice communication during a call when you wanted to communicate in text.

I think that part is still worth mentioning, but separately from the operation to make the media establishment.

So, making two requirements of it, I propose

6.2.1.x Where ICT provides functionality that allows bidirectional voice communication, and ICT provides RTT,
the ICT shall allow concurrent voice and text.

6.2.1.y Where ICT provides functionality that allows bidirectional voice communication, and ICT provides RTT, the ICT shall allow single user actions to act on all media during establishment, supplementary services, multiparty actions and disconnections.

I am not sure about if the notes are important.

+1 to Gunnar's suggestion. It clears up the "single connection" problem which has always been awkward and easy to misunderstand. (PS in the past there have also been suggestions that the text part of the call be done separately from the voice. E.g make a voice call and a separate RTT call if you want to use both - which is why the "on a single call" came from that evolved to "with a single connection" when "call" became ambiguous with new technologies.

Mikes edits to the notes all look good - and the notes would be attached to the second of his two provisions.

(Note -- if we wanted to keep this as one provision - then we still should use Gunnar's language to clear up the "on a single connection" -- even though it makes it longer.)

I agree with the proposal by @hellstromgu for 6.2.1.x "concurrent voice and text", with a simplification of the precondition: "Where ICT provides bidirectional voice communication, and ICT provides RTT".

But I do not understand the second requirement 6.2.1.y "actions act on all media". To me this requirement is very confusing and I don't know what its purpose is. Maybe it could be rewritten to be clearer (I don't have any suggestion as I don't understand the requirement).

A similar requirement is found in TS 122 173 clause 4 about general service requirements on multimedia telephony.

"- When a supplementary service is invoked it applies to all media components of an IMS Multimedia Telephony communication. "

By our requirement we apply that also on initiating the communication and closing the communication. The default case is that all intended or established media are influened by the operation. E.g. the normal case for initiating a communication with voice and RTT is to make one single request and both voice and RTT are initiated by that request.

How can it be better described than in the proposal? Why is it hard to understand?

So the latest suggestion, taking into account Loïc's suggestion is:

6.2.1.x Where ICT provides bidirectional voice communication, and ICT provides RTT,
the ICT shall allow concurrent voice and text.

6.2.1.y Where ICT provides bidirectional voice communication, and ICT provides RTT, the ICT shall allow single user actions to act on all media during establishment, supplementary services, multiparty actions and disconnections.

One point raised in the STF call today was that including network "supplementary services" may include some ambiguities such as, ~"network voicemail" for lack of a better term. If an RTT user is redirected to a voice mailbox, even if we presume they can leave an RTT message on the network voicemail service, what if the receiving party has no way to review the message? (One real scenario mentioned was mobile RTT user calling a wireline/landline number.)

The fact that the receiving device does not implement RTT (when it should -- e.g. voicemailbox) or can't (e.g. analog phone) does not mean the supplementary service should not support RTT-- or RTT will not work for all the receiving devices where it would work.

Mentioning "Supplementary service" caused concerns, so we need to explain this with other words. Proposal:

6.2.1.y Where ICT provides bidirectional voice communication, and ICT provides RTT,

the ICT shall allow single user actions to act on all desired or established media during establishing, modifying or disconnecting the session.

I think removing supplementary services is a mistake. When you make a rule like this with a list of what you can think of -- the stuff you don't think of "or that they don't recognize as falling within your listed items, will not work. For example -- on a voice call I can - with a single action, stop voicemail or re-record it. But with new language -- I would not need to cover that for RTT users because it was a supplemental service and not "establishing, modifying or disconnecting the session."

if I had a list of supplementary services in front of me I'm sure I can identify a bunch more places where not supporting RTT would be a problem.

I am not sure the supplementary services is a problem. On the call I didnt hear of any specific example of a problem - that wasn't something that we did want covered.

Analog phones were mentioned - but that isnt a supplementary service and analog phones won't work with any RTT. I don't think we should = worry about terminal devices. RTT should work all the way up to when it can't (e.g. the call is connected to a PSTN/POTS device or network) (or even a cell phone that didnt implement RTT) so that the call will work when it is connected to devices where it will work. (i.e., just because it won't work with some device doesnt mean we shouldnt require it so that it works with all devices where it does work).

The supplementary service spec is 3GPP TS 22.173 https://www.3gpp.org/ftp/Specs/archive/22_series/22.173/22173-i01.zip The statement about acting on all media is the last paragraph in clause 4.1, saying:

When a supplementary service is invoked it applies to all media components of an IMS Multimedia Telephony communication. A supplementary service can be activated by the user for one or more types of media components. If one or more of these media components are present in the IMS Multimedia Telephony communication then the supplementary service is invoked.

I suggest that we agree on the latest proposal from Mike above, and that we only include Note 1. The other notes go to far in usage assumptions.

I am lost. I don't see any notes at all in "the latest Mike suggestion". and it proposes two different clauses -- which one are you referring to as keeping note1.

Can someone post a clean copy of what it is we are discussing with all language and all notes included?

thanks G

You can find the notes in the current draft and at the top of this issue. The proposal I have to get this issue agreed is that we just use the following two clauses proposed by Mike above and Note 1:

6.2.1.2 Where ICT provides bidirectional voice communication, and ICT provides RTT,
the ICT shall allow concurrent voice and text.

NOTE 1: With multiparty communication, such as a conference system, conference floor control can be used to avoid confusion caused by multiple participants contributing at the same time.

6.2.1.3 Where ICT provides bidirectional voice communication, and ICT provides RTT,
the ICT shall allow single user actions to act on all media during establishment, supplementary services, multiparty actions and disconnections.

The clauses need headers. Inserted here. Also changed from text to RTT in last line of 6.2.1.2

6.2.1.2 Concurrent voice and RTT
Where ICT provides bidirectional voice communication, and ICT provides RTT,
the ICT shall allow concurrent voice and RTT.

NOTE 1: With multiparty communication, such as a conference system, conference floor control can be used to avoid confusion caused by multiple participants contributing at the same time.

6.2.1.3 Single user actions
Where ICT provides bidirectional voice communication, and ICT provides RTT,
the ICT shall allow single user actions to act on all media during establishment, supplementary services, multiparty actions and disconnections.

6.2.1.3 has some similarities (but another purpose) with 6.2.9 in #96 (closed). So it should be checked if they should be positioned close to each other.

marked this issue as related to #96 (closed)

THANKS! very helpful.

Looks good to me.

Want to plug those into the document I sent as part of your review?
(Also check the test I did to see if it still works. I think it should.

Why do we need note 1 here? That is entirely unrelated to RTT! Should be deleted!

closed

mentioned in issue #264 (closed)

reopened

@schneidermat It could be removed. it was added because there were concerns mentioned in our earlier discussions about how this could be handled. This was added to make it clear that the ordinary methods could be used to handle this. It was felt helpful to industry in giving them cover if they just relied on ordinary means. If the other industry representatives do not think it is helpful to them to have this-- it could be removed in my opinion. It was put there for their benefit.

@schneidermat In another communication you indicated that "multi-party action" might need to be defined. I agree. That would not be very clear to many.

You suggested adding a parenthetical (with examples) in the provision. But that is not allowed. I think we could solve it either by

putting in a note like your parenthetical "Note: multi-party actions are things like establishment, transfer,on-hold“, reconnect, disconnect, etc. where more than two parties are on the call or will be on the call at the end.
creating a definition of "multi-party action".

I think maybe the note is all that is needed - and easier. But I agree we should do something to clarify

Repetition of 6.2.1.2, the note deleted and Aa new proposal for 6.2.1.3 avoiding supplementary services and multiparty actions:

6.2.1.2 Concurrent voice and RTT
Where ICT provides bidirectional continous voice communication, and ICT provides RTT,
the ICT shall allow concurrent voice and RTT.

6.2.1.3 Single user actions
Where ICT provides bidirectional continous voice communication, and ICT provides RTT,
the ICT shall allow single user actions to act on all media during establishment, modifications during the communication and disconnections.

+1 to both of these from Gunnar. Nice wordsmithing. (need oxford comma before "and disconnections" )

The proposals in this issue were part of an agreed comprehensive approach to clause 6.2 and have, as such, now been included in the latest working draft.

The issue can now be closed.

closed

Concurrent voice and text (from clause 13.4.3 in TR 103 708)

Designs

Child items ...

Activity

Note: It is important that bidirectional communication with concurrent voice and text be as easy to initiate, answer, and transfer as bidirectional voice only.

Concurrent voice and text (from clause 13.4.3 in TR 103 708)

Relates to

Activity

Note: It is important that bidirectional communication with concurrent voice and text be as easy to initiate, answer, and transfer as bidirectional voice only.