Subject: [siprec] Fwd: Re: SIPREC and Mediactrl

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 30 Jul 2010 14:23:24 +0200

Here we go again. Sorry for resurrecting this once more ;-). I promise 
this is the last time I interfere.

Simon

-------- Messaggio originale --------
Oggetto: 	Re: SIPREC and Mediactrl
Data: 	Wed, 12 May 2010 14:56:04 +0200
Mittente: 	[email-masked]
A: 	Hutton, Andrew <[email-masked]>
CC: 	[email-masked] <[email-masked]>, Paul Kyzivat <[email-masked]>

Hi Andy,

I'll try to answer your question by extracting some relevant piece of
text from our draft (draft-romano-dcon-recording-01). I'm sorry about
the terminology, which might not be aligned 100% with the terms you
are currently adopting in your documents. The following piece is about
audio and video.

**************************************************************************
 From an high level topology point of view, this is how a recorder for
audio and video streams could be envisaged:

               SIP   +------------+ SIP
          /----------|   XCON AS  |--------
         /           +------------+        \
        /                   |MEDIACTRL      \
       /                    |                \
    +-----+              +-----+              +-----+
    |     |     RTP      |     |   RTP        |     |
    |UA-A +<------------>+Mixer+<------------>+UA-B |
    |     |              |     |              |     |
    +-----+              +-++--+              +-----+
                          |   |
               RTP UA-A   |   | RTP UA-B (Rx+Tx)
               (Rx+Tx)    V   V
                       +----------+
                       |          |
                       | Recorder |
                       |          |
                       +----------+

       This is a slightly modified version of the
       topology proposed on the DISPATCH mailing list,
       http://www.ietf.org/mail-archive/web/dispatch/current/
       msg00256.html
       where the Application Server has been specialized in an XCON-aware
       AS, and the AS<->Mixer protocol is the Media Control Channel
       Framework protocol (CFW) specified in
       [I-D.ietf-mediactrl-sip-control-framework].]

    Actually, recording audio and video streams in a conference
    may be accomplished in several ways.  Two different approaches might
    be highlighted:

    1.  recording each contribution from/to each participant in a
        separate file:

                                 +-------+
                                 | UAC-C |
                                 +-------+
                                     "
                             C (RTP) "
                                     "
                                     "
                                     v
   +-------+  A (RTP)           +----------+           B (RTP)  +-------+
   | UAC-A |===================>| Recorder |<===================| UAC-B |
   +-------+                    +----------+                    +-------+
                                     *
                                     *
                                     *
                                     ****>  A.gsm, A.h263
                                     ****>  B.g711, B.h264
                                     ****>  C.amr

    2.  recording the overall mix (one for audio and one from video, or
        more if several mixes for the same media type are available) in a
        dedicated file:

                                 +-------+
                                 | UAC-C |
                                 +-------+
                                     "
                             C (RTP) "
                                     "
                                     "
                                     v
   +-------+  A (RTP)           +----------+           B (RTP)  +-------+
   | UAC-A |===================>| Recorder |<===================| UAC-B |
   +-------+                    +----------+                    +-------+
                                     *
                                     *
                                     *
                                     ****>  (A+B+C).wav, (A+B+C).h263

    Of the two, the second is probably more feasable.  In fact, the first
    would require a potentially vast amount of separate recordings which
    would need to be subsequently muxed and correlated to each other.
    Besides, within the context of a multimedia conference, most of the
    times the streams are already mixed for all the participants, and so
    recording the mix directly would be a clear advantage.  Such an
    approach, of course, assumes that all the streams pass through a
    central point where the mixing occurs: it is the case depicted in
    the first figure.  The recording would take place in that point.  Such
    central point, the mixer (which in this case would also act as the
    recorder, or a frontend to it), might be a MEDIACTRL-based [RFC5567]
    Media Server.  Considering the similar nature of audio and video
    (both being RTP based and mixed by probably the same entity) they are
    analysed in the same section of this document.  The same applies to
    tagging and playout as well.  It is important to note that in case
    any policy is involved (e.g. moderation by means of the BFCP
    [RFC4582]) the mixer would take it into account when recording.  In
    fact, the same policies applied to the actual conference with respect
    to the delivery of audio and video to the participants need to be
    enforced for the recording as well.

    In a more general way, if the mixer does not support a direct
    recording of the mixes it prepares, recording a mix can be achieved
    by attaching the recorder entity (whatever it is) as a passive
    participant to the conference.  This would allow the recorder to
    receive all the involved audio and video streams already properly
    mixed, with policies already taken into consideration:

                                 +-------+
                                 |  UAC  |
                                 |   C   |
                                 +-------+
                                    " ^
                            C (RTP) " "
                                    " "
                                    " " A+B (RTP)
                                    v "
    +-------+  A (RTP)           +--------+  A+C (RTP)         +-------+
    |  UAC  |===================>| Media  |===================>|  UAC  |
    |   A   |<===================| Server |<===================|   B   |
    +-------+         B+C (RTP)  +--------+           B (RTP)  +-------+
                                     "
                                     "
                                     " A+B+C (RTP)
                                     "
                                     v
                               +----------+
                               | Recorder |
                               +----------+
                                     *
                                     ****>  (A+B+C).wav, (A+B+C).h263

    Whether or not the mixer is MEDIACTRL-based, it's quite likely that
    the AS handling the multimedia conference business logic has some
    control on the mixing involved.  This means it can request the
    recording of each available audio and/or video mix in a conference,
    if only by adding the passive participant as mentioned above.
    Besides, events occurring at the media level or business logic in the
    AS itself allow the AS to take note of timing information for each of
    the recorded media.  For instance, the AS may take note of when the
    video mixing started, in order to properly tag the video recording in
    the tagging phase.  Both the recordings and the timing events list
    would subsequently be used in order to prepare the metadata
    information of the audio and video in the overall session recording
    description.

    In a MEDIACTRL Media Server, such a functionality might be
    accomplished by means of the Mixer Control Package
    [I-D.ietf-mediactrl-mixer-control-package].  At the end of the
    conference, URLs to the actual recordings would be made available for
    the AS to use.  The AS might then subsequently access those
    recordings according to its business logic, e.g. to store them
    somewhere else (the MS storage might be temporary) or to implement an
    offline transcoding and/or mixing of all the recordings in order to
    obtain a single file representative of the whole audio/video
    participation in the conference.  Practical examples of these
    scenarios are presented in [I-D.ietf-mediactrl-call-flows].

    Of course, if the recording of a mix is not possible or desired, one
    could still fallback to the first approach, that is individually
    recording all the incoming contributions.  It is the case, for
    instance, of conferencing systems which don't implement video mixing,
    but just rely instead on a switching/forwarding of the potentially
    several video streams to each participant.  This functionality can
    also be achieved by means of the same control package previously
    introduced, since it allows for the recording of both mixes and
    individual connections.  Once the conference ends, the AS can then
    decide what to do with the recordings, e.g. mixing them all together
    offline (thus obtaining an overall mix) or leave them as they are.
    The tagging process would the subsequently take the decision into
    account, and address the resulting media accordingly.

