Subject: [siprec] proposed update to RTP handling section of protocol draft

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 11 Jul 2012 17:13:13 +0000

I am in the process of updating the RTP handling section (section 7) of the protocol draft. Per the consensus at IETF 83, the changes include expanding the recommendations to cover SIPREC aware UAs and adding a section on RTP session usage by the SRC to deliver media streams to the SRS (e.g. using multiple m-lines, SSRC multiplexing, mixing).
In doing so, it seems best to me to rearrange the sections as follows:

7. RTP Handling
7.1 RTP Mechanisms
7.1.1 - 7.1.9 (previously sections 7.2 - 7.9 in version 05 of draft)
7.2 Roles (previously section 7.1 in version 05 of draft)
7.3 Examples of RTP Usage by SRC (new, based on IETF 83 presentation)
7.3.1 Multiple m-lines
7.3.2 SSRC Multiplexing
7.3.3 Mixing

Please let me know if you have any concerns or alternate suggestions.

Cheers,
Charles

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jul 2012 13:24:36 -0400

Charles,

Ram and Partha and I were just discussing the BT "turret" use case. In 
this case they want to record a "mix" of media from multiple independent 
CS media streams onto a single RS m-line. (I guess this is an optimization.)

When doing this, there is a choice of how to do the "mix". It could be 
just running multiple independent RTP streams over the single RTP 
session. Or it could be a real mix, with a single SSRC and one or 
several CSRCs.

I don't know what we want to say about this, or where it ought to go. 
But if we don't say something, somewhere, I doubt that there would be 
much chance of interoperability.

	Thanks,
	Paul

On 7/11/12 1:13 PM, Charles Eckel (eckelcu) wrote:
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 11 Jul 2012 22:48:03 +0000

Hi Paul,

My current plan is to provide examples in which an SRC uses multiple m-lines, SSRC multiplexing, or mixing, without making an explicitly recommendations as to when one method is more appropriate than another. I will include a discussion of what happens when the SRS does not support or understand the RTP session usage chosen by the SRC. In this light, the turret use case could work in either manner you described; however, multiplexing multiple RTP session with a single m-line would require the definition and negotiation a new multiplexing mechanism, such as BUNDLE or SHIM. I am not planning to provide any details regarding those at this time. We can of course add them if we determine one or the other or both required or recommended for SIPREC.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Wednesday, July 11, 2012 10:25 AM
> To: [email-masked]
> Subject: Re: [siprec] proposed update to RTP handling section of protocol
> draft
> 
> Charles,
> 
> > I am in the process of updating the RTP handling section (section 7) of the
> protocol draft. Per the consensus at IETF 83, the changes include expanding
> the recommendations to cover SIPREC aware UAs and adding a section on
> RTP session usage by the SRC to deliver media streams to the SRS (e.g. using
> multiple m-lines, SSRC multiplexing, mixing).

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jul 2012 19:16:37 -0400

> My current plan is to provide examples in which an SRC uses multiple m-lines, SSRC multiplexing, or mixing, without making an explicitly recommendations as to when one method is more appropriate th…

I think it is probably best to wait until you have written what you 
describe. Then we can discuss if and how it might work for the turret 
case, which is especially unusual.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 12 Jul 2012 22:11:20 +0000

Sounds good. The text I am adding, particularly that for SSRC multiplexing, makes several assumptions. It will be helpful to tear into those. My goal is for the text to help facilitate those discussions.

Cheers,
Charles  

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2012 4:17 PM
> To: Charles Eckel (eckelcu)
> Cc: [email-masked]
> > My current plan is to provide examples in which an SRC uses multiple m-
> lines, SSRC multiplexing, or mixing, without making an explicitly
> recommendations as to when one method is more appropriate than
> another. I will include a discussion of what happens when the SRS does not
> support or understand the RTP session usage chosen by the SRC. In this
> light, the turret use case could work in either manner you described;
> however, multiplexing multiple RTP session with a single m-line would
> require the definition and negotiation a new multiplexing mechanism, such
> as BUNDLE or SHIM. I am not planning to provide any details regarding those
> at this time. We can of course add them if we determine one or the other or
> both required or recommended for SIPREC.
>