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

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 <ben@nostrum.com> wrote:

> +1.
>
> Mirja: does Roman’s proposed text (below) work for you?
>
> Thanks!
>
> Ben.
>
> > On May 31, 2018, at 2:37 PM, Adam Roach <adam@nostrum.com> 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 <thomass.stach@gmail.com>
> 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 <
> thomass.stach@gmail.com> 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
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
>
>