RE: [MMUSIC] Accessibility relatedparametersindraft-ietf-mmusic-sdp-media-content-01.txt

["Arnoud van Wijk" <[e-mail]>]

Hi Gunnar,
The ToIP client MAY switch from split screen to a single screen. It does not
have to. In the Dutch mobile text telephone platform, we will make it an
option in the client to go from splitscreen to single screen when
communicating with a PSTN text telephone. It is up to the users to choose
it.

The most important part is that the users know that they may have to use the
turn-taking etiquette in the call. As you wrote below, almost all textphone
calls require turn-taking etiquette.

The chance of connecting to a native V.18 is still very slim. 
Maybe we can say if it is native v1.8, that it will not use txp label. That
is more or less to be determined by trials if that is desirable or not.

But for 99% of all texttelephone calls it will require turn-taking etiquette
anyway.

Cheers

Arnoud

> -----Original Message-----
> From: Gunnar Hellstrom [mailto:[e-mail]]
> Sent: donderdag 23 februari 2006 15:23
> To: Arnoud van Wijk; 'Jani Hautakorpi (JO/LMF)'
> Cc: [e-mail]; [e-mail]
> Subject: RE: [MMUSIC] Accessibility relatedparametersindraft-ietf-mmusic-
> sdp-media-content-01.txt
> 
> 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
> [e-mail] <mailto:[e-mail]>
> Mob: [phone]
> Phone: [phone]
> www.omnitor.se <http://www.omnitor.se>
> 
> 
> -----Original Message-----
> From: Arnoud van Wijk [mailto:[e-mail]]
> Sent: Thursday, February 23, 2006 1:47 PM
> To: 'Gunnar Hellstrom'; 'Jani Hautakorpi (JO/LMF)'
> Cc: [e-mail]; [e-mail]
> 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:[e-mail]]
> > Sent: donderdag 23 februari 2006 0:24
> > To: Arnoud van Wijk; 'Jani Hautakorpi (JO/LMF)'
> > Cc: [e-mail]; [e-mail]
> > 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
> > [e-mail] <mailto:[e-mail]>
> > Mob: [phone]
> > Phone: [phone]
> > www.omnitor.se <http://www.omnitor.se>
> >
> >
> > -----Original Message-----
> > From: Arnoud van Wijk [mailto:[e-mail]]
> > Sent: Wednesday, February 22, 2006 11:53 AM
> > To: 'Jani Hautakorpi (JO/LMF)'; 'Gunnar Hellstrom'
> > Cc: [e-mail]; [e-mail]
> > 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:[e-mail]]
> > > Sent: woensdag 22 februari 2006 7:34
> > > To: Gunnar Hellstrom
> > > Cc: [e-mail]; [e-mail]
> > > 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
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/mmusic
> >
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mmusic



_______________________________________________
mmusic mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic