Re: [MMUSIC] [rtcweb] JSEP Issue #394: What appears in m= lines.

Jonathan Lennox <jonathan@vidyo.com> Tue, 10 January 2017 17:49 UTC

Return-Path: <prvs=7183fb35b7=jonathan@vidyo.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A15E129D5B; Tue, 10 Jan 2017 09:49:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.998
X-Spam-Level:
X-Spam-Status: No, score=0.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=3.599, SPF_PASS=-0.001] autolearn=no autolearn_force=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 KVpCm8pIkZAN; Tue, 10 Jan 2017 09:49:21 -0800 (PST)
Received: from mx0b-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) (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 661B9129D5D; Tue, 10 Jan 2017 09:49:11 -0800 (PST)
Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v0AHibJg011298; Tue, 10 Jan 2017 12:49:08 -0500
Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 27ttaqhsnr-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 10 Jan 2017 12:49:08 -0500
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Tue, 10 Jan 2017 11:49:07 -0600
From: Jonathan Lennox <jonathan@vidyo.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Thread-Topic: [rtcweb] [MMUSIC] JSEP Issue #394: What appears in m= lines.
Thread-Index: AQHSa2LFsapXFV8lFEKmmkXm5smJ5qEyYYCA
Date: Tue, 10 Jan 2017 17:49:06 +0000
Message-ID: <EF4B1EF8-B1D6-46B3-B67E-33361A02385F@vidyo.com>
References: <52E4A8FC978E0241AE652516E24CAF001E483F95@ESESSMB309.ericsson.se> <CABcZeBPznLKNHek-SGE5Ly6QTOBL-j65sZBb5MbwQVkmBkpyFw@mail.gmail.com> <9717b211-9dbc-8d50-dece-6dc17e921711@ericsson.com>
In-Reply-To: <9717b211-9dbc-8d50-dece-6dc17e921711@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [160.79.219.114]
Content-Type: text/plain; charset="utf-8"
Content-ID: <3C24D80C3F29D841961DF47FF611A815@vidyo.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-10_15:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701100245
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/0Wjx0XXAt2urO_qj5I-Rldj-wS0>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] JSEP Issue #394: What appears in m= lines.
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 10 Jan 2017 17:49:22 -0000

> On Jan 10, 2017, at 10:13 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
> 
> Den 2016-12-22 kl. 18:30, skrev Eric Rescorla:
>> 
>> 
>> On Thu, Dec 22, 2016 at 7:15 AM, Magnus Westerlund
>> 
>>    Okay, I agree that having any rules for what you should offer here
>>    based on what the actual outcome is not the best idea here. I think
>>    the rules should be based on capability and intent. So if you only
>>    are going offer TCP candidates, then you clearly should use TCP/…,
>> 
>> 
>> I'm going to push on this. If we've already agreed that mismatches are
>> normal, why should we do that? Wouldn't it be better to just effectively
>> deprecate this field?
>> 
> 
> So, my main argument for including any rules for how to set it, would be that the this part of the PROTO field still has meaning outside of WebRTC context. There one may actually have it to match what is goind to be used. Thus, it can provide some guidance to gateways on what to expect. It might be that we should actually set it to UDP for those not supporting ICE/TCP, and to TCP for the ones that supports both UDP and TCP. That would still provide information to the gateway.

If you’re using ICE, as far as I can tell there are only two cases where the transport parts of the PROTO field (and the m/c transport values) are still relevant:

1. If you’re talking to an endpoint that doesn’t do ICE, it tells the peer what the fallback protocol should be.  This isn’t relevant for WebRTC, but still is for general MMUSIC cases.

2. If you have an SDP-inspecting middlebox, it tells it what media protocol to look for (for latching and the like).  This mostly isn’t meaningful before ICE has concluded, but it is afterward.

My suggestion would be that the PROTO MUST match the active candidate, if you have one; otherwise, it MUST match the (for WebRTC, generally arbitrarily-chosen) default candidate, if you have one; otherwise (the initial state of trickle) it MUST match one of the protocols of the candidates you’re expecting to gather (ideally, the one that you’ll choose as the default).

This basically matches the rules for m/c transport values already in JSEP, I believe.

Now, the tricky thing is of course whether this works for answers — whether the PROTO for the answer has to match the offer.  A problem occurs when the answerer isn’t expecting to gather any candidates that use the protocol used by the offerer’s default candidate.

My suggestion would be that the rules I’ve specified apply anyway, and that the answer PROTO doesn’t have to match the offer PROTO.  This will only confuse any inspecting middleboxes until the next offer/answer exchange occurs.