Subject: [siprec] Comment on metadata-02 - Media Stream

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Jul 2011 15:36:14 +0200

In section 6.5, Media Stream seems to be defined as follows:
"A Media Stream block MUST have properties of media as seen by SRC and
   sent to SRS."
Ignoring the possibly inappropriate RFC 2119 language, I don't think this clearly defines whether:
a) this represents a medium of the CS (i.e., corresponding to a media description in the CS SDP); or
b) this represents a medium of the RS (i.e., corresponding to a media description in the RS SDP).

Both of these are "seen by SRC". There need not be a 1:1 relationship between the two, and hence we need to make it clear which it represents.

Although personally I had expected a), a couple of threads in recent months have seemed to indicate b) is the general consensus.

Possibly a definition like:
"A Media Stream block represents a single RTP session between an SRC and an SRS. Note that, because of possible mixing at the SRC, a Media Stream block does not necessarily represent a single RTP session between CS participants."

However, if we accept this principle, I wonder what the Start Time and End Time attributes mean. The start and end of an RS RTP session correspond to the relevant offer-answer exchanges, so they don't really need to be in XML. So I suspect I still haven't drilled down into the real meaning of MS sufficiently.

John (as individual)

---

From: Leon Portman <[email-masked]>
Date: Thu, 7 Jul 2011 16:49:47 +0300

Actually I was expecting (a) as well. And it should point to the relevant media lines in RS SDP. If two or more Media Streams point to the same RS SDP m-line label, then we have mixing use case

So something like this: CS MS  (1:1)- > XML MS -> (N:1) -> RS MS

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Thursday, July 07, 2011 4:36 PM
To: [email-masked]
Subject: [siprec] Comment on metadata-02 - Media Stream

John (as individual)
 
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 8 Jul 2011 10:29:01 +0530

Hello John / Leon,

Thanks for your comments on MS block in the metadata. I agree that the
current text is little confusing.
It is because when we started off with the metadata draft we intended
that MS block represents properties of CS media.

However after discussions we reached to a consensus that MS does not
need to have CS media parameters. 

John's suggestion for definition is

> "A Media Stream block represents a single RTP session between an SRC
> and an SRS. Note that, because of possible mixing at the SRC, a Media
> Stream block does not necessarily represent a single RTP session
> between CS participants."

My suggestion is

"An MS block/class represents an entity which helps to link participants
( of CS) to its associated Media Streams ( in RS), the properties of
which will be carried in RS SDP".

Please suggest if this text works fine. If not refine/suggest
improvements.

Regards,
Ram

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Leon Portman
> Sent: Thursday, July 07, 2011 7:20 PM
> To: Elwell, John; [email-masked]
> Subject: Re: [siprec] Comment on metadata-02 - Media Stream
> 
> Actually I was expecting (a) as well. And it should point to the
> relevant media lines in RS SDP. If two or more Media Streams point to
> the same RS SDP m-line label, then we have mixing use case
> 
> Both of these are "seen by SRC". There need not be a 1:1 relationship
> between the two, and hence we need to make it clear which it
> represents.
> 
> Although personally I had expected a), a couple of threads in recent
> months have seemed to indicate b) is the general consensus.
> 
> "A Media Stream block represents a single RTP session between an SRC
> and an SRS. Note that, because of possible mixing at the SRC, a Media
> Stream block does not necessarily represent a single RTP session
> between CS participants."
> 
> However, if we accept this principle, I wonder what the Start Time and
> End Time attributes mean. The start and end of an RS RTP session
> correspond to the relevant offer-answer exchanges, so they don't
really
> need to be in XML. So I suspect I still haven't drilled down into the
> real meaning of MS sufficiently.
> 
> John (as individual)
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 8 Jul 2011 08:49:35 +0200

Ram,

In my opinion your proposed definition is too abstract - I think a reader would have a hard time understanding what such an object represents in the real world. Can you pinpoint your objections to my proposal?

Thanks,

John

> From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
> Sent: 08 July 2011 05:59
> To: Leon Portman; Elwell, John; [email-masked]
> Subject: RE: [siprec] Comment on metadata-02 - Media Stream
> 
> Hello John / Leon,
> 
> > Behalf Of Elwell, John
> > a) this represents a medium of the CS (i.e., corresponding 
> to a media
> > description in the CS SDP); or
> > b) this represents a medium of the RS (i.e., corresponding 
> to a media
> > description in the RS SDP).
> >

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 8 Jul 2011 12:30:21 +0530

John,

I don't have any such issues with your definition. I think we can add "
MS block helps to link participants ( of CS) to its associated Media
Streams ( in RS), the properties of which will be carried in RS SDP" to
your definition. 

I would like to have this line as it clearly says the intention /purpose
of MS block.

Regards,
Ram

> From: Elwell, John [mailto:[email-masked]]
> Sent: Friday, July 08, 2011 12:20 PM
> To: Ram Mohan R (rmohanr); Leon Portman; [email-masked]
> In my opinion your proposed definition is too abstract - I think a
> reader would have a hard time understanding what such an object
> represents in the real world. Can you pinpoint your objections to my
> proposal?
> 
> Thanks,
> 
> John
> 
> 
> > > Ignoring the possibly inappropriate RFC 2119 language, I don't
> think
> > > this clearly defines whether:

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 8 Jul 2011 14:31:44 +0200

OK, sounds like a good compromise.

John 

> Sent: 08 July 2011 08:00
> To: Elwell, John; Leon Portman; [email-masked]

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 8 Jul 2011 21:55:03 +0530

