Subject: [siprec] Comments on requirements 13/14

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Jun 2010 17:03:02 +0200

>From an off-line discussion with some of you, it came to my attention that REQ-013 and REQ-014 are intended to cover at least two cases:
- where two directions of communication for a given medium are sent to the SRS using separate RSs;
- where multiple (bidirectional) media are sent to the SRS using separate RSs.

If that is so, I really think the requirements should be sub-divided:

"REQ-013 The mechanism MUST support the ability to deliver multiple media for a given Communication Session over separate Recording Sessions to the SRS.

REQ-013bis The mechanism MUST support the ability to deliver different directions of a given medium for a given Communication Session over separate Recording Sessions to the SRS.

REQ-014 The mechanism MUST support the ability to deliver multiple media for a given Communication Session over a single Recording Session to the SRS.

REQ-014bis The mechanism MUST support the ability to deliver different directions of a given medium for a given Communication Session over a single Recording Session to the SRS."

I also heard a suggestion that REQ-013 was intended to cover redundancy scenarios. However, in that case, delivering "to the SRS" (i.e., to a single SRS) would not make sense - surely you would deliver to different SRSs. So if we need a requirement on redundant RSs, I think that would be a separate requirement. However, personally I am not convinced we need a requirement on this, since whatever solution we come up with it is likely that somebody could deploy it in a redundant manner. I doubt our solution would need to do anything special to allow redundancy.

John (as individual)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jun 2010 11:17:24 -0400

> REQ-013bis The mechanism MUST support the ability to deliver different directions of a given medium for a given Communication Session over separate Recording Sessions to the SRS.

Isn't that a special case of the more general case where there is a 
conference involving two or more participants and the streams for each 
are delivered separately?

> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Jun 2010 18:15:42 +0200

In the light of Paul's comment, I would amend my proposal as follows:

REQ-013bis The mechanism MUST support the ability to deliver media from different parties in a given Communication Session over separate Recording Sessions to the SRS.

REQ-014bis The mechanism MUST support the ability to deliver media from different parties in a given Communication Session over a single Recording Session to the SRS."

John 

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 17 June 2010 16:17
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [siprec] Comments on requirements 13/14
> 
> 
> 
> Elwell, John wrote:
> >>From an off-line discussion with some of you, it came to my 
> attention that REQ-013 and REQ-014 are intended to cover at 
> least two cases:
> > "REQ-013 The mechanism MUST support the ability to deliver 
> multiple media for a given Communication Session over 
> separate Recording Sessions to the SRS.
> > 
> > REQ-013bis The mechanism MUST support the ability to 
> deliver different directions of a given medium for a given 
> Communication Session over separate Recording Sessions to the SRS.
> 
> > REQ-014 The mechanism MUST support the ability to deliver 
> multiple media for a given Communication Session over a 
> single Recording Session to the SRS.
> > 
> > REQ-014bis The mechanism MUST support the ability to 
> deliver different directions of a given medium for a given 
> Communication Session over a single Recording Session to the SRS."
> > 
> > I also heard a suggestion that REQ-013 was intended to 
> cover redundancy scenarios. However, in that case, delivering 
> "to the SRS" (i.e., to a single SRS) would not make sense - 
> surely you would deliver to different SRSs. So if we need a 
> requirement on redundant RSs, I think that would be a 
> separate requirement. However, personally I am not convinced 
> we need a requirement on this, since whatever solution we 
> come up with it is likely that somebody could deploy it in a 
> redundant manner. I doubt our solution would need to do 
> anything special to allow redundancy.
> > 
> > John (as individual)

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jun 2010 12:39:25 -0400

wordsmithing...

> REQ-013bis The mechanism MUST support the ability to deliver media from different parties in a given Communication Session over separate Recording Sessions to the SRS.

suggest s/deliver/independently deliver/

Otherwise this might be satisfied by delivering them mixed together.

> REQ-014bis The mechanism MUST support the ability to deliver media from different parties in a given Communication Session over a single Recording Session to the SRS."

s/deliver/independently deliver/

	Thanks,
	Paul

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 17 Jun 2010 09:54:37 -0700

