Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-01

Hi Paul & all,

It is possible to follow RFC 6337 offer/answer guidelines in case UPDATE
method (Sec 6.4 of draft-partha-rtcweb-jsep-sip-01) is used for Trickle ICE
instead of INFO. 

The concern with Trickle ICE handling w.r.t RFC 3264 O/A is that the SDP
feature interaction like BUNDLE leads to more glare handling during every
session creation as UPDATE is exchanged in both directions. IMO, RFC 3264
O/A shall be updated to handle the media address change only SDP which
reduces the glare situation but handle the original glare situation. The SDP
"a" attribute like "media-address-change-only" or "ice-candidate-change"
shall help to achieve this functionality. The attribute will be
backward-compatible as "a" attribute will be ignored in case the other
end-point does not support. Also, the attribute shall be used within partial
offer/answer as well.

Thanks
Partha  

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: Thursday, October 24, 2013 9:38 PM
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on
> draft-ivov-mmusic-trickle-ice-sip-01
> 
> I'm far from an expert on ICE, so maybe this is covered and I just
> don't
> know it...
> 
> ISTM there is a need for some real clarity about the relationship
> between ICE state and SDP O/A state, and if/when pieces of state move
> or
> are synchronized between them. This isn't clear even for SDP O/A on its
> own, but with ICE, and now with trickle ICE, and with Partial O/A it is
> becoming even more of a problem.
> 
> RFC 6337 started to clarify SDP O/A itself, but it didn't deal with the
> sorts of issues that are coming up in this discussion.
> 
> 	Thanks,
> 	Paul
> 
> On 10/24/13 11:36 AM, Jonathan Lennox wrote:
> >
> > On Oct 24, 2013, at 10:34 AM, Christer Holmberg
> <christer.holmberg@ericsson.com>
> >   wrote:
> >
> >> Hi,
> >>
> >>>> We have to remember, though, that a trickled candidate is not a
> new
> >>>> candidate "type". The candidate types you trickle are the same
> types
> >>>> you send in Offer/Answer - tickle is simply an alternative
> candidate
> >>>> transport mechanism.
> >>>
> >>> Yes, that's right. I am not sure why you are saying it though.
> >>
> >> Because when you say:
> >>
> >> 	"we treat trickle candidates in the same way as peer-reflexive
> candidates"
> >>
> >> ...it sounds like a trickle candidate is a new type of candidate
> (similar to peer-reflexive candidate), which is not true.
> >>
> >>
> >> You should say:
> >>
> >> 	"We treat candidates that were provided using the trickle ICE
> mechanism in the same way as peer-reflexive candidates"
> >
> > There's a problem with this.
> >
> > RFC 5245 says:
> >
> >     However, the peer reflexive candidate is not paired with other
> remote
> >     candidates.  This is not necessary; a valid pair will be
> generated
> >     from it momentarily based on the procedures in Section 7.1.3.2.2.
> If
> >     an agent wishes to pair the peer reflexive candidate with other
> >     remote candidates besides the one in the valid pair that will be
> >     generated, the agent MAY generate an updated offer which includes
> the
> >     peer reflexive candidate.
> >
> > In other words, peer-reflexive candidates aren't automatically paired
> with all remote candidates; they're only paired with the remote
> candidate you were checking when you discovered them, unless you send
> them in an updated offer.
> >
> > Candidates provided over Trickle don't have a remote candidate to be
> automatically paired with, so "treating them like peer-reflexive
> candidates" doesn't make much sense.
> >
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic