Re: [MMUSIC] Partial Offer/Partial Answer draft - MIME type value

[Emil Ivov <[e-mail]>]

Christer, "I tried to explain" to you that what you are saying has been
addressed and cannot happen. If you believe that there is a specific
situation that is still possible and is a problem, then please describe
that rather than continuing to suggest that things don't work without any
valid arguments whatsoever.

--sent from my mobile
On 20 Oct 2013 21:50, "Christer Holmberg" <[e-mail]>
wrote:

>
> Hi,
>
> >> Example:
> >>
> >> 1. Alice sends an SDP Offer to Bob.
> >>
> >> 2. Bob sends the SDP Answer to Alice, with candidates A, B and C.
> >>
> >> 3. After that, Bob sends, using trickle ICE, candidates D and E to
> Alice.
> >>
> >> If Alice receives the SDP Answer first, and then the trickle ICE
> request, she will assume that Bob first provided candidates A, B and C (in
> the SDP Answer), and then added D and E (in the trickle ICE request).
> >>
> >> If Alice receives the trickle ICE request first, and then the SDP Answer
> >
> > Don't do that then.
> >
> > It's been pretty clear from the start that any session *modification*
> mechanism that does not also contain the full session state completely
> falls apart in the face of unordered delivery. This is a fundamental
> information problem, and you aren't going to write rules that somehow cause
> it not to be true.
> >
> > We haven't yet tackled how to send trickle ICE in SIP, much less partial
> offers and partial answers. When we do, the only way it's going to have any
> chance of working at all is by requiring ordered delivery.
>
> I totally agree, and my opinion (which I tried to explain to Emil) is that
> it applies also to candidates.
>
> Regards,
>
> Christer
>