Subject: Re: [MMUSIC] Re: ietf-mmusic-sdp-media-content-03

From: Colin Perkins <[email-masked]>
Date: Tue, 20 Jun 2006 23:29:50 +0100

Hi,

Just following up on this... did we ever get agreement on the right  
way to proceed? If an updated draft is needed, I'd like to get it in  
before the deadline. Cullen? Jani?

Colin

On 18 May 2006, at 22:25, Gunnar Hellstrom wrote:
> Hi,
> I agree that the content parameters "txp" and "user-floor" indicate  
> similar functionality.
>
> But I see nothing wrong in having them both in the specification  
> anyway.
>
> The txp parameter value may be used to invoke some automated  
> mechanism in a text capable gateway to support conversion between  
> full duplex simultaneous multimedia communication and half-duplex  
> turn-taking, alternating text - voice communication in PSTN. But it  
> can also be used just as a warning to the IP user to be aware of  
> possible limitations in simultanity and duplex use of media.
>
> We could go deeper in specifying exactly what limitations are valid  
> at each moment, but I doubt that any manufacturer want to refine  
> their gateway designs to that degree.
> If we want to go deeper, we could use the following parameters:
>
> -    voice-text-alternating    ( in fact influencing two media )
>
> -    half-duplex                  ( when strictly only one  
> direction at a time can be used )
>
> -    half-duplex-interruptable  ( when only one direction at a time  
> should be used for contents, but it is possible to send an  
> indication that the other party want the turn. )
>
>
> I think that txp is enough.
>
> I just participate in a discussion where we have tried to meet  
> requirements to keep gateway resources low by allowing it to set up  
> a real-time text connection between a PSTN gateway and an IP  
> terminal only when there are indications that text will be used. It  
> is a compromise that may be needed in reality.
>
> In the draft document from that discussion, we use both the  
> a=content:txp parameter, and the following parmeters from RFC 3840  
> and 3841.
>
> Contact: duplex="half",
>
> Contact: <uri>;text
>
> Accept-Contact: *;text;require
>
> Accept-Contact: *;text
>
>
> I would appreciate very much to get comments on the parameter  
> values and logic we have drafted.
>
> ----------------------Proposed alternative to ITU-T V.151 Annex D,  
> using caller and callee capabilities and preferences and media- 
> contents to control gateway - IP text capable terminal  
> communication--------------------------------------------------------- 
> ---------------
>
> Alternative proposal for V.151 Annex D.
> ANNEX D2
>
> Interworking IP Text Devices with V.151 Gateways.
> Connect text channel when usage of real-time text is likely.
>
>
>
> D.1 Introduction
> Some non-Gateway IP devices in the network not having a means of  
> modulating or demodulating PSTN textphone signals, such as IVR  
> systems, voicemail systems, IP phones, Multimedia telephones or  
> other devices, may support the transmission of real-time text over  
> IP networks and, ideally, interwork with V.151-compliant Gateways  
> in order to provide a means through which users of PSTN textphone  
> devices can communicate with those IP devices.  This class of  
> devices is referred to herein as an "IP Text Device” (ITD).  This  
> Annex defines the procedures that may be used in order to allow for  
> such interworking between V.151 Gateways and ITDs. The main  
> principle is to use RFC 4103 as the default text transport method  
> between gateways and ITD:s, and open text channels only when it is  
> likely that the text channel will be used.
>
> D.2 Exchanging capabilities and opening media streams
> When establishing a call, an ITD may advertise support for real- 
> time text  in accordance with IETF RFC 4103.
>
> In general, ITDs also transmit text characters when communicating  
> with other ITDs using RFC 4103, which specifies the establishment  
> of a separate RTP stream specifically for transmitting text  
> characters.  However, since V.151 PSTN gateway devices interleave  
> audio and text data when used for Gateway - to - gateway operation,  
> V.151 gateways need to support both RFC 4103 to interwork with ITDs  
> and RFC 4351 for communicating with other PSTN gateways.
>
> As such, V.151 gateways are Recommended to indicate support for  
> both transport methods initially when exchanging capability  
> information. However, relatively few calls use real-time text in  
> the PSTN, and therefore it may be desirable for the gateway to not  
> open the text channel until either party in the call explicitly  
> acts to use real-time text.
>
> According to normal procedures in IP multimedia systems, it is  
> allowable to indicate capability for other transport protocols for  
> real-time text as well as RFC 4103 and connect such alternatives.
>
> ----
>
> D.2.2    SDP based systems
> Similar logic follows for SDP-based systems.
>
> In SIP-based systems, the terminal and gateway shall announce  
> support for text in the Contact field according to RFC 3840, and  
> may indicate preference for text according to RFC 3841.
>
> Contact: <uri>;text
>
> A calling SIP terminal who does not put priority to text may  
> indicate an interest to use text by:
>
> Accept-Contact: *;text
>
> A calling SIP terminal who want to put priority to establishing a  
> text connection shall indicate that by:
>
> Accept-Contact: *;text;require
>
> Most commonly, PSTN text telephones support alternating text and  
> audio during the call, but not simultaneous text and audio. If the  
> gateway only supports alternating text and audio during the PSTN  
> text session, it may be beneficial to make the ITD user aware of  
> this limitation. It is proposed to use the Duplex parameter of RFC  
> 3840 for this purpose.
>
> Contact: duplex="half"
>
> There is a parameter also for use in the text media description:
>
> a=content:txp
>
> It should be used to indicate to the ITD user that the text channel  
> is half duplex and turn-taking habits should be used.
>
>
>
> Note that while the use of RFC 2198 redundancy or other fault  
> tolerance scheme is not shown in the abbreviated examples below,  
> appropriate mechanisms should be employed to protect the  
> transmission of the text stream in accordance with the text  
> transport specifications.
>
>
>
> D.2.2.1 Call from PSTN
> Consider the following abbreviated example SDP that might be found  
> in an offer sent by a V.151 Gateway not offering RFC 4103 support  
> initially, but indicating text support and that the text support is  
> alternating with audio:
>
>       Contact: <uri>;text;duplex="half"
>
>        m=audio 7200 RTP/AVP 0 98
>
>        a=rtpmap:98 t140c/8000
>
>        a=fmtp:98 cps=20
>
> If the gateway at that time already knows that text will be needed  
> in the call, a requirement for text shall be included, and a media  
> line for text. The decision to include text when offering the call  
> may be because textphone tones have already been detected on the  
> PSTN line, the gateway may be configured to be a dedicated text  
> gateway, or it may be known by subscription or any other external  
> means that either user has preference for text.
>
>       Accept-Contact: *;text;require
>
>       Contact: <uri>;text;duplex="half"
>
>        m=audio 7200 RTP/AVP 0 98
>
>        a=rtpmap:98 t140c/8000
>
>        a=fmtp:98 cps=20
>
>        m=text 7202 RTP/AVP 99
>
>        a=rtpmap:99 t140/1000
>
>       a=content:txp
>
>
>
> If the answering device is an ITD, with no specific indication that  
> text would be used,  it would accept only the G.711 audio.
>
>       Contact: <uri>;text
>
>       m=audio 7200 RTP/AVP 0
>
>
>
> If the answering device is an ITD where the user has indicated a  
> preference for text, it would accept the text/t140 medium and  
> optionally G.711 audio.
>
>       Contact: <uri>;text
>
>        m=audio 7200 RTP/AVP 0
>
>        m=text 7202 RTP/AVP 99
>
>        a=rtpmap:99 t140/1000
>
> Note that this response is only possible when the gateway had  
> included text/140 in the offer. For other cases, the terminal needs  
> to do a reinvite to add text to the call.
>
> D.2.2.2 Call from IP terminal
> A calling ITD could give a strong indication that it requires text  
> support in the call by an INVITE according to this example:
>
>       Contact: <sip:[email-masked]>;text
>
>       Accept-Contact: *;text;require
>
>        m=audio 7200 RTP/AVP 0
>
>        m=text 7202 RTP/AVP 99
>
>        a=rtpmap:99 t140/1000
>
>
>
> The network would make efforts to connect to a text capable  
> gateway, that may acknowledge the text channel initially, because  
> of the indication that text is required. The gateway should also  
> start text channel connection procedures on the PSTN side.
>
>       Contact: <gwy-uri>;text;duplex="half"
>
>        m=audio 7200 RTP/AVP 0
>
>        m=text 7202 RTP/AVP 99
>
>        a=rtpmap:99 t140/1000
>
>        a=fmtp:99 cps=20
>
>       a=content:txp
>
>
>
> If on the other hand, the ITD user is not depending on text, but  
> want to have it available for occasional use, the ITD can be  
> configured to make its INVITE as follows:
>
>
>
>       Contact: <sip:[email-masked]>;text
>
>       Accept-Contact: *;text
>
>        m=audio 7200 RTP/AVP 0
>
>        m=text 7202 RTP/AVP 99
>
>        a=rtpmap:99 t140/1000
>
>        a=fmtp:99
>
>
>
> The network would try to connect to a text capable gateway, but may  
> connect through a non capable. The gateway may decide to not  
> acknowledge the text channel initially, but indicates its text  
> capability in the Contact header.
>
>       Contact: <gwy-uri>;text;duplex="half"
>
>        m=audio 7200 RTP/AVP 0
>
>
>
> D.2.2.3 Text channel establishment during a call
> If at a later stage in the call, either party in the call starts  
> text activity, and no text channel was set up initially, a text  
> channel should be added to the session by a REINVITE. .
>
> This is an example of how it would be expressed from the gateway,
>
>        Contact: <uri>;text;duplex="half"
>
>        m=audio 7200 RTP/AVP 0
>
>         m=text 7202 RTP/AVP 99
>
>         a=rtpmap:99 t140/1000
>
>         a=fmtp:99 cps=20
>
>        a=content:txp
>
> The other party should answer with a similar sdp.
>
>
>
> If instead it is the ITD user who starts text activity, a text  
> channel should be added to the session by a REINVITE from the ITD  
> according to the following example. .
>
>        Contact: <uri>;text
>
>        m=audio 7200 RTP/AVP 0
>
>        m=text 7202 RTP/AVP 99
>
>        a=rtpmap:99 t140/1000
>
>        a=fmtp:99 cps=20
>
>
>
> The gateway should answer with
>
>        Contact: <uri>;text;duplex="half"
>
>        m=audio 7200 RTP/AVP 0
>
>        m=text 7202 RTP/AVP 99
>
>        a=rtpmap:99 t140/1000
>
>        a=fmtp:99 cps=20
>
>        a=content:txp
>
> .
>
> The line "a=content:txp" is sent from the gateway as an indication  
> that half duplex procedures should be applied by the users in the  
> text stream.
>
> D.3 Procedure for terminals including both RFC 4103 and RFC 4351  
> support
> In the case when a terminal implements both RFC 4103 and RFC 4351  
> for text transport, the following procedures should be applied in  
> the terminal.
>
> When establishing a call, an ITD may advertise support for ToIP in  
> accordance with Annex B or Annex C, with one notable important  
> exception: the ITD shall not include a list of supported  
> modulations.  Absence of the list of modulations shall be used as  
> an indicator to the V.151 Gateway that the remote side is an ITD.
>
> Further, ITD devices shall not utilize SSEs in order to control  
> state transition to ToIP.  Rather, once a media flow is established  
> to transport T.140 characters, either the Gateway or the ITD may  
> transmit text immediately and without further negotiation.  Payload  
> type switching is used to transition between AUDIO and Text Relay  
> modes.
>
> D.4 State transition and text handling
> The following description assumes that a V.151-compliant Gateway is  
> in communication with an ITD and media flows have been established  
> to transport text over IP in accordance with RFC 4103.
>
> When the gateway compliant to this annex detects a PSTN textphone  
> that it supports using text relay, it shall autonomously connect to  
> the textphone.  After connection on the PSTN side, the gateway  
> shall open the text channel to the ITD. It shall decode the  
> characters received and transmit those to the ITD, giving proper  
> respect to the maximum character-per-second (CPS) parameter  
> advertised by the ITD.  Determining the type of PSTN textphone  
> device in use is the responsibility of the Gateway and the ITD need  
> not concern itself with what kind of PSTN textphone device is  
> connected to the Gateway.
>
> Likewise, when the ITD first has characters to send to the Gateway  
> using text/140 payload type, the ITD opens the text channel if it  
> was not opened before. Then the ITD transmits the characters to the  
> Gateway. The Gateway shall perform a probing, as necessary, to  
> determine the type of PSTN device connected, if any.  While  
> probing, the Gateway shall buffer any characters received and  
> transmit those when probing completes and the gateway is connected  
> to the text phone.  The size of the character buffer is a matter of  
> implementation, but should support the reception and buffering of  
> characters for at least 60 seconds at the specified maximum  
> character-per-second (CPS) value signaled to the ITD.
>
> If the Gateway does not support the modulation used by the PSTN  
> textphone device, the Gateway may transmit the received textphone  
> signals via VBD or the audio stream, depending on the capabilities  
> of the ITD.  Further, the Gateway may simply discard characters  
> received from the ITD or transmit them to the PSTN textphone device  
> using a pre-provisioned modulation.
>
>
> /
>
> Gunnar
> ---------------------------------------------------------------------- 
> -------
> Gunnar Hellström, Omnitor
> [email-masked] <mailto:[email-masked]>
> Mob: +46 708 204 288
> Phone: +46 8 556 002 03
> www.omnitor.se <http://www.omnitor.se>
>
>
> -----Original Message-----
> From: Jani Hautakorpi (JO/LMF) [mailto:[email-masked]]
> Sent: Wednesday, May 17, 2006 10:12 AM
> To: Cullen Jennings
> Cc: [email-masked]; [email-masked]; Gonzalo
> Camarillo; IETF MMUSIC WG
> Subject: [MMUSIC] Re: ietf-mmusic-sdp-media-content-03
>
>
> Hi Cullen,
>
> Cullen Jennings wrote:
> > I was just reviewing this document and I can't figure out  the
> > difference from user-floor and txp from the point of view describing
> > the content.
>
> Actually, there are no major differences between them, but Gunnar
> Hellstrom and Arnoud van Wijk (in the cc:) really wanted a value that
> was "txp". Gunnar and Arnoud can explain this better, but the main
> reason is that this way they can refer to and further describe the  
> usage
> of "txp" from some other draft, e.g. ietf-draft-sipping-toip.
>
> > It seems like this might be better to indicate that the
> > content type was "simplex" as normal media is assumed to be  
> "duplex".
>
> This is a matter of naming. Personally I believe that "user-floor" is
> more descriptive than "simplex", because there can also be such one- 
> way
> media that doesn't require user level floor control. What do you  
> think?
>
> > I'm not sure I like what I am proposing here but I think we need to
> > improve on the definition for these two. The current description  
> of  txt
> > does not seem to match the requirements for it on the email list   
> and
> > the definition of user-floor I have no idea when to add to a stream.
>
> I would say that "txp" is exactly what was described on the mmusic's
> mailing list, please see the "[MMUSIC] I-D ACTION:
> draft-ietf-mmusic-sdp-media-content-01.txt" thread, starting 18th Feb.
>
> Regarding the addition of "user-floor" to media stream: The device  
> that
> needs to add this value knows it by itself. For example, a new
> walkie-talkie type of device can know that it requires user level  
> floor
> control. But of course we can try to elaborate this on the draft,  
> if you
> want.
>
> > It also might be nice to provide more guidance on what is  
> appropriate
> > to signal with "content" and what is not. For example, I would  
> not  want
> > people signaling the mpeg profile using this. I think what we   
> want to
> > do here is something like signal the "semantic content" of  the  
> stream
> > such that an application that is offered multiple streams  can  
> pick the
> > right stream or map the streams to the users  preferences. Would  
> it be
> > possible to add more text about what would  not be appropriate to  
> use
> > this registry for.
>
> I really can't see how somebody could try to signal the mpeg profile
> with this draft, because it just doesn't have enough features for
> signaling such information. I feel that the possible use scenarios are
> already quite limited, and it's hard for me to invent how anybody  
> could
> misuse this draft. But, if you (or somebody else) can come up with  
> some
> valid, non-appropriate use cases, I'm happy to add them to the draft.
>
>
> --
> Jani
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

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

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 24 Jun 2006 12:55:58 -0700