I agree with John's last statement. I also don't think we need to
explicitly spell out the redundancy part of the mechanism since the
requirements do not spell out any restrictions from using redundant SRS.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Thursday, June 17, 2010 11:03 AM
To: [email-masked]
Subject: [siprec] Comments on requirements 13/14

>From an off-line discussion with some of you, it came to my attention
that REQ-013 and REQ-014 are intended to cover at least two cases:
- where two directions of communication for a given medium are sent to
the SRS using separate RSs;
- where multiple (bidirectional) media are sent to the SRS using
separate RSs.

"REQ-013 The mechanism MUST support the ability to deliver multiple
media for a given Communication Session over separate Recording Sessions
to the SRS.

REQ-013bis The mechanism MUST support the ability to deliver different
directions of a given medium for a given Communication Session over
separate Recording Sessions to the SRS.

REQ-014 The mechanism MUST support the ability to deliver multiple media
for a given Communication Session over a single Recording Session to the
SRS.

REQ-014bis The mechanism MUST support the ability to deliver different
directions of a given medium for a given Communication Session over a
single Recording Session to the SRS."

I also heard a suggestion that REQ-013 was intended to cover redundancy
scenarios. However, in that case, delivering "to the SRS" (i.e., to a
single SRS) would not make sense - surely you would deliver to different
SRSs. So if we need a requirement on redundant RSs, I think that would
be a separate requirement. However, personally I am not convinced we
need a requirement on this, since whatever solution we come up with it
is likely that somebody could deploy it in a redundant manner. I doubt
our solution would need to do anything special to allow redundancy.

John (as individual)

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Dave Smith" <[email-masked]>
Date: Thu, 17 Jun 2010 10:18:04 -0700

A recommended change and a question provided below.  

Regards,
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Thursday, June 17, 2010 9:39 AM
To: Elwell, John
Cc: [email-masked]
Subject: Re: [siprec] Comments on requirements 13/14

wordsmithing...

[DS] Change "...deliver multiple media..." to "...deliver different
types of media...."

> REQ-013bis The mechanism MUST support the ability to deliver media
from different parties in a given Communication Session over separate
Recording Sessions to the SRS.

Otherwise this might be satisfied by delivering them mixed together.
[DS] So this should read "....the ability to independently deliver
media....", correct? 

> REQ-014 The mechanism MUST support the ability to deliver multiple
media for a given Communication Session over a single Recording Session
to the SRS.
> 
> REQ-014bis The mechanism MUST support the ability to deliver media
from different parties in a given Communication Session over a single
Recording Session to the SRS."

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Jun 2010 13:31:36 -0400

> [DS] So this should read "....the ability to independently deliver

yup - that's what I meant.

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Jun 2010 20:59:34 +0200

> From: Dave Smith [mailto:[email-masked]] 
> Sent: 17 June 2010 18:18
> To: Paul Kyzivat; Elwell, John
> Cc: [email-masked]
> Subject: RE: [siprec] Comments on requirements 13/14
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
[JRE] I had assumed it would not necessarily be different types of media, e.g., 2 video channels (main + presentation, say). I prefer the existing wording.

John

> --------------------------------------------------------------
> -----------------------------------------------------
> CONFIDENTIALITY NOTICE: This e-mail and any files attached 
> may contain confidential and proprietary information of 
> Alcatel-Lucent and/or its affiliated entities. Access by the 
> intended recipient only is authorized. Any liability arising 
> from any party acting, or refraining from acting, on any 
> information contained in this e-mail is hereby excluded. If 
> you are not the intended recipient, please notify the sender 
> immediately, destroy the original transmission and its 
> attachments and do not disclose the contents to any other 
> person, use it for any purpose, or store or copy the 
> information in any medium. Copyright in this e-mail and any 
> attachments belongs to Alcatel-Lucent and/or its affiliated entities.
> 					
>

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 18 Jun 2010 09:55:23 +0800

Suggest adding word mixed and un-mixed.

REQ-013 The mechanism MUST support the ability to deliver *un-mixed*
multiple media for a given Communication Session over separate Recording
Sessions to the SRS.

REQ-013bis The mechanism MUST support the ability to deliver media from
different parties in a given Communication Session over separate Recording
Sessions to the SRS.

REQ-014 The mechanism MUST support the ability to deliver *mixed* multiple
media for a given Communication Session over a single Recording Session to
the SRS.