Hello John,

Regarding your other question on Start/Stop time attribute in MS block

The definition as per the current draft is:
 Start Time - Represents Media Start time at SRC.
 End Time - Represents Media End time at SRC.

We had a long discussion couple of months back on the Start/Stop time
attribute and what it means. It was a long thread with title " [siprec]
start/stop times & the metamodel". I just went through the thread again
to refresh my memory. It looks we *did not* reach to a *concrete*
conclusion even though there were some general agreements.

Refer to parts of mail thread here
http://www.ietf.org/mail-archive/web/siprec/current/msg01850.html
http://www.ietf.org/mail-archive/web/siprec/current/msg01814.html

To summarize these are some of the salient points we discussed at that
time:
- the start time of a media stream is the time (according to the CS) of
the first participant to a new media stream, and the stop time as the
time that the last participant leaves the media stream.
- There were discussions around how SRC derives this time (is it based
on wall clock time of SRC e.t.c)
- There was also discussions on what is the significance of start/stop
time w.r.t different RTP models (translator, endpoint) and how SRS may
want to use it for synchronization and playback

Now would be a good time to re-start the discussion again so that we can
conclude at least in IETF 81.

Regards,
Ram

> Sent: Thursday, July 07, 2011 7:06 PM
> To: [email-masked]
really

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 8 Jul 2011 21:59:35 +0530

So I would combine and have the text for MS block as:

" A Media Stream block represents a single RTP session between an SRC
and an SRS. Note that, because of possible mixing at the SRC, a Media
Stream block does not necessarily represent a single RTP session between
CS participants. MS block helps to link participants ( of CS) to its
associated Media Streams ( in RS), the properties of which will be
carried in RS SDP"

Please let me know if anyone has concerns otherwise I will incorporate
this text in the next version of draft.

Regards,
Ram

> Sent: Friday, July 08, 2011 6:02 PM
> > > > Thanks for your comments on MS block in the metadata. I agree
> that
> > > the
> > > > > "A Media Stream block represents a single RTP session between
> an
> > > SRC
> > > > > "A Media Stream block represents a single RTP session between
> an
> > > SRC

---

From: Leon Portman <[email-masked]>
Date: Sun, 10 Jul 2011 10:50:03 +0300

Sound good to me as well. May be we should say "to link participant media"?

Leon

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Friday, July 08, 2011 3:32 PM
To: Ram Mohan R (rmohanr); Leon Portman; [email-masked]
Subject: RE: [siprec] Comment on metadata-02 - Media Stream

John 

> Streams ( in RS), the properties of which will be carried in RS SDP" 
> to your definition.
> 
> I would like to have this line as it clearly says the intention 
> /purpose of MS block.
> 
> Regards,
> Ram
> 
> > > "An MS block/class represents an entity which helps to link 
> > > participants ( of CS) to its associated Media Streams ( in RS), 
> > > the
> properties of

---

From: Leon Portman <[email-masked]>
Date: Sun, 10 Jul 2011 10:57:46 +0300

Ram Hi

But do we want to link participant to RS media or Participant media to RS media? What will be the logic to reconstruct participant media sessions ( I am not talking about codecs and ports but types of the media for example). Specially ones that are not recorded or offered. I remember that we had discussion to support it.

Regards

Leon

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Friday, July 08, 2011 7:30 PM
To: Elwell, John; Leon Portman; [email-masked]
Subject: RE: [siprec] Comment on metadata-02 - Media Stream

" A Media Stream block represents a single RTP session between an SRC and an SRS. Note that, because of possible mixing at the SRC, a Media Stream block does not necessarily represent a single RTP session between CS participants. MS block helps to link participants ( of CS) to its associated Media Streams ( in RS), the properties of which will be carried in RS SDP"

Please let me know if anyone has concerns otherwise I will incorporate this text in the next version of draft.

Regards,
Ram

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Sun, 10 Jul 2011 14:31:59 +0530

Leon,

As you mentioned, it is possible to indicate special case of "not
recorded" through RS SDP as port value containing 0 in the media ("m="
line) level. Actual RTP session is NULL for those MS. In case you feel
that this definition has to be reworded, Pls suggest the text.

Thanks
Partha    

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Leon Portman
> Sent: Sunday, July 10, 2011 1:28 PM
> To: Ram Mohan R (rmohanr); Elwell, John; [email-masked]
> But do we want to link participant to RS media or Participant 
> media to RS media? What will be the logic to reconstruct 
> participant media sessions ( I am not talking about codecs 
> and ports but types of the media for example). Specially ones 
> that are not recorded or offered. I remember that we had 
> discussion to support it.
> 
> Regards
> 
> Leon
> 
> " A Media Stream block represents a single RTP session 
> between an SRC and an SRS. Note that, because of possible 
> mixing at the SRC, a Media Stream block does not necessarily 
> represent a single RTP session between CS participants. MS 
> block helps to link participants ( of CS) to its associated 
> Media Streams ( in RS), the properties of which will be 
> carried in RS SDP"
> 
> Please let me know if anyone has concerns otherwise I will 
> incorporate this text in the next version of draft.
> 
> Regards,
> Ram
> 
> > > > represents in the real world. Can you pinpoint your 
> objections to
> > my
> > > > proposal?
> > > >
> > > > Thanks,
> > > >
> > > > John
> > > >
> > > >
> > > > > > So something like this: CS MS  (1:1)- > XML MS -> 
> (N:1) -> RS
> > MS
> > > > > >
> > > > > > Leon
> > > > > >
> > > > > > Although personally I had expected a), a couple of 
> threads in
> > > > recent

