Subject: [siprec] recordpref attribute

From: Michael Baj <[email-masked]>
Date: Mon, 25 Jul 2011 03:00:30 +0000

I apologize in advance if some of these questions have already been answered.

When record pref is used to indicate the termination of recording of the media (as in the case where recordpref:on then later was changed to recordpref:off), should the SRC send a BYE to the SRS with a Reason header?  Will the SRS honor this reason and understand the termination reasons of the media?
Alternately, the RA should retain the RD/RS and could reINVITE the SRS with media set inactive, this may be more appropriate should the participant 
desire not to have sensitive information recorded (such as a credit card #), then re-enable recording once the sensitive information has been
transmitted to the other party.

The record attribute in the SDP answer indicates the media may be recorded, it does not indicate IF the media is actually being recorded, should there be clarification of this attribute?
How does the recipient of the SDP ever learn of the media "record" attribute state.

Thanks,
Mike

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 25 Jul 2011 13:52:40 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Baj
> Sent: 25 July 2011 04:01
> To: [email-masked]
> Subject: [siprec] recordpref attribute
> 
> When record pref is used to indicate the termination of 
> recording of the media (as in the case where recordpref:on 
> then later was changed to recordpref:off), should the SRC 
> send a BYE to the SRS with a Reason header?  Will the SRS 
> honor this reason and understand the termination reasons of the media?
> Alternately, the RA should retain the RD/RS and could 
> reINVITE the SRS with media set inactive, this may be more 
> appropriate should the participant 
> desire not to have sensitive information recorded (such as a 
> credit card #), then re-enable recording once the sensitive 
> information has been
[JRE] Way back we had an agreement that we assume the SRC somehow has access to policy as to what to record / what not to record, and therefore can start or stop recording at any time. Reasons are not given to the SRS - the TerminationReason in metadata doesn't seem to have a means to express this, but perhaps it should. If the SRC's policy is to stop recording when a participant expresses a preference for recording off, the same applies.

The action taken by the SRC in this case is up to the SRC. For example, if only video is stopped and audio continues, the audio stream would need to be stopped (e.g., switch to a=inactive). If all streams are to be stopped, one option might be to terminate the entire recording (BYE), but alternatively the streams could be suspended.

> 
> The record attribute in the SDP answer indicates the media 
> may be recorded, it does not indicate IF the media is 
> actually being recorded, should there be clarification of 
> this attribute?
[JRE] There is a separate attribute for indicating, per medium, whether recording is taking place.

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

> 
> Thanks,
> Mike
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jul 2011 07:57:00 -0400

Michael,

> transmitted to the other party.

There isn't any specification of *how* to "not record" - that is an 
implementer choice.

*If* the SRC is establishing a new RS for each call to be recorded, then 
it *might* want to terminate the RS with BYE when asked to stop 
recording. But as you note, there are other ways. This can be viewed as 
an optimization decision in the implementation based on the sorts of 
usage it expects, or observes.

> The record attribute in the SDP answer indicates the media may be recorded, it does not indicate IF the media is actually being recorded, should there be clarification of this attribute?

It only indicates *may* be recorded because the SRC in general doesn't 
know what the SRS will do with the information sent to it. Even though 
it is sending media and metadata to the SRS, the SRS might choose not to 
record it.

> How does the recipient of the SDP ever learn of the media "record" attribute state.

I don't understand the question.
Are you asking how the UA informs the *user* of that UA?

We've intentionally left that for the UA to decide.
Perhaps it has a display where it can indicate this.
Or it could locally mix something into the media stream to indicate 
this. (Obviously what/how to mix something in depends on the type of 
media - its different for audio and video. Conceivably an indication of 
video recording could be mixed into the audio, or visa versa.)

	Thanks,
	Paul

---

From: Michael Baj <[email-masked]>
Date: Mon, 25 Jul 2011 12:17:18 +0000

Paul,

Clarification on my last question:
"How does the recipient of the SDP ever learn of the media "record" attribute state?"

I meant this in 2 ways.  The first you answered by describing UA behavior.  The second way I meant to ask this question is given this scenario:

UA-A sends invites UA-B with a=recordpref:on.  UA-B has no knowledge of what the SRC does with the recordpref attribute, or even that UA-A requested that the session be recorded.  It would seem to me that the SRC should send a=record:on to UA-B.  Then, as per your example, UA-B may choose to display some indication on the phone on receipt of this attribute.  However, as you pointed out, the SRC never *really* knows if the SRS is recording the media, only that it it sending media to the SRS.

Thanks,
Mike

On Jul 25, 2011, at 7:57 AM, Paul Kyzivat wrote:

> There isn't any specification of *how* to "not record" - that is an implementer choice.
> 
> *If* the SRC is establishing a new RS for each call to be recorded, then it *might* want to terminate the RS with BYE when asked to stop recording. But as you note, there are other ways. This can be viewed as an optimization decision in the implementation based on the sorts of usage it expects, or observes.
> 
> It only indicates *may* be recorded because the SRC in general doesn't know what the SRS will do with the information sent to it. Even though it is sending media and metadata to the SRS, the SRS might choose not to record it.
> 
> Or it could locally mix something into the media stream to indicate this. (Obviously what/how to mix something in depends on the type of media - its different for audio and video. Conceivably an indication of video recording could be mixed into the audio, or visa versa.)
> 
> 	Thanks,
> 	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Jul 2011 10:01:53 -0400

> UA-A sends invites UA-B with a=recordpref:on.  UA-B has no knowledge of what the SRC does with the recordpref attribute, or even that UA-A requested that the session be recorded.  It would seem to…

a=recordpref and a=record are quite different things. And whether the 
SRC decides to do recording may or may not depend on receiving a=recordpref.

But once the SRC decides to record, its obligated to inform all the UAs 
of that, not just one that requested recording.

	Thanks,
	Paul