Re: [MMUSIC] AD review: draft-ietf-mmusic-image-attributes-06
Kyunghun Jung <kyunghun.jung@samsung.com> Mon, 27 September 2010 06:48 UTC
Return-Path: <kyunghun.jung@samsung.com>
X-Original-To: mmusic@core3.amsl.com
Delivered-To: mmusic@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E93C23A6C70 for <mmusic@core3.amsl.com>; Sun, 26 Sep 2010 23:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.231
X-Spam-Level:
X-Spam-Status: No, score=-0.231 tagged_above=-999 required=5 tests=[AWL=-1.078, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_19=0.6, MIME_BASE64_BLANKS=0.041, MIME_BASE64_TEXT=1.753, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf-n5RugDtso for <mmusic@core3.amsl.com>; Sun, 26 Sep 2010 23:48:42 -0700 (PDT)
Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by core3.amsl.com (Postfix) with ESMTP id 805C33A6B6F for <mmusic@ietf.org>; Sun, 26 Sep 2010 23:48:41 -0700 (PDT)
Received: from ep_ms7_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (Sun Java(tm) System Messaging Server 7u3-15.01 64bit (built Feb 12 2010)) with ESMTP id <0L9E009BT89WWZA0@mailout1.samsung.com> for mmusic@ietf.org; Mon, 27 Sep 2010 15:49:08 +0900 (KST)
Received: from ep_spt01 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0L9E002NH89XMY@ms7.samsung.com> for mmusic@ietf.org; Mon, 27 Sep 2010 15:49:10 +0900 (KST)
Content-return: prohibited
Date: Mon, 27 Sep 2010 06:49:07 +0000
From: Kyunghun Jung <kyunghun.jung@samsung.com>
To: Robert Sparks <rjsparks@nostrum.com>
Message-id: <0L9E002NI89XMY@ms7.samsung.com>
MIME-version: 1.0
MIME-version: 1.0
Content-type: text/html; charset="windows-1252"
Content-transfer-encoding: base64
X-Priority: 3
Msgkey: 20100927054413800@kyunghun.jung
X-MTR: 20100927054413800@kyunghun.jung
X-EPLocale: ko_KR.windows-1252
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale:
X-EPHeader: ML
X-EPTrCode:
X-EPTrName:
X-MLAttribute:
X-RootMTR: 20100927052607360@kyunghun.jung
X-ParentMTR: 20100927052607360@kyunghun.jung
X-Generator: Namo ActiveSquare 7 7.0.0.42
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, "draft-ietf-mmusic-image-attributes@tools.ietf.org" <draft-ietf-mmusic-image-attributes@tools.ietf.org>
Subject: Re: [MMUSIC] AD review: draft-ietf-mmusic-image-attributes-06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: kyunghun.jung@samsung.com
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Sep 2010 06:48:44 -0000
Hi,
I am afraid for this late reply. Here in Korea we had a seven-day holidays last week.
My answers to your kind (and second set of) comments (shown in blue) are shown below (in red).
Kyunghun Jung
Samsung Electronics Co., Ltd.
The problem is that without that definition, you have normative requirements in this draft that are ambiguous.
Saying that a "high end" device MUST do something without characterizing the device does not help interoperability.
If you are not willing to provide something an implementer can use to unambiguously know the requirement applies
to his implementation, you need to change all of these requirements to MAY.
-> O.k. "high end" might be removed in several locations in the draft without affecting the intention of the document:
a high end device which sees no reason to use the image attribute -> a device which sees no reason to use the image attribute.
The draft needs to say when this will happen. I think you missed an important part of my comment.
-> We believe that such an infinite negotiation can happen but this new attribute shall not be responsible for such an event.
Use of "a=imageattr" in fact can delay the negotiation procedure at the cost of a more refined codec configurations. However,
imageattr is not the only source of possible infinite delay. Such an infinite exchange of SDP offers and answers originate from
the basic design principles of SIP and SDP.
If the state machine inside a device is poorly programmed such that it rejects any offer even only slightly different from its preferred
configuration, the negotiation will continue until the answerer finds the one. This way, the level of refined negotiation is traded for the
delay to reach the configuration.
For example, RFC4867 defines RTP payload types for AMR and AMR-WB speech codec, which have 8 and 9 pre-defined bit-rates
called "mode." A SDP parameter defined in this RFC, "mode-set," enables a reduced set of modes to be negotiated but the answer
can either accept or reject the offer. To reach an absolutely intended configurations, a significant number of negotiations may be necessary.
Whether to use this feature or not is left as the discretion of the implementation and no mechanisms against infinite negotiation is defined
for "mode-set." 3GPP recommends the use of this attribute only by the multimedia gateway and the handset is required to supporte
all modes.
If you are concerned about the possibility that no size specified by the imageattr attribute can be supported by the answerer, please note
that typical codec specifications does not require any image size to be mandated or supported at a given level, with the possible exception of
the smallest sizes such as QCIF. Therefore such a possibility is out of the scope of this draft.
Support of more image sizes will reduce the setup delay of course. In MPEG-4 or H.264, the codec standards only specify the maximum image
sizes supported at a level and most codec implementations are developed with this in mind. In other words, there exist many methods to exit
an infinite negotiation by falling back to a basic configuration.
------- Original Message -------
Sender : Robert Sparks<rjsparks@nostrum.com>
Date : 2010-09-18 04:58 (GMT+09:00)
Title : Re: [MMUSIC] AD review: draft-ietf-mmusic-image-attributes-06
inline
Hi,
Let me answer some of your questions.
Kyunghun Jung
Samsung Electronics Co., Ltd.
------- Original Message -------
Sender : Robert Sparks<rjsparks@nostrum.com>
Date : 2010-08-20 03:06 (GMT+09:00)
Title : [MMUSIC] AD review: draft-ietf-mmusic-image-attributes-06
(There is a copy of these comments at http://www.nostrum.com/~rjsparks/mmusic-image-attributes.txt" rel="nofollow">http://www.nostrum.com/~rjsparks/mmusic-image-attributes.txt
for awhile in case any mail clients re-wrap the lines in a way that makes this too hard to read).
The document places requirements on "high end" devices without defining them or characterizing
them beyond what you can take away from the name. Without a more objective definition, these
requirements effectively reduce to "Some implemantation MAY" do these things. If that's what you
mean, please say it that way. If you really are trying to inflict SHOULDs and MUSTs on something,
please reduce the ambiguity in what they are.-> This attribute is initially designed with handsets supporting 4G mobile video telephony in mind
where media is transported over very expensive bandwidth but its nenefits can be enjoyed by other
devices if quality loss and unnecessary computation from rsizing is to be avoided.
Although we at 3GPP consider "high end" as the description of mobile communications devices with
high computational power with high resolution display (but smaller dot picth), supporting mutiple radio
frequency bands or roaming capability, we did not find enough reason to introduce such device specifications
or classifications of a specific inductry or product in the Internet draft.
The draft needs to say when this will happen. I think you missed an important part of my comment.
I'm surprised that there hasn't been more discussion around the message size bloat
associated with including an imageattr line with "send * recv *" in offers where the offerrer
isn't planning to use this document's extension. Have I missed that searching the archives?
If so, please provide a pointer. Were other negotiation mechanisms considered?Since the problem was initially discussed at 3GPP in June 2007 and informed to IETF MMUSIC,
hundreds of emails containing comments and answers were exchanged. The negotiation mechanisms
were designed here based on the received suggestions and corrections. In fact, initial idea was to
recycle (extend the usage of) existing SDP attributes, not defining a new one.
It might be difficult to zip the hundreds of e-mails exchanged here and send it to you or release in the
mailing list but let me introduce key documents which might be used to understand the background
of asking IETF to solve this problems.
http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_44/Docs/S4-070408.zip" rel="nofollow">http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_44/Docs/S4-070408.zip
http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_47" rel="nofollow">http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_47/Docs/S4-080083.zip" rel="nofollow">http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_47http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_47/Docs/S4-080083.zip" rel="nofollow">/Docs/S4-080083.zip
The document should better capture the motivation for allowing the answerer to create attribute
value entries that aren't covered by the offer's proposal. It should better describe _when_ additional
offer/answer exchanges would be induced (informing the operator as well as the implementor), and show
that this can't result in the infinite ping-pong loop that the general pattern of answering with a
subset of the offer was created to avoid in the first place.
-> It is not forbidden to add new sizes in the SDP answer and delay from additional negotiation isleft as the discretion of the implementation. Those intending to use their bit-rate in a more favourable
way need to take the risk of longer negotiation.
In section 3.1.1, the document should call out where to find the definition of
WSP and DIGIT you are intending to use. The last two lines of comments at the
end of key-value's ABNF need to start with semicolons
3.1.1.2: second bullet (o), last sub-bullet (*): It's not clear what "should not on its own include"
means. Are you trying to say that if an offer doesn't include an a=imageattr for a stream, then the
offer MUST NOT include one?
3.1.1.2: third bullet (o), first sub-bullet (*): This use of SHOULD is unclear. When would the
offer _not_ resort to other methods? I think you're trying to say that if the image attribute
is not included in the answer, then the offerer knows the answerer does not support this mechanism
and continues to process the answer as if this mechanism had not been offered.
3.1.1.2: second bullet (o), second sub-bullet (*): This has the same issue as the first sub-bullet.
Assuming I understand the intent, this would be clearer if you wrote along these lines:
* If the image attribute is included in the SDP answer, but none of the entries are usable or
acceptable, the offer MUST initiate a new offer/answer exchange without using the image attribute.
The draft should also indicate what to do with any media packets that might arrive before that second
offer/answer completes.
3.2.1: first paragraph - This MUST NOT belongs in 3.1.1.2, (at the last sub-bullet of the second bullet
if I've understood you), and it applies to _all_ answers, not just those to initial invites. I suggest
changing this sentence to something along these lines: "When the initial offer does not contain the
'imageattr' attribute, the rules in section 3.1.1.2 require the attribute to be absent in the answer."
3.2.6 : It's not clear what the purpose of this section is. If it's only to call out the problem and
capture the discussion of some possible solutions (but not specify a solution), that should be stated
more clearly. Right now, the text could be read to be recommending the solution in the 3rd bullet of
3.2.6.4, but it's not well specified. Either way, the document should note that using port 0 this way
may defeat the return of any information about image attributes from the answerer in the first
offer/answer round. Per 3264:
A port number of zero in the offer indicates that the
stream is offered but MUST NOT be used. This has no useful semantics
in an initial offer, but is allowed for reasons of completeness,
since the answer can contain a zero port indicating a rejected stream
(Section 6).
In section 6, it notes that media formats for rejected streams are ignored. Devices wishing to save
bandwidth may surpress any attributes associated with that m-line. Also, be very careful with the
semantics - when a slot for a rejected stream is reused, it is adding a new media stream, not
modifying/updating an existing stream.
4.2.3: The example claims it is presenting a complete SDP offer - it isn't. It would be more
accurate to say "more of the SDP offer is shown"
The draft needs to note that the coupling between the attributes in the offer and answer is associated
with the codec, not the payload type number. It's possible to negotiate different payload type numbers
for the same codec in the pair of unidirectional streams assocated with an m line. The offer can
indicate a PT number of 101 and the answer can use PT 102, for example. If that happens, the offerer
will be sending RTP with payload frames labeled 102 and the answerer will be sending frames labeled 101.
(But the answerer's SDP would have contained a=imageaddr:102).
It would also be good to call out what's allowed with this parameter when an m-line has more than one
payload type number mapped to the same codec.
Nits:
Introduction: last paragraph first sentence : This sentence doesn't parse for me.
Is it trying to say "This document is limited to point-to-point unicast communication scenarios"?
3.1.1.2: first bullet (o), second sub-bullet (*): Should "recommended" be in upper case?
3.2.9 : first paragraph: The MUST requirement in the 2nd sentence misrepresents what the answer is.
There are no unknown parameters to remove from the answer - the answer is not a copy of the offer,
it is content that the answerer generates. It would be better to say the answerer MUST ignore
any unknown parameters in the offer and MUST NOT include them in the answer it generates.
4.1 : The last part of this example is confusing. Instead of "If Bob does not support any x and y
resolution in any of of (sic) the X and Y ranges", perhaps you could say "If Bob does not support
any x and y resolution in one of the provided send or recv ranges". Then instead of starting the
next sentence as "In this case", start it as "For instance, if Bob doesn't support any of the offered
alternatives in the recv attr-list in the offer", and delete the sentence starting "In the above example".
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic" rel="nofollow">https://www.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] AD review: draft-ietf-mmusic-image-attri… Robert Sparks
- Re: [MMUSIC] AD review: draft-ietf-mmusic-image-a… Kyunghun Jung
- Re: [MMUSIC] AD review: draft-ietf-mmusic-image-a… Ingemar Johansson S
- Re: [MMUSIC] AD review: draft-ietf-mmusic-image-a… Ingemar Johansson S
- Re: [MMUSIC] AD review: draft-ietf-mmusic-image-a… Robert Sparks
- Re: [MMUSIC] AD review: draft-ietf-mmusic-image-a… Robert Sparks
- Re: [MMUSIC] AD review: draft-ietf-mmusic-image-a… Kyunghun Jung
- Re: [MMUSIC] AD review: draft-ietf-mmusic-image-a… Ingemar Johansson S
- Re: [MMUSIC] AD review: draft-ietf-mmusic-image-a… Ingemar Johansson S
- Re: [MMUSIC] AD review: draft-ietf-mmusic-image-a… Ingemar Johansson S