Subject: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording.

From: <[email-masked]>
Date: Wed, 28 Mar 2012 15:48:37 +0100

This is as follow up to the threads
   “How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream”
   http://www.ietf.org/mail-archive/web/siprec/current/msg03126.html

   “How to specify in metadata that a participants stream is being recorded in multiple m line streams”
    http://www.ietf.org/mail-archive/web/siprec/current/msg03107.html

Siprec support for mixed stream recording:
   I propose multiple streams would use the same label,
   indicating that the streams are recorded in the same recording m-line stream.

Siprec support for recording same CS stream in multiple m line streams of 1 RS:
   This is the converse of the above, I propose that multiple labels be allowed in a  stream element,
   the meaning would be that the stream is recorded in all of the referenced recording m-line streams.

Implications for existing metadata specification:
   This does not change the existing metadata usage of streams and labels, it just adds more flexibility.
   The only changes required would be that
      1. stream’s label element  maxoccurs=”1” restriction would need to be removed
      2. there would  be a 1:n stream:label relationship not 1:1.
         I can’t see anything in draft-ietf-siprec-metadata-06 that says there is a 1:1 relationship anyway.

Examples:
   Mixed Stream Recording:
      If we have a persistent RS with a single m-line, and a single CS being recorded via a mixed TX/RX stream,
     then the metadata will have a single <stream> element, which has a label referencing a RS m-line.

      Now if we add a 2nd CS to that RS, we will now have two <Stream> elements, one for each CS.
      If they are both being mixed onto the one RS m-line stream, both <stream> elements will have the same label, ie:

      <stream id="Axzg12XHdhjelfjhdldjf;34jn78=="
                    session="zzlafnvvjlCHllaHF6mn8kkSS==”>
                    <label>99</label>
                </stream>
      <stream id="EiXGlc+4TruqqoDaNE76ag=="
                    session="zSfPoSvdSDCmU3A3TRDxAw==">
                    <label>99</label>
                </stream>

   Duplicate Stream Recording
      If we have a persistent RS with a single m-line, and a single CS being recorded via a mixed TX/RX stream,
      then the metadata will have a single <stream> element, which has a label referencing a RS m-line.

      If we have a a persistent RS with a two m-line’s for duplicated recording, then
      the metadata will have a single <stream> element, which has a two labels referencing both the RS m-lines.

     <stream id="Axzg12XHdhjelfjhdldjf;34jn78=="
                    session="zzlafnvvjlCHllaHF6mn8kkSS==”>
                    <label>99</label>
                    <label>100</label>
                </stream>

   Finally, we could have both the above scenarios together, where the mixed two CS recording is duplicated:

      <stream id="Axzg12XHdhjelfjhdldjf;34jn78=="
                    session="zzlafnvvjlCHllaHF6mn8kkSS==”>
                    <label>99</label>
                    <label>100</label>
                </stream>
      <stream id="EiXGlc+4TruqqoDaNE76ag=="
                    session="zSfPoSvdSDCmU3A3TRDxAw==">
                   <label>99</label>
                    <label>100</label>
                </stream>

So why do I think siprec should support these changes ?

   Requirements for mixed stream recording:

      RFC6341 refers to mixed recording in use cases 3 and 11 and in REQ 9::

      In Use Case 3:
         In some cases, more than one concurrent Communication Session (on
         a single end-user apparatus, e.g., trading-floor turret) is mixed
         into one Recording Session:

                          |-------- CS 1 -------|
                             |-------- CS 2 -------|
                        |-------- CS 3 -------|

            RS  |----------- Recording Session --------------|
            t--->

      In Use case 11:
         In trading-floor environments, in order to minimize storage and
         recording system resources, it may be preferable to mix multiple
         concurrent calls (Communication Sessions) on different handsets/
         speakers on the same turret into a single recording session.

      REQ-009: The mechanism MUST support the ability for an SRC to
         deliver mixed audio streams from different parties of a given
         Communication Session to an SRS.

      To me this implies multiple CS’s in one mixed recorder stream, since the requirement specifically
      says ”mix”, and ”to minimise storage”.

   Requirements for Duplicated stream recording:
      RFC6341 does not specifically mention duplicated recording
      But I don’t think allowing it would complicate the metadata, and it will be down to the recorder
      implementation how it handles the duplicated CS recording.

