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

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

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