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

[Roman Shpount <[e-mail]>]

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]>
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]>
> 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
>
>
>
>
>
>