Rgds
John Stafford | Solution Architect 1 | BT Global Services

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Wed, 28 Mar 2012 21:42:40 +0000

John,

I'll explain how to form metadata XML element for your requirement:

"Siprec support for recording same CS stream in multiple m line streams of 1 RS:
   This is the converse of the above, I propose that multiple labels be allowed in a  stream element,
   the meaning would be that the stream is recorded in all of the referenced recording m-line streams."

Here,  There are two CS's,  2 m'line and 1 RS. For representing as per current XML schema is as follows,

      <stream id="Axzg12XHdhjelfjhdldjf;34jn78=="
                    session="zzlafnvvjlCHllaHF6mn8kkSS==">
                    <label>99</label>
       </stream>
      <stream id="Axzg12XHdhjelfjhdldjf;34jn78=="
                    session=" zSfPoSvdSDCmU3A3TRDxAw==">
                    <label>99</label>
       </stream>
      <stream id="EiXGlc+4TruqqoDaNE76ag=="
                    session=" zzlafnvvjlCHllaHF6mn8kkSS==">
                    <label>100</label>
       </stream>
      <stream id="EiXGlc+4TruqqoDaNE76ag=="
                    session="zSfPoSvdSDCmU3A3TRDxAw==">
                   <label>99</label>
       </stream>

Could you please explain the issue in the above approach.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 28, 2012 8:19 PM
To: [email-masked]
Subject: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording.

This is as follow up to the threads
   "How to specify in metadata that multiple CS's are being recorded in a single mixed RS m line stream"
   http://www.ietf.org/mail-archive/web/siprec/current/msg03126.html

   "How to specify in metadata that a participants stream is being recorded in multiple m line streams"
    http://www.ietf.org/mail-archive/web/siprec/current/msg03107.html

Implications for existing metadata specification:
   This does not change the existing metadata usage of streams and labels, it just adds more flexibility.
   The only changes required would be that
      1. stream's label element  maxoccurs="1" restriction would need to be removed
      2. there would  be a 1:n stream:label relationship not 1:1.
         I can't see anything in draft-ietf-siprec-metadata-06 that says there is a 1:1 relationship anyway.

Examples:
   Mixed Stream Recording:

      <stream id="Axzg12XHdhjelfjhdldjf;34jn78=="
                    session="zzlafnvvjlCHllaHF6mn8kkSS==">
                    <label>99</label>
                </stream>
      <stream id="EiXGlc+4TruqqoDaNE76ag=="
                    session="zSfPoSvdSDCmU3A3TRDxAw==">
                    <label>99</label>
                </stream>

      If we have a a persistent RS with a two m-line's for duplicated recording, then
      the metadata will have a single <stream> element, which has a two labels referencing both the RS m-lines.

     <stream id="Axzg12XHdhjelfjhdldjf;34jn78=="
                    session="zzlafnvvjlCHllaHF6mn8kkSS==">
                    <label>99</label>
                    <label>100</label>
                </stream>

      <stream id="Axzg12XHdhjelfjhdldjf;34jn78=="
                    session="zzlafnvvjlCHllaHF6mn8kkSS==">
                    <label>99</label>
                    <label>100</label>
                </stream>
      <stream id="EiXGlc+4TruqqoDaNE76ag=="
                    session="zSfPoSvdSDCmU3A3TRDxAw==">
                   <label>99</label>
                    <label>100</label>
                </stream>

      In Use Case 3:

                          |-------- CS 1 -------|
                             |-------- CS 2 -------|
                        |-------- CS 3 -------|

      In Use case 11:

      To me this implies multiple CS's in one mixed recorder stream, since the requirement specifically
      says "mix", and "to minimise storage".

   Requirements for Duplicated stream recording:
      RFC6341 does not specifically mention duplicated recording
      But I don't think allowing it would complicate the metadata, and it will be down to the recorder
      implementation how it handles the duplicated CS recording.

Rgds

