Subject: [AVT] Update of rtp-keepalive draft

From: "Xavier Marjou" <[email-masked]>
Date: Mon, 15 Jan 2007 11:02:43 +0100

To keep this topic alive, I plan to update the following individual draft:
http://tools.ietf.org/wg/behave/draft-marjou-behave-app-rtp-keepalive-00.txt

I am therefore interested of any feedback, especially on which
mechanism(s) is best.

Xavier

> On 12/3/06, Dan Wing <[email-masked]> wrote:
> Minutes of the last BEHAVE meeting have been posted to:
> http://www3.ietf.org/proceedings/06nov/minutes/behave.html
>
> Application Keepalive for NATs, Xavier Marjou -
> draft-marjou-behave-app-rtp-keepalive-00
> status:  separate from ICE, or integrate into Application milestone document?
>
> JR – this is app design guidelines. How about if we charter to create
> that document and put this text, along with other text around it in
> STUN all in one document?
> Xavier Marjou (speaker, XM) – take to list.
> Chair – question of which mechanisms might be best asked in AVT FA –
> good to ask AVT for sure. But we should discuss here Magnus – both
> groups working on it Chair – consensus to fold this into application
> document, per JR's proposal.
> Will figure out what to do on list.
> FA – support. Think it's a good idea. But do we have an editor for
> that, will it get done? I don't want to send this to dev/null.
> PM – in our BEHAVE app document are we the best place to have that
> discussion?
> chair - don't have a clear decision on what to do, will work to figure
> out where this goes.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Lee Dilkie <[email-masked]>
Date: Mon, 15 Jan 2007 14:04:08 -0500

I'd vote for 4.1 first, followed by 4.5 (which sounds a lot like 4.7 to
me only it's defined).

reasons:

sending a 0-byte udp packet is solving a network issue, not an RTP issue
and shouldn't pretend to be RTP.

the cons specified:
 - udp specific, well yes but this isn't an issue with tcp anyway.
 - rx-ing party might not handle this. Perhaps, but since these are
intended to be used for NAT traversal I would assume the rx-ing party
would be most probably aware since the address:port of the received udp
needs to be communicated to the tx-ing party anyway, and they generally
need to share the same socket(or at least appear to).

Otherwise I'd pick an unused RTP payload type value and define it as
reserved for NAT keepalive usage. I guess this most closely maps to 4.5.

Regards,

Lee Dilkie

(we implemented the 0-byte udp in our solution, FWIW, although we choose
30 second intervals).

---

From: Colin Perkins <[email-masked]>
Date: Tue, 16 Jan 2007 16:58:55 +0000

Do we need to mandate an alternative? All of the alternatives  
specified will work, and RTP implementations have to be robust to  
receiving all seven types of packet anyway (otherwise, there is a  
trivial denial-of-service attack on the application). As long as  
something is sent at an appropriate interval, the NAT will be happy,  
and the application can use whatever mechanism is appropriate for it.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: "Yuval Nissan" <[email-masked]>
Date: Tue, 16 Jan 2007 22:25:22 +0200

The issue of keepalive is also related to the RTP endpoint - If the remote side stops the voice connection because of some problem during silence, there is no certain way to discover it.
 
So I think the recommended alternative should solve both issues (4.5 does the job)
 
Regards,
Yuval

________________________________

מאת: Colin Perkins [mailto:[email-masked]]
נשלח: ג 16/01/2007 18:58
אל: Lee Dilkie
עותק לידיעה: [email-masked]; Xavier Marjou; [email-masked]
נושא: Re: [AVT] Update of rtp-keepalive draft

Colin

--
Colin Perkins
http://csperkins.org/

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Jan 2007 09:10:24 +0100

> The issue of keepalive is also related to the RTP endpoint - If the remote side stops the voice connection because of some problem during silence, there is no certain way to discover it.

The solution to that is called RTCP. It is there, it also provides other 
features. Use it instead of inventing new mechanisms.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Xavier Marjou" <[email-masked]>
Date: Thu, 18 Jan 2007 17:10:21 +0100

> Do we need to mandate an alternative?
Personally, I would really prefer to only have one alternative
recommended when STUN is not yet available.

When too many alternatives exist for one same thing, this results in
additional complexity in interoperability and also in future
specifications that would rely on that thing.

Xavier