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

[Adam Roach <[e-mail]>]

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