Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

[Roman Shpount <[e-mail]>]

On Thu, May 10, 2012 at 10:13 AM, Cullen Jennings <[e-mail]> wrote:

>
> On May 3, 2012, at 2:34 PM, Roman Shpount wrote:
>
> > On Thu, May 3, 2012 at 4:29 PM, Christer Holmberg <
> [e-mail]> wrote:
> > You could also choose not to alert the remote user until the ICE
> procedures have finished - more or less using ICE with preconditions.
> >
> > Of course, that is going to trigger actions in STUN/TURN servers, even
> if the called party won't accept the call, but at least from a user
> experience perspective that is still better than lifting the hook, and
> having to wait for whatever-time-it-takes-for-ICE-to-finish seconds before
> one can start to talk.
> >
> >
> > This also has a downside of disclosing user's IP to the caller without
> the user confirmation. For a lot of applications this can be serious
> security flaw.
> > _____________
>
> The initial media flow could be forced to provide only relay ICE
> candidates to help mitigate this. (I think we decided awhile back that was
> one of the things we would provide support for in the API). Later with the
> user answers or consents in same way, the ICE can move the media to a non
> relay flow.
>
> Just to make this clear, in this scenario, once application receives the
offer, it will generate a provisional answer with only relay candidates,
send this answer to the calling party, completes the ICE process on the
called party side, and then alert the called party. Once called user
accepts the call, application will send the final answer with relay,
reflexive and local candidates. This can also be implemented with final
answer with only relay candidates by the called party before user accepts
the the call, and O/A in the opposite direction once the call is accepted.
There is still a slight chance of clipping the media from the calling party
towards the called party since the answer might not arrive to the calling
party or ICE process from the calling party to the called party might not
complete before the called party answers. To avoid this, application will
need to send a separate message via signaling or data channel once the ICE
process on the calling side completes and only alert the called party once
this signaling message is received. What it boils down to is that
application should setup the media channel (provide relay candidates only
from the called side, if IP privacy is a concern), send a separate
signaling message when it is done, and then alert the user. This will
significantly slow down the actual call setup and will use a bunch of extra
resources, but will solve the clipping problem.
_____________
Roman Shpount