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

[Emil Ivov <[e-mail]>]

The new SDP O/A you mention would cause an ICE restart and that's what will
define agent state. Not previously exchange trickled candidates.

I am not sure I understand the relation to your argument though (about
trickled candidates affecting session SDP) so I might be missing your point.

Emil

--sent from my mobile
On 19 Oct 2013 17:43, "Christer Holmberg" <[e-mail]>
wrote:

>  Hi Emil,
>
> Assume you have an m- line, for which you provide candidates using trickle ICE.
>
> Then, you add the m- line to a BUNDLE group, using SDP O/A, which means it will inherit the address properties and candidates of the BUNDLE group.
>
> Are you saying that the previously provided trickle candidates are still comsidered valid, eventhough they are associated with different address properties etc?
>
> Regards,
>
> Christer
>
> Sent from my Sony Ericsson Xperia arc S
>
> Emil Ivov <[e-mail]> wrote:
>
>
>   Hey Christer,
>  On 19 Oct 2013 08:10, "Christer Holmberg" <[e-mail]>
> wrote:
>
>> Hi Emil,
>>
>> Similar to POF/PAN, the sending of candidates do affect the session SDP
>> (bacause, as you said, they are sent within SDP).
>>
>
>  I don't think this is accurate. Use of SDP for additional candidates is
> just a coincidence. It was readily available syntax for describing
> candidates and it might be convenient in some implementations (although
> this is probably of marginal value).
>
> The point is that the syntax is not due to a relationship to Offer/Answer
> and could have just as easily be based on JSON or XML or anything else.
>
>  Also, trickled candidates DO NOT update the session SDP the way a new m=
> line does. There is only a loose relation between them and subsequent O/As.
> The origin field does NOT need to be updated. New candidates in new O/As
> may appear without having been trickled and trickled candidates can just
> well be omitted in subsequent O/As. In other words, a trickled candidate
> would only affect the state of the ICE agent in exactly the same way a peer
> reflexive candidate would and it would be orthogonal to O/A, again, just as
> peer reflexive candidates are.
>
>
>> So, while we would need to think about whether using POF/PAN would make
>> sense or not, why do you think that we "can't" do it?
>>
>
>  OK, maybe "can't" is not entirely accurate here. I am sure that we
> *could* make it would with O/A if we really put our backs into it. In a
> similar way, I am sure we could also make it work by exchanging candidates
> in a shared Dropbox folder. In either case, I don't see why we would want
> to incur such a thing on our selves. I don't see any advantage to doing
> this.
>
>  On the downside, trickling candidates in Offer/Answer would imply the
> following problems:
>
>  *  Very high glare probability.
>  * Unnecessarily complex implementation (really, this would be a
> nightmare and I sincerely advise anyone supporting offer answer for trickle
> to first try and implement it).
>  * Ambiguity between ICE restarts and trickle updates.
>
>  Also, given how we have already had this discussion and converged on use
> of INFO, it is unclear to to me as to why we are revisiting this. I don't
> think anyone has reported any problems on the alternative.
>
> Cheers,
> Emil
>
>
>>
>> Regards,
>>
>> Christer
>>
>> Sent from my Sony Ericsson Xperia arc S
>>
>> Emil Ivov <[e-mail]> wrote:
>>
>>
>> On Fri, Oct 18, 2013 at 6:24 PM, Paul Kyzivat <[e-mail]>
>> wrote:
>> > On 10/18/13 6:11 PM, Emil Ivov wrote:
>> >>
>> >> I do think that a different MIME type makes more sense here for the
>> >> reasons Paul explained.
>> >
>> >
>> > In the sip world, we may *also* want a new content-disposition. Using
>> > 'session' as the content-disposition with the new content type implies
>> that
>> > the the body is just a different representation of an offer or answer.
>> (We
>> > were once considering exactly that with SDPng.)
>> >
>> > We *might* want to think of it that way, or not.
>> >
>> >
>> >> It might be worth adding that the same MIME type would be used when
>> >> sending candidate updates with Trickle ICE for SIP, which to me at
>> >> least, makes a lot of sense.
>> >
>> >
>> > I still wonder why trickle ICE needs a *different* mechanism for partial
>> > offers. Couldn't we just use this one?
>>
>> By "this one", do you mean POF/PAN or application/sdpfrag?
>>
>> We don't need anything different than application/sdpfrag.
>>
>> We can't use POF/PAN because we are not sending offers and answers. We
>> are just exchanging candidates in agent-to-agent messages. The use of
>> SDP is an unfortunate coincidence, not an indication of offers and
>> answers.
>>
>> Emil
>>
>> >
>> >         Thanks,
>> >         Paul
>> >
>> >> --sent from my mobile
>> >>
>> >> On 18 Oct 2013 16:55, "Christer Holmberg"
>> >> <[e-mail] <mailto:[e-mail]
>> >>
>> >>
>> >> wrote:
>> >>
>> >>     Hi,
>> >>
>> >>      > I think you and I are thinking of this differently.
>> >>      >
>> >>      > I'm thinking that the POFs and PANs are something new, different
>> >>     from offers and answers. They go on *between* offers and answers.
>> >>      >
>> >>      > IIUC you are thinking of POFs and PANs as extended forms of
>> >>     offers and answers.
>> >>
>> >>     It's not the way I think - I just wanted to explore how/if things
>> >>     would work IF we were thinking like that, and what the pros and
>> cons
>> >>     would be :)
>> >>
>> >>     We have to keep in mind that, no matter how we look at it, the
>> >>     Offers/Answers and POFs/PANs are tightly connected, meaning that
>> >>     they impact the same SDP state, can cause race conditions etc.
>> >>
>> >>     Regards,
>> >>
>> >>     Christer
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>     On 10/18/13 5:06 PM, Christer Holmberg wrote:
>> >>      > Hi,
>> >>      >
>> >>      >>>>> Content-Disposition does not apply to intermediaries. So, a
>> >> proxy
>> >>      >>>>> that only understands application/sdp (e.g. for gate control
>> >>      >>>>> purpose) will not even look at the C-D header field value
>> for
>> >>      >>>>> other bodies. And, unless such proxy understands POF/PAN,
>> there
>> >>      >>>>> may not be any media passing through...
>> >>      >>>>
>> >>      >>>> Right. A middlebox that doesn't understand
>> application/sdpfrag
>> >>      >>>> won't know to look at its contents and let the new streams
>> >>     through.
>> >>      >>>> And a middlebox that sees something marked as
>> >>     "application/sdp" that conveys only a tiny fraction of the session
>> >>     will probably be just as catastrophic; I would imagine everything
>> >>     but the modified streams would be shut off. There's no way to win
>> >> here.
>> >>      >>>
>> >>      >>> I think it would reject the Offer - at least that's what it
>> >>     should do according to 3264.
>> >>      >>
>> >>      >> 3264 only talks about how to process offers and answers
>> described
>> >> in
>> >>      >> SDP. It does not say how those are conveyed in sip. 3261 says
>> >>     that they are carried in body parts of content-type application/sdp
>> >>     with content-disposition of 'session'. If a body part has
>> >>     content-type application/sdp but has a disposition other than
>> >>     'session' then it isn't an offer or answer according to 3261, and
>> so
>> >>     3264 doesn't apply.
>> >>      >
>> >>      > 3264 says that all m- line must be present in an Offer - even if
>> >>     they are not modified. So, what I meant was that in case all m-
>> >>     lines are NOT present (in the case of a POF), such Offer would be
>> >>     rejected - unless the middlebox understands the POF/PAN mechanism .
>> >>      >
>> >>      >>>> At some point, we have to come to peace with the fact that
>> any
>> >>     middleboxes that aren't primarily in the business of stifling
>> >>     progress will need to keep pace with protocol extensions as they
>> get
>> >>     deployed.
>> >>      >>>
>> >>      >>> I really wish things worked that way :)
>> >>      >>
>> >>      >> So progress ends because middleboxes don't permit it?
>> >>      >>
>> >>      >> Maybe you are right. Then sip will go the way of h323 while the
>> >>     world moves on to webrtc.
>> >>      >
>> >>      > I think that getting explicit rejections, rather than having to
>> >>     try to
>> >>      > figure out where things go wrong, is good for progress :)
>> >>      >
>> >>      > Anyway, it wasn't really a suggestion - I just wanted to do some
>> >>      > brainstorming :)
>> >>      >
>> >>      > Regards,
>> >>      >
>> >>      > Christer
>> >>      >
>> >>
>> >>     _______________________________________________
>> >>     mmusic mailing list
>> >>     [e-mail] <mailto:[e-mail]>
>> >>     https://www.ietf.org/mailman/listinfo/mmusic
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> mmusic mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/mmusic
>> >>
>> >
>> > _______________________________________________
>> > mmusic mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>>
>> --
>> Emil Ivov, Ph.D.                       67000 Strasbourg,
>> Project Lead                           France
>> Jitsi
>> [e-mail]                        PHONE: [phone]
>> https://jitsi.org                       FAX:   [phone]
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>