---

From: Leon Portman <[email-masked]>
Date: Sun, 10 Jul 2011 13:23:38 +0300

Ram Hi
 I agree that we can indicate it via RS SDP but I don't think it will be most elegant solution. 
What is from your point of view, is the main compelling  reason for  MS block to represent RS media and not CS media?

Regards

Leon

-----Original Message-----
From: Parthasarathi R (partr) [mailto:[email-masked]] 
Sent: Sunday, July 10, 2011 12:02 PM
To: Leon Portman; Ram Mohan R (rmohanr); Elwell, John; [email-masked]
Subject: RE: [siprec] Comment on metadata-02 - Media Stream

Leon,

As you mentioned, it is possible to indicate special case of "not recorded" through RS SDP as port value containing 0 in the media ("m="
line) level. Actual RTP session is NULL for those MS. In case you feel that this definition has to be reworded, Pls suggest the text.

Thanks
Partha    

> But do we want to link participant to RS media or Participant media to 
> RS media? What will be the logic to reconstruct participant media 
> sessions ( I am not talking about codecs and ports but types of the 
> media for example). Specially ones that are not recorded or offered. I 
> remember that we had discussion to support it.
> 
> Regards
> 
> Leon
> 
> between CS participants. MS block helps to link participants ( of CS) 
> to its associated Media Streams ( in RS), the properties of which will 
> be carried in RS SDP"
> 
> > > [mailto:[email-masked]] On
> > > > > > Behalf Of Elwell, John

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 11 Jul 2011 09:29:40 +0530

Hi Leon,

1) For the use case where SRC offers a set of streams (say audio and
video) but SRS does chose to record only part of them (say audio only),
the SRC may still continue to send updates for that m-line ( with port
=0).  
2) For the use case SRC may not offer all the media types ( of CS) as it
may not have capability to record, the SRC can still send the initial
offer with port 0 in the m=line.

I remember this was something for which there was no concerns from any
one. In case you see some issues with this approach, Please let us know
the same.
Please refer to one of the mail threads for an earlier discussion on
this topic
http://www.ietf.org/mail-archive/web/siprec/current/msg01304.html

I would not prefer MS block to represent CS media for just these cases
as it would be duplication at XML level when we have agreed that MS
block represents RS media for all other use-cases.

Regards,
Ram

> From: Leon Portman [mailto:[email-masked]]
> Sent: Sunday, July 10, 2011 3:54 PM
> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); Elwell, John;
> [email-masked]
> What is from your point of view, is the main compelling  reason for
MS
> block to represent RS media and not CS media?
> 
> Regards
> 
> Leon
> 
> > > > I don't have any such issues with your definition. I think we
can
> > > > add "
> > > > > > > Actually I was expecting (a) as well. And it should point
> to
> > > the
> > > > > > > "A Media Stream block MUST have properties of media as
seen
> > > > > > by SRC and

---

From: Leon Portman <[email-masked]>
Date: Mon, 11 Jul 2011 13:49:05 +0300

Ram Hi

My concern is not  technical implementation but logical meaning. Metadata XML represents CS: participants, states, medias. It is very confusing (at least for me) that media is about recording session and not communication session. However If everybody ok with that, let's go forward with  the current approach.

Leon
-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Monday, July 11, 2011 7:00 AM
To: Leon Portman; Parthasarathi R (partr); Elwell, John; [email-masked]
Subject: RE: [siprec] Comment on metadata-02 - Media Stream

Hi Leon,

1) For the use case where SRC offers a set of streams (say audio and
video) but SRS does chose to record only part of them (say audio only), the SRC may still continue to send updates for that m-line ( with port =0).  
2) For the use case SRC may not offer all the media types ( of CS) as it may not have capability to record, the SRC can still send the initial offer with port 0 in the m=line.

I remember this was something for which there was no concerns from any one. In case you see some issues with this approach, Please let us know the same.
Please refer to one of the mail threads for an earlier discussion on this topic http://www.ietf.org/mail-archive/web/siprec/current/msg01304.html

I would not prefer MS block to represent CS media for just these cases as it would be duplication at XML level when we have agreed that MS block represents RS media for all other use-cases.

Regards,
Ram

MS
can
seen

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 11 Jul 2011 16:26:07 +0530

Hi Leon,
Please see inline

> Sent: Monday, July 11, 2011 4:19 PM
> To: Ram Mohan R (rmohanr); Parthasarathi R (partr); Elwell, John;
> [email-masked]
> My concern is not  technical implementation but logical meaning.
> Metadata XML represents CS: participants, states, medias. It is very
> confusing (at least for me) that media is about recording session and
> not communication session. However If everybody ok with that, let's go
> forward with  the current approach.

One reason why I want to avoid explicitly saying MS block logically
represents media of CS is the media of RS can be different from CS [
possibly due to SRC acting as endpoint and doing transcoding e.t.c]. In
such cases it will be confusing to say MS block represents CS media. 

Current proposed text is
carried in RS SDP""

I feel the above text conveys sufficient meaning that the MS block
represents media of the participants (who are part of CS)

If the text I proposed below is confusing, Please suggest some more
edits to make it more clear.

Regards,
Ram

