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

[Flemming Andreasen <[e-mail]>]

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] 
> <mailto:[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
>