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