Re: [rtcweb] STUN for keep-alive

> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On
> Behalf Of Muthu Arul Mozhi Perumal (mperumal)
> Sent: Wednesday, September 14, 2011 4:24 AM
> To: Christer Holmberg; rtcweb@ietf.org
> Subject: Re: [rtcweb] STUN for keep-alive
> 
> |Well, it depends on the amount of outgoing media traffic,
> |but in cases where you only receive media you would still
> |need to send keep-alives.
> 
> If you are not sending anything the NAT binding in that direction will
> likely timeout. On the other hand, if you are operating in a controlled
> environment ICE already allows you to set the STUN keepalive duration
> to
> the longest duration possible in your environment, so it is already
> flexible.

PCP can allow the client to know and control the NAT's UDP timeout,
http://tools.ietf.org/html/draft-ietf-pcp-base-13#section-7.3.

-d

> However, it mandates STUN keepalives to be used when an agent is a full
> ICE implementation and is communicating with a peer that supports ICE
> (lite/full). Are you saying it should allow a different UDP keepalive
> method because it can possible have a lesser performance impact?
> 
> Muthu
> 
> |-----Original Message-----
> |From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> |Sent: Wednesday, September 14, 2011 3:59 PM
> |To: Muthu Arul Mozhi Perumal (mperumal); rtcweb@ietf.org
> |Subject: RE: [rtcweb] STUN for keep-alive
> |
> |
> |Hi,
> |
> |>|Because, eventhough the keep-alives messages aren't authenticated,
> and
> |>|do not trigger responses, a gateway would still have to
> |>|process them, and since a gateway typically would serve a large
> number of browser
> |>|clients, that could have quite big performance impact (the number of
> |>|STUN keep-alives sent per session of course depend on how much other
> |>|media traffic there is, but still).
> |>
> |>STUN keepalives are required by ICE only in the absence of
> |>media traffic.
> |
> |Yes. That's what I meant with the:
> |
> |	"(the number of STUN keep-alives sent per session of course
> depend on how much other media
> |traffic there is, but still)"
> |
> |...statement :)
> |
> |>Here are the snip from RFC 5245:
> |>
> |><snip>
> |>10.  Keepalives
> |>
> |>If there has been no packet sent on the candidate pair ICE is
> |>using for a media component for Tr seconds (where packets
> |>include those defined for the component (RTP or RTCP) and
> |>previous keepalives), an agent MUST generate a keepalive on
> |>that pair.  Tr SHOULD be configurable and SHOULD have a
> |>default of 15 seconds.  Tr MUST NOT be configured to less
> |>than 15 seconds.
> |></snip>
> |>
> |><snip>
> |>20.2.3.  Keepalives
> |>
> |>STUN keepalives (in the form of STUN Binding Indications) are
> |>sent in the middle of a media session.  However, they are
> |>sent only in the absence of actual media traffic. In
> |>deployments that are not utilizing Voice Activity Detection
> |>(VAD), the keepalives are never used and there is no increase
> |>in bandwidth usage.  When VAD is being used, keepalives will
> |>be sent during silence periods.  This involves a single
> |>packet every 15-20 seconds, far less than the packet every
> |>20-30 ms that is sent when there is voice.  Therefore,
> |>keepalives don't have any real impact on capacity planning.
> |></snip>
> |>
> |>Do you think there is still a problem?
> |
> |Well, it depends on the amount of outgoing media traffic, but in cases
> where you only receive media
> |you would still need to send keep-alives.
> |
> |Regards,
> |
> |Christer
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb