RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-04.txt

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> Thu, 20 July 2006 21:09 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3flo-0003zb-DJ; Thu, 20 Jul 2006 17:09:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3flO-0003Zl-31 for mmusic@ietf.org; Thu, 20 Jul 2006 17:08:54 -0400
Received: from pne-smtpout1-sn2.hy.skanova.net ([81.228.8.83]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3fhS-0006XM-46 for mmusic@ietf.org; Thu, 20 Jul 2006 17:04:51 -0400
Received: from Misan (213.64.228.153) by pne-smtpout1-sn2.hy.skanova.net (7.2.075) id 44A2E86F0044F599; Thu, 20 Jul 2006 23:04:49 +0200
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
To: Colin Perkins <csp@csperkins.org>
Subject: RE: [MMUSIC] I-D ACTION:draft-ietf-mmusic-sdp-media-content-04.txt
Date: Thu, 20 Jul 2006 23:04:42 +0100
Message-ID: <CCEIKIABCPCLIACIPNMKOEMGCFAA.gunnar.hellstrom@omnitor.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
In-Reply-To: <5F451929-D614-4F48-B89D-204DA2D8A753@csperkins.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Cc: mmusic@ietf.org
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Errors-To: mmusic-bounces@ietf.org

Colin,

I do not understand why the discussion has taken this turn.
As I remember it, the txp parameter was introduced by the authors sometimes
last autumn. It was a discussion between using the user-floor parameter and
having one specific and the decision was to have one specific, even if it
was no big preference.

Arnoud has declared that he has very good use of the parameter already in a
gateway - terminal implementation.

Then this winter we have been asked to refine the wording, and done so.

And now you start claiming that the whole idea was a mistake and should not
have been done without really saying what is wrong with having this
parameter.

You claim that I have proposed to use it for negotiation in the draft
amended V.151 Annex D, but I have not.
The explicit wording about use of the parameter is this:
"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."

It is clearly just an indication to the users. It must be shown in the user
interface.
It is not used to accept or deny the stream or anything like that. Just
simply to inform the user about the type of origin for this medium. No
negotiation.

Accept now?

Gunnar




----------------------------------------------------------------------------
-
Gunnar Hellstrom, Omnitor
gunnar.hellstrom@omnitor.se
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se


-----Original Message-----
From: Colin Perkins [mailto:csp@csperkins.org]
Sent: Thursday, July 20, 2006 5:00 PM
To: Gunnar Hellstrom
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] I-D
ACTION:draft-ietf-mmusic-sdp-media-content-04.txt


Gunnar,

On 20 Jul 2006, at 17:50, Gunnar Hellstrom wrote:
> The textphone with limitations we are talking about is in the PSTN.
> The
> gateway should not imply any limitations on the IP side.
>
> But we want to give the IP terminal user a hint that the far end
> user may
> not be able to receive anything while she is typing. So she must
> take care
> and adopt the old turntaking habits ending typing with GA and
> waiting for
> the other one to end with GA ( or whatever turntaking token is used
> in her
> country )

I understand your use case. I just do not think it appropriate for a
content label.

> That is very similar to using the user-floor parameter giving the
> user a
> hint that you may not be seen all the time and may need to request
> the floor and be acknowledged for the others to see you.
>
> We apparently need to enter more words around what terminal it is
> that has
> the limitations and how it influences the media flow ( = not at all
> on the
> IP path ).
>
> Would that eliminate your problems with the "txp" parameter?

No. If you make this a separate attribute, I will have no objections,
but as I have said before, I do not believe such feature negotiation
belongs in the content label attribute.

Colin

_______________________________________________
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