Subject: Re: [MMUSIC] Re: SDP QoS Mechanism Identification

From: Gonzalo Camarillo <[email-masked]>
Date: Sat, 03 Mar 2007 11:48:29 +0200

Hi Jean Francois,

good points. I have added the following sentence to indicate that the 
attributes are not interdependent:

    The 'qos-mech-send' and 'qos-mech-recv' attributes are not
    interdependent; one can be used without the other.

Now the section related to subsequent offer/answer exchanges reads as 
follows:

4.4.  Subsequent Offer/answer Exchanges

    If, during an established session for which the QoS mechanism to be
    used for a given direction was agreed using the mechanism defined in
    this specification, an endpoint receives a subsequent offer that does
    not contain the QoS selection attribute corresponding to that
    direction (i.e., the 'qos-mech-send' or 'qos-mech-recv' attribute is
    missing), the endpoints SHOULD continue using the same QoS mechanism
    used up to that moment.

I will be submitting a new revision of the draft with the changes above 
before the cut off. As agreed, I will still submit it as individual (we 
will wait for the charter to be updated in order to submit it as a WG item).

Until it appears in the archives, you can fetch it from:

http://users.piuha.net/gonzalo/temp/draft-polk-mmusic-qos-mechanism-identification-03.txt

Cheers,

Gonzalo

Jean-Francois Mule wrote:
> Gonzalo,
> 
>    The draft should make it clear that 'qos-mech-send' and
> 'qos-mech-recv' session and media-level attributes are not
> inter-dependent: one could be used without the other. 
> 
> Gonzalo Camarillo wrote:
>> 4.4.  Subsequent Offer/answer Exchanges
>>
>>    If, during an ongoing session that uses QoS, an endpoint receives a
>>    subsequent offer that does not contain the 'qos-mech-send' and
> 'qos-
>>    mech-recv' attributes, the endpoints SHOULD continue using the same
>>    QoS mechanism or mechanisms used up to that moment.
> 
> Here are a few questions/comments on this new requirement text.
>>    If, during an ongoing session that uses QoS, an endpoint receives a
>                    ^^^^^^^         ^^^^^^^^^^^^^
> s/ongoing/established?
> I thought about active but you could have an established session where
> the media is not active in one or both directions so that may be
> confusing.
> 
> "that uses QoS" implies that QoS was successfully negotiated, this is
> misleading as this requirement may apply to sessions where no QoS is in
> effectively use but for which a QoS negotiation was attempted (and
> potentially failed).
> What qualifies this session is not that QoS is in use, but rather that a
> QoS mechanism was attempted in the first O/A due to the token lists.
> 
> Suggest expanding the text to say something like: during an established
> session for which the QoS mechanism(s) were previously exchanged, ...
> with better wording.
> 
>>    subsequent offer that does not contain the 'qos-mech-send' and
> 'qos-
>>    mech-recv' attributes, 
> 
> Given that those 2 attributes are not necessarily linked or
> inter-dependent, it suffices that only one attribute is left out of the
> subsequent offer for this requirement to be applicable. If this is true,
> then this sentence should be modified (at a minimum, say "or", or
> better, reword to take into account the potential asymmetries.
> 
>> the endpoints SHOULD continue using the same
>>    QoS mechanism or mechanisms used up to that moment.
> You may consider adding a note that QoS re-negotiations using the same
> QoS mechanisms might however be required.
> 
> 
> Jean-Francois.
> 
> 

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