Subject: [siprec] Consensus calls from Quebec

From: "Elwell, John" <[email-masked]>
Date: Thu, 4 Aug 2011 11:31:57 +0200

The following were agreed at the Quebec face-to-face. Please raise any objections by 2011-08-14.

Metadata:
- Include associate/dissociate times for Participant in a CS.
- A Participant can exist outside the context of a CS or CSG.
- Contact header field parameters to be included as an attribute of an association between Participant and CS.
- Multiple identifiers to be allowed for a Participant.
- Metadata to include information to associate a Participant with a CSRC value.
- All receiving Participants are to be explicitly indicated (no receive by default).

Protocol:
- Proceed with snapshot request to recover from synchronization issues (but not syntax errors).
- Inclusion of sequence number in metadata XML.
- A snapshot request to lead to repeat of SDP (offer-answer) in addition to re-sending of XML.
- Addition of option tag(s) so that they can be used in Require to ensure RS failure if non-compliant UA encountered.
- Adoption of draft as WG item (note that it will not at this stage include RTP text - that will be adopted later).

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Aug 2011 10:25:17 -0400

> - Metadata to include information to associate a Participant with a CSRC value.

I'd like to double check with those who know RTP better than I:

I *presume* that CSRC assignments may be made on a per-media stream 
basis, and so the association of Participant to CSRC must be specified 
separately for each stream.

So, a participant may have multiple CSRCs - potentially a different one 
for each stream in which it participates.

And IIUC the CSRC value representing a participant can change over time 
within a stream.

I think it may also be the case that one CSRC value may represent 
different participants in different streams, though its my impression 
this would be rare.

Does anyone disagree with the above?

And a question: can a single participant have multiple CSRCs 
concurrently for the same stream?

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 15 Aug 2011 14:17:14 -0700

Hi Paul,

Sorry for the late response. Please see comments inline.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
> Sent: Thursday, August 04, 2011 7:25 AM
> To: [email-masked]
> Subject: Re: [siprec] associate a Participant with a CSRC value
> 

It is really more the SSRC assignment that we needed, and yes, there may
be more than 1. The SSRCs becomes the CSRCs when a mixer combines
multiple contributing sources into a single mixed stream. In this case
the SSRC is that of the mixer, and the CSRCs are the SSRCs of the
original streams combined by the mixer. 
The SSRC can change due to collisions of SSRC values, and multiple SSRCS
may be used to multiplex multiple streams within a single RTP session.

> for each stream in which it participates.

Yes, but really multiple SSRCs, which may result in multiple CSRCs.

> And IIUC the CSRC value representing a participant can change over
time

Yes.

> different participants in different streams, though its my impression

I guess is a mixer is mixing previously mixed streams, this could
happen; but really the first mixer should preserve the original SRCSs as
CSRCs in the stream it sends, and the second mixer should preserve these
CSRCs as CSRCs in the stream it sends.
 
Cheers,
Charles

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