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

[Paul Kyzivat <[e-mail]>]

On 1/10/17 3:35 PM, Roman Shpount wrote:
> On Tue, Jan 10, 2017 at 2:27 PM, Paul Kyzivat <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On 1/10/17 1:08 PM, Roman Shpount wrote:
>
>         1. When c= line is set to "IN IP4 0.0.0.0" and m= line is set to
>         port 9,
>         so that these lines carry no valid address information as it is
>         specified in JSEP, protocol should be UDP/DTLS/SAVPF for RTP
>         or UDP/DTLS/SCTP for data
>
>
>     To do this cleanly, IMO there should be no singling out of IP4. The
>     fact is that in this case the c= line is not needed. (And this isn't
>     the only case where it isn't. It also isn't needed for MSRP and for
>     websockets - things that use URLs in attributes instead of c=.) So
>     perhaps we should revise 4566bis to make c= optional for m= lines
>     where it isn't needed. Or define a new addrtype for use in c= (e.g.
>     simply "IP" or "IP4/6") and define a placeholder address value for
>     this case. For example:
>
>       c=IN IP -
>
>
> It is cleaner, but this needs to be defined somewhere. Current JSEP uses
> "IN IP4 0.0.0.0" and port 9.

4566bis is still in progress, so it could be done there.

>         2. When c= line and m= line carry valid address information,
>         protocol
>         should match the candidate specified in c= and m= lines.
>
>         3. In cases when c= line and m= line carry valid address
>         information, when initial offer and answer are generated, they must
>         include UDP candidates and UDP candidates must be used as
>         defaults. Once
>         ICE nomination process is complete, only the active candidate
>         pair MUST
>         be included in SDP, and the transport for the active pair must
>         be used.
>
>
>     I think this could be handled by having different <proto> values:
>
>     ICE/DTLS      DTLS over either UDP or TCP
>     ICE/UDP/DTLS  DTLS over only UDP
>     ICE/TCP/DTLS  DTLS over only TCP
>
>     ICE/DTLS/RTP/SAVPF      Like above, but for RTP/SAVPF
>     ICE/UDP/DTLS/RTP/SAVPF  "
>     ICE/TCP/DTLS/RTP/SAVPF  "
>
>     So this allows restricting the type of candidates that are allowed,
>     or not. And it avoids "lying" about the type that is to be used.
>
>
> We can define it this way, but I am not sure defining anything beyond
> ICE/DTLS/RTP/SAVPF and ICE/DTLS/SCTP is actually needed. Once we specify
> that ICE is used, actual candidates can be examined to see which
> candidate types are supported.

Perhaps choice of UDP/TCP/both can be left to the candidates. I guess if 
one side wants to restrict to one or the other it can offer only 
candidates of the type it wants.

	Thanks.
	Paul