Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows
draft-ietf-avt-app-rtp-keepalive-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Lars Eggert |
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the Yes position for Robert Sparks |
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Tim Polk |
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for David Harrington |
2011-03-31
|
10 | Robert Sparks | State Change Notice email list has been changed to avtcore-chairs@tools.ietf.org, draft-ietf-avt-app-rtp-keepalive@tools.ietf.org from avt-chairs@tools.ietf.org, draft-ietf-avt-app-rtp-keepalive@tools.ietf.org |
2011-03-11
|
10 | Cindy Morgan | State changed to RFC Ed Queue from Approved-announcement sent. |
2011-03-10
|
10 | (System) | IANA Action state changed to No IC from In Progress |
2011-03-10
|
10 | (System) | IANA Action state changed to In Progress |
2011-03-10
|
10 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2011-03-10
|
10 | Cindy Morgan | IESG has approved the document |
2011-03-10
|
10 | Cindy Morgan | Closed "Approve" ballot |
2011-03-10
|
10 | Cindy Morgan | Approval announcement text regenerated |
2011-03-10
|
10 | Cindy Morgan | Ballot writeup text changed |
2011-03-10
|
10 | Robert Sparks | Ballot writeup text changed |
2011-03-10
|
10 | Tim Polk | [Ballot Position Update] Position for Tim Polk has been changed to No Objection from Discuss |
2011-03-07
|
10 | David Harrington | [Ballot comment] I cleared. |
2011-03-07
|
10 | David Harrington | [Ballot discuss] |
2011-03-07
|
10 | David Harrington | [Ballot Position Update] Position for David Harrington has been changed to No Objection from Discuss |
2011-03-04
|
10 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to Yes from No Objection |
2011-03-04
|
10 | (System) | New version available: draft-ietf-avt-app-rtp-keepalive-10.txt |
2011-02-07
|
10 | Cindy Morgan | Approval announcement text regenerated |
2010-10-28
|
10 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss by Robert Sparks |
2010-10-21
|
10 | David Harrington | [Ballot discuss] Updated for -08- 1. RTCP is an integral part of RTP. This document can't rule RTCP out of scope. It needs to be … [Ballot discuss] Updated for -08- 1. RTCP is an integral part of RTP. This document can't rule RTCP out of scope. It needs to be covered. |
2010-09-24
|
09 | (System) | New version available: draft-ietf-avt-app-rtp-keepalive-09.txt |
2010-09-14
|
10 | David Harrington | [Ballot comment] 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: … [Ballot comment] 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. |
2010-09-14
|
10 | David Harrington | [Ballot discuss] Updated for -08- 1. RTCP is an integral part of RTP. This document can't rule RTCP out of scope. It needs to be … [Ballot discuss] Updated for -08- 1. RTCP is an integral part of RTP. This document can't rule RTCP out of scope. It needs to be covered. 2. Section 7: The [TODO] markers in the text must be resolved by defining appropriate values for the different protocols. |
2010-09-14
|
10 | David Harrington | [Ballot comment] Comment (2010-02-17) Section 1, first bullet: I would say that streaming applications is one of the biggest usage of uni- directional RTP flows. … [Ballot comment] Comment (2010-02-17) 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. |
2010-09-14
|
10 | David Harrington | [Ballot discuss] I think there is good value in publishing some of this content. However, some things should be addressed prior to the documents approval. … [Ballot discuss] 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. 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. |
2010-06-21
|
10 | Robert Sparks | [Ballot discuss] The document has a couple of [TODO]s still listed. The authors indicated on the AVT list that they would be coordinating with the … [Ballot discuss] The document has a couple of [TODO]s still listed. The authors indicated on the AVT list that they would be coordinating with the BEHAVE working group to clear those open issues. |
2010-06-18
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-06-18
|
08 | (System) | New version available: draft-ietf-avt-app-rtp-keepalive-08.txt |
2010-04-09
|
10 | David Harrington | [Ballot comment] Comment (2010-02-17) Section 1, first bullet: I would say that streaming applications is one of the biggest usage of uni- directional RTP flows. … [Ballot comment] Comment (2010-02-17) 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. |
2010-04-09
|
10 | David Harrington | [Ballot discuss] I think there is good value in publishing some of this content. However, some things should be addressed prior to the documents approval. … [Ballot discuss] 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. |
2010-04-09
|
10 | David Harrington | [Ballot Position Update] New position, Discuss, has been recorded by David Harrington |
2010-02-19
|
10 | (System) | Removed from agenda for telechat - 2010-02-18 |
2010-02-18
|
10 | Cindy Morgan | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Cindy Morgan |
2010-02-18
|
10 | Cindy Morgan | Responsible AD has been changed to Robert Sparks from Cullen Jennings |
2010-02-18
|
10 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2010-02-18
|
10 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2010-02-18
|
10 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko |
2010-02-18
|
10 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2010-02-17
|
10 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded by Ralph Droms |
2010-02-17
|
10 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2010-02-17
|
10 | Dan Romascanu | [Ballot comment] I support the DISCUSSes from Robert and Magnus. |
2010-02-17
|
10 | Magnus Westerlund | [Ballot comment] Section 1, first bullet: I would say that streaming applications is one of the biggest usage of uni-directional RTP flows. The failure to … [Ballot comment] 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. |
2010-02-17
|
10 | Magnus Westerlund | [Ballot discuss] I think there is good value in publishing some of this content. However, some things should be addressed prior to the documents approval. … [Ballot discuss] 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. |
2010-02-17
|
10 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded by Magnus Westerlund |
2010-02-17
|
10 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
2010-02-16
|
10 | Tim Polk | [Ballot discuss] (1) Given that it is declarative (and not subject to negotiation) I do not understand the utility of the a=rtp-keepalive SDP attribute. Since … [Ballot discuss] (1) Given that it is declarative (and not subject to negotiation) I do not understand the utility of the a=rtp-keepalive SDP attribute. Since the agent intends to use this solution if the a=rtcp-mux is not recognized whether the rtp-keepalive is recognized or not, it doesn't seem to add much value. Are you expecting middleboxes to process this value? If no entity is going to act on this information, why send it? (2) [Similar to Robert's discuss] I agree that multiplexing RTCP and RTP packets is an excellent solution. I also think that incorrect version numbers (as specified in 4.5) would be a terrible waste, given the limited number of possibilities. The remaining solutions all seem to have merit for some scenarios, as well as significant drawbacks. Perhaps it would be better to recognize multiplexing RTCP and RTP as the recommended solution, forbid the incorrect version number solution, and let applications pick their poison when a=rtcp-mux does not appear in the answer. (3) While a peer is required by RFC 3530 to "ignore packets with payload types it does not understand", that does not preclude examination by the peer in an attempt to determine if it is under attack. Since falling back to the alternative indicates the peer is not aware of this specification, the Cons for section 4.6 should note that the peer may consider the keepalive traffic a DOS attack and terminate the connection. |
2010-02-16
|
10 | Tim Polk | [Ballot discuss] (1) Given that it is declarative (and not subject to negotiation) I do not understand the utility of the a=rtp-keepalive SDP attribute. Since … [Ballot discuss] (1) Given that it is declarative (and not subject to negotiation) I do not understand the utility of the a=rtp-keepalive SDP attribute. Since the agent intends to use this solution if the a=rtcp-mux is not recognized whether the rtp-keepalive is recognized or not, it doesn't seem to add much value. Are you expecting middleboxes to process this value? If no entity is going to act on this information, why send it? (2) [Similar to Robert's discuss] I agree that multiplexing RTCP and RTP packets is an excellent solution. I also think that incorrect version numbers (as specified in 4.5) would be a terrible waste, given the limited number of possibilities. The remaining solutions all seem to have merit for some scenarios, as well as significant drawbacks. Perhaps it would be better to recognize multiplexing RTCP and RTP as the recommended solution, forbid the incorrect version number solution, and let applications pick their poison when a=rtcp-mux does not appear in the answer. (3) While a peer is required by RFC 3530 to "ignore packets with payload types it does not understand", that does not preclude examination by the peer in an attempt to determine if it is under attack. Since falling back to the alternative indicates the peer is not aware of this specification, the Cons for section 4.6 should note that the peer may consider the keepalive traffic a DOS attack and terminate the connection. |
2010-02-16
|
10 | Tim Polk | [Ballot Position Update] New position, Discuss, has been recorded by Tim Polk |
2010-02-16
|
10 | Robert Sparks | [Ballot discuss] I am happy to see this discussion of ways that have been tried in the past to keep NAT bindings alive published. I … [Ballot discuss] I am happy to see this discussion of ways that have been tried in the past to keep NAT bindings alive published. I support the conclusion that multiplexing RTCP and RTP is the RECOMMENDED solution and that the other mechanisms are NOT RECOMMENDED. However, I think the document's current approach of making falling back to sending RTP with an unknown payload type RECOMMENDED is a mistake. The document argues that this "always works". That is inconsistent with what I have observed in the field. We lived through a period where simple un-negotiated comfort-noise packets were causing unintended malfunction in several kinds of endpoints. It is highly likely that implementations seeing a null payload with an unsolicited type are going to do something very unexpected. In general, recommending that elements violate part of a specification because some other part of the specification says to ignore that violation is very dangerous and will lead to long term interoperability problems. The robustness principle being taken advantage of here has two parts - Be conservative in what you send ("Don't send things you haven't been told are ok to send") and Be liberal in what you receive ("Don't break if the other guy sends you the wrong thing") only works when most of the elements do both things. Asking a large part of the system to ignore half of that equation removes the robustness. The same argument this document is making to say it's ok to send these will eventually be used by stack or middlebox implementors to drop these packets before they get to where they've possibly done any good. I think this document should keep the discussion of these alternate techniques, and even point out that of the alternatives other than multiplexing RTP/RTCP, sending unsolicited payload types breaks fewer things. But putting that forth as a Proposed Standard way to behave is not the right thing to do. |
2010-02-16
|
10 | Robert Sparks | [Ballot Position Update] New position, Discuss, has been recorded by Robert Sparks |
2010-02-16
|
10 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
2010-02-16
|
10 | Adrian Farrel | [Ballot comment] 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 … [Ballot comment] 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. |
2010-02-14
|
10 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2010-02-11
|
10 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Shawn Emery |
2010-02-11
|
10 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Shawn Emery |
2010-02-09
|
10 | Cullen Jennings | Note field has been cleared by Cullen Jennings |
2010-02-09
|
10 | Cullen Jennings | Placed on agenda for telechat - 2010-02-18 by Cullen Jennings |
2009-12-11
|
10 | Lars Eggert | [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss by Lars Eggert |
2009-12-07
|
07 | (System) | New version available: draft-ietf-avt-app-rtp-keepalive-07.txt |
2009-10-20
|
10 | Cullen Jennings | Removed from agenda for telechat - 2009-10-22 by Cullen Jennings |
2009-10-20
|
10 | Cullen Jennings | [Note]: 'This still needs to be put on an IESG call. Started to for Oct 22, 2009 call but then took if off that call … [Note]: 'This still needs to be put on an IESG call. Started to for Oct 22, 2009 call but then took if off that call to give time to resolve some issues.' added by Cullen Jennings |
2009-10-19
|
10 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded by Alexey Melnikov |
2009-10-19
|
10 | Alexey Melnikov | [Ballot comment] This looks like one big hack, but Ok. |
2009-10-19
|
10 | Lars Eggert | [Ballot comment] Section 1., paragraph 15: > Note that if a given media uses a codec that already integrates a > keepalive mechanism, … [Ballot comment] 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? |
2009-10-19
|
10 | Lars Eggert | [Ballot discuss] Good document. I'd like to bring up one quick issue: Section 7., paragraph 1: > An application supporting this specification MUST transmit … [Ballot discuss] Good document. I'd like to bring up one quick issue: Section 7., paragraph 1: > An application supporting this specification MUST transmit either > keepalive packets or media packets at least once every Tr seconds > during the whole duration of the media session. Tr SHOULD be > configurable, and otherwise MUST default to 15 seconds. DISCUSS: Please see Section 3.5 of RFC5405 and check if you want to bring your recommendation in line with what we've written there (SHOULD NOT send more frequently than every 15 sec, SHOULD investigate if other mechanisms are available, etc.) You might also want to quote or refer to some of the other content of that section here, since this text talks more generally about when keepalives are appropriate. |
2009-10-19
|
10 | Lars Eggert | [Ballot Position Update] New position, Discuss, has been recorded by Lars Eggert |
2009-10-18
|
10 | Cullen Jennings | [Ballot Position Update] New position, Yes, has been recorded for Cullen Jennings |
2009-10-18
|
10 | Cullen Jennings | Ballot has been issued by Cullen Jennings |
2009-10-18
|
10 | Cullen Jennings | Created "Approve" ballot |
2009-10-18
|
10 | Cullen Jennings | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Cullen Jennings |
2009-10-18
|
10 | Cullen Jennings | Placed on agenda for telechat - 2009-10-22 by Cullen Jennings |
2009-06-23
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-06-23
|
06 | (System) | New version available: draft-ietf-avt-app-rtp-keepalive-06.txt |
2009-06-22
|
10 | Cullen Jennings | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Cullen Jennings |
2009-06-16
|
10 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Shawn Emery. |
2009-06-02
|
10 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2009-05-28
|
10 | Amanda Baber | IANA comments: Upon approval of this document, IANA will make the following assignment in the "att-field (media level only)" registry at http://www.iana.org/assignments/sdp-parameters Type SDP Name … IANA comments: Upon approval of this document, IANA will make the following assignment in the "att-field (media level only)" registry at http://www.iana.org/assignments/sdp-parameters Type SDP Name Reference ---- ------------------ --------- att-field (media level only) rtp-keepalive [RFC-avt-app-rtp-keepalive-05] We understand the above to be the only IANA Action for this document. |
2009-05-24
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2009-05-24
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Shawn Emery |
2009-05-19
|
10 | Cindy Morgan | Last call sent |
2009-05-19
|
10 | Cindy Morgan | State Changes to In Last Call from Last Call Requested by Cindy Morgan |
2009-05-19
|
10 | Cullen Jennings | Last Call was requested by Cullen Jennings |
2009-05-19
|
10 | Cullen Jennings | State Changes to Last Call Requested from AD Evaluation::External Party by Cullen Jennings |
2009-05-19
|
10 | (System) | Ballot writeup text was added |
2009-05-19
|
10 | (System) | Last call text was added |
2009-05-19
|
10 | (System) | Ballot approval text was added |
2009-05-19
|
10 | Cullen Jennings | Intended Status has been changed to Proposed Standard from BCP |
2009-05-01
|
10 | Cullen Jennings | State Changes to AD Evaluation::External Party from AD Evaluation by Cullen Jennings |
2009-05-01
|
10 | Cullen Jennings | This is just largely defining a way for the UA to deal with keep alives - I'd like to change the track from BCP to … This is just largely defining a way for the UA to deal with keep alives - I'd like to change the track from BCP to Proposed Standard. Does this cause any problems? When using RTCP mux, I'd like a little more information about what RTCP you send. Particularly in the case of a one way media stream where the sender is behind the NAT. Thought I know we typically don't use static payload types, this seems like an ideal one to use a static payload type for. This could allow diagnostic and logging tools that did not see the SDP to still be able to understand what was going on. Thoughts? Does a device that does not support the fallback solution but will do the RTCP-mux include the keep-alive attribute? |
2009-05-01
|
10 | Cullen Jennings | State Changes to AD Evaluation from Publication Requested by Cullen Jennings |
2009-02-04
|
10 | Cindy Morgan | (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he … (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Tom Taylor is Document Shepherd. I have read this version of the document and believe it is ready for publication. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has been well reviewed, by participants in the AVT, BEHAVE, and MMUSIC Working Groups. It began in 2007 as a BEHAVE work proposal with a broader scope, but was eventually focussed on RTP keepalive in the absence of ICE support. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No concern. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No concerns. No IPR disclosures. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is solid WG consensus. As evidenced by the Acknowledgements section, a number of people provided comments that helped the document take shape along the way. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? ID nits is confused about the presence of the RFC 2119 boilerplate text, but it is there as section 2. All OK otherwise. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. All OK. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? All OK. The proposed rtp-keepalive SDP parameter drew no comments from MMUSIC. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document lists the different mechanisms that enable applications using Real-time Transport Protocol (RTP) to maintain their RTP Network Address Translator (NAT) mappings alive. It also makes a recommendation for a preferred mechanism. This document is not applicable to Interactive Connectivity Establishment (ICE) agents. Working Group Summary This document began in 2006 as a proposed BEHAVE work item with broader scope. The scope was refined after discussion between BEHAVE, MMUSIC, and AVT Working Groups to that indicated above. The rtp-keepalive SDP parameter was added by direction of the AVT Chair when no comments were received either for or against that proposal. Document Quality This document was shaped by comments from a number of contributors, as listed in the Acknoledgements section. As a general application guide, it is expected to have broad implementation. (end) |
2009-02-04
|
10 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2009-01-30
|
05 | (System) | New version available: draft-ietf-avt-app-rtp-keepalive-05.txt |
2008-10-02
|
04 | (System) | New version available: draft-ietf-avt-app-rtp-keepalive-04.txt |
2008-04-08
|
03 | (System) | New version available: draft-ietf-avt-app-rtp-keepalive-03.txt |
2008-02-08
|
02 | (System) | New version available: draft-ietf-avt-app-rtp-keepalive-02.txt |
2007-12-17
|
01 | (System) | New version available: draft-ietf-avt-app-rtp-keepalive-01.txt |
2007-06-22
|
00 | (System) | New version available: draft-ietf-avt-app-rtp-keepalive-00.txt |