Subject: Re: [siprec] Comments on draft-ietf-siprec-req-04

From: "De Villiers de Wet" <[email-masked]>
Date: Mon, 1 Nov 2010 09:52:25 +0200

Ram

How would the proposed changes to Pause & Resume of an RS impact the
definition and intended usage of Recorded Media Stream and Received
Media Stream in the metadata model?  

If pause/resumed is done by discontinuing/resuming media transmission
from the SRC side, does that mean new Received Media Stream(s), and new
Recorded Media Stream(s)?

De Villiers

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: 29 October 2010 12:20
To: Dave Smith; Henry Lum; [email-masked]
Cc: Leon Portman
Subject: Re: [siprec] Comments on draft-ietf-siprec-req-04

> -----Original Message-----
> From: Dave Smith [mailto:[email-masked]] 
> Sent: 28 October 2010 15:28
> To: Dave Smith; Henry Lum; [email-masked]
> Cc: Elwell, John; Ken Rehor (krehor); [email-masked]; 
> Leon Portman
> Subject: RE: [siprec] Comments on draft-ietf-siprec-req-04
> 
> 
> 
> -----Original Message-----
> From: Dave Smith 
> Sent: Thursday, October 28, 2010 12:41 AM
> To: Henry Lum; [email-masked]
> Subject: RE: [siprec] Comments on draft-ietf-siprec-req-04
> 
> I have provided inputs to Henry's responses below.  
> 
> Also, I have the following input to SIPREC-REQ-04.
> 
> - Recommend to update the Definition for Pause Resume   
> 
> Here is what is written in the Draft-04:  Pause and Resume during a
> Communication Session: 
> 	Pause: The action of temporarily discontinuing the recording of
> media during a CS.  
> 	Resume: The action of recommencing the recording of media for a
> CS following a pause.
> 
> I recommend to rewrite as follows:  Pause and Resume an RS:
> 	Pause:  The action of temporarily discontinuing the transmission
> or collection of RS media 
> 	Resume:  The action of recommencing the transmission or
> collection of RS media 
> 
> Rational:  Since we already have good definitions of CS and RS, and
> those definitions explain the relationship between CS and RS, 
> we should
> be able to make the definition for Pause/Resume simple, refer it to RS
> only, and leverage the definitions already provided for CS and RS.
> Also, this keeps the definition of Pause/Resume focused on the context
> of the RS,  not the CS or Playback.  Also, I believe that the 
> purpose of
> a Pause of a recording is to temporarily discontinue the collection of
> CS media, typically for security reasons, and could be implemented by
> either temporarily discontinuing the SRC media transmissions or by
> temporarily discontinuing SRS media collection (depending on 
> particular
> user needs).  REQ-015 and REQ-016 support this notion.  
[JRE] According to my interpretation the distinction between REQ-015 and
REQ-016 is based on whether the SRC initiates the pause (because it no
longer wants to make media available for recording) or the SRS initiates
the pause (because it is not in a position to accept media for
recording). In both cases I imagined the SRC would stop sending media.
If the requirements are open to different interpretations, perhaps they
need clarifying.

John

> 
> 
> Regards,
> Dave
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Henry Lum
> Sent: Wednesday, October 27, 2010 3:29 PM
> To: [email-masked]
> Subject: [siprec] Comments on draft-ietf-siprec-req-04
> 
> - REQ-030 and REQ-033 don't relate to the subheading 
> security; only -029
> and -032 are
> [DS] I agree.  
> 
> - REQ-040 seem to be missing a word in the sentence:
> "REQ-040 The mechanism SHALL provide means for an SRS to "authenticate
> SRC on RS initiation."
> [DS] I agree, and is consistent with Deepanshu's updated email on this
> subject. 
> 
> - REQ-060/061: I am a little fuzzy about what integrity actually means
> for media and metadata. Can someone explain? 
> [DS] We discussed this very early on and the input, as I remember, was
> that it meant that the mechanism must ensure that the media/metadata
> provided to the SRS by the SRC is an accurate representation of the
> original CS media/metadata.  I recommend that we re-write 
> REQ-060/061 in
> these terms instead (or include both).  
> 
> - REQ-072: I am uneasy about this requirement as it indicates that we
> endorse the idea of an SRC tapping into a CS without notifying the
> participants. We already have requirement REQ-024 to provide 
> a means to
> provide indications to the participants. Whether the SRC does this or
> not is up to the actual deployment, and I believe REQ-024 alone is
> sufficient to handle this situation.
> [DS] I agree.  I recommend to remove REQ-072.  Also, I am not 
> so sure we
> need REQ-073 and recommend to remove it (I think REQ-032 is 
> all that is
> needed). 
> 
> 
> Regards,
> Henry
> 
> 					
> --------------------------------------------------------------
> ----------
> -------------------------------------------
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
> confidential and proprietary information of Alcatel-Lucent and/or its
> affiliated entities. Access by the intended recipient only is
> authorized. Any liability arising from any party acting, or refraining
> from acting, on any information contained in this e-mail is hereby
> excluded. If you are not the intended recipient, please notify the
> sender immediately, destroy the original transmission and its
> attachments and do not disclose the contents to any other 
> person, use it
> for any purpose, or store or copy the information in any medium.
> Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
> and/or its affiliated entities.
> 					
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
> 
> 					
> --------------------------------------------------------------
> -----------------------------------------------------
> CONFIDENTIALITY NOTICE: This e-mail and any files attached 
> may contain confidential and proprietary information of 
> Alcatel-Lucent and/or its affiliated entities. Access by the 
> intended recipient only is authorized. Any liability arising 
> from any party acting, or refraining from acting, on any 
> information contained in this e-mail is hereby excluded. If 
> you are not the intended recipient, please notify the sender 
> immediately, destroy the original transmission and its 
> attachments and do not disclose the contents to any other 
> person, use it for any purpose, or store or copy the 
> information in any medium. Copyright in this e-mail and any 
> attachments belongs to Alcatel-Lucent and/or its affiliated entities.
> 					
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 1 Nov 2010 10:54:30 +0100

Sounds reasonable to me.

John 

> Sent: 29 October 2010 18:04
> To: Elwell, John; Henry Lum; [email-masked]
> Cc: Ken Rehor (krehor); [email-masked]; Leon Portman
> Good point.  Probably the idea is to terminate the transmission of
> media.  I can imagine that for security purposes we probably 
> don't ever
> want to transmit the media during a Pause.  
> However, there may be non-security related use cases where 
> transmission
> is OK but collection is not desired (e.g., a focus on 
> minimizing storage
> footprint...only collecting key media); although as long as 
> there isn't
> a side effect (e.g., clipping of media, which we have REQ-004 for) I
> don't see why halting transmission wouldn't be acceptable.  
> 
> If that is the case, the definitions could be: 
> 	Pause and Resume an RS:
> and collection of RS media 
>  	Resume:  The action of recommencing the transmission and
> collection of RS media
>  
> And probably we could combine REQ-015 and REQ-016 into a single req't
> and simplify it as follows:  
> 	REQ-015  The mechanism MUST support the ability to pause and
> resume the transmission and collection of RS media.
> 
> 
> Sound reasonable?
> 
> 
> Regards,
> Dave
> 
> 
> Sent: Friday, October 29, 2010 3:20 AM
> Cc: Ken Rehor (krehor); [email-masked]; Leon Portman
> may contain

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Nov 2010 09:20:57 -0400

On 11/1/2010 3:52 AM, De Villiers de Wet wrote:
> Ram
>
> How would the proposed changes to Pause&  Resume of an RS impact the

ISTM there are a number of options for how to pause and the impact on 
the metamodel:

1) the SRC does a new o/a and removes the paused media stream(s)
2) the SRC does a new o/a and marks the paused media stream(s) inactive
3) the SRC leaves the paused streams alone (continuing to send media)
    but sends metadata indicating that the stream(s) are paused
4) combo of (1) and (3)
5) combo of (2) and (3)

IMO (3) is a bad idea - if you don't want the media recorded its better 
to not send it, so you are certain it *can't* be recorded.

(2) is a bit more explicit than (1). It also is better in that any QoS 
that has been negotiated will be preserved, while (1) will require 
renegotiation when the resume occurs.

But neither (1) or (2) is definitive that the change is intended as a 
pause. There could be other reasons. So (4) and (5) provide the 
mechanism to be explicit.

If the mechanism of (3) is defined, then which to use can be a choice by 
the SRC.

	Thanks,
	Paul

---

From: "De Villiers de Wet" <[email-masked]>
Date: Tue, 2 Nov 2010 09:29:35 +0200

Paul

What you said makes sense - I agree option (5) is the best.  The benefit
over options (4) and (1) is that it does not (seem to) require a new
Received Media stream entity and a new Recorded Media Stream entity, one
of these just get updated with info about the pause event.

De Villiers

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 01 November 2010 15:21
To: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-req-04

the SRC.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Tue, 2 Nov 2010 11:10:07 +0200

Today we are using option (2) - putting in SDP media inactive attribute.
Anyway we should have metadata events to indicate reasons for pause/resume.
So my vote is for (2)

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of De Villiers de Wet
Sent: Tuesday, November 02, 2010 9:30 AM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-req-04

Paul

De Villiers

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 01 November 2010 15:21
To: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-req-04

the SRC.

	Thanks,
	Paul