[Vcon] vCon core issue #3B/C: parties not in the recording

Dan Petrie <dan.ietf@sipez.com> Fri, 20 March 2026 03:51 UTC

Return-Path: <dan.ietf@sipez.com>
X-Original-To: vcon@mail2.ietf.org
Delivered-To: vcon@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 03064CE6AC99 for <vcon@mail2.ietf.org>; Thu, 19 Mar 2026 20:51:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Level:
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_SUBJ_ACC_NUM=0.1] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPt8yUcUKRxi for <vcon@mail2.ietf.org>; Thu, 19 Mar 2026 20:51:07 -0700 (PDT)
Received: from sonic309-22.consmr.mail.gq1.yahoo.com (sonic309-22.consmr.mail.gq1.yahoo.com [98.137.65.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id A3C1BCE6AC5E for <vcon@ietf.org>; Thu, 19 Mar 2026 20:50:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1773978644; bh=G7bgs6DBVMlEazR3KUviXCrZq6x77965G3WCqGZIYr4=; h=Date:From:To:Subject:References:From:Subject:Reply-To; b=n72wAOli/TZiJC/23gx0UA6Qp+lXPawLU7/Ya0EaDSXKlB9gakSsPU0HKoInGyAXcI0ZCWTybmOX91V8xSkoFTk/+2oPZ/CSZmc3enACzGruOA0VUGegTjLx7D3ngnrzxCVNqo3kOMc5Sc7PHMdp1rj/1VHeRn1pw1dfPIYxC7j+gd0ZhFNIeES4u5aH4nd/WXy87sDKXop+rhKz/RwHLSmSNT8DJZPg9ukd893wG0jc7myMMFESQtYUdoPJ3roO+QYfCpMGIrpIOF/xOav9I8UUXP+jfpHE+/CfLcoQquFYyV/YD3ySd1/sxPcK7BrWAdMdB523FUTPUPdFGX5L7g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1773978644; bh=4zO/BQZktR5STCpPqIbT03YL3LrgyDmxh/hVb2Lj0Hf=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=NFN1tfbgc1Qekm78nIgfqDCnsDHXzu+hQXL1MejddvQjBg0uvV/JDiEv8lLdUsyJC7vvC5QSr+QLo//fduW5Ayf5clAh0Xfo3v0LolZGIuu90pKITXO4RF2i3uSwAaIpvVM36ahFhQCd9soSH9GanyUgNtiPoo2boaMrj8GSPHf5sU2UsEAHafDUKYH9MRuMBi7uPGuL78t9KZa1jiug1nUOBqDQeEDZWBTa2+NVpUVZSNq3OdDa0IF/1QxlsgAe7nc6JSdTg5jesbV2lXdAaNZMLO63dLzmXsADKN46WEkcoEKzy+MisVzpU+2T39nttnE1j5oK/y7+aDv8YjutPw==
X-YMail-OSG: PBNteDgVM1m0wpq3F_r4lZoJcNbEqYk9SZD6jsXQ.YxLHz_bf.rezSAIUpy9Ajs gy9lOH0JAKn26fSoOsiJkFmsgmMnJZDQ7p9EWXm7fcvQjbtbxd0SXYUZKtb_EdwdomqTgbnLl5hc 4bDWg8nodisUW.Jds.8euiiwEvZ_ICrzz7D1aIQfz1tyoG6WS3y39pCRoKZPZjNOBjpgcLsWrpj0 d6i8GxM0Pin6D3QEGmtFOsKLTtFS5rYJrWkq._GSKXxa1BfqUPQ3uGQH92.uDhIISlU.rLuTe87P 6zujYM52BB1S6ySR4yNV3Z4iOn3kVVXz6lUjHg0IfhOcR12cmRkLddBTRsNvPMM0erJh7aTkAX3R OriHqJ3fWA0yU6ae_uRiBPgRbxP1MlWj3j57qMqAjnZmfGvyHxva60BhgBWt_dpwUIZv2Md4DUSs YLR6CoZKwhwuNRFet7XH13U91rzacc1eZzIjMvbFu.MQcN7AOxXCfYL7nMMA8e7qtHGRVVQ0bb.T mB9hO9b5B1x6Di.rwTS1d65syuQCCuf.4uo1yQqdryagkmxFRWwjL_C_VrJ.y.7fpekXpJYNN1lJ Im.8w9QM8N82iSn7_OSzbuQ2gMhaIVIPBbqQK1kHc3tnzZVD6moP0z2cVPyGXy8fLf4tfvEsiSeN E5uCfTVaC9xyVXMO_gsI4s9j2z8g4AonwsBFCcGxXHCA6GiPwfS17XG5XV856jhsjqE_6uXHpeaF QvszruqSqWpvATmSMxI2XMXLHvf_vDKQsFjAaZvbe08pVQ5wjP_48E4QCHWR56de61pbOI7sHaE_ JQ_HZfaLfxYybkTTdjtyFgI6p7oJ0W9LiheZZmDJCevgBuo_LNGX1awl1469_StWW1j1WiqqJUNP 5e8WmJJzsRRJk1DP0IStAfUCDNqWg0d3bY__LMMMKEjTEBgl8ljScCDgr_30siXk2BnAI.CYSwin B7Y2bl_GA49YMJbuvmc1b7ynwu7UjYlpPyjBhSyKnKRPI5qPQrqub4Ck6DLpBK5cQYa07FI8fkPk 3EJYNMDNq5WhTj4ei7g.qSLFS08uF5IDHftitmUdgvMqNLhswCq9kFIZYQnuOSqwPjFwoEbkxBY8 9ljkShuT4gSm58K5QKChSfLMQKPNbXSaR2SkucWJ6EUNdVGtkNKDWiBO_OOQ4UyX_b9JGNOAJ8Kp thQaMFJM9P.iG4oP9pbZf2b5hk2vTaWmJCtonqkwGzTxYpIJX5kK4t9AiRyzUF_X6XJNHN3quicV AaaAhpY22pHV_0Zawaxla7SW.lVtu6uoYmc__tdS6HwiNEOfPq5se2A8l.h3HPKWS9Fv9MADw2G9 oKDqXNbyPyUi2CiLZwLYOxkGnGnpHKuhBHUD3w7JgoZVR9buAmjZxynqyOj8H4VyOCgny1bFgF.5 M4p7TjD9WmKGY42ktIXqWR1rabP09hx.mM3jiJacZuu5rlz9GE.G6jQVV_ncEOQ.HXMyVZzWZGWX DeUZ8ZxMmDLImvTdAWXs.iEdstODk5j_AJKf22oBemiD6srpU3jB3DqpyJ6_4nhP8NNtz_Xk_Uqb tnrmx4e_KsYltlehHWmWpbVYuQxXc4xdtwzkABKoFk4O021UXKAac.TuZuTLHcNAmoLU1fLbCApX d2ISthFHa5fM3P8BLEobpWdnB3rfrh5YqFUc1qNEVcFrimmWNRhPCHbU89sfN.cy4_pVPXg4SDqq FGzVpnEe5wQzex1J68kM2do6nzJpXCUihVG.udC49S0KEOPjv6a1QtjjoiR1_PDSX9ys4Othkdd5 eQYkFpFVL4gpLV2sIr0hHVBRmKt1u1ayKWilGRwL7d45I1t5cdaSDesFWPC3_ZjoSPg0YOY52v9g ByKXZOouGD9EYfAmIKRzDJOC4ZY7HkZ4d7g5r93V7zy6NWaeIUzIZuPNfoFL_BJHKfzoQeyTy7.Q 5prHQDcTSUWV.LeIxPYxrlZW3sZh4hZDaVyk7EphnHET0deRSUpsNwwT9yLmwj6GtSMBME3wwdz7 rilARHS.pGAVF99H8uwHrMAPRUOv2H8wSVcPmJTRLfQnxciW0K_g95yYsyFSw9PdVrS7aBT3Krgt FGi_eZd0UcwvNuvHo.i7vINhM7MRLEjoatHt0Tofjnn3lD8AmP55CrEeI.l0naid2xbsCGyX04Ah ANwm5inhOZXp81_pJiNgzvrr8fubilhTA2q8IuaYQd00ujo5FZC_Z0zfjXrRYQbDz0o3to4bfbGG rrKcAVRrXL4o-
X-Sonic-MF: <dan.ietf@sipez.com>
X-Sonic-ID: f6c17260-b3d1-431e-83a7-bd1d1f824d1f
Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Fri, 20 Mar 2026 03:50:44 +0000
Date: Fri, 20 Mar 2026 03:50:39 +0000
From: Dan Petrie <dan.ietf@sipez.com>
To: "vcon@ietf.org" <vcon@ietf.org>, Jonathan Lennox <jonathan.lennox42@gmail.com>, Scott Godin <sgodin@sipez.com>
Message-ID: <1980352132.918310.1773978639669@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_918309_1421716845.1773978639667"
References: <1980352132.918310.1773978639669.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.25380 YMailNorrin
Message-ID-Hash: TGCOGTVYD7IIB2KRM4OTKV2532C76NSZ
X-Message-ID-Hash: TGCOGTVYD7IIB2KRM4OTKV2532C76NSZ
X-MailFrom: dan.ietf@sipez.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Vcon] vCon core issue #3B/C: parties not in the recording
List-Id: container for conversation data <vcon.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/vcon/ahkH1t2oUXFbH5zGWdxhJIxESlw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/vcon>
List-Help: <mailto:vcon-request@ietf.org?subject=help>
List-Owner: <mailto:vcon-owner@ietf.org>
List-Post: <mailto:vcon@ietf.org>
List-Subscribe: <mailto:vcon-join@ietf.org>
List-Unsubscribe: <mailto:vcon-leave@ietf.org>

Issue 3B/C) When we have a recordings for each party (or group of parties) we end up with a Dialog Object for each recording.  The current  Dialog Object defines how to label the parties in the recording (whether they speak or not).  It does not define how to specify parties that are in a separate recording/Dialog Object, but in the same call.