---

From: <[email-masked]>
Date: Thu, 29 Mar 2012 10:04:31 +0100

Partha,

  so you are saying there is no need to allow multiple labels on a stream element, as a stream elemet can be repeated in the metadata multiple times.

  I dont see how this matches the object model, a element with a unique id can surely on occur once in the matadata.

Rgds
John Stafford | Solution Architect 1 | BT Global Services | Tel:+44 (0)1932 773504   | E: [email-masked]<mailto:[email-masked]>  |  www.bt.com/globalservices<http://www.bt.com/globalservices>

________________________________
From: Ravindran, Parthasarathi [[email-masked]]
Sent: 28 March 2012 22:42
To: Stafford,J,John,JRJ3X C; [email-masked]
Subject: RE: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording.

John,

I’ll explain how to form metadata XML element for your requirement:

“Siprec support for recording same CS stream in multiple m line streams of 1 RS:
   This is the converse of the above, I propose that multiple labels be allowed in a  stream element,
   the meaning would be that the stream is recorded in all of the referenced recording m-line streams.”

Here,  There are two CS’s,  2 m’line and 1 RS. For representing as per current XML schema is as follows,

                    session=" zSfPoSvdSDCmU3A3TRDxAw==”>

Thanks
Partha

Examples:
   Mixed Stream Recording:

      In Use Case 3:

                          |-------- CS 1 -------|
                             |-------- CS 2 -------|
                        |-------- CS 3 -------|

      In Use case 11:

Rgds

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Mar 2012 23:33:32 +0200

> indicating that the streams are recorded in the same recording m-line

Unless these streams are somehow independently separable by the SRS, it 
seems to me that they are functionally equivalent to a single CS with 
multiple participants.

Or, are the separate because the parties in one of the calls can't hear 
the people in the other call?

Without some sense of what this means (in terms of how the multiple 
streams have been combined) this could be incomprehensible to the SRS.

> referenced recording m-line streams.

I am having difficulty understanding why that would be a useful thing to 
do. Can you explain? Is is for redundancy? It isn't *very* redundant - 
neither the source nor the destination of the streams is duplicated. I 
guess you can get *something* if the two streams are on different 
subnets. We had envisioned accomplishing redundancy by establishing 
independent RS sessions to two different SRSs.

But allowing what you request seems innocuous enough. But do you then 
expect us to provide guidance to the SRS implementer about what to do 
when this usage occurs?

> If they are both being mixed onto the one RS m-line stream, both
> <stream> elements will have the same label, ie:

I suppose you have some idea of how these will be combined into the 
single RTP session represented by the m-line. But there are a lot of 
possibilities, and its not clear if/how they are reversible. (Reversible 
only by human ears is perhaps one way, though probably not the best.)

> session="zzlafnvvjlCHllaHF6mn8kkSS==”>

See my redundancy comment above.

> Communication Session to an SRS.

I guess we clearly support 9 now, and probably not 3 and 11.

Recording of the mix of multiple independent calls could certainly 
result in recording mostly noise. Maybe not so bad if you are sending 
the different calls as separate RPT streams (distinct SSRCs), especially 
if there were some way to associate the individual RTP streams to the 
siprec streams.

> implementation how it handles the duplicated CS recording.

As I noted above, we did consider duplicated recording, and assumed you 
would achieve it via separate recording sessions.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Thu, 29 Mar 2012 18:35:45 +0100

Paul,

comments inline, JS

Rgds
John Stafford | Solution Architect 1 | BT Global Services ________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: 28 March 2012 22:33
To: [email-masked]
Subject: Re: [siprec] Proposal for minor changes to metadata to support mixed stream and duplicated stream recording.

JS: Yes thats it, the calls are completely separate so far as the participants are concerned.

JS: A simple audio mix was what we intended.

JS: The destination of the streams could be different if the recorder assigned streams to different loggers.

JS: I think it can be left to the SRS implmented, there I are I think two main choices

    record one stream and ignore the other,

    or record both and provide facility in search to replay iether recording of the CS.

JS: I had only envisaged the reversible only by human ears possibility, can you explain the other possibilities.

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