REQ-014bis The mechanism MUST support the ability to deliver media from
different parties in a given Communication Session over a single Recording
Session to the SRS."

Regards
Deepanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Elwell, John
Sent: 2010年6月18日 0:16
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec] Comments on requirements 13/14

"REQ-013 The mechanism MUST support the ability to deliver multiple media
for a given Communication Session over separate Recording Sessions to the
SRS.

REQ-013bis The mechanism MUST support the ability to deliver media from
different parties in a given Communication Session over separate Recording
Sessions to the SRS.

REQ-014 The mechanism MUST support the ability to deliver multiple media for
a given Communication Session over a single Recording Session to the SRS.

REQ-014bis The mechanism MUST support the ability to deliver media from
different parties in a given Communication Session over a single Recording
Session to the SRS."

John 

> attention that REQ-013 and REQ-014 are intended to cover at least two 
> cases:
> multiple media for a given Communication Session over separate 
> multiple media for a given Communication Session over a single 
> Recording Session to the SRS.
> > 
> cover redundancy scenarios. However, in that case, delivering "to the 
> SRS" (i.e., to a single SRS) would not make sense - surely you would 
> deliver to different SRSs. So if we need a requirement on redundant 
> RSs, I think that would be a separate requirement. However, personally 
> I am not convinced we need a requirement on this, since whatever 
> solution we come up with it is likely that somebody could deploy it in 
> a redundant manner. I doubt our solution would need to do anything 
> special to allow redundancy.
> > 
> > John (as individual)

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 18 Jun 2010 10:00:06 +0800

Are you suggesting  "s/deliver/independently deliver/" for 14bis too??

-----Original Message-----
Paul Kyzivat
Sent: 2010年6月18日 0:39

wordsmithing...

	Thanks,
	Paul

>> conference involving two or more participants and the streams for 
>> each are delivered separately?
>>
>> RSs, I think that would be a separate requirement. However, 
>> personally I am not convinced we need a requirement on this, since 
>> whatever solution we come up with it is likely that somebody could 
>> deploy it in a redundant manner. I doubt our solution would need to 
>> do anything special to allow redundancy.
>>> John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jun 2010 08:19:54 +0200

Deepanshu,

I had not made the assumption that REQ-014 implied prior mixing. The original text just talked about a single recording session, without any suggestion of whether streams were mixed or unmixed. In fact the subject of mixing is covered by a separate requirement (REQ-012). However, I  would observe that the note below REQ-012 talks about the mixing of audio streams from different CSs, and is silent about the mixing of streams from different parties in the same CS. Nevertheless, I would suggest keeping the subject of mixing outside REQ-013/013bis/014/014bis and dealing it in REQ-012 and possibly additional requirements.

John (as individual)

> From: Deepanshu Gautam [mailto:[email-masked]] 
> Sent: 18 June 2010 02:55
> To: Elwell, John; 'Paul Kyzivat'
> Cc: [email-masked]
> *mixed* multiple
> [mailto:[email-masked]] On Behalf Of
> Elwell, John
> Sent: 2010年6月18日 0:16
> To: Paul Kyzivat
> Cc: [email-masked]
> multiple media
> multiple media for
> least two 
> personally

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jun 2010 08:27:56 +0200

I am not convinced of the need for this wordsmithing, but the updated text would be:

"REQ-013 The mechanism MUST support the ability to deliver multiple media for a given Communication Session independently over separate Recording Sessions to the SRS.

REQ-013bis The mechanism MUST support the ability to deliver media from different parties in a given Communication Session independently over separate Recording Sessions to the SRS.

Note that I would not modify 014 or 014bis, because the word "independently" might prejudice separate requirements on whether media is mixed or unmixed. For 013 and 013bis, clearly the media has to be unmixed so I can accept adding the word independently if people thinks it helps.

John (as individual)

> Sent: 17 June 2010 17:39
> deliver media from different parties in a given Communication 
> Session over separate Recording Sessions to the SRS.
> 
> deliver media from different parties in a given Communication 
> Session over a single Recording Session to the SRS."
>

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 18 Jun 2010 18:00:29 +0800

I don't think "independently" is needed for 13.

-----Original Message-----
Sent: 2010年6月18日 14:28

I am not convinced of the need for this wordsmithing, but the updated text
would be:

