[AVTCORE] zrtp: draft-ietf-mmusic-sdp-mux-attributes vs draft-ietf-avtcore-rfc5764-mux-fixes

"Ben Campbell" <ben@nostrum.com> Tue, 24 May 2016 23:21 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0EBA112D16C; Tue, 24 May 2016 16:21:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id lAgXYzBzGAig; Tue, 24 May 2016 16:21:16 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F80312D167; Tue, 24 May 2016 16:21:13 -0700 (PDT)
Received: from [] (cpe-66-25-7-22.tx.res.rr.com []) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4ONLC4V069839 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 24 May 2016 18:21:12 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [] claimed to be []
From: "Ben Campbell" <ben@nostrum.com>
To: "mmusic WG" <mmusic@ietf.org>, "avt@ietf.org WG" <avt@ietf.org>
Date: Tue, 24 May 2016 18:21:10 -0500
Message-ID: <CD90C355-FAFD-44F9-8CB0-E40045E31046@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/xoftG9Al2f7Nix95Gww7X69-oko>
Cc: draft-ietf-avtcore-rfc5764-mux-fixes.all@ietf.org, draft-ietf-mmusic-sdp-mux-attributes.all@ietf.org
Subject: [AVTCORE] zrtp: draft-ietf-mmusic-sdp-mux-attributes vs draft-ietf-avtcore-rfc5764-mux-fixes
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2016 23:21:18 -0000


There appears to be a discrepancy between 
draft-ietf-mmusic-sdp-mux-attributes and 
draft-ietf-avtcore-rfc5764-mux-fixes concerning whether zrtp can be used 
with bundle.

mux-attributes puts the zrtp-hash attribute [RFC6189] in the "transport" 
category, meaning, among other things, that it can be used in a bundle 
group. However, as the demux rules are currently defined 5764-mux-fixes, 
zrtp messages cannot actually be demuxed. (If I read things correctly, 
the first byte of a zrtp message will be 16, which is not in any of the 
"known ranges" described in 5765 or 5764-mux-fixes, and therefore the 
message MUST be dropped.

That seems to leave the choice of adding zrtp messages to the demux 
rules in 5764-mux-fixes, or removing the implication that zrtp can be 
bundled from mux-attributes.

Adding rules for demuxing zrtp to 5765-mux-fixes would probably not be 
hard, but would be non-trivial. RFC 6189 calls for using the magic 
cookie to distinguish zrtp messages from stun messages.

Do people have opinions how to move forward with this? Am I interpreting 
the conflict correctly?Keep in mind that ZRTP is not a standards-track 
spec. But at the same time, I'm not sure we want to exclude it from the 
bundle mechanism.