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

[Roman Shpount <[e-mail]>]

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