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

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

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): [e-mail]

> -----Original Message-----
> From: Gunnar Hellstrom [mailto:[e-mail]]
> Sent: zondag 25 juni 2006 1:01
> To: Colin Perkins; Cullen Jennings; [e-mail]
> Cc: Gonzalo Camarillo; [e-mail]; IETF MMUSIC WG; Jani
> Hautakorpi (JO/LMF)
> Subject: SV: [MMUSIC] Re: ietf-mmusic-sdp-media-content-03
> 
> 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