Subject: [siprec] What should be <send> pointing in the following conference recording use-case ?

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 22 Sep 2011 22:06:17 +0530

Let's consider the following conference recording use-case. We have
three participants A, B and C in a conference.
SRC also acting as a conference focus and is recording mixed stream to
SRS. 
In this case in the metadata XML snapshot sent from SRC to SRS, what
should the <send> element of each participant point to  ?

Note that each participant A, B and C sends a separate stream to mixer
which mixes them and plays the mixed stream  back to each of them and
only this is being recorded. This means only the <recv> stream of each
of the participant is being recorded. 

Should we omit the <send> tag in this case in the metadata snapshot as
shown in the example below? OR
Should we still have <send> for each participant ? If yes what should it
have ? Note that there is no m-line in RS SDP mapping to the <send>
stream of each of these participants.

e.g:

        <participant
             id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
             session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
             <aor>sip:[email-masked]</aor>
             <recv>urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a</recv>
          </participant>
                   
         <participant
              id="urn:uuid:cd27cfa1-2bdd-4830-a653-70374d10f103"
              session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
              <aor>sip:[email-masked]</aor>
              <recv>urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a</recv>
         </participant>
          
          <participant
              id="urn:uuid:50000c9b-9191-40a4-8231-5bcbca5e2b17"
              session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
              <aor>sip:[email-masked]</aor>
              <recv>urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a</recv>
          </participant>

          <stream id="urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a"
              session="urn:uuid:cd27cfa1-2bdd-4830-a653-70374d10f103">
              <label>98</label>
          </stream>

Regards,
Ram

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Sep 2011 09:48:58 +0200

I think the point is that all three participants are contributing to the stream, so they are sending as well as receiving. If it is known at a particular point in time that a particular participant is not contributing (e.g., microphone muted), then the <send/> element should be omitted. Dynamic changes (e.g., when the mixer senses silence or near silence from a contributor and doesn't include that contributor in the mix) should not be reflected in the metadata - in this case the participant should still be marked as sending to that stream.

John (as individual) 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
> Sent: 22 September 2011 17:36
> To: [email-masked]
> Subject: [siprec] What should be <send> pointing in the 
> following conference recording use-case ?
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Feenstra, Friso" <[email-masked]>
Date: Fri, 23 Sep 2011 08:04:59 +0000

Hi John,

I am not sure if this is a good idea. I will give an example.

During a meeting one participant is mumbling. The mixer removes the contributor providing the 'near silence' from the mix, so the other participants do not hear the mumbled contribution. Still it is recorded. As a result the recorded stream does not reflect the stream heard by the other participants during the meeting and from the metadata no indication is received that the stream was removed from the mix.

Friso (as individual)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: vrijdag 23 september 2011 9:49
To: Ram Mohan R (rmohanr); [email-masked]
Subject: Re: [siprec] What should be <send> pointing in the following conference recording use-case ?

John (as individual) 

Think green - keep it on the screen.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 23 Sep 2011 13:48:26 +0530

> From: Elwell, John [mailto:[email-masked]]
> Sent: Friday, September 23, 2011 1:19 PM
> Subject: RE: What should be <send> pointing in the following
> conferencerecording use-case ?
> 
> I think the point is that all three participants are contributing to
> the stream, so they are sending as well as receiving. If it is known
at
> a particular point in time that a particular participant is not
> contributing (e.g., microphone muted), then the <send/> element should
> be omitted. Dynamic changes (e.g., when the mixer senses silence or
> near silence from a contributor and doesn't include that contributor
in
> the mix) should not be reflected in the metadata - in this case the
> participant should still be marked as sending to that stream.

This may be ok. But I want to highlight the fact that in reality we are
recording only the stream received by all the participants and NOT the
sent streams of each of the participant. Note that each participant is
sending a separate stream to mixer(which is also SRC) and the mixed
stream is received by all participants and also recorded to an SRS.

In this specific instance if we end up in adding <send> for every
participant, it will point the same
stream("urn:uuid:f3373a7b-4958-4e55-8820-d03a191fb76a") as the <recv>
element is pointing to.  This may be wrong as SRS may think same stream
is being sent/received by all participants since all <send> and all
<recv> will point to same stream.

This was the reason I started to wonder what <send> should have.

Of course an SRS can still find the contributing sources of each
participant by using the other attribute (CSRC) that are discussing in
the other mail threads.

Regards,
Ram

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 23 Sep 2011 13:52:14 +0530

Hi John,

I agree with you. The purpose of <send> element is created to indicate
what is negotiated in SIP rather than exact RTP contribution. 

I think that it is one of the reason for asking <csrc> element in
metadata to indicate who is contributing at the specific time of the
conference. Let us discuss in detail during today's meeting.

Hi Friso,

<send> & <receive> are introduced to handle the scenario like whisper
call in call center. The media inactivity will not be reflected by this
attribute.

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Feenstra, Friso
>Sent: Friday, September 23, 2011 1:35 PM
>To: Elwell, John; Ram Mohan R(rmohanr); [email-masked]
>Subject: Re: [siprec] What should be <send> pointing in thefollowing
>conference recording use-case ?
>
>Hi John,
>
>During a meeting one participant is mumbling. The mixer removes the
>contributor providing the 'near silence' from the mix, so the other
>participants do not hear the mumbled contribution. Still it is
recorded.
>As a result the recorded stream does not reflect the stream heard by
the
>other participants during the meeting and from the metadata no
>indication is received that the stream was removed from the mix.
>
>Friso (as individual)
>
>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Elwell, John
the
>stream, so they are sending as well as receiving. If it is known at a
>particular point in time that a particular participant is not
near
>silence from a contributor and doesn't include that contributor in the
>mix) should not be reflected in the metadata - in this case the
>This e-mail and any attachment is for authorised use by the intended
>recipient(s) only. It may contain proprietary material, confidential
>information and/or be subject to legal privilege. It should not be
>copied, disclosed to, retained or used by, any other party. If you are
>not an intended recipient then please promptly delete this e-mail and
>any attachment and all copies and inform the sender. Thank you.
>
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Sep 2011 10:39:12 +0200

Friso,

These dynamic changes in who is contributing are available from RTP. The potential frequency of changes make this information unsuitable for reflecting in metadata.

John (as individual) 

> From: Feenstra, Friso [mailto:[email-masked]] 
> Sent: 23 September 2011 09:05
> To: Elwell, John; Ram Mohan R (rmohanr); [email-masked]
> Subject: RE: [siprec] What should be <send> pointing in the 
> During a meeting one participant is mumbling. The mixer 
> removes the contributor providing the 'near silence' from the 
> mix, so the other participants do not hear the mumbled 
> contribution. Still it is recorded. As a result the recorded 
> stream does not reflect the stream heard by the other 
> participants during the meeting and from the metadata no 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> Subject: Re: [siprec] What should be <send> pointing in the 
> I think the point is that all three participants are 
> contributing to the stream, so they are sending as well as 
> receiving. If it is known at a particular point in time that 
> a particular participant is not contributing (e.g., 
> microphone muted), then the <send/> element should be 
> omitted. Dynamic changes (e.g., when the mixer senses silence 
> or near silence from a contributor and doesn't include that 
> contributor in the mix) should not be reflected in the 
> metadata - in this case the participant should still be 
> marked as sending to that stream.
> 
> John (as individual) 
> 
> This e-mail and any attachment is for authorised use by the 
> intended recipient(s) only. It may contain proprietary 
> material, confidential information and/or be subject to legal 
> privilege. It should not be copied, disclosed to, retained or 
> used by, any other party. If you are not an intended 
> recipient then please promptly delete this e-mail and any 
> attachment and all copies and inform the sender. Thank you.
> 
> 
>

---

From: <[email-masked]>
Date: Fri, 23 Sep 2011 09:58:01 +0100

Ram

What is being recorded is a mix of the three participants send streams, so logically that is what meta data should show.

Wouldn't the RTCP SDES for the RS include the SSRC's of the three transmit streams ?

I dont think meta data needs to have any <recv> elements at all, as by default all participants are assumed to recieve all sends.
I think the sue of recv for conference scenarios leads to confusion.

Rgds
John Stafford | Solution Architect 1 | BT Global Services
 ________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Ram Mohan R (rmohanr) [[email-masked]]
Sent: 23 September 2011 09:18
To: Elwell, John; [email-masked]
Subject: Re: [siprec] What should be <send> pointing in the following   conferencerecording use-case ?

at
in

Regards,
Ram