Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04

[Magnus Westerlund <[e-mail]>]

On 2011-11-04 03:13, Qin Wu wrote:
> ----- Original Message ----- 
> From: "Magnus Westerlund" <[e-mail]>
> To: "Qin Wu" <[e-mail]>
> Cc: "IETF AVTCore WG" <[e-mail]>; <[e-mail]>
> Sent: Thursday, November 03, 2011 9:48 PM
> Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-monarch-04
> 
> 
>> Hi,
>>
>> Removing all issues that don't need additional discussion or commenting.
>>
>>
>>
>> On 2011-10-25 07:45, Qin Wu wrote:
>>>
>>> 9. Section 4:
>>> "It is also
>>>       fixed across multiple RTP sessions from the same source."
>>>
>>> I interpret "source" in the above as an end-point or RTP node. Which
>>> causes me to have the following comment.
>>>
>>> This is very commonly true, but not universally true. As CNAME
>>> identifies a synchronziation context, a given end-point could have media
>>> sources that belong to multiple synchronization contexts in the same
>>> session. For example have microphones and cameras from multiple rooms,
>>> where each room will be its own synchronization context.
>>>
>>>
>>>
>>> [Qin]: Agree with your thinking, but here what we emphasize is "across multiple RTP session"
>>>
>>> Does this really conflict with what you said?
>>>
>>> Anyway I will reword this in the new vesion.
>>>
> 
>> No, as long as we consider source as media recording device(s) in a
>> given synchronization context they will be fixed across multiple sessions.
>>
> 
> 
> [Qin]: Okay, do we have other use cases besides the above one you gave?

Not from the top of my head.


>>>
>>> 21. Section 7.1:
>>>
>>> Strictly the RTP end
>>>    system can only conclude that its RTP has been lost in the network,
>>>    though an RTP end system complying with the robustness principle of
>>>    [RFC1122] should survive with essential functions unimpaired.
>>>
>>> What is the purpose with this sentence? And what is actually seen as
>>> "essential functions"?
>>>
>>>
>>>
>>> [Qin]: I think essential functions are referred to as "media distribution"
>>
>> So you mean that a robustly built end-point will still be able to send
>> its media despite the fact that media it should receive has been lost in
>> between the sender and this receiver?
> 
> [Qin]: That's my understanding, is that okay with you?

Yes.


> 
>>>
>>> 23. Section 8. I agree that this draft shouldn't have a IANA
>>> Consideration other to say that it is has no actions. However, I think
>>> the document should consider if it has some guidance on IANA actions for
>>> the monitoring architecture. Some part of this is clearly about the
>>> consumption of XR block code points that isn't a major issue. And if we
>>> do run out a second RTCP packet type for XR block 2 could be assigned.
>>>
>>>
>>>
>>> [Qin]: The WG consensus is space depletion is not issue
>>>
>>> if you really want space expansion, you can define one XR block type
>>>
>>>  for vendor-specific extensions, with an enterprise number included 
>>>
>>> to identify the vendor making the extension. So I prefer to say
>>>
>>> "There is no IANA action in this document"
>>
>> Yes, but if that is the conclusion, shouldn't we document it?
> 
> [Qin]: Okay, I can put them in the new version.

Great

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