Re: [dispatch] Lossless Recording in SIPREC

[Mary Barnes <[e-mail]>]

On Mon, Feb 10, 2014 at 3:19 PM, DRAGE, Keith (Keith) <
[e-mail]> wrote:

>  The ADs make decisions.
>
> The DISPATCH WG chairs are there to represent the consensus of the WG. The
> charter does not create a special role for the DISPATCH WG chairs that goes
> beyond the role of any other WG chair.
>
> While I do not necessarily regard this as contentious, the only discussion
> we have had on the list is whether it should go to dispatch first. The WG
> has had no mails that say: "Let's dispatch this to SIPREC."
>
[MB]
That was the point of the email that I sent earlier.  This is the proposal.
 If you have a compelling reason why we shouldn't do that, then post it.

There clearly were suggestions that this topic should just be discussed in
SIPREC and Partha had added them to the thread.  Another participant
actually responded to the thread only in SIPREC (one of the reasons I
discourage cross-posting).
[/MB]

So my concern is that the WG itself has been effectively ignored.
>
[MB] Read my comment above. There is some common sense to be applied to the
process. [/MB]

>
> Let us see the question put to the WG.
>
[MB] The whole point of the DISPATCH process is that topics must be posted
to allow time for discussion and the WG to raise concerns. The DISPATCH
chairs then meet with the ADs (reviewing the relevant threads) and
determine whether there is enough interest in a topic and then propose the
best way to dispatch the topic.   There is nothing in IETF procedures that
require chairs to ask explicit questions.  Chairs make proposals and if you
disagree you can reply, in particular in cases that are clearly
non-controversial.

  Certainly, if there had been the slightest hint of controversy, we would
have kept the topic in DISPATCH until there was what the chairs deemed
clear consensus.   If you read the recording thread carefully, you can see
that one of the SIPREC chairs had previously told the individual that the
topic should be on SIPREC, so we are actually just clearly stating that
with this proposal/decision.  If you have concerns about the DISPATCH
process, please post a note to the RAI area mailing list. [/MB]

>
> regards
>
> Keith
>
>  ------------------------------
> *From:* Mary Barnes [mailto:[e-mail]]
> *Sent:* 10 February 2014 20:04
> *To:* DRAGE, Keith (Keith)
> *Cc:* Hutton, Andrew; Gerben Stam; [e-mail]
>
> *Subject:* Re: [dispatch] Lossless Recording in SIPREC
>
>  Keith,
>
>  I'm not sure what your point is.  The DISPATCH WG chairs make
> recommendations to the ADs based upon what they perceive as interest on the
> DISPATCH WG mailing list.   If you concerns about an explicit action noted
> below, please be specific.  It's not clear to me whether your concerned
> about the decision for the discussion to move to SIPREC or the general
> DISPATCH approach.
>
>  Mary.
>
>
> On Mon, Feb 10, 2014 at 1:42 PM, DRAGE, Keith (Keith) <
> [e-mail]> wrote:
>
>>  According to the charter:
>>
>> The Dispatch working group is chartered to consider proposals for
>> new work in the RAI area and identify, or help create, an appropriate
>> venue for the work.
>>
>> I would read this as a working group decision rather than a WG chairs
>> decision.
>>
>> Keith
>>
>>
>>
>>   ------------------------------
>> *From:* dispatch [mailto:[e-mail]] *On Behalf Of *Mary
>> Barnes
>> *Sent:* 10 February 2014 16:39
>> *To:* Hutton, Andrew
>> *Cc:* Gerben Stam; [e-mail]
>>
>> *Subject:* Re: [dispatch] Lossless Recording in SIPREC
>>
>>   Yes, that is the appropriate action.  The ADs just met with the
>> DISPATCH WG chairs in preparation for IETF-89. We discussed this topic and
>> agree that discussion should move to SIPREC WG mailing list. But, it's
>> important to note that this dispatchment in no way implies that the
>> community agrees that work is needed. It's up to the SIPREC WG to make that
>> decision.
>>
>>  Regards,
>> Mary
>> DISPATCH WG co-chair.
>>
>>
>> On Mon, Feb 10, 2014 at 8:05 AM, Hutton, Andrew <[e-mail]>wrote:
>>
>>> Hi Gerben,
>>>
>>> Looking back at our off-list discussion I did actually say that you
>>> "should start a discussion on the SIPREC list".
>>>
>>> Sorry if there was confusion.
>>>
>>> Andy
>>>
>>> > -----Original Message-----
>>> > From: dispatch [mailto:[e-mail]] On Behalf Of Ram
>>> > Mohan R (rmohanr)
>>>  > Sent: 06 February 2014 16:20
>>> > To: Gerben Stam
>>> > Cc: [e-mail]
>>> > Subject: Re: [dispatch] Lossless Recording in SIPREC
>>> >
>>> > Hi,
>>> >
>>> > Please see inline
>>> >
>>> > -----Original Message-----
>>> > From: Gerben Stam <[e-mail]>
>>> > Date: Thursday, 6 February 2014 8:40 pm
>>> > To: Cisco Employee <[e-mail]>
>>> > Cc: "[e-mail]" <[e-mail]>
>>> > Subject: RE: [dispatch] Lossless Recording in SIPREC
>>> >
>>> > >Hey Ram,
>>> > >
>>> > >I have had an off-line discussion with Andrew Hutton, chairman of the
>>> > >SIPREC group.
>>> > >He suggested to post this on the IETF dispatch group as it is a good
>>> > >topic to discuss in the team.
>>> >
>>> > Ok. I was not aware of this.
>>> >
>>> > >
>>> > >What would I need to do to bend this to SIPREC WG instead of Dispatch?
>>> > >
>>> > >Regards,
>>> > >
>>> > >Gerben
>>> > >
>>> > >-----Original Message-----
>>> > >From: Ram Mohan R (rmohanr) [mailto:[e-mail]]
>>> > >Sent: donderdag 6 februari 2014 15:45
>>> > >To: Gerben Stam
>>> > >Cc: [e-mail]
>>> > >Subject: Re: [dispatch] Lossless Recording in SIPREC
>>> > >
>>> > >Hi,
>>> > >
>>> > >Is there a reason why you want to have this discussion in dispatch and
>>> > >not in SIPREC WG which is meant to discuss the issues around SIP
>>> > >recording ?
>>> > >If you don¹t have any specific reason to do it here you may want to
>>> > start
>>> > >this discussion in SIPREC WG.
>>> > >
>>> > >I do have some comments on this topic but I think SIPREC WG is the
>>> > right
>>> > >place to have those discussions.
>>> > >
>>> > >
>>> > >Regards,
>>> > >Ram
>>> > >
>>> > >From:  Gerben Stam <[e-mail]>
>>> > >Date:  Thursday, 6 February 2014 3:58 pm
>>> > >To:  Gerben Stam <[e-mail]>
>>> > >Cc:  "[e-mail]" <[e-mail]>
>>> > >Subject:  [dispatch] Lossless Recording in SIPREC
>>> > >
>>> > >
>>> > >Dear DISPATCH group,
>>> > >
>>> > >SIPREC is a great initiative to standardize the interface for
>>> > capturing
>>> > >Communication Sessions.
>>> > >Session Recording is becoming more and more critical due to Compliance
>>> > >and regulatory changes over the last years.
>>> > >
>>> > >The compliance market is requesting more than capture only these days
>>> > >Confirmation is needed to acknowledge the entire Communication Session
>>> > >was captured correctly.
>>> > >RTCP Reports (rfc3611) will help to confirm complete handover of RTP
>>> > >content.
>>> > >
>>> > >
>>> > >
>>> > >New requirement is OElossless¹ Session Capturing.
>>> >
>>> > Why is this a new requirement ? RFC 6341 (SIPREC requirements) already
>>> > has
>>> > a requirement for Lossless recording. See REQ 005.
>>> >
>>> >
>>> > >Lossless indicating handover of content (RTP) is acknowledged by the
>>> > >receiver AND in case of receiving issues, the sender will resend.
>>> > >Reasons for loss may be UDP packet loss or receiver failing(over) and
>>> > >temporary not able to accept content.
>>> > >Current approach to address this OElossless¹ requirement is using 2
>>> > >independent parallel receivers.
>>> >
>>> > There may be other approaches well. For example an SRC may buffer for a
>>> > small duration to take care of the loss. Two parallel receivers still
>>> > does
>>> > not guarantee that recording is loseless as you can have UDP packet
>>> > loss
>>> > on both paths.
>>> >
>>> > >
>>> > >This requires the sender to send 2 individual streams, in fact 2
>>> > >independent SIPREC sessions.
>>> > >
>>> > >Not sure if this is covered currently as supported SIPREC deployment.
>>> >
>>> >
>>> > Current SIPREC does not have any such constraints. Depending on your
>>> > implementation model you can have the same CS recorded by multiple SRC
>>> > or
>>> > have same SRC do multiple recordings of same CS.
>>> >
>>> > Regards,
>>> > Ram
>>> >
>>> > > We do see implementations based on SIPREC supporting it.
>>> > >Alternative is quick failover at receiver in case of failure but as
>>> > >sender will send only once, this may lead to loss during failover.
>>> > >
>>> > >I am not aware of any rfc covering lossless content handover, but
>>> > there
>>> > >may be standards covering this already.
>>> > >
>>> > >
>>> > >Looking forward to discussion on the mailing list. I may be at the
>>> > London
>>> > >event.
>>> > >
>>> > >Regards,
>>> > >
>>> > >Gerben Stam,
>>> > >NICE Systems
>>> > >
>>> > >
>>> >
>>> > _______________________________________________
>>> > dispatch mailing list
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/dispatch
>>> _______________________________________________
>>> dispatch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>>
>>
>