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

["Hutton, Andrew" <[e-mail]>]

Hi All,

As John pointed out section 4.1.3 of the arch draft talks about the possibility of decomposing the SRC and making use of MediaCtrl within the decomposed SRC.

I tried to draw this and came up with the picture below which is similar to Paul's drawing but shows the SIP Session (Recording Session) and Metadata between the SRC and SRS.

This shows another way in which MediaCtrl could be used as part of the overall solution (i.e. decomposing the SRC and SRS) but I still have not seen anything to indicate that it would replaces any of the interfaces which are within the scope of SIPREC (i.e. Recording Session, MetaData, and Communication Session).

Sorry about the busy diagram.

                                                           +-----------+
                                  (Recording Session)      |  Session  |
                                   +------SIP------------->| Recording |
                                   |                       |  Server   |
                                   |   +----MetaData------>|  (SRS)    |
                                   |   |                   +-----------+
                                   |   |                         ^
                                   |   | SRC using MediaCtrl    RTP
                            +----------+--------------------------------+
                            | +-------------+                    |      |
                            | |    B2BUA    |                    |      |
                            | |             |           +------------+  |
                            | |   Session   |           |            |  |
           +--------+       | |  Recording  | MEDIACTRL |   Media    |  |
           |        |<- SIP +>|   Client    |<--------->|  Server    |  |
           |  UA-A  |       | |   (SRC)     |           | (Mixer)    |  |
           |        |       | |             |           |            |  |
           |        |       | +-------------+           |            |  |
           |        |       |         ^                 +------------+  |
           |        |       +---------|-------------------^---^---------+
           |        |---------------------------RTP-------+   |
           +--------+                SIP                      |
                                      V                       |
                                 +---------+                  |
                                 |         |                  |
                                 |  UA-B   |                  |
                                 |         |<-------RTP-------+
                                 |         |
                                 +---------+


