Subject: [siprec] Multiple recordings of the same CS/CSG...

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 May 2011 21:37:14 -0400

During the call today we got into a discussion of the 
pros/cons/mechanisms for achieving multiple recordings of the same CS or 
CSG.

I'm pretty sure this was initially posed as a potential requirement by 
Charles Eckel in:
http://www.ietf.org/mail-archive/web/siprec/current/msg01876.html

Paraphrasing, the argument is that two different participants in a CS, 
possibly with different SRCs, may both want to record the CS, and have 
control over *how* it is recorded. For instance, one may want to do its 
own mixing of the media streams and send the mix to the SRS for 
recording. It might also transcode, affecting the fidelity of the 
recording. Another participant might want all the streams recorded 
independently so they may later be analyzed separately.

It isn't immediately apparent if this sort of operation is possible with 
the current model. Superficially it seems it is not.

One question is whether this is something important to address. (If it 
happens to fall out without extra work then probably nobody will object, 
but if its extra work, then its something we really need to decide.)

Its my assertion that from a practical perspective this sort of behavior 
can be achieved with the model we have, as follows:

The mechanism currently on the table has each SRC assigning globally 
unique IDs for each CS, CSG, and various other things. This is still 
under debate, but whatever things don't end of having a globally unique 
id will almost certainly be scoped within something that does.

Unless they go to some effort to coordinate, two SRCs involved with the 
"same" CS will each assign their own unique id to it. When the SRC 
receives metadata, this CS will appear to it as two independent CSs. 
Hence, *by default* there will be two independent recordings.

If two SRCs what something different from that, they can potentially 
achieve it by coordinating unique id assignments among themselves. I am 
not proposing that we define a way to do that - at least for now it 
would be something proprietary between them. A "simple" example could be 
a fault-tolerant pair of SRCs that coordinate so that if one fails the 
other can take over and continue the recording. Here the pair would be 
coordinating a lot of sip knowledge in addition to the uuids.

*If* some SRCs are coordinating their uuid assigments, and if there are 
cases where they want to cause independent recordings to be made, then 
they can achieve that by simply *not* using the same uuid for a CS. Of 
course this opens up a whole can of worms about how they decide when 
they want to be part of the same recording and when not. But we don't 
need to get into that - it is their problem to solve.

AFAIK this ought to be sufficient for addressing Charle' problem.
Discussion welcome.

	Thanks,
	Paul

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 10 May 2011 10:47:29 +0530

This looks a pragmatic use-case and it seems at times it may need no
coordination among the SRCs at all to come up with such a unique ID
because it is reserved/distributed well ahead. Consider a meeting where
participants join from different geographic regions and each region has
an SRC performing mixing and recording of media streams generated by the
participants from that region. The meeting has a meeting ID reserved in
advance and each participant joins the meeting hosted at the SRC in that
region. The SRS can use the meeting ID to correlate these disparate
recordings.

However, it looks it would be a real challenge for the SRS to be able to
synchronously playback these disparate recording -- this doesn't look a
trivial problem to solve.

In essence, I agree we need a unique ID to address these use-cases. But,
the system should try to minimize the number of unique IDs needed.

