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

["Gunnar Hellstrom" <[e-mail]>]

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:[e-mail]]
Skickat: den 24 juni 2006 21:56
Till: Colin Perkins
Kopia: Gunnar Hellstrom; Jani Hautakorpi (JO/LMF); IETF MMUSIC WG;
[e-mail]; Gonzalo Camarillo
Ämne: Re: [MMUSIC] Re: ietf-mmusic-sdp-media-content-03



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

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

> 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.

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

>>
>> 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.

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

>>
>> 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

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


>>
>>
>> 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:[e-mail]>;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:[e-mail]>;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
>> [e-mail] <mailto:[e-mail]>
>> Mob: [phone]
>> Phone: [phone]
>> www.omnitor.se <http://www.omnitor.se>
>>
>>
>> -----Original Message-----
>> From: Jani Hautakorpi (JO/LMF) [mailto:[e-mail]]
>> Sent: Wednesday, May 17, 2006 10:12 AM
>> To: Cullen Jennings
>> Cc: [e-mail]; [e-mail]; 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
>> [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