> 2) For the use case SRC may not offer all the media types ( of CS) as
> it may not have capability to record, the SRC can still send the
> initial offer with port 0 in the m=line.
> 
> this topic http://www.ietf.org/mail-
> archive/web/siprec/current/msg01304.html
> 
> >  I agree that we can indicate it via RS SDP but I don't think it
will
> > be most elegant solution.
media
> > > media for example). Specially ones that are not recorded or
> offered.
> > I
> > > > > > > It is because when we started off with the metadata draft
> we
> > > > > intended
> > > > > > > > correspond to the relevant offer-answer exchanges, so
> they
> > > > don't
> > > > > > > really

---

From: Leon Portman <[email-masked]>
Date: Mon, 11 Jul 2011 15:53:09 +0300

I am ok with below.
Let's move forward. Thank you for the explanation.

Leon

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Monday, July 11, 2011 1:56 PM
To: Leon Portman; Parthasarathi R (partr); Elwell, John; [email-masked]
Subject: RE: [siprec] Comment on metadata-02 - Media Stream

Hi Leon,
Please see inline

> forward with  the current approach.

One reason why I want to avoid explicitly saying MS block logically represents media of CS is the media of RS can be different from CS [ possibly due to SRC acting as endpoint and doing transcoding e.t.c]. In such cases it will be confusing to say MS block represents CS media. 

Current proposed text is
" A Media Stream block represents a single RTP session between an SRC and an SRS. Note that, because of possible mixing at the SRC, a Media Stream block does not necessarily represent a single RTP session between CS participants. MS block helps to link participants ( of CS) to its associated Media Streams ( in RS), the properties of which will be carried in RS SDP""

I feel the above text conveys sufficient meaning that the MS block represents media of the participants (who are part of CS)

If the text I proposed below is confusing, Please suggest some more edits to make it more clear.

Regards,
Ram

will
media

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 11 Jul 2011 15:35:21 +0200