Muthu

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat (pkyzivat)
|Sent: Tuesday, May 10, 2011 7:07 AM
|To: [email-masked]
|Subject: [siprec] Multiple recordings of the same CS/CSG...
|
|During the call today we got into a discussion of the
|pros/cons/mechanisms for achieving multiple recordings of the same CS
or
|CSG.
|
|I'm pretty sure this was initially posed as a potential requirement by
|Charles Eckel in:
|http://www.ietf.org/mail-archive/web/siprec/current/msg01876.html
|
|Paraphrasing, the argument is that two different participants in a CS,
|possibly with different SRCs, may both want to record the CS, and have
|control over *how* it is recorded. For instance, one may want to do its
|own mixing of the media streams and send the mix to the SRS for
|recording. It might also transcode, affecting the fidelity of the
|recording. Another participant might want all the streams recorded
|independently so they may later be analyzed separately.
|
|It isn't immediately apparent if this sort of operation is possible
with
|the current model. Superficially it seems it is not.
|
|One question is whether this is something important to address. (If it
|happens to fall out without extra work then probably nobody will
object,
|but if its extra work, then its something we really need to decide.)
|
|Its my assertion that from a practical perspective this sort of
behavior
|can be achieved with the model we have, as follows:
|
|The mechanism currently on the table has each SRC assigning globally
|unique IDs for each CS, CSG, and various other things. This is still
|under debate, but whatever things don't end of having a globally unique
|id will almost certainly be scoped within something that does.
|
|Unless they go to some effort to coordinate, two SRCs involved with the
|"same" CS will each assign their own unique id to it. When the SRC
|receives metadata, this CS will appear to it as two independent CSs.
|Hence, *by default* there will be two independent recordings.
|
|If two SRCs what something different from that, they can potentially
|achieve it by coordinating unique id assignments among themselves. I am
|not proposing that we define a way to do that - at least for now it
|would be something proprietary between them. A "simple" example could
be
|a fault-tolerant pair of SRCs that coordinate so that if one fails the
|other can take over and continue the recording. Here the pair would be
|coordinating a lot of sip knowledge in addition to the uuids.
|
|*If* some SRCs are coordinating their uuid assigments, and if there are
|cases where they want to cause independent recordings to be made, then
|they can achieve that by simply *not* using the same uuid for a CS. Of
|course this opens up a whole can of worms about how they decide when
|they want to be part of the same recording and when not. But we don't
|need to get into that - it is their problem to solve.
|
|AFAIK this ought to be sufficient for addressing Charle' problem.
|Discussion welcome.
|
|	Thanks,
|	Paul
|_______________________________________________
|siprec mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 May 2011 06:24:25 -0400

Muthu,

If the SRCs *know* they will want to coordinate in this case there a 
number of ways they could use the currently proposed mechanisms to 
achieve that.

For example, a uuid could be assigned as part of the predefined meeting 
state. Then each SRC could use this uuid as a CSG id. Each connection to 
the focus could be defined with a unique CS id within the common CSG id.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 10 May 2011 08:54:12 -0700

I agree.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Sent: Monday, May 09, 2011 6:37 PM
> To: [email-masked]
> Subject: [siprec] Multiple recordings of the same CS/CSG...
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Leon Portman <[email-masked]>
Date: Tue, 10 May 2011 20:53:14 +0300

+1

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: Tuesday, May 10, 2011 6:54 PM
To: Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [siprec] Multiple recordings of the same CS/CSG...

I agree.

---

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

That should work..

thanks,
Muthu

