Subject: Re: [siprec] support for multiple m-lines

From: "Dave Higton" <[email-masked]>
Date: Thu, 1 Nov 2012 09:56:51 +0000

It is not the business of the SIPREC protocol document to specify how many streams a system must be capable of recording.  That is dependent on the end user's system requirements.  Capabilities should be determined and negotiated as part of a contract between supplier and customer.

Dave

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

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
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

NICE Systems UK Limited ("NICE") is registered in England under company number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 2 Nov 2012 13:41:19 +0000

Personally I share a similar option as Paul and Dave. Here is what the protocol draft currently says:

The reason I started this thread was because there was some concern expressed regarding this approach at IETF 84. Here is the corresponding section of the meeting minutes:

Protocol document - RTP Usage (Charles)
Picture - SRC using multiple m-lines:
If SRS does not support, it rejects one or more m-lines, and SRC might choose another option.
Discussion:
Hadriel: Is the question that if it just doesn't support multiple m-lines, so it just doesn't do anything. Isn't this related to earlier topic that SRS must support both. I object. ..
Hadriel: suggest that "Minimally must support multiple m-lines up to x number of audio and video."
Paul: SIP 101. If you offer multiple m-lines, then the recipient can decide what to take. Sender can decide then if it wants to send something else. Don't think we can say anything about this. Maybe the best thing to do is to publish some examples with "reasonable, common" cases.
Charles: what you said is what the draft says. It shows how it works for two.
Hadriel: We have a chance to improve interop. Most basic case will have two audio m-lines, thus should add something for minimal support (e.g., 2 m-lines).
Conclusion: agree with Hadriel. Text will be crafted.

I am happy to drop this and leave the text as is, but perhaps we want to revisit our discussion on this topic from IETF 84 at IETF 85.

Cheers,
Charles

> From: Dave Higton [mailto:[email-masked]]
> Sent: Thursday, November 01, 2012 5:57 AM
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: RE: support for multiple m-lines
> 
> It is not the business of the SIPREC protocol document to specify how many
> streams a system must be capable of recording.  That is dependent on the
> end user's system requirements.  Capabilities should be determined and
> negotiated as part of a contract between supplier and customer.
> 
> Dave
> 
> 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 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)
> 
> 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
> NICE Systems UK Limited ("NICE") is registered in England under company
> number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End,
> Southampton, Hampshire SO30 2ZP.
> 
> Confidentiality: This communication and any attachments are intended for
> the above-named persons only and may be confidential and/or legally
> privileged. Any opinions expressed in this communication are not
> necessarily those of NICE. If this communication has come to you in error
> you must take no action based on it, nor must you copy or show it to
> anyone; please delete/destroy and inform the sender by e-mail
> immediately.
> 
> Viruses: Although we have taken steps toward ensuring that this e-mail and
> attachments are free from any virus, we advise that in keeping with good
> computing practice the recipient should ensure they are actually virus free.

---

From: "Henry Lum" <[email-masked]>
Date: Fri, 2 Nov 2012 07:47:17 -0700

I agree that we cannot require SRS to support certain media types simply
because the product does not want to.

I also can't say how practical it is to impose any implementation limit
on the number of streams to accept. If the SRC cannot perform mixing and
the SRS is unwilling to accept more than one media stream, then it's
simply a capability mismatch. The protocol is doing the right thing to
allow both sides to properly negotiate and deal with such failure.
Similarly, in a CS, if the caller and callee don't support the same
media codecs then the SDP negotiation would fail and both sides can deal
with the failure.

Perhaps we can put some words around this to describe potential side
effects and possible failure handling, but I don't think there is much
we can mandate in the protocol for these types of scenarios.

Regards,
Henry

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> Paul Kyzivat
> Sent: October-30-12 8:32 PM
> To: [email-masked]
> Subject: Re: [siprec] support for multiple m-lines
> 
> On 10/30/12 12:47 PM, Charles Eckel (eckelcu) wrote:
> > 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 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:
> >
> > 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.
> 
> 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
>