Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows
RFC 6263

Note: This ballot was opened for revision 10 and is now closed.

Lars Eggert (was Discuss) No Objection

Comment (2009-10-19)
No email
send info
Section 1., paragraph 15:
>    Note that if a given media uses a codec that already integrates a
>    keepalive mechanism, no additional keepalive mechanism is required at
>    the RTP level.

  And since redundant keepalives waste bandwidth and energy, do we want
  to say they're NOT RECOMMENDED?

(Magnus Westerlund; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2010-02-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I think there is good value in publishing some of this content. However, some things should be addressed prior to the documents approval. 

1. RTCP is an integral part of RTP. There are a number of mechanism that doesn't work unless also the RTCP flows are kept alive. To me this document can't rule RTCP out of scope. It needs to be covered.

And normally it isn't difficult as regular RTCP reports maximum periodic interval is shorter than the the bindings. However, there are some important configuration considerations that needs to be covered. It will also require symmetric usage of RTCP between transport peers. 

2. Section 4.6:

This solution does not discuss which SSRC should be used. That has significant impact if the solution is possible to use or not. There are a number of RTP payload formats that does not handle gaps in RTP sequence number well. T.140 text is one of these. Thus this solution is only plausible in that case to use a different SSRC. 

This in its turn has negative impact on one thing. There is implementations that are badly implemented in regards to handling multiple SSRC's. They may kill of the state for the media sending SSRC. I do agree that they are not standards compliant.

3. Section 4:
In general I am missing a discussion on which solutions results in RTCP reporting on the keep-alive packets. At least 4.2 and 4.6 can result in reporting on the keep-alive packets. In 4.6 it is not 100% clear what should happen so that needs to be made clear to avoid issues. 

4. Section 6.1, first paragraph:
This section is in error. T.140 requires that for the SSRC(s) one is using that the sequence number space is continous. If one switches to another media format, and do not attempt to use them intermixed it can work. Thus, method 4.6 can be used if another SSRC than the ones used to transport actual media are used. 

I do agree with the second paragraph that for T.140 there is little need to use anything else than the idle mechanism. 

5. section 5:

What is the interpretation of the a=rtp-keepalive attribute in multicast sessions? 

6. Section 7: I agree with minimal value for Tr of 15 seconds. It makes sense when sent over UDP. However, a significant larger value, like 5 to 15 min makes more sense for TCP. This is an area where it is difficult to provide good recommendations without considering the underlying transport protocol.

(Cullen Jennings; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Jari Arkko; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Robert Sparks; former steering group member) (was No Objection, Discuss) Yes

Yes ()
No email
send info

(Adrian Farrel; former steering group member) No Objection

No Objection (2010-02-16 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Title
s/maintaining/keeping/


Need to expand acronyms the first time they show up in the document body
For example, ICE


The "this does not apply to ICE agents" is a bit terse and cryptic. If 
the reader might not know what an ICE agent is, you should probably 
describe it. You might also reasonably explain *why* this document 
does not apply to ICE agents.

(Alexey Melnikov; former steering group member) No Objection

No Objection (2009-10-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This looks like one big hack, but Ok.

(Dan Romascanu; former steering group member) No Objection

No Objection (2010-02-17 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support the DISCUSSes from Robert and Magnus.

(David Harrington; former steering group member) (was Discuss) No Objection

No Objection (2010-09-14)
No email
send info
Comment (2010-02-17) 

Section 1, first bullet:

RTSP and streaming should be mentioned, since these are important uses of unidirectional RTP flows.

Section 4:
Please discuss how the potential solutions meet the requirements.

section 4.6 - the English in the new text needs work.
OLD:
The SSRC is the same than one one of the media for which keepalive is  sent. 
NEW:
The SSRC is the same as for the media for which keepalive is  sent.

(Lisa Dusseault; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Pasi Eronen; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ralph Droms; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Tim Polk; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info