Subject: [siprec] last call comment on draft-ietf-siprec-req-09

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 19 Apr 2011 16:33:05 -0700

I raised this comment previously, but it was not clear to me that we
reached a conclusion. As it reads today, it is not clear to me if
multiple SRCs per RS is supported. As I understand it, there may be
multiple RSs per SRS, but only one SRS per RS. The question I have is:

Q1. Is there a similar restriction of one SRC per RS?

We could:
A1. State the limitation of one SRC per RS.
A2. Add a requirement that multiple SRCs per RS be supported.
A3. Do nothing and leave it to interpretation.

I am not happy with A3, and I previously was assuming A2. I could be
convinced to go with A1. 
I see supporting multiple SRCs as being useful in distributed recording
scenarios in which there is not a single B2BUA or conference server or
UA that is entirely responsible of the recording. For example, a peer to
peer SIP network in which case the peers each decide whether or not
their input should be recorded? Or a meeting with multiple presenters in
which each presenter sends their own contributions to be recorded? Are
such cases intentionally left out of scope?

I can see use cases in which multiple parties might want to have their
own recording of the same call/meeting, perhaps to record it from their
perspective or to have their permissions and preferences associated with
the recording. This lends itself nicely to the single SRC per RS model.
But other scenarios exist, for scalability, or geographic distribution,
or other reasons, in which allowing multiple SRCs to contribute to a
single RS would be useful.

Support for multiple SRCs definitely increases the complexity. Perhaps
it is worth it, perhaps not. I would like to hear what others think.

Thanks,
Charles

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 20 Apr 2011 11:17:04 +0530

In the most trivial case, when the SRC is collocated with the
participant's device (such as a phone) we would end up with multiple
SRCs. However, each SRC can still setup its own RS to the SRS. If the
SRS can identify these recording sessions as being part of the same
recorded session, I think we would have achieved what we wanted to.

My take: We could limit the model to one SRC per RS. However, we should
facilitate the SRS to correlate multiple RSs as being part of the same
recorded session -- this could perhaps be done by distributing a unique
ID to each SRC which it includes in the metadata it sends to the SRS,
with the distributing mechanism itself being outside the scope of SIPREC
(for e.g, it could be a 3pcc generating the ID and providing it to each
phone during call setup).

Muthu 

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Charles Eckel (eckelcu)
|Sent: Wednesday, April 20, 2011 5:03 AM
|To: [email-masked]
|Subject: [siprec] last call comment on draft-ietf-siprec-req-09
|
|I raised this comment previously, but it was not clear to me that we
|reached a conclusion. As it reads today, it is not clear to me if
|multiple SRCs per RS is supported. As I understand it, there may be
|multiple RSs per SRS, but only one SRS per RS. The question I have is:
|
|Q1. Is there a similar restriction of one SRC per RS?
|
|We could:
|A1. State the limitation of one SRC per RS.
|A2. Add a requirement that multiple SRCs per RS be supported.
|A3. Do nothing and leave it to interpretation.
|
|I am not happy with A3, and I previously was assuming A2. I could be
|convinced to go with A1.
|I see supporting multiple SRCs as being useful in distributed recording
|scenarios in which there is not a single B2BUA or conference server or
|UA that is entirely responsible of the recording. For example, a peer
to
|peer SIP network in which case the peers each decide whether or not
|their input should be recorded? Or a meeting with multiple presenters
in
|which each presenter sends their own contributions to be recorded? Are
|such cases intentionally left out of scope?
|
|I can see use cases in which multiple parties might want to have their
|own recording of the same call/meeting, perhaps to record it from their
|perspective or to have their permissions and preferences associated
with
|the recording. This lends itself nicely to the single SRC per RS model.
|But other scenarios exist, for scalability, or geographic distribution,
|or other reasons, in which allowing multiple SRCs to contribute to a
|single RS would be useful.
|
|Support for multiple SRCs definitely increases the complexity. Perhaps
|it is worth it, perhaps not. I would like to hear what others think.
|
|Thanks,
|Charles
|_______________________________________________
|siprec mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/siprec

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 20 Apr 2011 15:15:36 +0530

Muthu / Charles,

I believe the requirement of multiple SRC per RS is out of scope of
SIPREC now.

Ram

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Muthu ArulMozhi Perumal (mperumal)
> Sent: Wednesday, April 20, 2011 11:17 AM
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Apr 2011 08:41:39 -0400

IMO the RS is synonymous with the dialog between the SRC and the SRS, 
and so fundamentally there is only one SRC and one SRS per RS.

If there happen to be two SRCs in the same CS, and they establish RS1 
and RS2 to the *same* SRS, then it would be nice if the SRS could 
recognize that they are talking about the same CS. We early on ruled it 
out of scope, but I would like to provide at least some basics to 
facilitate that in the mechanism if it isn't too much trouble.

My thought here is that we at least draw the IDs from the same space, so 
its *possible* for the two SRCs to provide the same ID for the CS. That 
doesn't make it *easy* because the two SRCs would have to collaborate 
and share the ID before that could happen. But at least it would be 
*possible*. If we use a separate ID namespace for each RS that it would 
fundamentally be impossible.

	Thanks,
	Paul

---

From: "Muthu ArulMozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 20 Apr 2011 18:54:23 +0530

+1