> [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
> Sent: 08 July 2011 17:25
> To: [email-masked]
> Subject: [siprec] What does Start / Stop time attributes 
> signify for Media Stream block ? [ was RE: Comment on 
> metadata-02 - Media Stream ]
> 
> Hello John,
> 
[JRE] Phrased this way, it sounds like an MS object represents a CS media stream, but I thought from recent discussions you were saying an MS object represents an RS Media Stream (as described in RS SDP).
So consider the case of persistent recording. The RS SDP m-line starts when persistent recording starts (e.g., start of RS) and finishes when persistent recording stops (e.g., end of RS). So if the MS object represents an RS Media Stream, this implies the MS object's start time corresponds to the start of persistent recording and its end time corresponds to the end of persistent recording. They have nothing to do with when participants join or leave. As soon as you tie it to when the first participant joins / the last participant ends, it seems to me the MS object must relate to the CS media stream.

John (as individual)

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 13 Jul 2011 12:36:29 +0530

Hi John,

I still don't prefer to have the meaning or identity of MS block as
"represents CS media streams" for the same reasons I mentioned to Leon
in the other thread as it would create more confusion -
http://www.ietf.org/mail-archive/web/siprec/current/msg02240.html

Now regarding start/stop time for MS-
We have agreed in the last interim meeting to have unique ID for MS. IOW
same id shall be permitted to be used in two RS's to indicate it's a
same MS.

So start/end time shall be arrival of first participant and departure of
last participant in case MS is mixed stream.
In case MS is single stream, start/end time shall be arrival/departure
of corresponding participant.

So to summarize the start/stop time for a media-stream may be derived
from Participant start/stop time itself. I don't see real need to have
this attribute.

I would like to hear from others if they see a need to have Start/Stop
time attribute for MS block.

Regards,
Ram

> Sent: Monday, July 11, 2011 7:05 PM
> To: Ram Mohan R (rmohanr); [email-masked]
> Subject: RE: [siprec] What does Start / Stop time attributes signify
> for Media Stream block ? [ was RE: Comment on metadata-02 - Media
> Stream ]
> 
> 
> 
> [JRE] Phrased this way, it sounds like an MS object represents a CS
> media stream, but I thought from recent discussions you were saying an
> MS object represents an RS Media Stream (as described in RS SDP).
> So consider the case of persistent recording. The RS SDP m-line starts
> when persistent recording starts (e.g., start of RS) and finishes when
> persistent recording stops (e.g., end of RS). So if the MS object
> represents an RS Media Stream, this implies the MS object's start time
> corresponds to the start of persistent recording and its end time
> corresponds to the end of persistent recording. They have nothing to
do
> with when participants join or leave. As soon as you tie it to when
the
> first participant joins / the last participant ends, it seems to me
the
> MS object must relate to the CS media stream.
> 
> John (as individual)
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jul 2011 09:17:21 -0400

(I wrote this some time ago and apparently never sent it.
Hopefully better late than never.)

I think we may have fallen into a semantic muddle here, and I am as 
guilty of getting us there as anyone else.

ISTM that *ideally* we would like the recording to capture sufficient 
info to reconstruct all the media flows in the original CSs, and 
attribute them to the appropriate participants. In that case our MS 
metadata object represents *both* a CS media stream and an RS media 
stream for some period of time.

In *practice* we may be willing to accept less than that, as a tradeoff 
for reducing complexity in constructing or inserting the SRC, bandwidth, 
etc.

We can achieve the ideal if the SRC is willing and able to map every CS 
media stream to a distinct RS media stream. If the SRC combines multiple 
CS media streams into one RS media stream then we have strayed from the 
ideal. In that case our MS metadata object represents one RS media 
stream for a period of time as well as some mix of this CS media streams 
that are mapped onto it. We don't bother to specify the mix algorithm, 
so this is a fairly crude approximation to the individual CS streams.

In principle the CSRC data in the RS media stream may permit identifying 
the individual participants responsible for the media. But we have not 
specified any way of correlating SSRC/CSRC values to participants, so 
its not clear that this actually provides any useful functionality.

	Thanks,
	Paul

On 7/11/11 9:35 AM, Elwell, John wrote:
>> start/stop times&  the metamodel". I just went through the
>> thread again

---

From: Leon Portman <[email-masked]>
Date: Mon, 25 Jul 2011 16:25:44 +0300

Paul Hi

Today mixing is done on the RTP packet level: the audio is actually mixed on that same packet have audio from different streams. So SRSC will not work, the only way is to map CS media streams to one RS media stream

Leon 
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Monday, July 25, 2011 4:17 PM
To: [email-masked]
Subject: Re: [siprec] What does Start / Stop time attributes signify for Media Stream block ? [ was RE: Comment on metadata-02 - Media Stream ]

        Thanks,
        Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 26 Jul 2011 04:04:04 +0530

Leon,

Even mapping CS media streams to RS media stream may not be sufficient
when the RS media is a mixed media. The current metadata will have
information by which all the participant will have linkages to the mixed
MS (<send> will have the stream ID) . However we would need to have CSRC
mapped to participant ( perhaps as a participant attribute in XML) to
know the contributed stream of a  participant in the mixed stream.

Regards,
Ram

> Sent: Monday, July 25, 2011 9:26 AM
> To: Paul Kyzivat; [email-masked]
> Subject: Re: [siprec] What does Start / Stop time attributes signify
> Today mixing is done on the RTP packet level: the audio is actually
> mixed on that same packet have audio from different streams. So SRSC
> will not work, the only way is to map CS media streams to one RS media
> stream
> 
> Leon
> Subject: Re: [siprec] What does Start / Stop time attributes signify
> > So consider the case of persistent recording. The RS SDP m-line
> starts when persistent recording starts (e.g., start of RS) and
> finishes when persistent recording stops (e.g., end of RS). So if the
> MS object represents an RS Media Stream, this implies the MS object's
> start time corresponds to the start of persistent recording and its
end
> time corresponds to the end of persistent recording. They have nothing
> to do with when participants join or leave. As soon as you tie it to
> when the first participant joins / the last participant ends, it seems
> to me the MS object must relate to the CS media stream.
> >
> > John (as individual)
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jul 2011 22:03:06 -0400

On 7/25/11 9:25 AM, Leon Portman wrote:
> Paul Hi
>
> Today mixing is done on the RTP packet level:
> the audio is actually mixed on that same packet have audio from different streams.

Disclaimer - I know little about RTP, so take this with grain of salt.

The above statement seems rather sweeping. Are you speaking for all 
recording solutions, or your own?

> So SRSC will not work, the only way is to map CS media streams to one RS media stream

And, we are setting things up so that the individual streams can be sent 
unmixed. Its at the option of the SRC which to do.

My point was that if we are sending streams that include mixes of 
multiple participants, but not all of the participants, then how can the 
SRS determine *which* participants? (Isn't mixing typically "loudest 
two" or something like that, rather than mixing all the inputs?) The 
SSRC/CSRC could be used for this, but only if the mapping from SSRC/CSRC 
to participant is known.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Tue, 26 Jul 2011 16:21:39 +0300

Paul Hi

No, I am not describing specific implementation but definitions how I understand them. Mixing (or summation)is actual mixing of media streams (like conference participants audio mixing). Multiplexing is having multiple RTP packets from different sources sent over same port.

And we have separate use case where everything is sent separately

Leon

On Jul 26, 2011, at 5:03 AM, Paul Kyzivat <[email-masked]> wrote:

> The above statement seems rather sweeping. Are you speaking for all recording solutions, or your own?
> 
> And, we are setting things up so that the individual streams can be sent unmixed. Its at the option of the SRC which to do.
> 
> My point was that if we are sending streams that include mixes of multiple participants, but not all of the participants, then how can the SRS determine *which* participants? (Isn't mixing typically "loudest two" or something like that, rather than mixing all the inputs?) The SSRC/CSRC could be used for this, but only if the mapping from SSRC/CSRC to participant is known.
> 
>    Thanks,
>    Paul
> 
>> Leon

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 26 Jul 2011 10:27:31 -0400

> No, I am not describing specific implementation but definitions how I understand them. Mixing (or summation)is actual mixing of media streams (like conference participants audio mixing). Multiplexi…

OK, I see. I was being sloppy in my terminology. When I mentioned 
mixing, I meant *any* valid way of combining multiple media sources over 
a single RTP stream, regardless of whether that is mixing, multiplexing, ...

	Thanks,
	Paul

> On Jul 26, 2011, at 5:03 AM, Paul Kyzivat<[email-masked]>  wrote:
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 26 Jul 2011 20:32:03 +0530

Leon,

I had replied in an earlier about having an attribute to link
participants to its contributing media stream in a mixed RS stream.
Please let me know if you see a value in having this information at SRS.

http://www.ietf.org/mail-archive/web/siprec/current/msg02376.html

Ram

> Behalf Of Paul Kyzivat
> Sent: Tuesday, July 26, 2011 10:28 AM
> To: Leon Portman
> Cc: [email-masked]
> > No, I am not describing specific implementation but definitions how
I
> understand them. Mixing (or summation)is actual mixing of media
streams
> (like conference participants audio mixing). Multiplexing is having
> multiple RTP packets from different sources sent over same port.
> 
> >> And, we are setting things up so that the individual streams can be
> sent unmixed. Its at the option of the SRC which to do.
> >>
> multiple participants, but not all of the participants, then how can
> the SRS determine *which* participants? (Isn't mixing typically
> "loudest two" or something like that, rather than mixing all the
> inputs?) The SSRC/CSRC could be used for this, but only if the mapping
> from SSRC/CSRC to participant is known.
> >>
> >>     Thanks,
> >>     Paul
> >>
> >>> Leon
> >>> Subject: Re: [siprec] What does Start / Stop time attributes
> signify for Media Stream block ? [ was RE: Comment on metadata-02 -
> Media Stream ]
> >>>
> >>> CS media streams into one RS media stream then we have strayed
from
> >>>>>
> >>>>> To summarize these are some of the salient points we discussed
at
> >>>>> the first participant to a new media stream, and the stop time
as
> >>>> [JRE] Phrased this way, it sounds like an MS object represents a
> CS media stream, but I thought from recent discussions you were saying
> an MS object represents an RS Media Stream (as described in RS SDP).
end
an

---

From: Leon Portman <[email-masked]>
Date: Tue, 26 Jul 2011 18:12:31 +0300

Yes, we should have it. 

Leon

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 26 Jul 2011 09:06:57 -0700

+1

Behalf Of Leon Portman
> Sent: Tuesday, July 26, 2011 11:13 AM
> To: Ram Mohan R (rmohanr)
> Cc: <[email-masked]>
forMedia Stream block ? [ was RE:
> Comment on metadata-02 - MediaStream ]
> 
> Yes, we should have it.
> 
> Leon
> 
signify
> >>>>> So SRSC will not work, the only way is to map CS media streams
to
> >> one RS media stream
> >>>>> From: [email-masked] [[email-masked]] On
Behalf
> >> Of Paul Kyzivat [[email-masked]]
> >>>>> the individual participants responsible for the media. But we
have
> >> not
> >>>>> specified any way of correlating SSRC/CSRC values to
participants,
> >> so
> >>>>>>> Regarding your other question on Start/Stop time attribute in
MS
> >> block
> >>>>>>> We had a long discussion couple of months back on the
Start/Stop
> >> time
> >>>>>>> - There were discussions around how SRC derives this time (is
it
> >> based
[mailto:[email-masked]]
> >> On

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 26 Jul 2011 23:54:44 +0530

Hi all,

I agree that there is a need of the linkage between contributing source
in media & metadata. Still, I prefer to have the information about
contributing source in SDP (like a=csrc) rather than in XML. I'm looking
for this approach because SDP should be elaborate enough to explain
about the related media (RTP).

Thanks
Partha

> [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
> Sent: Tuesday, July 26, 2011 9:37 PM
> To: Leon Portman; Ram Mohan R (rmohanr)
> Cc: [email-masked]
> signifyforMedia Stream block ? [ was RE: Comment on 
> metadata-02 -MediaStream ]
> 
> +1
> 
> > > Please let me know if you see a value in having this 
> information at
> SRS.
> > >
> > >> mixing, I meant *any* valid way of combining multiple 
> media sources 
> > >> over a single RTP stream, regardless of whether that is mixing, 
> > >> multiplexing, ...
> > >>
> > >>    Thanks,
> > >>    Paul
> > >>
> > >>>>> the audio is actually mixed on that same packet have 
> audio from
> > >> different streams.
> > >>>>
> > >>>> Disclaimer - I know little about RTP, so take this 
> with grain of
> > >> salt.
> > >>>>
> > >>>> And, we are setting things up so that the individual 
> streams can
> be
> > >>>>> I think we may have fallen into a semantic muddle 
> here, and I am
> > > as
> > >>>>> attribute them to the appropriate participants. In 
> that case our
> > > MS
> > >>>>> media stream to a distinct RS media stream. If the 
> SRC combines
> > >> multiple
> > >>>>> stream for a period of time as well as some mix of 
> this CS media
> > >> streams
> > >>>>>>> attribute and what it means. It was a long thread 
> with title " 
> > >>>>>>> [siprec]
> > >>>>>>> - the start time of a media stream is the time 
> (according to 
> > >>>>>>> the CS) of the first participant to a new media stream, and 
> > >>>>>>> the stop time
> > > as
> > >> the
> > >>>>>> [JRE] Phrased this way, it sounds like an MS object 
> represents
> a
> > >>>>>>> time w.r.t different RTP models (translator, 
> endpoint) and how
> > >> SRS may
> > >>>>>>> Now would be a good time to re-start the discussion 
> again so 
> > >>>>>>> that we can conclude at least in IETF 81.
> > >>>>>>>
> > >>>>>>> Regards,
> > >>>>>>> Ram
> > >>>>>>>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 26 Jul 2011 11:30:55 -0700

> From: Parthasarathi R (partr)
> Sent: Tuesday, July 26, 2011 2:25 PM
> To: Charles Eckel (eckelcu); Leon Portman; Ram Mohan R (rmohanr)
> Cc: [email-masked]
> Subject: RE: [siprec] What does Start / Stop time attributes
signifyforMedia Stream block ? [ was RE:
> Comment on metadata-02 -MediaStream ]
> 
> Hi all,
> 
> I agree that there is a need of the linkage between contributing
source in media & metadata. Still, I
> prefer to have the information about contributing source in SDP (like
a=csrc) rather than in XML. I'm
> looking for this approach because SDP should be elaborate enough to
explain about the related media
> (RTP).

I agree to the use of CSRC, and I believe this is consistent with the
recommendations in the RTP recommendations draft. I think we also agreed
that we need a way to link the participant to the CSRC used for the
participant.

Cheers,
Charles
 
signify
> > > >>> No, I am not describing specific implementation but
definitions
> > how
> > > >>> On Jul 26, 2011, at 5:03 AM, Paul
Kyzivat<[email-masked]>
> > > >> wrote:
> > > >>>> The above statement seems rather sweeping. Are you speaking
for
> > all
> > > >> multiple participants, but not all of the participants, then
how
> > > >>>>> metadata object represents *both* a CS media stream and an
RS
> > > >>>>> In *practice* we may be willing to accept less than that, as
a
> > > >> tradeoff
> > > >>>>> for reducing complexity in constructing or inserting the
SRC,
> > > >> bandwidth,
> > > >>>>> etc.
> > > >>>>>
> > > >>>>> We can achieve the ideal if the SRC is willing and able to
map
> > > >> every CS
> > > >> finishes when persistent recording stops (e.g., end of RS). So
if
> > > >> to do with when participants join or leave. As soon as you tie
it
> > to
> > > >> when the first participant joins / the last participant ends,
it
> > seems
> > > >>>>>>> - There was also discussions on what is the significance
of
> > > >> start/stop
seen
they

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 27 Jul 2011 00:04:13 +0530

Partha,

inline

> From: Charles Eckel (eckelcu)
> Sent: Tuesday, July 26, 2011 2:31 PM
> To: Parthasarathi R (partr); 'Leon Portman'; Ram Mohan R (rmohanr)
> Cc: [email-masked]'
> signifyforMedia Stream block ? [ was RE: Comment on metadata-02 -
> MediaStream ]
> 

There was no objection on using CSRC in SDP.  What we need is a way to
link the participant to the CSRC used for that participant.

Ram

> recommendations in the RTP recommendations draft. I think we also
> agreed that we need a way to link the participant to the CSRC used for
> the participant.
> 
> Cheers,
> Charles
> 
> > Thanks
> > Partha
> >
> > > > >> inputs?) The SSRC/CSRC could be used for this, but only if
the
> > > mapping
> > > > >>>>> In *practice* we may be willing to accept less than that,
> as a
> > > > >> tradeoff
> > > > >>>>> ideal. In that case our MS metadata object represents one
> RS
> > > media
> > > > >>>>> that are mapped onto it. We don't bother to specify the
mix
> > > > >> algorithm,
> > > > >>>>> so this is a fairly crude approximation to the individual
> CS
> > > > >> streams.
> > > > >>>>>
> > > > >>>>> In principle the CSRC data in the RS media stream may
> permit
> > > > >> identifying
> > > > >>>>>>> [mailto:[email-masked]] On Behalf Of Ram Mohan
R
> > > > >> (rmohanr)
> > > > >> CS media stream, but I thought from recent discussions you
> were
> > > saying
> > > > >> an MS object represents an RS Media Stream (as described in
RS
> > > SDP).
> > > > >> time corresponds to the end of persistent recording. They
have
> > > nothing
> > > > >>>>>>>> Ignoring the possibly inappropriate RFC 2119 language,
I
> > > > >>>>>>>> Both of these are "seen by SRC". There need not be a
1:1
> > > > >>>>>>> relationship
> > > > >>>>>>>> and an SRS. Note that, because of possible mixing at
the
> > > > >>>>>>> SRC, a Media
> > > > >>>>>>>> Stream block does not necessarily represent a single
RTP
> > > > > session
> > > > >>>>>>>> End Time attributes mean. The start and end of an RS
RTP
> > > > > session

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 27 Jul 2011 00:14:03 +0530

Hi Charles,

I agree that there is a need to link participant with CSRC used for the
participant. It is possible to achieve through the current mechanism and
the steps are as follows:

1) <participant> element has <send> element with <stream> value.
2) <stream> has <label> attribute which links with RS SDP
3) RS SDP will have info about CSRC for the real-time media.

Please let me know your opinion here.

Thanks
Partha

> Sent: Wednesday, July 27, 2011 12:01 AM
> > Subject: RE: [siprec] What does Start / Stop time 
> attributes signifyforMedia Stream block ? [ was RE:
> > source in media & metadata. Still, I prefer to have the information 
> > about contributing source in SDP (like a=csrc) rather than 
> in XML. I'm 
> > looking for this approach because SDP should be elaborate 
> enough to explain about the related media (RTP).
> 
> I agree to the use of CSRC, and I believe this is consistent 
> with the recommendations in the RTP recommendations draft. I 
> think we also agreed that we need a way to link the 
> participant to the CSRC used for the participant.
> 
> Cheers,
> Charles
>  
> > Thanks
> > Partha
> > 
> > > > >> inputs?) The SSRC/CSRC could be used for this, but 
> only if the
> > > mapping
> > > > >>>>> ideal. In that case our MS metadata object 
> represents one RS
> > > media
> > > > >>>>> that are mapped onto it. We don't bother to 
> specify the mix
> > > > >> algorithm,
> > > > >>>>> so this is a fairly crude approximation to the 
> individual CS
> > > > >> streams.
> > > > >>>>>
> > > > >>>>> In principle the CSRC data in the RS media stream 
> may permit
> > > > >> identifying
> > > > >>>>> the individual participants responsible for the 
> media. But 
> > > > >>>>> we
> > > have
> > > > >> not
> > > > >>>>>>> [mailto:[email-masked]] On Behalf Of 
> Ram Mohan R
> > > > >> (rmohanr)
> > > > >>>>>>> Sent: 08 July 2011 17:25
> > > > >>>>>>> To: [email-masked]
> > > > >>>>>>> the CS) of the first participant to a new media stream, 
> > > > >>>>>>> and the stop time
> > > > > as
> > > > >> the
> > > > >> CS media stream, but I thought from recent 
> discussions you were
> > > saying
> > > > >> an MS object represents an RS Media Stream (as 
> described in RS
> > > SDP).
> > > > >> time corresponds to the end of persistent recording. 
> They have
> > > nothing
> > > > >>>>>>>> Ignoring the possibly inappropriate RFC 2119 
> language, I
> > > don't
> > > > >> think
> > > > >>>>>>>> Both of these are "seen by SRC". There need 
> not be a 1:1
> > > > >>>>>>> relationship
> > > > >>>>>>>> and an SRS. Note that, because of possible 
> mixing at the
> > > > >>>>>>> SRC, a Media
> > > > >>>>>>>> Stream block does not necessarily represent a 
> single RTP
> > > > > session
> > > > >>>>>>>> End Time attributes mean. The start and end of 
> an RS RTP
> > > > > session

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 26 Jul 2011 14:50:47 -0400

