Subject: [siprec] Proposed text for MTI required for interop

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Nov 2012 21:22:05 +0000

Proposed/drafty text for interop minimum to implement:

An SRS that supports recording audio CS MUST support the SRC to use separate audio-type m-lines in SDP, one per CS media direction; likewise an SRC that supports audio CS MUST support using separate audio-type m-lines in SDP to the SRS, one per CS media direction.  An SRS supporting video CS recording MUST support the SRC to use separate video-type m-lines in SDP, one m-line per CS media direction; likewise an SRC that supports video CS MUST support using separate video-type m-lines in SDP to the SRS, one per CS media direction.  Therefore, for an SRS supporting a typical audio call, the SRS has to at least support receiving two audio-type m-lines; for an SRS supporting a typical audio and video call, it has to support at least receiving four total m-lines in the SDP: two audio-type m-lines and two video-type m-lines.

Note that these requirements allow a video-only capable SRS without audio recording support, as well as allow an SRS to be implemented that only supports recording one direction of one stream in a CS - for example an SRS designed to record security monitoring cameras that only send (not receive) video without any audio.  These requirements were not written to prevent other models being implemented and used instead, such as using a single m-line and mixing the separate audio streams together; rather the requirements were written to provide a common base mode to implement, for interoperability.  Implementations may support other modes as well, but have to at least support the above ones so that they interoperate in the basic mode.

-hadriel

---

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Thu, 8 Nov 2012 21:34:42 +0000

This is close but is too specific about a one-to-one mapping of RS stream
to CS stream. There are scenarios where that might not happen. Here are a
few scenarios/use cases to consider:

One audio  voice messaging, mixed conference / trader CS, mixed 2-party CS
Two audio  channel separated 2-party CS
Multiple audio - multiparticipant conference / trader CS

One video  video surveillance
Multiple video  video surveillance

One audio, one video  video messaging, mixed conference CS, mixed audio
conference CS with active-speaker video (metadata may or may not need to
keep up with change of active speaker)
Two audio, one video ‹ channel separated audio from 2-party CS with
active-speaker video

Two audio, two video ‹ channel separated audio 2-party CS  (one audio, one
video per participant)

N audio, M video ‹ multi-camera CS

Ken

On 11/8/12 1:22 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>An SRS that supports recording audio CS MUST support the SRC to use
>separate audio-type m-lines in SDP, one per CS media direction; likewise
>an SRC that supports audio CS MUST support using separate audio-type
>m-lines in SDP to the SRS, one per CS media direction.  An SRS supporting
>video CS recording MUST support the SRC to use separate video-type
>m-lines in SDP, one m-line per CS media direction; likewise an SRC that
>supports video CS MUST support using separate video-type m-lines in SDP
>to the SRS, one per CS media direction.  Therefore, for an SRS supporting
>a typical audio call, the SRS has to at least support receiving two
>audio-type m-lines; for an SRS supporting a typical audio and video call,
>it has to support at least receiving four total m-lines in the SDP: two
>audio-type m-lines and two video-type m-lines.
>
>Note that these requirements allow a video-only capable SRS without audio
>recording support, as well as allow an SRS to be implemented that only
>supports recording one direction of one stream in a CS - for example an
>SRS designed to record security monitoring cameras that only send (not
>receive) video without any audio.  These requirements were not written to
>prevent other models being implemented and used instead, such as using a
>single m-line and mixing the separate audio streams together; rather the
>requirements were written to provide a common base mode to implement, for
>interoperability.  Implementations may support other modes as well, but
>have to at least support the above ones so that they interoperate in the
>basic mode.
>
>-hadriel
>
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Nov 2012 21:41:41 +0000

I *think* (but could easily be wrong) that the text I proposed covers all those in the normative requirement portion - i.s., in the lines that say MUST.  Because it says "per CS media direction".  So if there's only one CS media flow/direction, there's only one m-line; if there're 100 media flows, there could be 100 m-lines.  If the media is _already_ mixed when it reaches the SRC, it's one media direction/flow to it so only needs one m-line (per direction).

No?

-hadriel

---

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Thu, 8 Nov 2012 22:00:56 +0000

Oh I see. I was reading "per CS media direction" as the audio from each
participant, therefore needing one recording stream for each participant.

Ken

On 11/8/12 1:41 PM, "Hadriel Kaplan" <[email-masked]> wrote:

>
>I *think* (but could easily be wrong) that the text I proposed covers all
>those in the normative requirement portion - i.s., in the lines that say
>MUST.  Because it says "per CS media direction".  So if there's only one
>CS media flow/direction, there's only one m-line; if there're 100 media
>flows, there could be 100 m-lines.  If the media is _already_ mixed when
>it reaches the SRC, it's one media direction/flow to it so only needs one
>m-line (per direction).
>
>No?
>
>-hadriel
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Nov 2012 17:31:29 -0500

Hadriel,

Why should we put any limits on the SRC. It is in the driver seat 
regarding whether to mix or not. And so there is no need for it to 
support the mode it doesn't use. And consider a conference focus SRC. It 
may not be capable of sending unmixed media to the recorder. (If it did, 
it might have to send 100 streams.)

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 8 Nov 2012 22:54:36 +0000

Because then we'd have to have a MUST for the SRS to support BOTH modes instead, no? (which by the way I don't mind/care either way)

-hadriel

On Nov 8, 2012, at 5:31 PM, Paul Kyzivat <[email-masked]> wrote:

> Hadriel,
> 
> Why should we put any limits on the SRC. It is in the driver seat regarding whether to mix or not. And so there is no need for it to support the mode it doesn't use. And consider a conference focus SRC. It may not be capable of sending unmixed media to the recorder. (If it did, it might have to send 100 streams.)
> 
> 	Thanks,
> 	Paul	
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 Nov 2012 18:17:56 -0500

> Because then we'd have to have a MUST for the SRS to support BOTH modes instead, no? (which by the way I don't mind/care either way)

Yes. Isn't that a no-brainer?

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 9 Nov 2012 04:25:10 +0000

I dunno and don't care either way - either's fine with me, whatever the group wants.
:)

-hadriel