Harald,

You are right, the requirements on audio and video in the rtcweb use 
cases are not at all at the detail service quality level that 
F.700/F.703 are.
They merely talk about good audio and good video. So, we should align 
the real-time text and total conversation requirements to something 
similar to that level, and move details to the RTT or total conversation 
document.


It might be good to include a definition of the concepts of rea-time 
text and total conversation.

Mentioning F.700/F.703 in a note can add further high level explanations 
as Barry hints.

You are also right about the point about not requirig emergency service 
interoperability only for real-time text or total conversation. That is 
a general issue that should be considered and mentioned in a way so that 
real-time text and total conversation access to emergency services are 
included if emergency service access for video and audio is specified.

The requirement for emergency service access was not strictly expressed. 
It was "

Interworking with SIP calls with the same media set, and with SIP
    based emergency services is also in scope of this use case."

I do not see "is in scope" to lead to a "shall" requirement. It rather corresponds to "should be considered".

Some voices during the last call process for this document has been for more strict requirements wording.
So we need to make it clear what is requirements and what is for information.

I realize well that in some applications of RTCWEB, it will be obvious that there cannot be any expectation
that it could be used for emergency calls, and for such situations the emergency call requirement should not
be applied.

It seems to be valid to try to split the requirements in direct technical requirements on rtcweb, and
requirements on services made with RTCWEB.


Here is an effort to revise the proposed additions.

---------------------------Proposed addition to use cases and requirements -------------------

3. Definitions

Real-time text 		Text transmitted instantly while it is being typed or created, so that the recipient
			can read the sender's text as it is written, without waiting.  		
  
Total conversation	An audiovisual conversation service providing bidirectional real-time transfer of
			motion video, real-time text and audio between users in two or more locations.
			Note: High level information on real-time text and total conversation can be found in
			ITU-T F.700 and ITU-T F.703.

> 4.2.15.Simple Total Conversation service
>
> 4.2.15.1.Description
>   
>     This use-case has the audio and video communication of the Simple
>     Video Communication Service use-case (Section 4.2.1  <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09#section-4.2.1>).
>   
>     In addition to this, the users can send and receive real-time text
>     in the same call.  While one user types in the real-time text area, it
>      is nearly immediately presented to the other user.
>
>     By providing these three media together, the Total Conversation
>     service is provided.
>   
> 4.2.15.2.   Derived Requirements
>   
>     F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,
>   
>     F39,F40, F41
>   
>     A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27
>   
> ..............
>
>     F39              The browser MUST be able to handle text entry
>                     via applications to generate real-time
>                     text streams to be included in Total Conversation
>                     calls.       
>     ----------------------------------------------------------------
>     F40              The browser MUST be able to send real-time text
>                     streams to a peer.
>        
>   
>     ----------------------------------------------------------------
>     F41               The browser MUST be able to receive, process and
>                       convey real-time text streams from peers to
>                      applications.
>     ----------------------------------------------------------------
>     
>   
>
> .....
>
>     A27              The Web API MUST provide a mechanisms for  
>                     handling real-time text among the streams.  
>   .......

11.2 Informative references

[ ]    ITU-T Recommendation F.700 Framework Recommendation for 
multimedia services

[ ]    ITU-T Recommendation F.703    Multimedia Conversational Services

----------End of proposal--------------------------------------------------------------

/Gunnar

------------------------------------------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46708204288
On 2013-02-01 14:19, Barry Dingle wrote:
> Good point Harald regarding F.700 A.3.2.3 calling up "font support for 
> _all characters_ in ISO-10646-1".
>
> I suspect that the reference to F.700 was to the service and 
> performance requirements of a range of multimedia services. I am not 
> aware of another 'more suitable' set of Service Requirements document 
> that we can reference. F.700 (and F.703) are frequently referenced - 
> but some people probably quietly ignore the full implications of A.3.2.3.
>
> So we need to capture the 'general service requirements' but remove 
> any parts of F.700 (or F.703) that are not applicable.
>
> As the proposed additional use-case just adds RTT to the video+audio, 
> I suggest that we just add the (selected) RTT Requirements that suit 
> rtcweb to the use-case and maybe put an informational note to F.700 
> and F.703.
>
> Cheers,
> /Barry Dingle
>
>
>
> On Fri, Feb 1, 2013 at 10:07 AM, Harald Alvestrand 
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>
>     FWIW, I strongly object to a couple of formalities here:
>
>     - I object to making normative reference to F.700 and F.703.
>     - I object to requiring interworking with emergency services.
>
>     If there's strong support in the WG for including the use case,
>     I'm willing to go along with that.
>
>     (The reason for not wanting to normatively reference F.700 and
>     F.703 is that they're very large balls of string, and I have no
>     idea where the string may lead; for instance, the definition of
>     "Total Conversation" in section A.3.2.3 of F.700 requires font
>     support for all characters in ISO-10646-1; I doubt somewhat that
>     the person who wrote that paragraph has studied the task of
>     providing such font support - I found that particular linkage in a
>     few minutes of scanning the docs.)
>
>
>     On 01/30/2013 10:15 PM, Gunnar Hellstrom wrote:
>>     4.2.15.Simple Total Conversation service
>>
>>     4.2.15.1.Description
>>       
>>         This use-case has the audio and video communication of the Simple
>>         Video Communication Service use-case (Section 4.2.1  <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-09#section-4.2.1>).
>>       
>>         In addition to this, the users can send and receive real-time text
>>         in the same call.  While one user types in the real-time text area, it
>>          is nearly immediately presented to the other user.
>>
>>         By providing these three media together, the Total Conversation
>>         service is provided.
>>
>>         Interworking with SIP calls with the same media set, and with SIP
>>         based emergency services is also in scope of this use case.
>>       
>>     4.2.15.2.   Derived Requirements
>>       
>>         F1, F2, F3, F4, F5, F6, F8, F9, F10, F20, F21,
>>       
>>         F39,F40, F41
>>       
>>         A1, A2, A3, A4, A7, A8, A9, A10, A11, A12, A27
>>       
>>     ..............
>>
>>         F39              The browser MUST be able to handle text entry
>>                         via applications to generate real-time
>>                         text streams to be included in Total Conversation
>>                         calls. Real-time text and Total Conversation
>>                         Services are defined in ITU-T F.700 and F.703.
>>         ----------------------------------------------------------------
>>         F40               The browser MUST be able to send real-time text
>>                         streams to a peer.
>>       
>>         ----------------------------------------------------------------
>>         F41               The browser MUST be able to receive, process and
>>                           convey real-time text streams from peers to
>>                          applications.
>>         ----------------------------------------------------------------
>>         
>>       
>>
>>     .....
>>
>>         A27              The Web API MUST provide a mechanisms for  
>>                         handling real-time text among the streams.  
>>       ----------------------------------------------------------------
>
>
>     _______________________________________________
>     rtcweb mailing list
>     rtcweb@ietf.org <mailto:rtcweb@ietf.org>
>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb