Re: [AVT] FW: NewVersion Notification for draft-ietf-avt-ports-for-ucast-mcast-rtp-08

[Magnus Westerlund <[e-mail]>]

Ali C. Begen (abegen) skrev 2010-12-14 13:45:
> 
> I still think this adds unneeded complexity and complications. The visible profit is negligible (just saves some delay in certain - not all - cases).

Ok, I still think one should express this explicitly. But I can live
with not having an explicit list. However, I would like it to be very
clear that a client MUST have the capability to include the token with
any RTCP message type. So that in cases where a you get an error back
you have the capbability to include the token also for these messages.

Secondly, I would like to point out that it is not obvious unless we add
additional information in the error message which RTCP message type(s)
and sub-type(s) that caused an error message. That as there exist no
strong binding between a particular RTCP message and the error message.
So in cases multiple ones where sent in a short time frame the client
may be unable to determine which ones was refused.

> 
> Our proposal is to replace the "MUST"s in the 1st paragraph of 7.1 (and elsewhere if any) to something softer so that the attribute indicates a "hint" rather a "requirement".

Stop, don't run away here. This is two different cases. The current MUST
semantics is to my understanding, if the a=portmapping-req attribute is
present then there are something in this session requiring tokens to
use, i.e., you must have support for tokens to be able to participate. I
am strongly against changing that semantics unless it is to be more
specific on what is being required more than support for for port based
mapping. That is why I think the SDP attribute shall be included in all
media blocks (m=) where one sends RTCP messages requiring tokens.

The second part which I though we where discussing was the explicit
listing of messages that require token to be included. What the
semantics are of such a list is a different question from what the
general presence of the attribute is.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------