[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] RE: [BEHAVE] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT
- To: "'Lars Eggert'" <lars.eggert at nokia.com>
- Subject: [AVT] RE: [BEHAVE] RE: Moving draft-marjou-behave-app-rtp-keepalive to AVT
- From: "Dan Wing" <dwing at cisco.com>
- Date: Mon, 4 Jun 2007 13:54:29 -0700
- Authentication-results: sj-dkim-7; header.From=dwing@cisco.com; dkim=pass (s ig from cisco.com/sjdkim7002 verified; );
- Cc: 'Godred Fairhurst' <gorry at erg.abdn.ac.uk>, draft-ford-behave-app at tools.ietf.org, 'Behave WG' <behave at ietf.org>, 'mmusic' <mmusic at ietf.org>, 'Xavier Marjou' <xavier.marjou at orange-ft.com>, 'Tom Taylor' <tom.taylor at rogers.com>, 'Joerg Ott' <jo at acm.org>, 'IETF AVT WG' <avt at ietf.org>, 'Jean-Francois Mule' <jf.mule at cablelabs.com>, 'Colin Perkins' <csp at csperkins.org>, 'tsvwg chair' <tsvwg-chairs at tools.ietf.org>
- Dkim-signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1085; t=1180990473; x=1181854473; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20<dwing@cisco.com> |Subject:=20RE=3A=20[BEHAVE]=20RE=3A=20Moving=20draft-marjou-behave-app-r tp-keepalive=20to=20AVT |Sender:=20; bh=v4oCKRhZr00gXsdQY/MtUNXXVDumdNrVvvNytpt7ZdM=; b=boi1Bs5fnaQIZ88Zh7QNPMZYVQeya5lmGY6yOE6MrzgobkTIQ5qze3yKsX90uSuxu4usQMka mQSsbYYpYbLmRoQB+9wWWYkvK0fTwtG3kTVHSdSUAfG9VdHvWfaEw8Ec;
- In-reply-to: <273FB34D-25A1-4A12-937B-1AAE5B35F9DA@nokia.com>
- List-help: <mailto:avt-request@ietf.org?subject=help>
- List-id: Audio/Video Transport Working Group <avt.ietf.org>
- List-post: <mailto:avt@ietf.org>
- List-subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
- Thread-index: Aceme3lSljjfwKCrSgiInEGwlxLVWAAbigQw
> On 2007-6-1, at 21:09, ext Dan Wing wrote:
> > We need a document that consolidates NAT keepalive mechanisms for
> > UDP-based protocols, most notably RTP (and, to a lesser extent,
> > SIP). Currently this is spread in various documents and there
> > is no consolidated guidance to implementtors on the strength
> > or weakness of various approaches.
>
> I'm wondering if it'd make sense to add this guidance as a
> section in
> http://tools.ietf.org/html/draft-ietf-tsvwg-udp-guidelines?
I agree "send periodic UDP traffic" would be good in that
document. REQ-6 of draft-ford-behave-app-05 may provide the
beginnings of some useful text (CC'ing the authors of that
document).
As with all applications on today's Internet, an RTP
application needs to be robust and able to deal with whatever
is sent to it, so perhaps you're right -- an application-
specific keepalive document may well be overly specific and
we should, rather, document what any UDP-based application
should do to prevent middleboxes (such as NATs) from
clobbering a flow.
-d
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt