Subject: Re: [siprec] SIPREC and Mediactrl

From: "Elwell, John" <[email-masked]>
Date: Wed, 23 Jun 2010 12:55:40 +0200

Simon,

The current SIPREC architecture draft has some discussion on its relationship to MEDIACTRL, and we had further discussions in the SIPREC interim meeting yesterday - see minutes in SIPREC archive. We believe we have a reasonable understanding how SIPREC relates to MEDIACTRL, and in view of the fact we expect to use the full 2-hour slot in Maastricht for regular SIPREC business, we would like to decline your kind offer to give a demonstration during that session.

If you have further concerns about the relationship between the two architectures, please raise on the SIPREC list, and if necessary we might organise an ad hoc get-together of interested parties in Maastricht.

John (as SIPREC co-chair)

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 12 May 2010 13:56
> To: Hutton, Andrew
> Cc: [email-masked]
> Subject: Re: [siprec] SIPREC and Mediactrl
>
> 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~~~~~~~~~~~~~~~~~~~~~~~~~
>                            \ (    (   )
>                             \_)    ) /
>                                   (_/
>
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 23 Jun 2010 15:57:45 +0200

Hi John,

I had completely forgotten my offer about a 'mediactrl-enabled recording 
demo' (which, btw, was not just a 'mediactrl demo', as stated in 
yesterday's minutes) at the siprec session in Maastricht. I do have 
understood, after our e-mail exchanges a while ago, that there is no 
interest at all inside siprec related to this cross fertilization 
activity. I can only keep on suggesting that you have an in-depth look 
at what others have already done in the IETF before you consider 
cooperation proposals as out-of-scope. Though, I am sure you have 
on-board people having all the skills needed in order to arrive at a 
timely completion of the work in the charter of the WG.
I wish you a very successful meeting at next IETF!

Cheers,
Simon

Il 23/06/2010 12.55, Elwell, John ha scritto:
>> Quoting "Hutton, Andrew"<[email-masked]>:
>>
>>      
>>> Hi Simon,
>>>

           http://www.comics.unina.it/simonpietro.romano

---

From: Brian Rosen <[email-masked]>
Date: Wed, 23 Jun 2010 10:08:25 -0400

As chairs, we aren't going to allow this work group to re-invent this particular wheel.  It appears, based on recent discussion, that the only media "control" needed for siprec (which is only the recording side) is a "pause" command, for which the standard SIP "Hold" mechanism will do.  If that remains the case, then we have no other media control mechanisms.

Brian

On Jun 23, 2010, at 9:57 AM, Simon Pietro Romano wrote:

> Hi John,
> 
> I had completely forgotten my offer about a 'mediactrl-enabled recording demo' (which, btw, was not just a 'mediactrl demo', as stated in yesterday's minutes) at the siprec session in Maastricht. I do have understood, after our e-mail exchanges a while ago, that there is no interest at all inside siprec related to this cross fertilization activity. I can only keep on suggesting that you have an in-depth look at what others have already done in the IETF before you consider cooperation proposals as out-of-scope. Though, I am sure you have on-board people having all the skills needed in order to arrive at a timely completion of the work in the charter of the WG.

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 23 Jun 2010 16:40:54 +0200

> From: Simon Pietro Romano [mailto:[email-masked]]
> Sent: 23 June 2010 14:58
> To: Elwell, John
> Cc: Hutton, Andrew; [email-masked]; Gonzalo Camarillo
> yesterday's minutes) at the siprec session in Maastricht.
[JRE] I will correct the minutes.

> I do have
[JRE] Requirements we have for which MEDIACTRL might form the basis of a solution are rather limited, and although SIPREC and MEDIACTRL might co-exist, from our discussion yesterday we didn't see MEDIACTRL as a solution to SIPREC.

I think the essence of MEDIACTRL is the control channel, and it is not clear this would play a significant role in satisfying SIPREC requirements. I think those contributing to the SIPREC architecture have not seen a need for this to date. If a need can be demonstrated, we could reconsider.

Perhaps we have misunderstood what you have in mind, so I would encourage you to follow up on the mailing list if you think this would be OK, and as I said before, the decision not to add the demo to the SIPREC agenda for IETF#78 does not preclude less formal discussions between the individuals concerned in Maastricht.

John

> > The current SIPREC architecture draft has some discussion
> on its relationship to MEDIACTRL, and we had further
> discussions in the SIPREC interim meeting yesterday - see
> minutes in SIPREC archive. We believe we have a reasonable
> understanding how SIPREC relates to MEDIACTRL, and in view of
> the fact we expect to use the full 2-hour slot in Maastricht
> for regular SIPREC business, we would like to decline your
> kind offer to give a demonstration during that session.
> >
> > If you have further concerns about the relationship between
> the two architectures, please raise on the SIPREC list, and
> if necessary we might organise an ad hoc get-together of
> interested parties in Maastricht.
> >

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 23 Jun 2010 17:23:57 +0200

John,

there's really no problem at all. The demo was dedicated to those old- 
fashioned IETFfers who still believe that running code can help  
clarify things and perhaps stimulate consensus ;-). It is not on my to- 
do list at next meeting since a while ago.

Cheers,

Simon

Il giorno 23/giu/2010, alle ore 16.40, "Elwell, John" <[email-masked] 
 > ha scritto:

> [JRE] Requirements we have for which MEDIACTRL might form the basis  
> of a solution are rather limited, and although SIPREC and MEDIACTRL  
> might co-exist, from our discussion yesterday we didn't see  
> MEDIACTRL as a solution to SIPREC.
>
> I think the essence of MEDIACTRL is the control channel, and it is  
> not clear this would play a significant role in satisfying SIPREC  
> requirements. I think those contributing to the SIPREC architecture  
> have not seen a need for this to date. If a need can be  
> demonstrated, we could reconsider.
>
> Perhaps we have misunderstood what you have in mind, so I would  
> encourage you to follow up on the mailing list if you think this  
> would be OK, and as I said before, the decision not to add the demo  
> to the SIPREC agenda for IETF#78 does not preclude less formal  
> discussions between the individuals concerned in Maastricht.
>
> John
>
>