Skip to main content

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

Discuss


Yes

(Cullen Jennings)
(Jari Arkko)
(Robert Sparks)

No Objection

(Lisa Dusseault)
(Pasi Eronen)
(Ralph Droms)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)

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

Magnus Westerlund Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2010-02-17) Unknown
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 IESG member
Yes
Yes () Unknown

                            
Jari Arkko Former IESG member
Yes
Yes () Unknown

                            
Robert Sparks Former IESG member
(was No Objection, Discuss) Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2010-02-16) Unknown
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 IESG member
No Objection
No Objection (2009-10-19) Unknown
This looks like one big hack, but Ok.
Dan Romascanu Former IESG member
No Objection
No Objection (2010-02-17) Unknown
I support the DISCUSSes from Robert and Magnus.
David Harrington Former IESG member
(was Discuss) No Objection
No Objection (2010-09-14) Unknown
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.
Lars Eggert Former IESG member
(was Discuss) No Objection
No Objection (2009-10-19) Unknown
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?
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
No Objection
No Objection () Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
(was Discuss) No Objection
No Objection () Unknown