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

[Alan Ford <[e-mail]>]

> On 19 Oct 2016, at 13:08, Christer Holmberg <[e-mail]> wrote:
> 
> Hi,
> 
>>>> 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.
>> 
>> We would update the SCTP text too.
>> 
>>> 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.
>> 
>> The text is certainly valid for the offer, but when the answer is sent it
>> is known whether the peers support ICE or not.
>> 
>> In any case, I don¹t think there should be different rules for BFCF, SCTP
>> etc. This should be defined in draft-ietf-mmusic-ice-sip-sdp as a generic
>> rule.
> 
> 
> I was thinking a little more about this: maybe indicating a transport in
> the m- line that you don’t support isn’t a very good idea - even if it
> won’t be used with ICE.
> 
> Maybe it would be better to say that the m- line shall contain a transport
> that the peer is “most likely” to support. In case of BFCP, I guess
> neither TCP or UDP is mandatory to support, but in other cases there is
> often a mandatory transport.

That still implies they need to support the transport in question, so it’s not dissimilar to the SCTP text about default candidate.

Question really is - and this is probably something more for icebis than here - would it be legitimate to relax that requirement in the text I quoted earlier for the answerer? (The way it is written in 5245 suggests it applies to both offerer and answerer). I don’t see it being a problem for endpoints, but I’d be worried some proxies may expect behaviour here which isn’t true.

Regards,
Alan