The above should give you an idea of what we have in mind when we
think of re-using mediactrl in the framewrok of siprec. We are already
doing session recording in this way and would also be glad to present
a demo in a 10 minutes slot at the upcoming IETF, if needed.

Cheers,

Simon

Quoting "Hutton, Andrew"<[email-masked]>:

>  Hi Simon,
>
>  I changed the subject because I am having a hard time following all
>  the threads.
>
>  The SIPREC WG is currently capturing requirements and exploring
>  possible architectures and nothing has been ruled out so I don't
>  think we can be suffering from a "not invented here syndrome" already.
>
>  Personally I would like to understand more about how you think
>  mediactrl might be applicable to SIPREC.
>
>  During early discussions on requirements we discussed mediactrl and
>  it is of course easy to see how it is applicable internally within
>  the RC when it is an application server (B2BUA) or when the RS
>  itself is an application server controlling a media server. However
>  these are internal issues within the RC and RS and not within the
>  scope of SIPREC so I am not sure how you think mediactrl relates to
>  SIPREC.
>
>  Regards
>  Andy
>
>
>
>
>
>>  -----Original Message-----
>>  From: [email-masked]
>>  [mailto:[email-masked]] On Behalf Of Simon Pietro Romano
>>  Sent: 06 May 2010 15:06
>>  To: Paul Kyzivat
>>  Cc: [email-masked]
>>  Subject: Re: [siprec] FW:
>>  I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
>>
>>  Hi Paul. This is exactly what I dared to
>>  suggest at the last IETF meeting. I keep on thinking that the
>>  scope of
>>  siprec might be much less narrow rhan it currently is, if we
>>  tried and
>>  avoid the not invented here syndrome.
>>
>>  Simon
>>
>>
>>  Il giorno 06/mag/2010, alle ore 15.17, Paul Kyzivat
>>  <[email-masked]>  ha scritto:
>>
>>  >  I wasn't focusing on the detailed semantics of pause/resume.
>>  >  I'm just observing that the interface between the RC and the RS
>>  >  seems to be getting more "chatty" the longer it is discussed. Some
>>  >  of this is "control" and some of it is informative (metadata
>>  >  transfer).
>>  >
>>  >  ISTM that there is enough of this that the mediactrl
>>  approach ought
>>  >  to be *investigated* as a possible direction. That doesn't mean it
>>  >  will be selected.
>>  >
>>  >     Thanks,
>>  >     Paul
>>  >
>>  >  Ken Rehor (krehor) wrote:
>>  >>  There's Pause/Resume for Recording, which as you point out is
>>  >>  different
>>  >>  from Pause/Resume for Playback.
>>  >>  Recording Pause/Resume means media is not captured between
>>  Pause and
>>  >>  Resume. But unlike Start/Stop, Pause means the recording is
>>  >>  (assumed to)
>>  >>  going to resume. Stop implies the session is ending (and
>>  possibly the
>>  >>  file is closed).
>>  >>  Playback Pause/Resume (along with all playback features) is out of
>>  >>  scope.
>>  >>  Ken
>>  >>>  -----Original Message-----
>>  >>>  From: [email-masked] [mailto:[email-masked]] On
>>  >>>  Behalf Of Elwell, John
>>  >>>  Sent: Thursday, May 06, 2010 2:22 AM
>>  >>>  To: Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr)
>>  >>>  Cc: [email-masked]
>>  >>>  Subject: Re: [siprec]FW: I-DAction:draft-hutton-siprec-session-
>>  >>>  recording-arch-00.txt
>>  >>>
>>  >>>  I am not sure pause/resume is the correct terminology. With
>>  >>>  pause/resume, I would expect to resume at the point where
>>  I paused,
>>  >>>  i.e., with no loss of data. This implies buffering at the
>>  client for
>>  >>  an
>>  >>>  arbitrary period of time, in anticipation of an eventual resume. I
>>  >>>  think what is needed is just the ability to start/stop
>>  the recording
>>  >>>  (with loss of data while stopped). Pause/resume (and other
>>  >>  "trick-play"
>>  >>>  capabilities like fast forward/reverse) are features of playback,
>>  >>  which
>>  >>>  is out of scope.
>>  >>>
>>  >>>  John (as individual)
>>  >>>
>>  >>>>  -----Original Message-----
>>  >>>>  From: [email-masked]
>>  >>>>  [mailto:[email-masked]] On Behalf Of Paul Kyzivat
>>  >>>>  Sent: 05 May 2010 14:13
>>  >>>>  To: Ram Mohan R (rmohanr)
>>  >>>>  Cc: [email-masked]
>>  >>>>  Subject: Re: [siprec] FW:
>>  >>>>  I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
>>  >>>>
>>  >>>>  If you are going to be doing control of the recording
>>  >>>>  session, such as
>>  >>>>  pause/resume, then I think you should seriously be
>>  considering use
>>  >>  of
>>  >>>>  RTSP or mediactl. Otherwise you are reinventing the wheel.
>>  >>>>
>>  >>>>     Thanks,
>>  >>>>     Paul
>>  >>>>
>>  >>>>  Ram Mohan R (rmohanr) wrote:
>>  >>>>>  Hi Andy,
>>  >>>>>
>>  >>>>>  The metadata shall be added in the SIP header/SDP of
>>  >>>>  recording session
>>  >>>>>  (INVITE based dialog). For e.g REC-Time of metadata can be
>>  >>>>  derived from
>>  >>>>>  "Date" header of SIP. Any updation in the metadata can be
>>  >>>>  notified by
>>  >>>>>  UPDATE or RE-INVITE. I feel there is no need to create the
>>  >>>>  new (NOTIFY)
>>  >>>>>  mechanism just to pass the metadata.
>>  >>>>>
>>  >>>>>  We can use the same dialog (Recording Session) to indicate
>>  >>>>  pause/resume,
>>  >>>>>  stop/ re-start recording with metadata embedded in the message.
>>  >>>>>  If we are using out of band mechanism like NOTFIY, we
>>  need another
>>  >>>>>  mechanism to relate the Recording Session with Metadata.
>>  >>>>>
>>  >>>>>  Ram
>>  >>>>>
>>  >>>>>  -----Original Message-----
>>  >>>>>  From: Hutton, Andrew
>>  [mailto:[email-masked]]
>>  >>>>>  Sent: Wednesday, May 05, 2010 1:23 PM
>>  >>>>>  To: Brian Rosen; Ram Mohan R (rmohanr); [email-masked]
>>  >>>>>  Subject: RE: [siprec] FW:
>>  >>>>>  I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
>>  >>>>>
>>  >>>>>
>>  >>>>>  I am not sure that using INVITE is a good idea for a number
>>  >>>>  of reasons.
>>  >>>>>  It is going to need the INVITE to use a multipart body
>>  >>>>  which I am not so
>>  >>>>>  keen on. I prefer to keep the INVITE/reINVITE for creating
>>  >>>>  the session
>>  >>>>>  and use a different mechanism for metadata delivery.
>>  >>>>>
>>  >>>>>  The metadata may not be available when the recording session is
>>  >>>>>  established and it may change during the life of the
>>  >>>>  recording session
>>  >>>>>  without any need to renegotiate SDP so I guess we would
>>  >>>>  have to start
>>  >>>>>  talking about UPDATE as well. It seems cleaner to me to use an
>>  >>>  event
>>  >>>>>  package be it INFO events or NOTIFY events.
>>  >>>>>
>>  >>>>>  Regards
>>  >>>>>  Andy
>>  >>>>>
>>  >>>>>
>>  >>>>>>  -----Original Message-----
>>  >>>>>>  From: Brian Rosen [mailto:[email-masked]]
>>  >>>>>>  Sent: 04 May 2010 16:22
>>  >>>>>>  To: Ram Mohan R (rmohanr); Hutton, Andrew; [email-masked]
>>  >>>>>>  Subject: Re: [siprec] FW:
>>  >>>>>>  I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
>>  >>>>>>
>>  >>>>>>  <as individual>
>>  >>>>>>  Hmmmm
>>  >>>>>>
>>  >>>>>>  An event package is easy, the data is carried in the event
>>  >>>>>>  subscription
>>  >>>>>>  and/or NOTIFY.
>>  >>>>>>
>>  >>>>>>  INVITE is a bit trickier - you carry it in the body of the
>>  >>>>>>  message, and what
>>  >>>>>>  we need is a new MIME type.  Not too bad, and if it's
>>  >>>>>>  available then, why
>>  >>>>>>  send more messages?
>>  >>>>>>
>>  >>>>>>  You would use INFO if the metadata came after the session is
>>  >>>>>>  established.
>>  >>>>>>  On the other hand, if you defined it for INVITE, then
>>  >>>>>>  reINVITE could be
>>  >>>>>>  after the session was established.
>>  >>>>>>
>>  >>>>>>  Generally, I'm not an INFO fan, but with INFO packages, it's
>>  >>>>>>  less yucky.
>>  >>>>>>
>>  >>>>>>  So I guess the question is when does the data become
>>  >>>>>>  available?  Are we
>>  >>>>>>  thinking the event package is JUST for the metadata, or is
>>  >>>>>>  metadata tagging
>>  >>>>>>  along with something else?
>>  >>>>>>
>>  >>>>>>  I assumed it was available right from the beginning, in which
>>  >>>>>>  case carrying
>>  >>>>>>  it in the INVITE may be all you need, with the possibility of
>>  >>>>>>  a reINVITE if
>>  >>>>>>  you needed to change it mid stream.
>>  >>>>>>
>>  >>>>>>  Brian
>>  >>>>>>
>>  >>>>>>
>>  >>>>>>  On 5/4/10 10:54 AM, "Ram Mohan R (rmohanr)"
>>  >>>>  <[email-masked]>  wrote:
>>  >>>>>>>  Hi Andrew,
>>  >>>>>>>
>>  >>>>>>>  I have a comment with respect to the Mechanisms for
>>  >>>>>>  delivery of Metadata
>>  >>>>>>>  to Recording Server. I see from Section 4.3.2 that
>>  there are two
>>  >>>>>>>  mechanisms mentioned
>>  >>>>>>>  Using a new event package
>>  >>>>>>>  INFO package
>>  >>>>>>>
>>  >>>>>>>  Can we add another requirement here saying metadata could
>>  >>>>>>  be carried in
>>  >>>>>>>  a INVITE also ? I do believe we need to look at carrying
>>  >>>>  metadata in
>>  >>>>>>>  INVITE also along with the above mentioned delivery
>>  mechanisms.
>>  >>>>>>>
>>  >>>>>>>  Regards,
>>  >>>>>>>  Ram
>>  >>>>>>>
>>  >>>>>>>  -----Original Message-----
>>  >>>>>>>  From: [email-masked]
>>  >>>>>>  [mailto:[email-masked]] On Behalf
>>  >>>>>>>  Of Hutton, Andrew
>>  >>>>>>>  Sent: Thursday, April 29, 2010 11:04 PM
>>  >>>>>>>  To: [email-masked]
>>  >>>>>>>  Subject: [siprec] FW:
>>  >>>>>>>  I-DAction:draft-hutton-siprec-session-recording-arch-00.txt
>>  >>>>>>>
>>  >>>>>>>
>>  >>>>>>>  FYI - Just updated the name of the working group and made a
>>  >>  minor
>>  >>>>>>>  modification to the diagram to align with what was
>>  >>>>>>  presented at IETF77.
>>  >>>>>>>  -----Original Message-----
>>  >>>>>>>  From: [email-masked]
>>  >>>>>>>  [mailto:[email-masked]] On Behalf Of
>>  >>>>>>>  [email-masked]
>>  >>>>>>>  Sent: 29 April 2010 18:30
>>  >>>>>>>  To: [email-masked]
>>  >>>>>>>  Subject: I-D
>>  >>>>>>  Action:draft-hutton-siprec-session-recording-arch-00.txt
>>  >>>>>>>  A New Internet-Draft is available from the on-line Internet-
>>  >>>  Drafts
>>  >>>>>>>  directories.
>>  >>>>>>>
>>  >>>>>>>  Title           : An Architecture for Media Recording
>>  using the
>>  >>>>>>>  Session Initiation Protocol
>>  >>>>>>>  Author(s)       : A. Hutton, et al.
>>  >>>>>>>  Filename        :
>>  >>>>>>>  draft-hutton-siprec-session-recording-arch-00.txt
>>  >>>>>>>  Pages           : 13
>>  >>>>>>>  Date            : 2010-04-29
>>  >>>>>>>
>>  >>>>>>>  Session recording is a critical requirement in many
>>  >>>  communications
>>  >>>>>>>  environments such as call centers and financial trading.
>>  >>>>  In some of
>>  >>>>>>>  these environments, all calls must be recorded for regulatory,
>>  >>>>>>>  compliance, and consumer protection reasons.  Recording of
>>  >>>>>>  a session is
>>  >>>>>>>  typically performed by sending a copy of a media stream to
>>  >>>>>>  a recording
>>  >>>>>>>  device.  This document describes architectures for
>>  >>>>  deploying session
>>  >>>>>>>  recording solutions in an environment which is based on
>>  >>>>  the Session
>>  >>>>>>>  Initiation Protocol (SIP).  This is an initial draft
>>  >>>>  which explores
>>  >>>>>>>  possible architectural solutions and has many open issues.
>>  >>>>>>>
>>  >>>>>>>  A URL for this Internet-Draft is:
>>  >>>>>>>
>>  >>>>>>  http://www.ietf.org/internet-drafts/draft-hutton-siprec-sessio
>>  >>>>>  n-recordin
>>  >>>>>>>  g-arch-00.txt
>>  >>>>>>>
>>  >>>>>>>  Internet-Drafts are also available by anonymous FTP at:
>>  >>>>>>>  ftp://ftp.ietf.org/internet-drafts/
>>  >>>>>>>
>>  >>>>>>>  Below is the data which will enable a MIME compliant
>>  mail reader
>>  >>>>>>>  implementation to automatically retrieve the ASCII version of
>>  >>  the
>>  >>>>>>>  Internet-Draft.
>>  >>>>>>>  _______________________________________________
>>  >>>>>>>  siprec mailing list
>>  >>>>>>>  [email-masked]
>>  >>>>>>>  https://www.ietf.org/mailman/listinfo/siprec
>>  >>>>>>
>>  >>>>  _______________________________________________
>>  >>>>  siprec mailing list
>>  >>>>  [email-masked]
>>  >>>>  https://www.ietf.org/mailman/listinfo/siprec
>>  >>>>
>>  >>>  _______________________________________________
>>  >>>  siprec mailing list
>>  >>>  [email-masked]
>>  >>>  https://www.ietf.org/mailman/listinfo/siprec
>>  >  _______________________________________________
>>  >  siprec mailing list
>>  >  [email-masked]
>>  >  https://www.ietf.org/mailman/listinfo/siprec
>>  _______________________________________________
>>  siprec mailing list
>>  [email-masked]
>>  https://www.ietf.org/mailman/listinfo/siprec
>>

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Brian Rosen <[email-masked]>
Date: Fri, 30 Jul 2010 08:39:02 -0400

Simon

I understand that you are frustrated that this working group appears to you to not be paying attention to your contributions.  Your pictures below certainly relate to our architecture.  The SRC can be the UA, and the SRS can be the Mixer/Recorder.

What we don't understand is what mediacontrol does.  We create media sessions with the usual SIP/SDP stuff.  We have some control requirements, but they are limited to pause/resume, and we may simply use the SIP HOLD mechanism for that.  Understanding that our work is limited to the recording side, what would we use mediacontrol for?

I could say that if the SRC is an XCON conference participant, then we could use mediacontrol to control the conference mixer to get some custom mix of a conference to record.  However, that doesn't really support the use of mediacontrol for anything else in a recording system.

Brian

On Jul 30, 2010, at 8:23 AM, Simon Pietro Romano wrote:

> Here we go again. Sorry for resurrecting this once more ;-). I promise this is the last time I interfere.
> 
> Simon
> 
> Quoting "Hutton, Andrew" <[email-masked]>:
> 
> > Hi Simon,
> >