> link the participant to the CSRC used for that participant.

I must be missing something very basic.  How would an SRC know what the SSRC (and thus the CSRC) is going to be for RTP streams from the UA's of the CS, when it sends the initial RS INVITE with SDP to the SRS?  I mean there is technically an SDP attribute to indicate it if both UA's do that, but it's not exactly widely popular.

-hadriel

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 27 Jul 2011 00:29:15 +0530

Hadriel,

This is not the only model which an SRC can follow. In case SRC is
acting as mixer (RTP end point mixing all CS streams) it may follow this
approach if it has the capability to do the same.  The intent is to give
enough flexibility to the SRC so that it may choose to send (for cases
where it can determine)

For a simple SRC (RTP translator as oer Charles draft), we just need
label in XML pointing to RS SDP which will link the participants to
media.

Regards,
Ram

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Tuesday, July 26, 2011 2:51 PM
> Cc: Charles Eckel (eckelcu); Parthasarathi R (partr); Leon Portman;
> [email-masked]
> signifyforMediaStream block ? [ was RE: Comment on metadata-02 -
> MediaStream ]
> 
> 
> I must be missing something very basic.  How would an SRC know what
the
> SSRC (and thus the CSRC) is going to be for RTP streams from the UA's
> of the CS, when it sends the initial RS INVITE with SDP to the SRS?  I
> mean there is technically an SDP attribute to indicate it if both UA's
> do that, but it's not exactly widely popular.
> 
> -hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 26 Jul 2011 15:14:57 -0400

