[MMUSIC] Is simulcast going to enable asymmetric codec negotiation?
Martin Thomson <martin.thomson@gmail.com> Wed, 21 October 2015 20:08 UTC
Return-Path: <martin.thomson@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56E571AD368 for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 13:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_18=0.6, J_CHICKENPOX_19=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ujCA3Qj8NaV for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 13:08:50 -0700 (PDT)
Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (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 6DFDB1AD35C for <mmusic@ietf.org>; Wed, 21 Oct 2015 13:08:50 -0700 (PDT)
Received: by yknn9 with SMTP id n9so61350008ykn.0 for <mmusic@ietf.org>; Wed, 21 Oct 2015 13:08:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=oc58akHr3hkAuhcrNiS/Rc3EyX6bweKY4gshM/1B61o=; b=qA9h/nNfgYs3CuUNUXUkW9tlPYNZYF+nYN9K5VEAq9ILH08dL3fJJRAyjVgOXm8I/x LU3c0A9sgvbqCid2866SzMxRjOBzl28ExpNfRSsGGxZpOloSw8lXKQxq7bu52tYimzRa OgMCHOOg8MDAn8ztGowgFbbwA+/3hhRDFwT9JyNH5F1Om01BcW85UL+crcNBkzSX0rLM fQd8YqctUyQ0tMgtdgJCyKvA4fYxDEXrsiwEkrpjYUmDXIfD7NZ1wECJfXKzYSovAVYX otsXWLng8Q7hSe+y1ciVC8zH4JpVyizuxGe6KdfnAcpI6RABXzxVPNtpdL/FctY9q0Yo k0Tg==
MIME-Version: 1.0
X-Received: by 10.13.255.194 with SMTP id p185mr9018203ywf.207.1445458129765; Wed, 21 Oct 2015 13:08:49 -0700 (PDT)
Received: by 10.129.132.145 with HTTP; Wed, 21 Oct 2015 13:08:49 -0700 (PDT)
Date: Wed, 21 Oct 2015 13:08:49 -0700
Message-ID: <CABkgnnWe_qMLOc8Us4EbNawWkAz-mdydS5SpDzK7bFPSbJ3c_A@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/7Hl2IXhB2CINXNP6w4qg3dgk9TI>
Subject: [MMUSIC] Is simulcast going to enable asymmetric codec negotiation?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2015 20:08:51 -0000
In WebRTC we have the ability to express asymmetric capabilities, but no way to ensure that they are used. If you have an endpoint that only has support for a given codec in one direction (send or receive but not both), then you are basically forced to give up on that codec, even if it is otherwise awesome. m=audio 9 UDP/TLS/RTP/SAVPF 109 0 c=IN IP4 0.0.0.0 a=sendrecv a=rtpmap:109 opus/48000/2 a=rtpmap:0 PCMU/8000 a=simulcast: send pt=0 recv pt=109 Here, we have the ability to send mu-Law PCM and receive opus. Of course, if the other side doesn't understand a=simulcast this will degrade in the usual fashion, probably ending with an explosion of some sort, but if you have any cause to think that they support simulcast, this could be a way to get what you want.
- [MMUSIC] Is simulcast going to enable asymmetric … Martin Thomson