Re: [rtcweb] STUN for keep-alive

Can we assume that all PeerConnections will include an audio/video stream-
some may have only a 'data' connection between the
browsers- can't rely on RTCP can we (assuming we don't use RTCP for
generic data)?

Göran

On 2011-09-14 19:13, "Eric Rescorla" <ekr@rtfm.com> wrote:

>One new concern in this context is maintaining the consent freshness.
>The browser
>needs to be sure that the recipient of traffic is stil responding in a
>way that can't be
>forged. It's likely RTCP provides this (though we'd need to analyze to
>be sure) but
>perhaps better would be to mandate STUN checks at enough frequency that
>you get some sort of level of freshness.... maybe every 2 minutes or
>something.
>
>-Ekr
>
>On Wed, Sep 14, 2011 at 9:14 AM, Harald Alvestrand <harald@alvestrand.no>
>wrote:
>> On 09/14/11 15:07, Christer Holmberg wrote:
>>>
>>> Hi,
>>>
>>>>> |Sure, but there is still a max time between the keep-alives.
>>>>
>>>> You are free to set it to a very long duration that disables
>>>> keepalives for all practical purposes (assuming such duration
>>>> is represented by a 32-bit unsigned integer you can set it to
>>>> ~136 years).
>>>
>>> Yes, but at the end of the day something has to be sent in order to
>>>keep
>>> the NAT binding open.
>>>
>>>>> |Using e.g. RTP, the media handler would not have to be prepared to
>>>>> |receive the STUN keep-alives in the first place, it could
>>>>> |simply just
>>>>> |relay whatever comes on the media plane.
>>>>
>>>> If the media handles can handle STUN binding requests
>>>> efficiently I don't see why they can't handle STUN binding
>>>> indications (keepalives) in a similar manner.
>>>
>>> I believe it knows when to expect those. But, in any case, the main
>>>reason
>>> behind the proposal is to decrease the number of STUN requests.
>>
>> I think it's a more urgent desire that we should minimize the number of
>> variants of protocols in use.
>> Defining a variant of ICE that modifies the keepalive mechanism seems
>>to me
>> like a Bad Idea.
>>
>>                     Harald
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>_______________________________________________
>rtcweb mailing list
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb