Re: [bfcpbis] BFCPbis: UDP- and TCP candidates and proto value

[Alan Ford <[e-mail]>]

Hi Christer, all,

> On 14 Oct 2016, at 09:48, Christer Holmberg <[e-mail]> wrote:
> 
> >While the text is fine and probably closest to current behaviour, it means we can’t get the benefits from ICE if one end supported only one of UDP or TCP.
> >
> >Today if you offer only TCP or UDP as the proto value on the m-line, and the far end doesn’t, then the far end will zero-port the m-line and you’ll either re-INVITE if you support the other, or just run without BFCP. That same behaviour would continue with the proposed text.
> >
> >However, the real benefit of ICE in this circumstance would allow the offerer to offer TCP and UDP candidates under a TCP m-line, but the answerer, if they supported only UDP, could then only offer back only UDP
> >candidates (whilst matching the offerer’s proto). But given the text requires a default candidate to be present matching the proto on the m-line, then if the answerer did not support TCP, they would have to zero-port the line.
> >
> >However, I would assume that breaking the semantics of the offered proto field is probably not a good thing, and defining a transport-agnostic proto isn’t practical, so borrowing the proposed text (with the photo -> proto typo fixed) is probably sufficient at this stage. Unless anyone can think of a neater way of solving this?
> 
> I guess one solution would be to allow the answerer to use a m- line proto value that does NOT match the default candidate (or, doesn’t match ANY candidate).

That would certainly work in this scenario - different from the SCTP text, but would permit this behaviour, whilst still providing clear guidance.

However, I fear that would go against the ICE spec; specifically, 5245 says:

   The transport addresses that will be the default destination for
   media when communicating with non-ICE peers MUST also be present as
   candidates in one or more a=candidate lines.

So we’d no longer be adhering to that in the answer.

Regards,
Alan