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

worley@ariadne.com Tue, 07 March 2023 19:52 UTC

Return-Path: <worley@alum.mit.edu>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB804C151B0A for <sipcore@ietfa.amsl.com>; Tue, 7 Mar 2023 11:52:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.981
X-Spam-Level:
X-Spam-Status: No, score=-0.981 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiA_1PhhylqA for <sipcore@ietfa.amsl.com>; Tue, 7 Mar 2023 11:52:10 -0800 (PST)
Received: from resqmta-c1p-024062.sys.comcast.net (resqmta-c1p-024062.sys.comcast.net [96.102.19.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B1FC151AFD for <sipcore@ietf.org>; Tue, 7 Mar 2023 11:52:09 -0800 (PST)
Received: from resomta-c1p-022592.sys.comcast.net ([96.102.18.237]) by resqmta-c1p-024062.sys.comcast.net with ESMTP id ZWIop2qesGdamZdK3p6o1A; Tue, 07 Mar 2023 19:50:07 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20211018a; t=1678218607; bh=rfMkA9ud6O+aCiRWEnMues1tnVhhvGUDNbhdQxt0Rn4=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID:Xfinity-Spam-Result; b=lSH1dlcvaj087y8e4EEcUL9IfpWMHPPQKtPc3+9MzsgHt1JVIY6yyvtDj7cA7qgwh T5MwhAKiNytTfxa7lLMQAtmSbagRvAWjXnyER1CSM5M0rDTgBR17NZRw6RUohrikIN my7neFJ4BpNZEow8gCpV9+i2bFzIs0HAcmVaEi8SYLJBiLPt44IQ+JMRVXA15tbygC FZrnmQ9INiDdqI8eIVRopP76vqsHyg8xIe2/PIHZ6QV3/nrK+CkXT6o7+KTvvpC7mp ORkHUy2yofusYtRPnVAesGLZrS4inC/T91C96VkFki5Mu7UbKDoQMyTyoFluH3r3Pw 0fdn7JxXtUG0g==
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430::7e42]) by resomta-c1p-022592.sys.comcast.net with ESMTPA id ZdK2pZSMZ45ojZdK2p6hpu; Tue, 07 Mar 2023 19:50:07 +0000
X-Xfinity-VMeta: sc=0.00;st=legit
Received: from hobgoblin.ariadne.com (localhost [127.0.0.1]) by hobgoblin.ariadne.com (8.16.1/8.16.1) with ESMTPS id 327Jo5Fu3861712 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for <sipcore@ietf.org>; Tue, 7 Mar 2023 14:50:05 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.16.1/8.16.1/Submit) id 327Jo5Vt3861709; Tue, 7 Mar 2023 14:50:05 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: sipcore@ietf.org
In-Reply-To: <082A7485-5C3C-4356-88A8-6A333A07D60D@brianrosen.net>
Sender: worley@ariadne.com
Date: Tue, 07 Mar 2023 14:50:05 -0500
Message-ID: <87wn3sjq8i.fsf@hobgoblin.ariadne.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/6hghXySZSZwIyiIUrHGDbgxAmRk>
Subject: Re: [sipcore] How to signal that a conversation is being recorded
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Mar 2023 19:52:13 -0000

Brian Rosen <br@brianrosen.net> writes:
> 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?

I did a little poking around, and found that Siprec RFC 7866 sec. 5.3
defines an "a=record" attribute for SDP to indicate that the session is
being recorded.  And that seems to be an adequate solution to the
problem you describe.  (It take it as understood that each user's UA
will inform that user that recording is in progress, by whatever
mechanism is desired.)

Only after that, did I reread your message carefully, and you seem to be
completely aware of Siprec.  (Likely you know more about it than I do.)

> 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.

What exactly is the problem you're raising?

Dale