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:terminal@host.example.com>;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:terminal@host.example.com>;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
>> 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: Jani Hautakorpi (JO/LMF) [mailto:jani.hautakorpi@ericsson.com]
>> Sent: Wednesday, May 17, 2006 10:12 AM
>> To: Cullen Jennings
>> Cc: gunnar.hellstrom@omnitor.se; degodefroi@gmail.com; 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
>> mmusic@ietf.org
>> https://www1.ietf.org/mailman/listinfo/mmusic
>>
>>
>> _______________________________________________
>> 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