Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE for RTC calls)

[Roman Shpount <[e-mail]>]

Let's see:

4.1.4. Choosing Default Candidates

A candidate is said to be default if it would be the target of media
from a non-ICE peer; that target is called the DEFAULT DESTINATION.
If the default candidates are not selected by the ICE algorithm when
communicating with an ICE-aware peer, an updated offer/answer will be
required after ICE processing completes in order to "fix up" the SDP
so that the default destination for media matches the candidates
selected by ICE. If ICE happens to select the default candidates, no
updated offer/answer is required.

An agent MUST choose a set of candidates, one for each component of
each in-use media stream, to be default.

5.1. Verifying ICE Support

If this condition is not met, the agent MUST process the SDP based on
normal RFC 3264 procedures, without using any of the ICE mechanisms
described in the remainder of this specification...

6.1. Verifying ICE Support

The logic at the offerer is identical to that of the answerer as described
in Section 5.1, with the exception that an offerer would not ever generate
a=ice-mismatch attributes in an SDP.

My interpretation of this always was that ICE enabled end point MUST
generate an offer that will be understood by a non-ICE end point, properly
process on offer from a non-ICE enabled end point, and properly process an
answer from a non-ICE end point. So if we want RTC to be ICE complaint we
should be able to communicate with non-ICE end points, or define a new
specification.
_____________
Roman Shpount


On Tue, Sep 27, 2011 at 4:14 AM, Harald Alvestrand <[e-mail]>wrote:

> On 09/26/11 20:48, Roman Shpount wrote:
>
>> You can determine that end point is not behind symmetric NAT using older
>> STUN specification and list discovered IP as a default contact address in
>> SDP, if you are not behind NAT, you can list the relayed address of the TURN
>> server as the default address. If you do this, together with the offer that
>> lists ICE candidates, you would be able to traverse NAT and communicate with
>> non-ICE end points.
>>
>> I think discussion in this thread is not whether ICE needs to be supported
>> or implemented. I would say that ICE without a doubt should be supported. It
>> is about changing ICE specification as it stands right now, and force the
>> RTC end point only to communicate with end points that respond with ICE
>> compliant answer and complete ICE hand shake. This is actually against the
>> ICE specification as it is defined in RFC 5245, where answerer actually can
>> refuse to support ICE but still establish a call.
>>
> Roman,
>
> Which part of RFC 5245 are you referring to with this statement?
>
> Please describe the sections you think will be invoked when an SDP OFFER
> contains ICE candidates, the answerer does not want to use ICE, what the
> OFFER and ANSWER would look like, and which section of RFC 5245 is invoked
> when processing the ANSWER.
>
> Details are good.
>
>                Harald
>
> ______________________________**_________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>