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.

Magnus Westerlund Discuss

Discuss (2010-02-17 for -)
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.
Comment (2010-02-17 for -)
No email
send info
Section 1, first bullet:

I would say that streaming applications is one of the biggest usage of uni-directional RTP flows. The failure to mention RTSP and streaming seems strange.

Section 1, bullet 3: To me it appears inaccurate that comfort noise would be sent to seldom that a NAT binding would timeout. Can you mention any codec that would produce CN with longer interval than 1 second? 

Section 3, REQ-9:

This is not a requirement, it is a statement about the world.

Section 4:
The subsections on the potential solutions does not discuss how they meet the requirements. 

Section 4.3:

How can it be a con to require SDP signaling when you state in REQ-8 that is desirable. In fact only REQ-7 isn't supported by this solution which is a pretty good Pro list. 

I think my comments and discusses around 4.6 supports Robert Sparks discuss that the solution does not come without issues.

(Jari Arkko) Yes

(Cullen Jennings) Yes

(Robert Sparks) (was No Objection, Discuss) Yes

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Ralph Droms) No Objection

(Lisa Dusseault) No Objection

(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?

(Pasi Eronen) No Objection

(Adrian Farrel) No Objection

Comment (2010-02-16 for -)
No email
send info

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.

(David Harrington) (was Discuss) No Objection

Comment (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.
The SSRC is the same than one one of the media for which keepalive is  sent. 
The SSRC is the same as for the media for which keepalive is  sent.

(Russ Housley) No Objection

(Alexey Melnikov) No Objection

Comment (2009-10-19 for -)
No email
send info
This looks like one big hack, but Ok.

(Tim Polk) (was Discuss) No Objection

(Dan Romascanu) No Objection

Comment (2010-02-17 for -)
No email
send info
I support the DISCUSSes from Robert and Magnus.