Regards
Andy


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Elwell, John
> Sent: 05 August 2010 10:04
> To: Paul Kyzivat; Brian Rosen
> Cc: [e-mail]
> Subject: Re: [siprec] Fwd: Re: SIPREC and Mediactrl
>
> Another question with Simon's sketch, and similarly with
> Paul's sketch, is why do we need a mixer? I can understand
> why it would be needed if the two RTP streams (from UA-A and
> from UA-B) are to be sent mixed to the SRS, but otherwise
> there just needs to be an entity to replicate the existing
> streams. Of course, in a multi-party call, there would indeed
> be a mixer anyway (unless media are switched rather than
> mixed), but not in a two-party call.
>
> Notwithstanding that point, I think Paul's sketch is hinted
> at by the second paragraph of 4.1.3 in the architecture draft
> (although there is no figure for that case), except that
> there would be a SIP connection SRC to SRS.
>
> Simon's sketch requires an XCON AS in the call path, which
> again seems to be redundant for the 2-party case.
>
> John
>
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> > Sent: 02 August 2010 14:28
> > To: Brian Rosen
> > Cc: [e-mail]
> > Subject: Re: [siprec] Fwd: Re: SIPREC and Mediactrl
> >
> > Brian,
> >
> > I would map Simon's picture onto the siprec terminology differently:
> >
> >                SIP   +------------+ SIP
> >           /----------|     SRC    |--------
> >          /           +------------+        \
> >         /                   |MEDIACTRL      \
> >        /                    |                \
> >     +-----+              +-----+              +-----+
> >     |     |     RTP      |     |   RTP        |     |
> >     |UA-A +<------------>+Mixer+<------------>+UA-B |
> >     |     |              |     |              |     |
> >     +-----+              +-++--+              +-----+
> >                           |   |
> >                RTP UA-A   |   | RTP UA-B (Rx+Tx)
> >                (Rx+Tx)    V   V
> >                        +----------+
> >                        |          |
> >                        |   SRS    |
> >                        | Recorder |
> >                        +----------+
> >
> > BUT, as you can see, it doesn't really fit, because the
> > SRS/Recorder has
> > no SIP connection to the SRC.
> >
> > The "mixer" is simply doing the media forking, and passing it
> > on to the
> > recorder.
> >
> > It leaves a lot of questions open. Of note, it doesn't show
> > how metadata
> > might be captured. I suppose we might imagine it being
> passed via the
> > MEDIACTRL stream from the SRC to the "Mixer". But then I
> > don't see how
> > it gets to the SRS/Recorder. Is it possible to extend the MEDIACTRL
> > interface so it could be used to convey all the metadata we consider
> > important?
> >
> > This also seems to constrain the implementation of the
> media forking,
> > which may not be desirable, since often there is already
> machinery in
> > place that can do that part in a variety of ways.
> >
> >       Thanks,
> >       Paul
> >
> >
> > Brian Rosen wrote:
> > > 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
> > >>
> > >> -------- Messaggio originale --------
> > >> Oggetto:   Re: SIPREC and Mediactrl
> > >> Data:      Wed, 12 May 2010 14:56:04 +0200
> > >> Mittente:  [e-mail]
> > >> A:         Hutton, Andrew <[e-mail]>
> > >> CC:        [e-mail] <[e-mail]>, Paul Kyzivat
> > <[e-mail]>
> > >>
> > >>
> > >>
> > >> 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" <[e-mail]>:
> > >>
> > >> > 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: [e-mail]
> > >> >> [mailto:[e-mail]] On Behalf Of Simon
> > Pietro Romano
> > >> >> Sent: 06 May 2010 15:06
> > >> >> To: Paul Kyzivat
> > >> >> Cc: [e-mail]
> > >> >> 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
> > >> >> <[e-mail]> 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: [e-mail]
> > [mailto:[e-mail]] On
> > >> >> >>> Behalf Of Elwell, John
> > >> >> >>> Sent: Thursday, May 06, 2010 2:22 AM
> > >> >> >>> To: Paul Kyzivat (pkyzivat); Ram Mohan R (rmohanr)
> > >> >> >>> Cc: [e-mail]
> > >> >> >>> 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: [e-mail]
> > >> >> >>>> [mailto:[e-mail]] On Behalf Of
> Paul Kyzivat
> > >> >> >>>> Sent: 05 May 2010 14:13
> > >> >> >>>> To: Ram Mohan R (rmohanr)
> > >> >> >>>> Cc: [e-mail]
> > >> >> >>>> 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:[e-mail]]
> > >> >> >>>>> Sent: Wednesday, May 05, 2010 1:23 PM
> > >> >> >>>>> To: Brian Rosen; Ram Mohan R (rmohanr); [e-mail]
> > >> >> >>>>> 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:[e-mail]]
> > >> >> >>>>>> Sent: 04 May 2010 16:22
> > >> >> >>>>>> To: Ram Mohan R (rmohanr); Hutton, Andrew;
> > [e-mail]
> > >> >> >>>>>> 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)"
> > >> >> >>>> <[e-mail]> 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: [e-mail]
> > >> >> >>>>>> [mailto:[e-mail]] On Behalf
> > >> >> >>>>>>> Of Hutton, Andrew
> > >> >> >>>>>>> Sent: Thursday, April 29, 2010 11:04 PM
> > >> >> >>>>>>> To: [e-mail]
> > >> >> >>>>>>> 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: [e-mail]
> > >> >> >>>>>>> [mailto:[e-mail]] On Behalf Of
> > >> >> >>>>>>> [e-mail]
> > >> >> >>>>>>> Sent: 29 April 2010 18:30
> > >> >> >>>>>>> To: [e-mail]
> > >> >> >>>>>>> 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
> > >> >> >>>>>>> [e-mail]
> > >> >> >>>>>>> https://www.ietf.org/mailman/listinfo/siprec
> > >> >> >>>>>>
> > >> >> >>>> _______________________________________________
> > >> >> >>>> siprec mailing list
> > >> >> >>>> [e-mail]
> > >> >> >>>> https://www.ietf.org/mailman/listinfo/siprec
> > >> >> >>>>
> > >> >> >>> _______________________________________________
> > >> >> >>> siprec mailing list
> > >> >> >>> [e-mail]
> > >> >> >>> https://www.ietf.org/mailman/listinfo/siprec
> > >> >> > _______________________________________________
> > >> >> > siprec mailing list
> > >> >> > [e-mail]
> > >> >> > https://www.ietf.org/mailman/listinfo/siprec
> > >> >> _______________________________________________
> > >> >> siprec mailing list
> > >> >> [e-mail]
> > >> >> https://www.ietf.org/mailman/listinfo/siprec
> > >> >>
> > >>
> > >>
> > >>
> > >> --
> > >>                             _\\|//_
> > >>                             ( O-O )
> > >>    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
> > >>                     Simon Pietro Romano
> > >>               Universita' di Napoli Federico II
> > >>                  Computer Science Department
> > >>         Phone: [phone] -- Fax: [phone]
> > >>                 e-mail: [e-mail]
> > >>
> > >>     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
> > >>    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
> > >>                          oooO
> > >>    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
> > >>                           \ (    (   )
> > >>                            \_)    ) /
> > >>                                  (_/
> > >>
> > >> _______________________________________________
> > >> siprec mailing list
> > >> [e-mail] <mailto:[e-mail]>
> > >> https://www.ietf.org/mailman/listinfo/siprec
> > >
> > >
> > >
> > --------------------------------------------------------------
> > ----------
> > >
> > > _______________________________________________
> > > siprec mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/siprec
> > _______________________________________________
> > siprec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/siprec
> >
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec
>