Subject: [siprec] Comments on draft-ietf-siprec-metadata

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 11 May 2011 19:01:52 +0530

1) The rational for associating Media Streams with Participants looks
obvious. However, the rational for associating them directly with CS is
not so. There is no description in the draft on how the direct
association of Media Streams with CS is going to be beneficial for the
SRS when the same can be inferred from the indirect association of Media
Streams with Participants and Participants with the CS.
 
2) 4.5. Media Stream
   o  Codec params - represents codec parameters of the CS media
   o  Media Stream Reference - In implementations this can reference to
      m-line
 
It is not clear what the motivations are for these attributes and how
they are going to be beneficial for the SRS.
 
3) 5.4.1. Case 1
a) Shouldn't Participants D, E, F and G be attached to Participant B
(which is also an SRC) instead of Media Stream B1?
b) Shouldn't Media Stream A1 be associated with the CS? (provided there
is rational in #1).
 
4) 5.4.2.  Case 2
The first diagram shows Participant C receiving and mixing media streams
from Participants B, D and E, whereas the diagram below shows
Participant C receiving and mixing media streams from Participants D and
E only. Also, it looks a bit convoluted with page breaks.
 
5) The draft isn't consistent with usage of 'Participant' and
'participant'. The former seems to indicate the Participant
block/element, but they are used interchangeably as in:
4.3.2.  Associations
   o  Participant may be associated with zero or more CS's (It is
      possible, though unlikely, that there are participants who are not
      part of any CS).  An example of such a case is participants in a
      premixed media stream.  The SRC may have knowledge of such
      Participants, yet not have any signaling relationship with them.
      This might arise if one participant in CS is a conf focus.
 
6) 4.3.  Communication Session
   o  Call Termination Reason - This represents the reason why a CS was
      terminated.  The communication session MAY contain a Call.
 
If the SRC is a focus with many participants would each participant
joining the conference be considered a call? If the intention is to
indicate the CS termination reason, it seems better to call this
attribute as just Termination Reason.
 
Nitpicks:
 
7) Section 3 (Metadata Model):
For instance, the timing of changes may not explicitly conveyed from the
SRC to the SRC, because the mechanism (yet to be defined) which conveys
the metadata may implicitly provide the timing.  (E.g. the time a change
occurred by be assumed to be the same as the time when notification of
the change is received by the SRS.)
 
s/SRC to the SRC/SRC to SRS/
s/by be assumed/may be assumed/
 
8) 4.5. Media Stream
A Media Stream block shall have properties of media as seen by SRC and
sent to SRS.
 
s/shall have/SHALL have/
 
Muthu

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 May 2011 15:02:14 -0400

Muthu,

> Streams with Participants and Participants with the CS.

They can't necessarily be inferred, because the same participant can be 
associated with multiple CSs and with multiple MSs without all the MSs 
being in all the CSs.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 16 May 2011 09:36:26 +0530

Hi Muthu,
 
Thanks for your comments in Metadata. Please read inline.
 
Thanks
Partha

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Muthu ArulMozhi Perumal (mperumal)
Sent: Wednesday, May 11, 2011 7:02 PM
To: [email-masked]
Subject: [siprec] Comments on draft-ietf-siprec-metadata

2) 4.5. Media Stream
   o  Codec params - represents codec parameters of the CS media 
<Partha> This issue is tracked as
http://trac.tools.ietf.org/wg/siprec/trac/ticket/71. The intent of the
Codec params is to use RS SDP but it is still open issue </Partha>
 
   o  Media Stream Reference - In implementations this can reference to
      m-line  
<Partha> This attribute is label attribute reference from Metadata XML
</Partha>

3) 5.4.1. Case 1
a) Shouldn't Participants D, E, F and G be attached to Participant B
(which is also an SRC) instead of Media Stream B1?
<Partha> Figure needs to be updated as per the current closure of all
participant are under CS. The current figure is as per the earlier
understanding of participant are directly under RS instead of CS
</Partha>
 
b) Shouldn't Media Stream A1 be associated with the CS? (provided there
is rational in #1). 
<Partha>  Linkage is missing which will be added in the next revision
</Partha> 
 
4) 5.4.2.  Case 2
 
'participant'.  
 
<Partha> Participant is represented as a metadata block always. I'm not
very clear on your concern </Partha>
 The former seems to indicate the Participant block/element, but they
are used interchangeably as in:
4.3.2.  Associations
   o  Participant may be associated with zero or more CS's (It is
      possible, though unlikely, that there are participants who are not
      part of any CS).  An example of such a case is participants in a
      premixed media stream.  The SRC may have knowledge of such
      Participants, yet not have any signaling relationship with them.
      This might arise if one participant in CS is a conf focus.

<Partha> This shall be changed in the next revision </Partha>  
 
Nitpicks:

 
8) 4.5. Media Stream
 
s/shall have/SHALL have/ 
<Partha> Normative language has to revisited in the next revision
</Partha> 
 
Muthu