> enough flexibility to the SRC so that it may choose to send (for cases

My question still stands: assume an RTP mixer SRC system.  In the most general/normal case, until the SRC-mixer receives RTP from the real UA participants, it will not know what their SSRCs are going to be.  Right?  If so, then you'll have to send a re-INVITE/UPDATE to the SRS with the CSRC info.  Is that the intent/expectation? (could be, I dunno)

-hadriel

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 26 Jul 2011 12:54:37 -0700

> Sent: Tuesday, July 26, 2011 3:15 PM
[email-masked]
signifyforMediaStream block ? [ was RE:
> My question still stands: assume an RTP mixer SRC system.  In the most
general/normal case, until the
> SRC-mixer receives RTP from the real UA participants, it will not know
what their SSRCs are going to
> be.  Right?  If so, then you'll have to send a re-INVITE/UPDATE to the
SRS with the CSRC info.  Is
> that the intent/expectation? (could be, I dunno)

Yes. It would also need to send a re-INVITE /UPDATE to the SSRC if the
UA decided to change its SSRC or start using additional SSRCs
mid-session. 

Cheers,
Charles

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 26 Jul 2011 13:03:40 -0700

The SSRCs/CSRCs of the participant need to be known to the SRS. These
could be the same as the ones used by the UA associated with the
participant in the CS, or they could be ones assigned by the SRC. In any
case, the SRS needs to know to mapping of SSRC to participant such that
it knows which participant is speaking. If this information is not
available, then having a label for a media line in the RS SDP that has
linkage to one of more participants would be possible. When mixing media
from multiple participants there would be no indication of which
participants are in the mix at any given point in time, but it would
still be better than nothing.

Cheers,
Charles 

> Sent: Tuesday, July 26, 2011 2:44 PM
> To: Charles Eckel (eckelcu); 'Leon Portman'; Ram Mohan R (rmohanr)
> Cc: [email-masked]'
signifyforMedia Stream block ? [ was RE:
> I agree that there is a need to link participant with CSRC used for
the participant. It is possible to
> achieve through the current mechanism and the steps are as follows:
> 
> > > > > >> "loudest two" or something like that, rather than mixing
all
> > > > > >>>>> ISTM that *ideally* we would like the recording to
capture
> > > > > >> sufficient
> > > > > >> MS object represents an RS Media Stream, this implies the
MS
> > > > object's
> > > > > >>>>>>>> However, if we accept this principle, I wonder what
the
> > > > > >>>>>>> Start Time and
> > > > > >>>>>>>> need to be in XML. So I suspect I still haven't
drilled
> > > > > >>>>>>> down into the