|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat (pkyzivat)
|Sent: Wednesday, April 20, 2011 6:12 PM
|To: [email-masked]
|Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09
|
|IMO the RS is synonymous with the dialog between the SRC and the SRS,
|and so fundamentally there is only one SRC and one SRS per RS.
|
|If there happen to be two SRCs in the same CS, and they establish RS1
|and RS2 to the *same* SRS, then it would be nice if the SRS could
|recognize that they are talking about the same CS. We early on ruled it
|out of scope, but I would like to provide at least some basics to
|facilitate that in the mechanism if it isn't too much trouble.
|
|My thought here is that we at least draw the IDs from the same space,
so
|its *possible* for the two SRCs to provide the same ID for the CS. That
|doesn't make it *easy* because the two SRCs would have to collaborate
|and share the ID before that could happen. But at least it would be
|*possible*. If we use a separate ID namespace for each RS that it would
|fundamentally be impossible.
|
|	Thanks,
|	Paul
|
|On 4/19/2011 7:33 PM, Charles Eckel (eckelcu) wrote:
|> I raised this comment previously, but it was not clear to me that we
|> reached a conclusion. As it reads today, it is not clear to me if
|> multiple SRCs per RS is supported. As I understand it, there may be
|> multiple RSs per SRS, but only one SRS per RS. The question I have
is:
|>
|> Q1. Is there a similar restriction of one SRC per RS?
|>
|> We could:
|> A1. State the limitation of one SRC per RS.
|> A2. Add a requirement that multiple SRCs per RS be supported.
|> A3. Do nothing and leave it to interpretation.
|>
|> I am not happy with A3, and I previously was assuming A2. I could be
|> convinced to go with A1.
|> I see supporting multiple SRCs as being useful in distributed
recording
|> scenarios in which there is not a single B2BUA or conference server
or
|> UA that is entirely responsible of the recording. For example, a peer
to
|> peer SIP network in which case the peers each decide whether or not
|> their input should be recorded? Or a meeting with multiple presenters
in
|> which each presenter sends their own contributions to be recorded?
Are
|> such cases intentionally left out of scope?
|>
|> I can see use cases in which multiple parties might want to have
their
|> own recording of the same call/meeting, perhaps to record it from
their
|> perspective or to have their permissions and preferences associated
with
|> the recording. This lends itself nicely to the single SRC per RS
model.
|> But other scenarios exist, for scalability, or geographic
distribution,
|> or other reasons, in which allowing multiple SRCs to contribute to a
|> single RS would be useful.
|>
|> Support for multiple SRCs definitely increases the complexity.
Perhaps
|> it is worth it, perhaps not. I would like to hear what others think.
|>
|> Thanks,
|> Charles
|> _______________________________________________
|> siprec mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/siprec
|>
|_______________________________________________
|siprec mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/siprec

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 20 Apr 2011 16:46:07 +0200

I pretty much agree with what Paul and others have said in response to Charles. The RS really represents the SIP dialog, and associated media, between an SRC and an SRS. If two or more SRCs want to contribute to the same recording, there are a number of possibilities:
- Have a unique recording ID - this is not an identifier for the RS but for the recording.
- If the different SRCs are all recording parts of the same CS, a unique CS ID or some other unique attribute of the CS would serve the purpose.
- If the different SRCs are all recording different CSs from the same CS group, a unique CS Group ID would serve the purpose.
All of these are likely to require some means of communication between the SRCs, typically on the signalling path of the CS, but that has been ruled out of scope for this WG (various proposals for session identifiers are kicking around in DISPATCH).

Anyway, this is getting in the realm of solution, and the question to Charles is whether anything needs to be added to or changed in the Requirements document to cover his concern.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 20 April 2011 13:42
> To: [email-masked]

---

From: Leon Portman <[email-masked]>
Date: Wed, 20 Apr 2011 17:51:53 +0300

+1

The question is if it is more metadata requirement than the mechanism requirement.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Wednesday, April 20, 2011 5:46 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [siprec] last call comment on draft-ietf-siprec-req-09

John

> recognize that they are talking about the same CS. We early on ruled 
> it out of scope, but I would like to provide at least some basics to 
> My thought here is that we at least draw the IDs from the same space, 
> so its *possible* for the two SRCs to provide the same ID for the CS. 
> That doesn't make it *easy* because the two SRCs would have to 
> collaborate and share the ID before that could happen. But at least it 
> would be *possible*. If we use a separate ID namespace for each RS 
> that it would fundamentally be impossible.
> 
> 	Thanks,
> 	Paul
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 20 Apr 2011 12:52:11 -0700

Works for me. This addresses my concern and I agree that no new
requirements or modifications to requirements are necessary for this
from my perspective.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Leon Portman
> Sent: Wednesday, April 20, 2011 7:52 AM
> To: Elwell, John; Paul Kyzivat (pkyzivat); [email-masked]
Behalf Of Elwell, John
> I pretty much agree with what Paul and others have said in response to
Charles. The RS really
> represents the SIP dialog, and associated media, between an SRC and an
SRS. If two or more SRCs want
> to contribute to the same recording, there are a number of
possibilities:
> - If the different SRCs are all recording parts of the same CS, a
unique CS ID or some other unique
> attribute of the CS would serve the purpose.
> - If the different SRCs are all recording different CSs from the same
CS group, a unique CS Group ID
> would serve the purpose.
> All of these are likely to require some means of communication between
the SRCs, typically on the
> signalling path of the CS, but that has been ruled out of scope for
this WG (various proposals for
> session identifiers are kicking around in DISPATCH).
> 
> Anyway, this is getting in the realm of solution, and the question to
Charles is whether anything
> needs to be added to or changed in the Requirements document to cover
his concern.