Subject: [siprec] support for multiple m-lines

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 30 Oct 2012 16:47:27 +0000

At IETF 84, we had some discussion about an SRC using multiple m-lines. As a simple example, when recording an audio only point to point call, an SRC may offer 2 audio m-lines to the SRS, using one m-line for each participant audio stream.
The current text in the protocol draft is as follows:

   When using multiple m-lines, an SRC includes each m-line in an SDP
   offer to the SRS.  The SDP answer from the SRS MUST include all
   m-lines, with any rejected m-lines indicated with a zero port, per
   [RFC3264].  Having received the answer, the SRC starts sending media
   to the SRS as indicated in the answer.  Alternatively, if the SRC
   deems the level of support indicated in the answer to be
   unacceptable, it may initiate another SDP offer/answer exchange in
   which an alternative RTP session usage is negotiated.

The consensus from the room at the time was to add a requirement for the SRS to support a minimum number of m-lines. Here are some options:

a) SRS MUST support at least two audio m-lines (sufficient for audio only point to point call without any mixing or multiplexing)
b) SRS MUST support at least two audio m-lines and two video m-lines (sufficient for audio/video point to point call without any mixing or multiplexing)
c) SRS MUST support at least two audio m-lines and three video m-lines (sufficient for audio/video point to point call without any mixing or multiplexing, plus a shared content video channel)
 
If we address recording of conferences without mixing or multiplexing, this number of m-lines grows quickly.
For the purpose of the SIPREC protocol document, do people favor adding an SRS requirement for a, b, or c, or something else.

Thanks,
Charles

---

From: "Jain, Rajnish" <[email-masked]>
Date: Tue, 30 Oct 2012 17:03:58 +0000

I agree that specifying a MUST-level requirement on minimum number of m-lines for SRS to support for recording conferences that are not mixed is not practical. SRS implementations can still choose to implement products that exceed a, b, or c. However, in terms of a must meet requirements specification, I agree along the lines of a, b, or c. 

Thanks,
Raj

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: Tuesday, October 30, 2012 12:47 PM
To: [email-masked]
Subject: [siprec] support for multiple m-lines

 

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Oct 2012 20:32:29 -0400

> For the purpose of the SIPREC protocol document, do people favor adding an SRS requirement for a, b, or c, or something else.

I'm not sure there is anything useful that we can say.

You talk about conferences as perhaps needing more m-lines. But there is 
also the case of an SRC that wants to record multiple independent CSs 
over the same RS.

Regarding audio vs. video - I don't think we should require video 
support, because some plausible products may not want to support it. I 
suppose it is also possible to imagine a recorder product that is 
intended only to record video (e.g. surveillance) and not audio.

Clearly there is a problem if the SRS can't record at least the media it 
supports for at least one CS. (Or CS-group?)

For an SRC that is able to record multiple CSs in a single RS, I suppose 
we can assume that it will expect there to be *some* limit to how many, 
and so it might need to be prepared for rejection of an offer with too 
many m-lines. In that case it can have a fallback procedure of 
establishing another RS.

But for a single CS, I the only fallback would be from unmixed streams 
to mixed streams. And I suspect many SRCs won't be flexible enough to 
make that change.

So, while it would be nice to have some minimum to implement limit, in 
practice I think it might be impractical to impose one. I think this 
might be one of those "quality of implementation" issues. At most I 
think we might say that an SRS SHOULD be capable of accepting a separate 
stream for each participant, for each medium the SRS supports, for as 
many CSs and participants as it claims to support.

	Thanks,
	Paul