Re: [MMUSIC] AD review: draft-ietf-mmusic-image-attributes-06

[Ingemar Johansson S <[e-mail]>]

Hi

I just uploaded a new version of the image attribute where SHOULD is changed to MUST in section 3.1.1.2, with this change I hope that the issue below is fixed.
The remaing issues listed in http://www.ietf.org/mail-archive/web/mmusic/current/msg08319.html are still not resolved but I would suggest welcome that the document moves forward even it there is no solution to this.

Regards
Ingemar

________________________________
From: Ingemar Johansson S [mailto:[e-mail]]
Sent: den 29 september 2010 08:06
To: [e-mail]; Robert Sparks
Cc: [e-mail]; [e-mail]
Subject: RE: Re: [MMUSIC] AD review: draft-ietf-mmusic-image-attributes-06

Hi

Just as a (late) followup


3.1.1.2 (Answerer receiving the offer and sending the answer ) says



* The answerer may also, for its receive and send direction,

replace the entries with a complete new set of entries

different from the original proposed by the offerer. The

implementor of this feature should however be aware that this

may cause extra offer/answer exchanges.



Moreover (Offerer receiving the answer)

* If the image attribute is included in the SDP answer but none

of the entries are usablel or acceptable, the offerer SHOULD

resort to other methods to determine the appropriate image

size. In this case the offerer must also issue a new offer/

answer without the image attribute to avoid misunderstandings

between offerer and answerer.

In my opinion this should not lead to inifinite offer answers.


I would say that this should protect against infinte renegotiations. Alternatively I can consider a change from SHOULD to MUST to make things more strict.

Regards
/Ingemar

________________________________
From: Kyunghun Jung [mailto:[e-mail]]
Sent: den 27 september 2010 08:49
To: Robert Sparks
Cc: [e-mail]; [e-mail]
Subject: Re: Re: [MMUSIC] AD review: draft-ietf-mmusic-image-attributes-06


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.

What prevents this "longer" renegotiation from being infinite?

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