RE: [MMUSIC] Accessibility relatedparametersindraft-ietf-mmusic-sdp-media-content-01.txt
"Gunnar Hellstrom" <gunnar.hellstrom@omnitor.se> Thu, 23 February 2006 14:22 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHMx-0000PT-5t; Thu, 23 Feb 2006 09:22:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCHMv-0000PL-Bl for mmusic@ietf.org; Thu, 23 Feb 2006 09:22:57 -0500
Received: from 67.254.241.83.in-addr.dgcsystems.net ([83.241.254.67] helo=smtp.dgcsystems.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCHMs-0003xq-GK for mmusic@ietf.org; Thu, 23 Feb 2006 09:22:57 -0500
Received: from MISAN ([217.13.240.136]) by smtp.dgcsystems.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Feb 2006 15:22:52 +0100
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
To: Arnoud van Wijk <degodefroi@gmail.com>, "'Jani Hautakorpi (JO/LMF)'" <jani.hautakorpi@ericsson.com>
Subject: RE: [MMUSIC] Accessibility relatedparametersindraft-ietf-mmusic-sdp-media-content-01.txt
Date: Thu, 23 Feb 2006 15:22:51 +0100
Message-ID: <GLEFKJBKNILEBOELNIBIEEHGDGAA.gunnar.hellstrom@omnitor.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-reply-to: <004d01c63877$375949e0$2500a8c0@solstice>
Importance: Normal
X-OriginalArrivalTime: 23 Feb 2006 14:22:52.0731 (UTC) FILETIME=[A1C1D0B0:01C63884]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3
Cc: Gonzalo.Camarillo@ericsson.com, mmusic@ietf.org
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Errors-To: mmusic-bounces@ietf.org
Arnoud, What I try to tell is that it may be totally wrong to shift the user interface to a single window for PSTN textphone communication. 1. If you have a V.18 to V.18 communication, it is full duplex and the standards require the display to be split in some way between sent and received text. It looks as on IP and no strict turn taking etiquette is needed. 2. If you have a V.21 communication it is usually one screen, but fully possible to interrupt the other part by just sending text whenever you want. Turn-taking etiquette is needed. 3. If you have an EDT or DTMF or Baudot-TTY, it is strictly half duplex with no chance to transmit while you are receiving. Turn-taking etiquette is needed. 4. If the system happens to support the proprietary US textphones, communication is in principle half duplex, but there is a specific interrupt function that causes some action at the other end. So, we cannot force any strict user interface action from the client who receives the txp indicator. I do not want to cause more work by requiring subparameters, so let us go with txp and this description in section 5: > Typical use case > for this is e.g., a connection where one endpoint is an analog > textphone, and the other one is a native IP based text telephone. > The user should be made aware that presentation and communication > limitations exist. In a specific implementation no one can prevent you from taking a shortcut and implement swap to single screen display for all txp indications, knowing that most calls will be with textphones that matches that behaviour. Gunnar ---------------------------------------------------------------------------- - Gunnar Hellstrom, Omnitor gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se> Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se <http://www.omnitor.se> -----Original Message----- From: Arnoud van Wijk [mailto:degodefroi@gmail.com] Sent: Thursday, February 23, 2006 1:47 PM To: 'Gunnar Hellstrom'; 'Jani Hautakorpi (JO/LMF)' Cc: Gonzalo.Camarillo@ericsson.com; mmusic@ietf.org Subject: RE: [MMUSIC] Accessibility relatedparametersindraft-ietf-mmusic-sdp-media-content-01.txt Gunnar, that is exactly what Jani and I mean here. It has nothing to do with call mechanism/buffering etc. (RFC4103 already offers changes in character transmission speed). It is to alert the user that the media stream is originating from a PSTN texttelephone. You have to see it as a person who is used to bi-directional ToIP on a split screen. Both users send and receive text simultaneously. Then next call originates from a PSTN texttelephone and the user needs to be aware that they have to wait until the other has finished typing and indicates that it is the users turn now to type. The txp label will also allow, depending on the user interface, to go from split screen to a single screen, more or less behave like a PSTN texttelephone. (and disallow cut and paste of more then 50 characters to avoid flooding the PSTN textphone). But it can just as well be a pop up window alerting the user that he or she is connected to a PSTN texttelephone. I am asuming that the callee knows the PSTN texttelephony etiquette. (wait for turns, indicate GA or * or x when finished typing etc etc). Greetz Arnoud van Wijk > -----Original Message----- > From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] > Sent: donderdag 23 februari 2006 0:24 > To: Arnoud van Wijk; 'Jani Hautakorpi (JO/LMF)' > Cc: Gonzalo.Camarillo@ericsson.com; mmusic@ietf.org > Subject: RE: [MMUSIC] Accessibility related parametersindraft-ietf-mmusic- > sdp-media-content-01.txt > > Jani, > OK, I understand. Your idea was to have the meaning of the values enough > described in the sdp-media-content specification. > > Then we should add a few more words to explain suitable behaviour of a > client receiving the "txp" indicator. > > I assume the most common case would be in connection with the m=text media > description. > > I dislike to drag the variations of PSTN textphones into requirements on > variations in behaviour of SIP clients. But I cannot figure out how a SIP > client shall react on reception of the txp indication. The expected > variation is too wide with: > -half duplex or full duplex or interruptable half duplex, > -split window or common window, > -simultaneous voice and text or alternating voice and text, > -national character set or further limited or Unicode > -4 or 6 or 10 or 30 or 120 characters per second. > > It is tempting to ask for a subparameter for the type of textphone that is > commected beyond the gateway. > One architecturally ugly way to do it would be to ask gateway implementors > to generate a > RFC 2833bisdata event in an audio channel giving information on the type > of > textphone in contact, and the application would then have knowledge about > what characteristics to use towards them. > See section 2.7.1 in: > http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2833bisdata-06.txt > > > > We could make it easy for us and just specify : "txp" indicates that the > other party has a textphone, and that the user should be made aware that > presentation and communication restrictions may apply. > > So, the phrase in section 5 deascribing txp could be extended to end like > this: > > Typical use case > for this is e.g., a connection where one endpoint is an analog > textphone, and the other one is a native IP based text telephone. > The user should be made aware that presentation and communication > limitations exist. > > > ? > > Gunnar > > > > -------------------------------------------------------------------------- > -- > - > Gunnar Hellstrom, Omnitor > gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se> > Mob: +46 708 204 288 > Phone: +46 8 556 002 03 > www.omnitor.se <http://www.omnitor.se> > > > -----Original Message----- > From: Arnoud van Wijk [mailto:degodefroi@gmail.com] > Sent: Wednesday, February 22, 2006 11:53 AM > To: 'Jani Hautakorpi (JO/LMF)'; 'Gunnar Hellstrom' > Cc: Gonzalo.Camarillo@ericsson.com; mmusic@ietf.org > Subject: RE: [MMUSIC] Accessibility related > parametersindraft-ietf-mmusic-sdp-media-content-01.txt > > > I think if we say in the ToIP draft that it is advised to use txp label to > indicate a texttelephone in the call, it should not delay the RFC. > The only thing is that when the RFC is released, will it be possible to > swap > the reference to the media content draft with the media content RFC? > > Greetz > > Arnoud > > > -----Original Message----- > > From: Jani Hautakorpi (JO/LMF) [mailto:jani.hautakorpi@ericsson.com] > > Sent: woensdag 22 februari 2006 7:34 > > To: Gunnar Hellstrom > > Cc: Gonzalo.Camarillo@ericsson.com; mmusic@ietf.org > > Subject: Re: [MMUSIC] Accessibility related parametersindraft-ietf- > mmusic- > > sdp-media-content-01.txt > > > > Gunnar, > > > > > Explanation 2 > > > --------------- > > > There could be another explanation: The table in section 10 could be > the > > > initial table, and you regard the meaning of the values enough > described > > in > > > the media-content specification. Then all xxxx would point at the > > > media-content specification. > > > > This is the right explanation. We're planning to register the coming RFC > > number of this draft in the table. But if you want to specify the usage > > of "txp" in some other draft, we can make an informational reference > > from this draft to that one. > > > > > What is our intention? It could be suitable with an RFC-editor note > > about > > > the meaning of XXXX and how it shall be handled. > > > > I'll add a note for RFC-editor. > > > > > Yes, I was thinking that if we bring in a reference to "txp" in the > > > sipping-toip specification, then we need to wait until media-content > is > > > published and the table of values registered by IANA until we can > > proceed to > > > publication. > > > > I guess this isn't a serious problem. > > > > > > -- > > Jani H. > > > > > > _______________________________________________ > > mmusic mailing list > > mmusic@ietf.org > > https://www1.ietf.org/mailman/listinfo/mmusic > _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic
- RE: [MMUSIC] Accessibility related parametersindr… Arnoud van Wijk
- [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-c… Internet-Drafts
- [MMUSIC] Accessibility related parameters in draf… Gunnar Hellstrom
- Re: [MMUSIC] Accessibility related parameters in … Jani Hautakorpi (JO/LMF)
- RE: [MMUSIC] Accessibility related parameters ind… Gunnar Hellstrom
- Re: [MMUSIC] Accessibility related parameters ind… Jani Hautakorpi (JO/LMF)
- RE: [MMUSIC] Accessibility related parametersindr… Gunnar Hellstrom
- RE: [MMUSIC] Accessibility related parametersindr… Arnoud van Wijk
- RE: [MMUSIC] Accessibility relatedparametersindra… Gunnar Hellstrom
- RE: [MMUSIC] Accessibility relatedparametersindra… Arnoud van Wijk
- RE: [MMUSIC] Accessibility relatedparametersindra… Gunnar Hellstrom
- Re: [MMUSIC] Accessibility relatedparametersindra… Jani Hautakorpi (JO/LMF)
- RE: [MMUSIC] Accessibility related parameters in … Gunnar Hellstrom
- Re: [MMUSIC] Accessibility related parameters in … Jani Hautakorpi (JO/LMF)
- RE: [MMUSIC] Accessibility related parameters in … Gunnar Hellstrom