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

From: Cullen Jennings <[email-masked]>
Date: Mon, 15 May 2006 03:12:57 +0200

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. It seems like this might be better to indicate that the  
content type was "simplex" as normal media is assumed to be "duplex".  
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.

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.

Cullen

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

---

From: "Jani Hautakorpi (JO/LMF)" <[email-masked]>
Date: Wed, 17 May 2006 11:11:40 +0300

Hi Cullen,

Cullen Jennings wrote:
> 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  

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?

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

> 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

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 18 May 2006 23:25:22 +0200

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,

--
Jani