"REQ-013 The mechanism MUST support the ability to deliver multiple media
for a given Communication Session independently over separate Recording
Sessions to the SRS.

REQ-013bis The mechanism MUST support the ability to deliver media from
different parties in a given Communication Session independently over
separate Recording Sessions to the SRS.

Note that I would not modify 014 or 014bis, because the word "independently"
might prejudice separate requirements on whether media is mixed or unmixed.
For 013 and 013bis, clearly the media has to be unmixed so I can accept
adding the word independently if people thinks it helps.

John (as individual)

> deliver media from different parties in a given Communication Session 
> over separate Recording Sessions to the SRS.
> 
> deliver media from different parties in a given Communication Session 
> over a single Recording Session to the SRS."
> 
> >> attention that REQ-013 and REQ-014 are intended to cover at least 
> >> two cases:
> >> cover redundancy scenarios. However, in that case, delivering "to 
> >> the SRS" (i.e., to a single SRS) would not make sense - surely you 
> >> would deliver to different SRSs. So if we need a requirement on 
> >> redundant RSs, I think that would be a separate requirement. 
> >> However, personally I am not convinced we need a requirement on 
> >> this, since whatever solution we come up with it is likely that 
> >> somebody could deploy it in a redundant manner. I doubt our 
> >> solution would need to do anything special to allow redundancy.
> >>> John (as individual)

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 18 Jun 2010 18:11:31 +0800

John,

I'm fine with working on 12 to complete what is missing in it about mixing
(same as you mentioned), but i think mixing is nothing but delivering
multiple media streams over single RS, isn't?. So I think 14 *is* implying
prior mixing.

Regards
Deepanshu 

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 2010年6月18日 14:20
To: Deepanshu Gautam; 'Paul Kyzivat'
Cc: [email-masked]
Subject: RE: [siprec] Comments on requirements 13/14

Deepanshu,

I had not made the assumption that REQ-014 implied prior mixing. The
original text just talked about a single recording session, without any
suggestion of whether streams were mixed or unmixed. In fact the subject of
mixing is covered by a separate requirement (REQ-012). However, I  would
observe that the note below REQ-012 talks about the mixing of audio streams
from different CSs, and is silent about the mixing of streams from different
parties in the same CS. Nevertheless, I would suggest keeping the subject of
mixing outside REQ-013/013bis/014/014bis and dealing it in REQ-012 and
possibly additional requirements.

John (as individual)

> media for a given Communication Session over a single Recording 
> Session to the SRS.
> 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: 2010年6月18日 0:16
> To: Paul Kyzivat
> Cc: [email-masked]
> media for a given Communication Session over separate Recording 
> Sessions to the SRS.
> 
> media for a given Communication Session over a single Recording 
> Session to the SRS.
> 
>=

---

From: "Jain, Rajnish" <[email-masked]>
Date: Fri, 18 Jun 2010 06:17:30 -0400

Agree. Would also add "streams" as below:

> "streams" for a given Communication Session independently over separate Recording
> Sessions to the SRS.

> Of Deepanshu Gautam
> Sent: Friday, June 18, 2010 6:00 AM
> To: 'Elwell, John'; 'Paul Kyzivat'
> Cc: [email-masked]
> Of
> for

DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 18 Jun 2010 18:33:24 +0800

REQ-12 is silent about the mixing of streams from different parties in the
same CS. To fix this I suggest to add the following requirement.

REQ-012bis: The mechanism MUST support the ability for an SRC to deliver
mixed audio streams from different parties of a given Communication Session
to an SRS.

Regards
Deepanshu

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 2010年6月18日 14:20
To: Deepanshu Gautam; 'Paul Kyzivat'
Cc: [email-masked]
Subject: RE: [siprec] Comments on requirements 13/14

Deepanshu,

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jun 2010 12:36:52 +0200

Deepanshu,

I disagree. You can send multiple media streams unmixed (as separate RTP streams) over the same RS.

John (as individual) 

> Sent: 18 June 2010 11:12

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jun 2010 12:42:45 +0200

Deepanshu,

