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

[Harald Alvestrand <[e-mail]>]

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