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

From: Magnus Westerlund <[email-masked]>
Date: Tue, 10 Jan 2017 16:13:23 +0100

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.

I think simple rules based on implementation capabilities for how to set 
it are better than no rules. Especially as it would carry some 
information, not zero, which is the result of no rules.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 10 Jan 2017 17:49:06 +0000

> On Jan 10, 2017, at 10:13 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> 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.