Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT)

[Ben Campbell <[e-mail]>]

Understood, and I think I knew that. I called out her name in hopes she notices it when digging out from under the pile of mail that will certainly await her when she returns. :-)

Ben.

> On Jun 1, 2018, at 6:45 PM, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> My co-AD is off the net this week - she is back on next week, I believe.
> 
> Silence is not a reflection of AD response to the proposed text.
> 
> Spencer
> 
> On Fri, Jun 1, 2018, 16:29 Ben Campbell <[e-mail]> wrote:
> +1.
> 
> Mirja: does Roman’s proposed text (below) work for you?
> 
> Thanks!
> 
> Ben.
> 
> > On May 31, 2018, at 2:37 PM, Adam Roach <[e-mail]> wrote:
> >
> > Of the solutions proposed so far, this is the one I like the most. Thanks, Roman.
> >
> > /a
> >
> > On 5/31/18 2:11 PM, Roman Shpount wrote:
> >> Thomas,
> >>
> >> One slight correction:
> >>
> >> "Implementors MUST aggregate ICE candidates in case that unreliable transport protocol such as UDP is used. A Trickle ICE agent MUST NOT have more than one INFO request pending at any one time.
> >> When INFO messages are sent over an unreliable transport, they are retransmitted according to the rules specified in  RFC3261 section 17.1.2.1."
> >>
> >> Regards,
> >>
> >> _____________
> >> Roman Shpount
> >>
> >> On Thu, May 31, 2018 at 3:06 PM, Thomas Stach <[e-mail]> wrote:
> >> Hi,
> >>
> >> I'd be also OK with Roman's Proposal and go ahead with the following text:
> >>
> >> "Implementors MUST aggregate ICE candidates in
> >> case that UDP is used as transport protocol.
> >> A Trickle ICE agent MUST NOT have
> >> more than one INFO request pending at any one time.
> >> When INFO messages are sent over an unreliable transport,
> >> they are retransmitted according to the rules specified in
> >> RFC3261 section 17.1.2.1."
> >>
> >> I hope that this text is also acceptable for the WG and  our ADs.
> >> Thanks
> >>
> >> Thomas
> >>
> >>
> >> On 2018-05-31 16:28, Flemming Andreasen wrote:
> >>> Hi
> >>>
> >>> Did we reach a conclusion on this thread ? If not, what do we need to move it forward ?
> >>>
> >>> Thanks
> >>>
> >>> -- Flemming
> >>>
> >>> On 5/22/18 5:11 PM, Roman Shpount wrote:
> >>>> On Tue, May 22, 2018 at 4:07 PM, Thomas Stach <[e-mail]> wrote:
> >>>> E.g. something like:
> >>>>
> >>>> "Implementors MUST aggregate ICE candidates in
> >>>> case that UDP is used as transport protocol.
> >>>> It is RECOMMENDED that Trickle ICE implementations
> >>>> implement a way to estimate the round-trip time (RTT)
> >>>> and send only one INFO request per estimated RTT.
> >>>> If the RTT is unknown, a Trickle ICE agent MUST NOT have
> >>>> more than one INFO request pending at any one time.
> >>>> In case of re-transmissions a Trickle-ICE agent needs to adhere to the default SIP
> >>>> retransmission schedule resulting in intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc."
> >>>>
> >>>>
> >>>> I think it should be enough to require that a Trickle ICE agent MUST NOT have more than one INFO request pending at any one time. Requiring only one request in progress will also deal with remote proxy or client overload more gracefully. RTT is likely not a right measure here since INFO message can traverse multiple proxies and RTT would need to include transport delays between the proxies as well as proxy processing delay.
> >>>>
> >>>> Also, there is no need to specify how normal SIP re-transmission works, especially as it can be interpreted that you disallow modification of SIP timer values when trickle ICE is used or modify RFC 3261 in some way. I think it would be better simply state that when INFO messages are sent over an unreliable transport, they are retransmitted according to the rules specified in rfc3261 section 17.1.2.1 (https://tools.ietf.org/html/rfc3261#section-17.1.2.1).
> >>>>
> >>>> Finally, is it allowed to cancel (stop transmitting) the current INFO request with ICE candidates and start a new INFO request with new candidate set if new candidate is discovered while INFO message is being transmitted? My assumption is that it is not allowed.
> >>>>
> >>>> Regards,
> >>>> _____________
> >>>> Roman Shpount
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
>