Subject: [siprec] use case 8 - geographically distribued/centralized recording

From: "Henry Lum" <[email-masked]>
Date: Thu, 10 Jun 2010 08:05:57 -0700

Hi,

It's unclear to me what the last sentence in use case 8 mean:

   o Conference based solution is not applicable because it will require

   to reroute all communications via data centers.

Conference-based solution can sometimes be useful for recording
purposes. I think this statement is a bit too specific in certain
deployment models, and I suggest that we remove this statement from the
use case.

Regards,

Henry

-------------------------------------------------------------------------------------------------------------------
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: "Hutton, Andrew" <[email-masked]>
Date: Sun, 13 Jun 2010 18:04:21 +0200

I agree and I seem to remember we agreed to removed to remove this statement about a conference based solution in a recent discussion.

Regards
Andy

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henry Lum
Sent: 10 June 2010 16:06
To: [email-masked]
Subject: [siprec] use case 8 - geographically distribued/centralized recording

Hi,

Conference-based solution can sometimes be useful for recording purposes. I think this statement is a bit too specific in certain deployment models, and I suggest that we remove this statement from the use case.

Regards,
Henry

---

From: "Jain, Rajnish" <[email-masked]>
Date: Sun, 13 Jun 2010 15:13:32 -0400

I agree as well. We need to be able to (optionally) record shared lines and conferences in addition to (or as an alternative to) recording individual participants.

Thanks,
Raj

From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Sunday, June 13, 2010 12:04 PM
To: Henry Lum; [email-masked]
Subject: Re: [siprec] use case 8 - geographically distribued/centralized recording

Regards
Andy

Regards,
Henry

________________________________
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: Paul Kyzivat <[email-masked]>
Date: Sun, 13 Jun 2010 16:28:37 -0400

Jain, Rajnish wrote:
> I agree as well. We need to be able to (optionally) record shared lines 
> and conferences in addition to (or as an alternative to) recording 
> individual participants.

This seems like a "duh" to me - how could you possibly forbid it? In 
some cases it wouldn't even be possible to tell this is what is happening.

I expect the significant aspect to this is when the SRC *knows* that the 
stream being offered is a mix, and wants to provide the identities of 
all the participants.

One thing I was wondering about in that case:

Should there be provision for specifying the correlation between SSRC in 
the media stream and a particular participant? (I think it would have to 
be optional, since the SRC may not know it.)

	Thanks,
	Paul

> Thanks,
> 
> Raj
> 
>  
> 
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Hutton, Andrew
> *Sent:* Sunday, June 13, 2010 12:04 PM
> *To:* Henry Lum; [email-masked]
> *Subject:* Re: [siprec] use case 8 - geographically 
> distribued/centralized recording
> 
>  
> 
> I agree and I seem to remember we agreed to removed to remove this 
> statement about a conference based solution in a recent discussion.
> 
>  
> 
> Regards
> 
> Andy
> 
>      
> 
>     ------------------------------------------------------------------------
> 
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Henry Lum
>     *Sent:* 10 June 2010 16:06
>     *To:* [email-masked]
>     *Subject:* [siprec] use case 8 - geographically
>     distribued/centralized recording
> 
>     Hi,
> 
>      
> 
>     It’s unclear to me what the last sentence in use case 8 mean:
> 
>      
> 
>     deployment models, and I suggest that we remove this statement from
>     the use case.
> 
>      
> 
>     Regards,
> 
>     Henry
> 
>      
> 
>      
> 
> 
>     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.
> 
> 
> ------------------------------------------------------------------------
> 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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Dave Smith" <[email-masked]>
Date: Mon, 14 Jun 2010 01:29:16 -0700

I agree also.  

Although there may be some efficiencies associated with not allowing a
conferencing solution (for example, for a use case where a conversation
between two remote endpoints located near each other does not have to be
sent/pin-tailed/tromboned through a central data center), a conferencing
solution may provided some benefits (in addition to the recording
benefits, e.g., reporting).  And the operational cost of a conferencing
architecture may not be prohibitive; and the benefits may outweigh them
(in some use cases).  

Yes, I'd recommend to remove that statement as well.

Regards,

Dave

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henry Lum
Sent: Thursday, June 10, 2010 8:06 AM
To: [email-masked]
Subject: [siprec] use case 8 - geographically
distribued/centralizedrecording

Hi,

Regards,

Henry

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: "Henry Lum" <[email-masked]>
Date: Mon, 14 Jun 2010 07:39:45 -0700

The SRC, if it's recording for another endpoint in the communication
session, does not know the SSRC until it receives the media stream. It
may be too late for the SRC for synchronize this information when
establishing the RS. It's a nice to have but I don't think we can count
on it.

Henry

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Sunday, June 13, 2010 4:29 PM
To: Jain, Rajnish
Cc: Hutton, Andrew; Henry Lum; [email-masked]
Subject: Re: [siprec] use case 8 - geographically distribued/centralized
recording

This seems like a "duh" to me - how could you possibly forbid it? In 
some cases it wouldn't even be possible to tell this is what is
happening.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Jun 2010 11:41:09 -0400

> establishing the RS. It's a nice to have but I don't think we can count

It should not be necessary to know the information at the time the media 
stream is negotiated by the SRC and SRS. The correlation between 
participant and SSRC could be passed on later when it is known.

But unless the SRC is acting as the mixer, it may *never* know that 
correlation. So I think there will be many cases when the recorder has a 
  premixed stream and doesn't know how to correlate the parts of it to 
individual participants even if it does know who those participants are.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 14 Jun 2010 22:18:28 +0530

Please see inline for comments <Ram>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat (pkyzivat)
Sent: Monday, June 14, 2010 9:11 PM
To: Henry Lum
Cc: Jain, Rajnish; [email-masked]
Subject: Re: [siprec] use case 8- geographically distribued/centralized
recording

<Ram> In case where the SRC acts as mixer and knows that it is mixing
the participant streams, it can indicate the same in the metadata to
SRS.
The metadata could have a field that correlates all the participants to
that media stream ( that represents the mixed media of those
participants).
I don't see a real need to have SSRC here.
</Ram>
	Thanks,
	Paul

------------------------------------------------------------------------
-------------------------------------------

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 15 Jun 2010 12:22:28 +0200

Getting into details of SSRC sounds like we are going beyond the bounds of the requirements document. If there is a requirement we can express in more general terms, fine, but otherwise can we leave this until discussing solutions?

John (as individual) 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 14 June 2010 16:41
> To: Henry Lum
> >>     *From:* [email-masked] 
> [mailto:[email-masked]]
> > *On
> >>     Behalf Of *Henry Lum
> >>        o Conference based solution is not applicable 
> because it will
> > require
> >>     only is authorized. Any liability arising from any 
> party acting,
> > or
> >>     notify the sender immediately, destroy the original 
> transmission
> > and
> >>     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
> --------------------------------------------------------------
> -----------------------------------------------------
> > 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: Paul Kyzivat <[email-masked]>
Date: Tue, 15 Jun 2010 09:05:27 -0400

I don't really have an agenda here. I was just probing to see if there 
was a perceived need for that sort of information - e.g. for the purpose 
of demuxing pre-mixed streams. I'm ok with passing on that level of detail.

	Thanks,
	Paul

Elwell, John wrote:
>> [mailto:[email-masked]] *On 
>> ----------
>> ----------
>> ----------