Ok, I just entered proper comments in tracker, bit more inline here.

On Jun 20, 2006, at 3:29 PM, Colin Perkins wrote:

> way to proceed? If an updated draft is needed, I'd like to get it  
> in before the deadline. Cullen? Jani?
>
> Colin
>
>
>
>
>> I agree that the content parameters "txp" and "user-floor"  
>> indicate similar functionality.
>>

I've no problem with one, both, or three but it needs to be clear  
what implementers need to do.

>> turn-taking, alternating text - voice communication in PSTN. But  
>> it can also be used just as a warning to the IP user to be aware  
>> of possible limitations in simultanity and duplex use of media.
>>
>> We could go deeper in specifying exactly what limitations are  
>> valid at each moment, but I doubt that any manufacturer want to  
>> refine their gateway designs to that degree.
>> -    half-duplex-interruptable  ( when only one direction at a  
>> time should be used for contents, but it is possible to send an  
>> requirements to keep gateway resources low by allowing it to set  
>> up a real-time text connection between a PSTN gateway and an IP  
>> terminal only when there are indications that text will be used.  
>> It is a compromise that may be needed in reality.

I agree this is needed - just want it to be clear.

>> Accept-Contact: *;text;require

It seems like the 3840 style stuff may be the way you want to signal  
this.

>> communication-------------------------------------------------------- 
>> ----------------
>>
>> Annex defines the procedures that may be used in order to allow  
>> for such interworking between V.151 Gateways and ITDs. The main  
>> audio and text data when used for Gateway - to - gateway  
>> operation, V.151 gateways need to support both RFC 4103 to  
>> interwork with ITDs and RFC 4351 for communicating with other PSTN  
>> gateways.
>>
>> It should be used to indicate to the ITD user that the text  
>> channel is half duplex and turn-taking habits should be used.
>>
>>
>>
>> initially, but indicating text support and that the text support  
>> is alternating with audio:
>>
>> If the answering device is an ITD, with no specific indication  
>> that text would be used,  it would accept only the G.711 audio.
>>
>>       Contact: <uri>;text
>>
>>       m=audio 7200 RTP/AVP 0
>>
>>
>>
>> included text/140 in the offer. For other cases, the terminal  
>> needs to do a reinvite to add text to the call.
>>
>> The network would try to connect to a text capable gateway, but  
>> may connect through a non capable. The gateway may decide to not  
>> state transition to ToIP.  Rather, once a media flow is  
>> established to transport T.140 characters, either the Gateway or  
>> the ITD may transmit text immediately and without further  
>> negotiation.  Payload type switching is used to transition between  
>> AUDIO and Text Relay modes.
>>
>> The following description assumes that a V.151-compliant Gateway  
>> is in communication with an ITD and media flows have been  
>> established to transport text over IP in accordance with RFC 4103.
>>
>> that it supports using text relay, it shall autonomously connect  
>> to the textphone.  After connection on the PSTN side, the gateway  
>> device in use is the responsibility of the Gateway and the ITD  
>> need not concern itself with what kind of PSTN textphone device is  
>> was not opened before. Then the ITD transmits the characters to  
>> the Gateway. The Gateway shall perform a probing, as necessary, to  
>> to the text phone.  The size of the character buffer is a matter  
>> of implementation, but should support the reception and buffering  
>> of characters for at least 60 seconds at the specified maximum  
>> received from the ITD or transmit them to the PSTN textphone  
>> device using a pre-provisioned modulation.
>>
>>
>> /
>>
>> Gunnar
>> --------------------------------------------------------------------- 
>> --------
>> more descriptive than "simplex", because there can also be such  
>> one-way
>> > does not seem to match the requirements for it on the email  
>> list  and
>> > possible to add more text about what would  not be appropriate  
>> to use
>> > this registry for.
>>

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sun, 25 Jun 2006 01:00:44 +0200

Hi,

You want a more stringent text for the "txp" parameter.

The current one in -03 is:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

   txp: This indicates that the media stream is originated from a
      textphone, and it requires special behavior from the receiving
      application.  A typical use case for this is a connection where
      one endpoint is an analog textphone of a kind that cannot handle
      two-way simultaneous text communication, and the other one is a
      native IP based real time text capable terminal.  The human users
      normally need to apply formal turn-taking habits, and need to
      figure out to what extent it is possible to interrupt the other
      party if the need arises.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I looked back into the earlier discussion. I had a proposed line about
that the application should give an indication to the user. That was deleted
with the motivation that application actions should not be documented in
this draft.
However, I see no other use of the "txp" parameter ( and also the
"user-floor" parameter ) than to convey it clearly to the user because it
requires different behaviour from the user.

So, I suggest to modify the wording to clearly indicate that "txp" is only
sent from a party knowing that its real-time text presentation capability is
limited.

And I suggest to enter a few words of the intended usage of the parameter.
This is new text proposal:

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
   txp: This indicates that the media stream is originated from a
      textphone that is incapable of handling simultaneous
      two-way communication. This limitation requires special behavior
      from the user of a terminal receiving the indication. The
      indication should be used for an indication in the user interface.

      A typical use case is a connection where one endpoint
      is an analog textphone of a kind that cannot handle two-way
      simultaneous text communication, and the other one is a native
      IP based real time text capable terminal.  The human user
      need to change behaviour when this indication is received, and
      apply formal turn-taking habits. They may also need to figure
      out to what extent it is possible to interrupt the other
      party if the need arises.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

The earlier discussion indicated that there are too many variations in
capability to handle simultaneity and two-way communication in legacy
textphones for it to be realistic to give detailed info with txp
subparameters. So, I prefer to just indicate "txp" for all.

I would appreciate very much to get comments on the procedures described
below in proposed V.151 Annex D2 as well.

Regards
Gunnar

-----Ursprungligt meddelande-----
Från: Cullen Jennings [mailto:[email-masked]]
Skickat: den 24 juni 2006 21:56
Till: Colin Perkins
Kopia: Gunnar Hellstrom; Jani Hautakorpi (JO/LMF); IETF MMUSIC WG;
[email-masked]; Gonzalo Camarillo
Ämne: Re: [MMUSIC] Re: ietf-mmusic-sdp-media-content-03

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Sun, 25 Jun 2006 11:55:32 +0200

The new proposal text as suggested by Gunnar covers the usage of txp in the
best way.
Note: The Dutch mobile textphone platform has already implemented the
parameter txp as in the proposed text. And it works very well.

Greetz

Arnoud

Arnoud A. T. van Wijk
AnnieS New Technology
www.AnnieS.nl
Mobile textphone (SIP): [email-masked]

> From: Gunnar Hellstrom [mailto:[email-masked]]
> Sent: zondag 25 juni 2006 1:01
> To: Colin Perkins; Cullen Jennings; [email-masked]
> Cc: Gonzalo Camarillo; [email-masked]; IETF MMUSIC WG; Jani
> Hautakorpi (JO/LMF)
> Subject: SV: [MMUSIC] Re: ietf-mmusic-sdp-media-content-03
> 
> Hi,
>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 25 Jun 2006 10:29:30 -0700

Ok - if this is the best we can define it, I'm ok with that as it is.  
If there is an good document that we could provide an formational  
referfrece to that defined a textphone, that would be good but if not  
we don't have to have a reference for this.

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sun, 25 Jun 2006 20:23:38 +0200

Cullen,

First a small addition: The "human user" mentioned in the middle of the new
text should be extended to read: "the human user of the IP terminal"

Then, you asked for references for better understanding of the limitations
in PSTN textphone protocols.

ITU-T V.18 "Modem operation in the text telephone mode."
is the traditional source. Even if it mainly deals with modem
discrimination, it also tells for each legacy type if it is half duplex or
full duplex.

But more words around what to do when converting between the legacy types
and full duplex, simultaneous real-time text and voice is found in a couple
of other documents:

ITU-T H.248.2 Facsimile, text conversation and call discrimination packages.
Describes gateway procedures between PSTN textphones and SIP.

ETSI EG 202 320 Duplex Universal Speech and Text.
Has all standardised legacy textphone methods briefly described and also SIP
real-time text and gateway procedures between them.

If you want to stay within IETF, you may refer to RFC 2805, where section
11.2.4 gives a very brief insight in the requirements for interworking with
legacy textphones with the following words:

>From RFC 2805:
"11.2.4.  Trunking/Access Gateway with text telephone access ports

   An access gateway with ports capable of text telephone communication,
   must provide communication between text telephones in the SCN and
   text conversation channels in the packet network.

   Text telephone capability of ports is assumed to be possible to
   combine with other options for calls as described in section 11.2.6
   (e.) on "Adaptable NASes".

   The port is assumed to adjust for the differences in the supported
   text telephone protocols, so that the text media stream can be
   communicated T.140 coded in the packet network without further
   transcoding [7].

   The protocol must be capable of reporting the type of text telephone
   that is connected to the SCN port. The foreseen types are the same as
   the ones supported by ITU-T V.18:  DTMF, EDT, Baudot-45, Baudot-50,
   Bell, V.21, Minitel and V.18. It should be possible to control which
   protocols are supported. The SCN port is assumed to contain ITU-T
   V.18 functionality [8].

   The protocol must be able to control the following functionality
   levels of text telephone support:

   a.   Simple text-only support: The call is set into text mode from
        the beginning of the call, in order to conduct a text-only
        conversation.

   b.   Alternating text-voice support: The call may begin in voice mode
        or text mode and, at any moment during the call, change mode on
        request by the SCN user. On the packet side, the two media
        streams for voice and text must be opened, and it must be
        possible to control the feeding of each stream by the protocol.

   c.   Simultaneous text and voice support: The call is performed in a
        mode when simultaneous text and voice streams are supported. The
        call may start in voice mode and during the call change state to
        a text-and-voice call.

   A port may implement only level a, or any level combination of a, b
   and c, always including level a.

   The protocol must support:

   d.   A text based alternative to the interactive voice response, or
        audio resource functionality of the gateway when the port is
        used in text telephone mode.

Greene, et al.               Informational                     [Page 28]

RFC 2805            MG Control Protocol Requirements          April 2000

   e.   Selection of what national translation table to be used between
        the Unicode based T.140 and the 5-7 bit based text telephone
        protocols.

   f.   Control of the V.18 probe message to be used on incoming calls.
"

Since RFC 2805 refers to V.18, I suggest that you include a reference to RFC
2805.

/ Gunnar

-----------------------------

-----Ursprungligt meddelande-----
Fran: Cullen Jennings [mailto:[email-masked]]
Skickat: den 25 juni 2006 19:30
Till: Arnoud van Wijk
Kopia: 'Gunnar Hellstrom'; 'Colin Perkins'; 'Gonzalo Camarillo'; 'IETF
MMUSIC WG'; 'Jani Hautakorpi (JO/LMF)'
Amne: Re: [MMUSIC] Re: ietf-mmusic-sdp-media-content-03