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

[Magnus Westerlund <[e-mail]>]

Dan Wing skrev 2010-12-13 22:44:
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> David R Oran
>> Sent: Saturday, December 11, 2010 12:06 PM
>> To: Ali C. Begen (abegen)
>> Cc: [e-mail]
>> Subject: Re: [AVT] FW: New Version Notification for draft-ietf-avt-
>> ports-for-ucast-mcast-rtp-08
>>
>>
>> On Dec 11, 2010, at 12:28 PM, Ali C. Begen (abegen) wrote:
>>
>>> This revision changes the packet formats for port mapping. We are no
>> longer using the RTCP feedback packet format, instead we defined a new
>> RTCP control packet format. This was brought up by Colin and Magnus.
>>>
>> Looks good.
>>
>>> I checked the registry (for RTCP packet types) and grabbed the first
>> available number (210) for TOKEN. If anybody else is using it for
>> something else or planning to use it for something else, now is a good
>> time to let us know. We don't want any surprises later.
>>>
>>> For diff:
>>> https://datatracker.ietf.org/doc/draft-ietf-avt-ports-for-ucast-
>> mcast-rtp/history/
>>>
>>> Regarding the final remaining open issue, Magnus and I would like to
>> hear from others. See the thread here:
>>> http://www.ietf.org/mail-archive/web/avt/current/msg14028.html
>>>
>>> It is about whether the SDP should somehow signal what RTCP
>> packets/messages need to carry a Token (and where the 'portmapping-req'
>> attribute should be placed - in the multicast or unicast block in the
>> SDP. As the authors, we believe the current text in section 4.3 is
>> sufficient and in addition there is no clear way of doing this in the
>> SDP without introducing new issues.
>> Whether this adds complexity issues probably depends on exactly what
>> the semantic is. For example, if the SDP represents a "hint" to the
>> client to try to use a token request as opposed to a requirement that
>> his request won't work otherwise, I don't see a big problem. Clients
>> that don't take the hint still work, with the extra RTT.
> I like that.  It would always up to the server (not the SDP) to decide 
> if the server needs a token, anyway; this would just codify it that the 
> SDP is a hint to avoid a round trip.  This is better than an idea I
> was kicking around, which was for the client to just always include
> a token in every RTCP message (which has no computational burden to
> the client).

I think that is fine with me. A hint is all I ever wanted as I did
consider this as a potential interop issue. If you have a hint from the
server that you should send tokens on the following message types or I
will likely send an error that resolves that concern for me.

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