Hi Peter,

I hope I’m answering the right question:

I think something like the STUN connectivity check or authorization is required to be implemented in the browser to prevent the Javascript application from sending RTP or some other UDP data to any arbitrary IP addresses and port. If the browser only allows the sending after a successful connectivity check it can ensure (to some extent) that the other peer also actually wants to receive this traffic. That code needs to reside in the browser so that the browser can act as the gatekeeper.

Markus

From: ext Peter Musgrave [mailto:peter.musgrave@magorcorp.com]
Sent: 09 February, 2011 22:16
To: Adam Roach
Cc: Isomaki Markus (Nokia-CIC/Espoo); rtc-web@alvestrand.no; dispatch@ietf.org; xavier.marjou@orange-ftgroup.com
Subject: Re: [dispatch] [RTW] RTC-Web I-D about interworking between RTC-Web and SIP-RTP

I also agree with the "make RTP just work" - signal where and how you want.. 

Sorry if I am being dense here - do we not need ICE connectivity checks to finish before RTP can be sent? Or is the point that this will take too long to get into browser code and that ICE in Javascript with STUN in the browser gets rolled out faster?

Peter Musgrave

On 2011-02-09, at 3:07 PM, Adam Roach wrote:

The critical thing seems to be the STUN connectivity check or media authorization part. If we mandate browsers to get that exchange done before they are allowed to generate any RTP packets on behalf of the application, this will ruin the possibility of interop with 99% of existing SIP clients (without some kind of an SBC)