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

[Christer Holmberg <[e-mail]>]

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.

The idea was that, if the answerer doesn’t support the transport in the m-
line of the offer, it would have to reject the m- line (as you pointed out
earlier).

>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.

I DID send an e-mail to the MMUSIC list (I think it is more related to
SIP/SDP-usage of ICE than ICE in general) about this a few days ago, but
nobody has replied. Feel free to jump on the discussion :)

Obviously, if you e.g., include TCP in the m- line of the answer (because
the offer contained TCP), but you don’t actually support TCP, the m- line
port value would only be a “dummy value”.

Regards,

Christer