Lets say we have a call with 3 parties and the audio for each party is recorded in a separate 1 channel audio file.  So we have 3 Dialog Objects, one for the recording for each party's audio.  The first Dialog Object contains the recording for party 0.
We have:{
  "type": "recording,
   "parties": [0],   "body": single channel audio file...}

but this does not show that parties 1 and 2 were also part of the call.  There will be the other dialogs for the recordings for parties 1 and 2:
{  "type": "recording,
   "parties": [1],
...},
{  "type": "recording,
   "parties": [2],...}
However there is no indication they were all in the same call.

If for the first dialog we put:   "parties": [0, 1, 2],As currently defined in the I-D, this would indicate that the audio for all three parties was mixed into the single channel audio record.If we did:   "parties": [0, [1, 2]],
As currently defined in the I-D, this would indicate that we have a two channel recording.  The first channel for party 0 and the second channel for parties 1 and 2.  This would be incorrect for a single channel recording.

Option 1:
Do we create an "other_parties" (name up for suggestions) field to list those not recorded.
{
  "type": "recording,
   "parties": [0],   "other_parties": [1, 2],   "body": single channel audio file...}
Option 2:We label all of the dialogs as being part of the same call (e.g. "call_uuid" see example below) and make the consumer of the data hunt through all of the dialogs, find which ones are all the same call and collect the parties from those dialogs? We may need this concept of call labeling to solve other problems (see issue 3D), the collecting the parties from all of the dialogs for the same call seems inconvenient.
"dialog": [  {
    "type": "recording,
     "parties": [0],
     "call_uuid": "12345",     "body": single channel audio file  ...  },
  {    "type": "recording,
     "parties": [1],     "call_uuid": "12345",  ...  },
  {    "type": "recording,
     "parties": [2],     "call_uuid": "12345",  ...  }]

Option 3:   Do both.  Set other_parties and call_uuid.
Other options?

Cheers,Dan