Although I pointed out that the note below REQ-012 seems to limit REQ-012 to multiple CSs, in fact the existing wording of REQ-012 allows for both  ("...streams from a single or multiple Communication Session..."). So perhaps we don't need a REQ-012bis, but merely an extension of the note to cover the two situations. Alternatively, if we have a REQ-012bis as you suggest, we would need to limit REQ-012 to streams from multiple CSs.

John (as individual) 

> Sent: 18 June 2010 11:33
> Subject: Mixed media from different parties in single CS
> 
>

---

From: Deepanshu Gautam <[email-masked]>
Date: Fri, 18 Jun 2010 18:49:20 +0800

I'm not quit a fan of *Notes*, I prefer limiting REQ-12 for multiple CSs.
The outcome would be...

REQ-012 The mechanism MUST support the ability for an SRC to deliver mixed
audio streams from multiple Communication Sessions to an SRS.
REQ-012bis: The mechanism MUST support the ability for an SRC to deliver
mixed audio streams from different parties of a given Communication Session
to an SRS.

Regards
Deepanshu

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 2010年6月18日 18:43
To: Deepanshu Gautam; 'Paul Kyzivat'
Cc: [email-masked]
Subject: RE: Mixed media from different parties in single CS

Deepanshu,

Although I pointed out that the note below REQ-012 seems to limit REQ-012 to
multiple CSs, in fact the existing wording of REQ-012 allows for both  ("...
streams from a single or multiple Communication Session..."). So perhaps we
don't need a REQ-012bis, but merely an extension of the note to cover the
two situations. Alternatively, if we have a REQ-012bis as you suggest, we
would need to limit REQ-012 to streams from multiple CSs.

John (as individual) 

> REQ-12 is silent about the mixing of streams from different parties in 
> the same CS. To fix this I suggest to add the following requirement.
> 
> REQ-012bis: The mechanism MUST support the ability for an SRC to 
> deliver mixed audio streams from different parties of a given 
> Communication Session to an SRS.
> 
> Regards
> Deepanshu
> 
> 
> 
> 
> original text just talked about a single recording session, without 
> any suggestion of whether streams were mixed or unmixed. In fact the 
> subject of mixing is covered by a separate requirement (REQ-012).
> However, I  would
> observe that the note below REQ-012 talks about the mixing of audio 
> streams from different CSs, and is silent about the mixing of streams 
> from different parties in the same CS. Nevertheless, I would suggest 
> keeping the subject of mixing outside REQ-013/013bis/014/014bis and 
> dealing it in REQ-012 and possibly additional requirements.
> 
> John (as individual)
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jun 2010 12:56:21 +0200

That seems clearer.

John 

> Sent: 18 June 2010 11:49
> deliver media 
> deliver media 
> deliver media 
> multiple 
> deliver media

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jun 2010 09:13:55 -0400

> Are you suggesting  "s/deliver/independently deliver/" for 14bis too??

Yes, I was.

The mixed vs. unmixed distinction is another way of saying what Was
trying to say. I'm ok with either.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jun 2010 10:40:28 -0400

> multiple media streams over single RS, isn't?. So I think 14 *is* implying

No. Mixing is about delivering multiple media streams over a single
*media stream* in the RS.

Consider the cases (assuming each participant is using a single audio
media stream:

- each participant stream is delivered as an independent
  stream over the RS. There are as many media streams in
  the RS as there are participants.

- There are fewer media streams in the RS than there are participants.
  Some of those streams contain a mix of multiple participant
  media streams.

There are at least a couple of different ways of ending up with mixed
streams:

- There was a premixed stream presented at one end of the CS.
  Somehow, the SRC is able to determine that it represents
  multiple participants.

- The streams are independent in the CSs being included in the
  RS, but the SRC is premixing them.

(But I don't believe how the streams ended up being mixed is relevant to
the SRS.)

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 18 Jun 2010 17:13:26 +0200

I agree with what Paul says.

John 

> Sent: 18 June 2010 15:40
> To: Deepanshu Gautam
> Cc: Elwell, John; [email-masked]

---

From: Leon Portman <[email-masked]>
Date: Sun, 20 Jun 2010 15:36:53 +0300

This one of the reasons why we need metadata: to tell SRS the participating media for each mix.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Friday, June 18, 2010 6:13 PM
To: Paul Kyzivat; Deepanshu Gautam
Cc: [email-masked]
Subject: Re: [siprec] Comments on requirements 13/14

John