Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows
draft-ietf-avt-app-rtp-keepalive-10

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.