Subject: RE: [Sipping] RFC 3351 and Generic Transcoding

From: "Even, Roni" <[email-masked]>
Date: Wed, 27 Nov 2002 16:14:42 +0200

Hi,
I think that the major problem I see is the relationship between RFC 3351
that present user requirements for the SIP in support of deaf, hard of
hearing and speech impaired individuals and the draft-camarillo-sip-deaf-01.

The requirement section in RFC 3351 list specific requirements:

1. To be able to establish calls between a system that has text input and
text or video (sign language or lip synch) display and a speech phone or
another text based system (SIP based or other technology (V.18 is the only
one specified but I think it means T.140 over V.18 or coming from other
protocols (T.140/T.134/T.120 or H.32x))

2. The Relay service can be using human operator like Typetalk or automatic
translators.  

3. Use Profile which I think asks for how to use offer/answer model when
setting the call to establish the correct media based on the profile while
having security on the user (anonymity)

4. Having a good description of such a UA so that interoperability will be
achieved as in item 1, I assume that it means specifying the media protocols
and call flows.

5. The solution should hide from the other side that the origin was from a
speech terminal.

 draft-camarillo-sip-deaf-01 address the transcoding and relay aspects of
the requirements. The 3PCC based solution for that application looks OK. Is
a transcode service a must for a deaf individual.  

An editorial comment is that the text before section 2.2 seems to be
missing.

Another comment is about the sentence in the introduction  "All the examples
provided in this document use the Session Description Protocol (SDP) [4].
However, other session description  formats can be used with the same call
flows." . For a solution for deaf individuals we need to describe a
recommended implementation and not example.

The draft is not addressing the user profile requirement and the interop
with legacy system, maybe there is a need for a document that will define
general transcoding and use it also for a best current practice for
supporting deaf individuals.

BTW  Is there a text media type . Is there an RTP specification for T.140
and is T.140 the protocol to be used for the solution.

As for general transcoding requirements.

I would like to add a requirement for having the transcode send multiple
instance of the same audio stream content (English, French, Spanish) to the
UA enabling him to identify the streams (same content and which language is
each stream) also the same stream using different codecs enabling redundancy
and   

Thanks
Roni Even
Polycom

> -----Original Message-----
> From: Guido Gybels [mailto:[email-masked]]
> Sent: Tuesday, November 26, 2002 4:31 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [Sipping] RFC 3351 and Generic Transcoding
> 
> 
> Hi all,
> 
> >>> "Drage, Keith (Keith)" <[email-masked]> 11/26/02 12:19AM >>>
> >>RFC 3351 quite clearly does not have the scope of general 
> transcoding requirements for SIP networks, but concentrates 
> on those for >>transcodings applicable to deaf users.
> 
> RFC3351 describes user requirements for deaf and hard of 
> hearing people. The section on Transcoding in that RFC is not 
> part of the requirements section (5), but belongs to chapter 
> 6 which describes *some* real world scenarios, as examples to 
> make the requirements more clearly and to raise awareness for 
> service providers and system designers about the kind of 
> services deaf and hard of hearing people would need.
> Transcoding is clearly a service that can be used for all 
> users, not just deaf and hard of hearing people. As such, it 
> was not an objective of RFC3351 to provide requirements for 
> transcoding services in general (things like time 
> synchronisation of various media streams, selection from 
> available streams, etc spring to mind). Our design team 
> would, however, be interested in participating in efforts to 
> describe the generic requirements for transcoding (I assume 
> we are talking about user and functional requirements here).
> One also needs to clearly distinguish between the SIP 
> requirements for transcoding (in how far is SIP able to 
> signal and control the set up/control/tear down of such a 
> session versus non-SIP requirements (like for SDP and such). 
> Maybe the correct approach is to create a high-level 
> requirements document for transcoding and then to create 
> protocol-specific documents from that high-level document 
> (ensuring in that way than any protocol-specific effort will 
> fully cover all of the transcoding issues).
> 
> Guido
> 
> 
> 
> 
> 
> **************************************************************
> **********
> This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity to
> whom they are addressed. Any views or opinions expressed
> are solely those of the author and do not necessarily represent
> RNID policy.
> 
> If you are not the intended recipient you are advised that any
> use, dissemination, forwarding, printing or copying of this
> email is strictly prohibited.
> 
> If you have received this email in error please notify the RNID
> Helpdesk by telephone on: +44 (0) 207 296 8282.
> 
> The Royal National Institute for Deaf People  
> Registered Office 19-23 Featherstone Street 
> London EC1Y 8SL No. 454169 (England)
> Registered Charity No. 207720
> **************************************************************
> **********
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP