Re: [sipcore] How to signal that a conversation is being recorded

[Brian Rosen <[e-mail]>]

If you are recording audio, then you probably want whatever indication that is rendered to the user in the audio stream, but if you are recording video, you probably want it in the video stream.  To do that locally, you need to know what is being recorded.

Brian


> On Mar 10, 2023, at 1:01 AM, Ranjit Avasarala <[e-mail]> wrote:
> 
> Hi Robert
> what use case you can think of for making it stream specific like audio or video?
> 
> On Wed, Mar 8, 2023 at 11:15 AM Robert Sparks <[e-mail] <mailto:[e-mail]>> wrote:
>> I'm not following how that helps.
>> 
>> I suggest also that it would be good, if a mechanism is being built, to 
>> make it stream specific. (Recording audio vs video).
>> 
>> The part of the conversation that says bits need to be signaled in the 
>> SDP (including the ability to ensure the integrity of the SDP), and 
>> that, perhaps, notification needs to exist in media itself makes sense 
>> to me.
>> 
>> RjS
>> 
>> On 3/8/23 11:00 AM, Ranjit Avasarala (Nokia) wrote:
>> > By sending a SIP header like:  recording: on the SRC can avoid sending the whole SDP.
>> >
>> > Regards
>> > Ranjit
>> >
>> > -----Original Message-----
>> > From: Brian Rosen <[e-mail] <mailto:[e-mail]>>
>> > Sent: Wednesday, March 8, 2023 10:32 AM
>> > To: Ranjit Avasarala (Nokia) <[e-mail] <mailto:[e-mail]>>
>> > Cc: Paul Kyzivat <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>
>> > Subject: Re: [sipcore] How to signal that a conversation is being recorded
>> >
>> >
>> > CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/ext for additional information.
>> >
>> >
>> >
>> > Why do you think a header is needed in addition to the SDP indication?  This is, after all, a media issue.
>> >
>> > Brian
>> >
>> >> On Mar 8, 2023, at 11:25 AM, Ranjit Avasarala (Nokia) <[e-mail] <mailto:[e-mail]>> wrote:
>> >>
>> >> RFC 7866 details on procedures on how participants are notified that
>> >> session is being recorded e.g. using SDP attribute:  a=record:on.
>> >>
>> >> But can we also have a SIP based mechanism like a new header:  recording: on sent in SIP INVITE by the SRC.
>> >>
>> >> Regards
>> >> Ranjit
>> >>
>> >> -----Original Message-----
>> >> From: sipcore <[e-mail] <mailto:[e-mail]>> On Behalf Of Paul Kyzivat
>> >> Sent: Tuesday, March 7, 2023 3:32 PM
>> >> To: Brian Rosen <[e-mail] <mailto:[e-mail]>>
>> >> Cc: [e-mail] <mailto:[e-mail]>
>> >> Subject: Re: [sipcore] How to signal that a conversation is being
>> >> recorded
>> >>
>> >>
>> >> CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See http://nok.it/ext for additional information.
>> >>
>> >>
>> >>
>> >> On 3/7/23 8:31 AM, Brian Rosen wrote:
>> >>> The only legal constraints I know (and IANAL) is the requirement to tell the other party that you are recording.
>> >> Perhaps this is a case when input from a lawyer is necessary - to prevent doing something that seems technically fine but that will then be shot down by lawyers.
>> >>
>> >>> I do understand the issue of a malicious actor in the middle of the path.  My use case wouldn’t have that problem, but the general case would. I suspect that we would note that in the security considerations and suggest that the recording entity insert the indications in the media if they are worried about that threat.  Real fixes would be messy: round-trip with some material only known to the endpoint?  Something like a digital signature with a cert known by the originator as the identity of the recipient?
>> >> It won't be possible to prevent a bad actor with access to the recording mechanism from blocking the notification. (That has always been true, as long as there has been telephone recording.) So I guess the goal is to have clear rules for honest equipment/sw manufacturers. And to minimize the number of components that need to be cognizant of this.
>> >>
>> >> Obviously, if the indication is sent in the signaling rather than the media it will only be displayed to the end user if the endpoint understands the feature. Not so for indication in the media.
>> >>
>> >> I think that means that there must be a negotiation between the notifier and each notifyee. If it succeeds then the notification can be omitted from the media and the endpoints will be free to render in the optimal way for the device. If the negotiation fails then the indication needs to be in the media.
>> >>
>> >> But needing to implement both will be unattractive to implementors.
>> >>
>> >>         Thanks,
>> >>         Paul
>> >>
>> >>> Brian
>> >>>
>> >>>> On Mar 6, 2023, at 10:05 PM, Paul Kyzivat <[e-mail] <mailto:[e-mail]>> wrote:
>> >>>>
>> >>>> Brian,
>> >>>>
>> >>>> Are there legal constraints here?
>> >>>>
>> >>>> I presume that the party doing the recording has a legal obligation to ensure an indication makes it to the other participants that are being recorded. OTOH there may be others in the call that might wish to suppress the indication, to one or more of the participants.
>> >>>>
>> >>>> If the indication is in the signaling, then everybody in the signaling path has an opportunity to meddle with the indication.
>> >>>>
>> >>>> That is potentially also true if the indication is in the media. But it may at least be a lot harder to do.
>> >>>>
>> >>>> I have no recommendation yet, just exploring.
>> >>>>
>> >>>>      Thanks,
>> >>>>      Paul
>> >>>>
>> >>>> On 3/6/23 5:51 PM, Brian Rosen wrote:
>> >>>>> Many are familiar with a requirement to insert an audible indication of a voice call being recorded, and in some circumstances, visible indication of a video recording.   SIPREC provides the recording mechanism, and it’s possible for the SIPREC client to insert the indications.  This doesn’t work very well in applications like emergency services, where recording often happens in multiple places.  We don’t want multiple media insertions.  The usual SIP way to do things like this is to pass the indication as data in signaling, and render the audio/video/whatever locally.
>> >>>>> Suppose we wanted to do that: we would need to pass to all endpoints (think conference) the information that the session was being recorded.
>> >>>>> Does that make sense?
>> >>>>> What would you suggest we use to carry that indication?
>> >>>>> Brian
>> >>>>> _______________________________________________
>> >>>>> sipcore mailing list
>> >>>>> [e-mail] <mailto:[e-mail]>
>> >>>>> https://www.ietf.org/mailman/listinfo/sipcore
>> >>>> _______________________________________________
>> >>>> sipcore mailing list
>> >>>> [e-mail] <mailto:[e-mail]>
>> >>>> https://www.ietf.org/mailman/listinfo/sipcore
>> >> _______________________________________________
>> >> sipcore mailing list
>> >> [e-mail] <mailto:[e-mail]>
>> >> https://www.ietf.org/mailman/listinfo/sipcore
>> 
>> _______________________________________________
>> sipcore mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore