Re: [MMUSIC] Questions/Comments on draft-ietf-mmusic-sdp-bwparam-03.txt

[Magnus Westerlund <[e-mail]>]

Hi Geetha,

See comments below.

Geetha Srikantan wrote:
> hi Magnus,
> 
> Thanks for the response and clarifications.
> My response is inline.
> 
> 
> 
>>>2. Section 6.2.3, 2nd paragraph - it would be good to clarify that this 
>>
> entire 
> 
>>>   paragraph refers to the media level values.
>>>   This paragraph is a little confusing to read..it might help to mention
>>>   explicitly that it is RECOMMENDED to use both the AS and TIAS fields;
>>>   AS for backwards compatibility, older implementations would ignore the 
>>
> TIAS 
> 
>>>   field; TIAS would be recognized by newer and compliant implementations,
>>>   which must ignore the AS value.
>>
>>No, It does not only apply for the media level, but both levels. AS can 
>>be present at both levels, if one includes it at either level one is 
>>recommended to include TIAS also.
> 
> 
> I see..I didn't realize that AS can be present at the session level, too.
> 
> 
>>I don't quite understand what you mean with confusing to read. The 
>>information you ask for is there: "..., it is RECOMMENDED to also 
>>include the "AS" modifier when using "TIAS"". Do you have a more 
>>concrete proposal on how reformulate the paragraph?
> 
> 
> I meant 'confusing' in the sense that the motivation for this is
> not completely clear to me.
> I interpreted this part of the text to mean that - if both AS and TIAS values
> are present in the SDP, then a newer (i.e. bwparam-compliant) implementation 
> should ignore the AS values. An older (i.e. bwparam-non-compliant) 
> implementation would try to use the AS values and ignore the TIAS values. Is 
> that right? By providing both AS and TIAS values, it would permit 
> interoperability with older and newer implementations - if that is the only 
> reason, we might want to say so explicitly in the text. If there are other 
> reasons to provide both values, would you please
> explain?
> 

No, there exist no further reasons than backwards compatibility to 
include both values. Your correct in your deduction that a new 
implementation SHOULD only use the TIAS value, while an old not 
understanding TIAS will use AS. I think I provide enough explanation for 
these rule in the first part of the first sentence of paragraph 2 in 6.2.3.

Is the current text difficult to understand?



> 
>>>4. 6.3, is there any ambiguity in the last paragraph? For instance, is it ok 
>>
> to
> 
>>>   *not* have maxprate if one or the other of TIAS or the max packet rate 
>>>   for the transport is not available?
>>
>>Yes, if one can't derive a packet rate due to for example non packet 
>>based transport then its ok. However if you use TIAS and have a 
>>transport like IP/UDP/RTP you shall have it. Perhaps I should 
>>reformulate the sentence to be more strict and explanatory.
> 
> 
> 
> Thanks..that clarifies it. Perhaps something like this:
> 
> "maxprate" SHALL be included for all transports where a packet rate can be 
> derived and TIAS is included. For example, if you use TIAS and a transport like 
> IP/UDP/RTP, for which the max packet rate can be derived, then "maxprate" shall 
> be included. If either (a) the packet rate for the transport cannot be derived, 
> or (b) TIAS is not included, then, "maxprate" is not required to be included.
> 
> 

Thanks, I will use this with some modifications.



Best Regards

Magnus Westerlund

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

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