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

[Thomas Stach <[e-mail]>]

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).
>>
>> 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
>>
>