|-----Original Message-----
|From: Paul Kyzivat (pkyzivat)
|Sent: Tuesday, May 10, 2011 3:54 PM
|To: Muthu ArulMozhi Perumal (mperumal)
|Cc: [email-masked]
|Subject: Re: [siprec] Multiple recordings of the same CS/CSG...
|
|Muthu,
|
|If the SRCs *know* they will want to coordinate in this case there a
|number of ways they could use the currently proposed mechanisms to
|achieve that.
|
|For example, a uuid could be assigned as part of the predefined meeting
|state. Then each SRC could use this uuid as a CSG id. Each connection
to
|the focus could be defined with a unique CS id within the common CSG
id.
|
|	Thanks,
|	Paul
|
|On 5/10/2011 1:17 AM, Muthu ArulMozhi Perumal (mperumal) wrote:
|> This looks a pragmatic use-case and it seems at times it may need no
|> coordination among the SRCs at all to come up with such a unique ID
|> because it is reserved/distributed well ahead. Consider a meeting
where
|> participants join from different geographic regions and each region
has
|> an SRC performing mixing and recording of media streams generated by
the
|> participants from that region. The meeting has a meeting ID reserved
in
|> advance and each participant joins the meeting hosted at the SRC in
that
|> region. The SRS can use the meeting ID to correlate these disparate
|> recordings.
|>
|> However, it looks it would be a real challenge for the SRS to be able
to
|> synchronously playback these disparate recording -- this doesn't look
a
|> trivial problem to solve.
|>
|> In essence, I agree we need a unique ID to address these use-cases.
But,
|> the system should try to minimize the number of unique IDs needed.
|>
|> Muthu
|>
|> |-----Original Message-----
|> |From: [email-masked] [mailto:[email-masked]] On
|> Behalf Of Paul Kyzivat (pkyzivat)
|> |Sent: Tuesday, May 10, 2011 7:07 AM
|> |To: [email-masked]
|> |Subject: [siprec] Multiple recordings of the same CS/CSG...
|> |
|> |During the call today we got into a discussion of the
|> |pros/cons/mechanisms for achieving multiple recordings of the same
CS
|> or
|> |CSG.
|> |
|> |I'm pretty sure this was initially posed as a potential requirement
by
|> |Charles Eckel in:
|> |http://www.ietf.org/mail-archive/web/siprec/current/msg01876.html
|> |
|> |Paraphrasing, the argument is that two different participants in a
CS,
|> |possibly with different SRCs, may both want to record the CS, and
have
|> |control over *how* it is recorded. For instance, one may want to do
its
|> |own mixing of the media streams and send the mix to the SRS for
|> |recording. It might also transcode, affecting the fidelity of the
|> |recording. Another participant might want all the streams recorded
|> |independently so they may later be analyzed separately.
|> |
|> |It isn't immediately apparent if this sort of operation is possible
|> with
|> |the current model. Superficially it seems it is not.
|> |
|> |One question is whether this is something important to address. (If
it
|> |happens to fall out without extra work then probably nobody will
|> object,
|> |but if its extra work, then its something we really need to decide.)
|> |
|> |Its my assertion that from a practical perspective this sort of
|> behavior
|> |can be achieved with the model we have, as follows:
|> |
|> |The mechanism currently on the table has each SRC assigning globally
|> |unique IDs for each CS, CSG, and various other things. This is still
|> |under debate, but whatever things don't end of having a globally
unique
|> |id will almost certainly be scoped within something that does.
|> |
|> |Unless they go to some effort to coordinate, two SRCs involved with
the
|> |"same" CS will each assign their own unique id to it. When the SRC
|> |receives metadata, this CS will appear to it as two independent CSs.
|> |Hence, *by default* there will be two independent recordings.
|> |
|> |If two SRCs what something different from that, they can potentially
|> |achieve it by coordinating unique id assignments among themselves. I
am
|> |not proposing that we define a way to do that - at least for now it
|> |would be something proprietary between them. A "simple" example
could
|> be
|> |a fault-tolerant pair of SRCs that coordinate so that if one fails
the
|> |other can take over and continue the recording. Here the pair would
be
|> |coordinating a lot of sip knowledge in addition to the uuids.
|> |
|> |*If* some SRCs are coordinating their uuid assigments, and if there
are
|> |cases where they want to cause independent recordings to be made,
then
|> |they can achieve that by simply *not* using the same uuid for a CS.
Of
|> |course this opens up a whole can of worms about how they decide when
|> |they want to be part of the same recording and when not. But we
don't
|> |need to get into that - it is their problem to solve.
|> |
|> |AFAIK this ought to be sufficient for addressing Charle' problem.
|> |Discussion welcome.
|> |
|> |	Thanks,
|> |	Paul
|> |_______________________________________________
|> |siprec mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/siprec
|>

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 11 May 2011 10:43:22 -0700

+1

As I alluded in the other thread that this is a matter between the SRCs
to determine whether they want to reference the same CS using a common
identifier as the "same recording".

Henry

> Behalf Of Leon Portman
> Sent: Tuesday, May 10, 2011 1:53 PM
> To: Charles Eckel (eckelcu); Paul Kyzivat (pkyzivat); [email-masked]
> Behalf Of Charles Eckel (eckelcu)
> > pros/cons/mechanisms for achieving multiple recordings of the same
CS
> > would be something proprietary between them. A "simple" example
could
> > AFAIK this ought to be sufficient for addressing Charle' problem.

-------------------------------------------------------------------------------------------------------------------
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.