Content Splicing for RTP Sessions
draft-ietf-avtext-splicing-for-rtp-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-11-14
|
13 | Jinwei Xia | New version available: draft-ietf-avtext-splicing-for-rtp-13.txt |
2012-11-14
|
12 | Amy Vezza | State changed to RFC Ed Queue from Approved-announcement sent |
2012-11-13
|
12 | (System) | IANA Action state changed to No IC |
2012-11-13
|
12 | Amy Vezza | State changed to Approved-announcement sent from Approved-announcement to be sent |
2012-11-13
|
12 | Amy Vezza | IESG has approved the document |
2012-11-13
|
12 | Amy Vezza | Closed "Approve" ballot |
2012-11-13
|
12 | Amy Vezza | State changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2012-11-13
|
12 | Amy Vezza | Ballot approval text was generated |
2012-11-12
|
12 | Pete Resnick | [Ballot comment] At base, I disagree with the WG and some of the ADs that this document should include anything about user experience; that is … [Ballot comment] At base, I disagree with the WG and some of the ADs that this document should include anything about user experience; that is not a requirement for the protocol. But the author and WG have done a good job of addressing all of my other concerns and the user experience discussion in the document is very limited, so I am clearly "in the rough" and it is only right that I not hold up the document. |
2012-11-12
|
12 | Pete Resnick | [Ballot Position Update] Position for Pete Resnick has been changed to Abstain from Discuss |
2012-11-12
|
12 | Jinwei Xia | New version available: draft-ietf-avtext-splicing-for-rtp-12.txt |
2012-11-09
|
11 | Stewart Bryant | [Ballot comment] It is a pity that this design does not allow the content security domain to be separated from the content insertion trigger domain, … [Ballot comment] It is a pity that this design does not allow the content security domain to be separated from the content insertion trigger domain, since it exposes the content to an additional interception point. However the restriction is clearly described. |
2012-11-09
|
11 | Stewart Bryant | [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss |
2012-10-22
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-10-22
|
11 | Jinwei Xia | New version available: draft-ietf-avtext-splicing-for-rtp-11.txt |
2012-10-11
|
10 | Cindy Morgan | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation |
2012-10-11
|
10 | Jinwei Xia | New version available: draft-ietf-avtext-splicing-for-rtp-10.txt |
2012-10-10
|
09 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley |
2012-10-10
|
09 | Martin Stiemerling | [Ballot comment] Thank you for addressing my concerns! |
2012-10-10
|
09 | Martin Stiemerling | [Ballot Position Update] Position for Martin Stiemerling has been changed to No Objection from Discuss |
2012-10-09
|
09 | Wesley Eddy | [Ballot Position Update] Position for Wesley Eddy has been changed to No Objection from Abstain |
2012-10-09
|
09 | Barry Leiba | [Ballot comment] Thank you for the extensive work on this document since the -07 version. This is *much* clearer, and addresses all my significant concerns. … [Ballot comment] Thank you for the extensive work on this document since the -07 version. This is *much* clearer, and addresses all my significant concerns. Only one, small, non-blocking point: I suggest expanding "SSRC" and "CSRC" on first use. For the record, I have no issue with Section 4.3 -- I see nothing wrong with a non-normative section that calls out an issue (including a user-experience issue) that's likely to come up in implementations, and warns them about it. If it tried to be normative, or if it went into a lot of detail about user interface design, I might agree that it's a problem... but it doesn't, and I don't. |
2012-10-09
|
09 | Barry Leiba | Ballot comment text updated for Barry Leiba |
2012-10-09
|
09 | Robert Sparks | [Ballot comment] Thanks for addressing my concerns. Please consider adding (or pointing to) a discussion of what the impact of having a loop is. |
2012-10-09
|
09 | Robert Sparks | [Ballot Position Update] Position for Robert Sparks has been changed to No Objection from Discuss |
2012-10-08
|
09 | Pete Resnick | [Ballot discuss] REQ-7: There at least needs to be a forward reference to section 4.5 in this section. That said, I am still bothered by … [Ballot discuss] REQ-7: There at least needs to be a forward reference to section 4.5 in this section. That said, I am still bothered by this section. The first sentence is written in the passive voice, so I can't tell what it's saying: Is it saying that splicing should not be easily detected *by the RTP receiving implementation* (in which case section 4.5 is really all that this is talking about), or is it saying that splicing should not be easily detected *by the RTP stream end-user* (in which case it's talking about section 4.3, which I think is bogus)? The second half of REQ-7 talks about both, but then goes on to say that this memo is only concerned with the RTP layer. Please rewrite this section to make it clear that you are only talking about the protocol, not the user experience. Section 4.3: Similar to the above, this is really all user experience, not protocol clipping. I think this section should simply be dropped. Section 4.5: "User Invisibility" is not the requirement in 4.5; it is "Receiving implementation invisibility." Section 4.5 does not address user experience invisibility and should be re-titled. With regard to all of the above, if the WG insists on talking about user experience in this document, I will simply Abstain on it. |
2012-10-08
|
09 | Pete Resnick | Ballot comment and discuss text updated for Pete Resnick |
2012-10-08
|
09 | Adrian Farrel | [Ballot comment] I am ballotting No Objection on this document although I am not convinced by the Security thoughts. It doesn't seem to me to … [Ballot comment] I am ballotting No Objection on this document although I am not convinced by the Security thoughts. It doesn't seem to me to be impossible to construct a three-way security arrangement for source, splicer, and destination. But maybe the point here is that the very act of splicing *is* a violaiton of the source-destination relationship. Thus the destination correctly only has a relationship with the splicer. |
2012-10-08
|
09 | Adrian Farrel | [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from No Record |
2012-10-07
|
09 | Stewart Bryant | [Ballot discuss] I have a concern regarding requirement 4, since in some cases exposing the content in the clear at the ad insertion point would … [Ballot discuss] I have a concern regarding requirement 4, since in some cases exposing the content in the clear at the ad insertion point would be considered a service security vulnerability. The basis for this vulnerability seems to be the need to provide access to the keying indicators. Surely it is possible to design an out of band, or a semi-out of band, indication system and not expose the content itself to this vulnerability? |
2012-10-07
|
09 | Stewart Bryant | Ballot discuss text updated for Stewart Bryant |
2012-10-01
|
09 | Gonzalo Camarillo | State changed to IESG Evaluation from IESG Evaluation::External Party |
2012-10-01
|
09 | Gonzalo Camarillo | Telechat date has been changed to 2012-10-11 from 2012-05-10 |
2012-10-01
|
09 | Magnus Westerlund | Changed protocol writeup |
2012-10-01
|
09 | Magnus Westerlund | IETF state changed to Submitted to IESG for Publication from WG Document |
2012-10-01
|
09 | Magnus Westerlund | Changed protocol writeup |
2012-08-27
|
09 | Stephen Farrell | [Ballot comment] Thanks for addressing my discuss points. I think the current version's truth-in-advertising approach to the fact that it breaks e2e security is much … [Ballot comment] Thanks for addressing my discuss points. I think the current version's truth-in-advertising approach to the fact that it breaks e2e security is much better. (Though it'd be even better if you could figure a way to do this that would not break e2e security. I'd encourage folks wanting to insert advertisements to try think about that.) |
2012-08-27
|
09 | Stephen Farrell | [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss |
2012-08-13
|
09 | Magnus Westerlund | Resent to the AD for processing after addressing the IESG comments. The WG last call on the changes was commented by both Colin Perkins and … Resent to the AD for processing after addressing the IESG comments. The WG last call on the changes was commented by both Colin Perkins and Roni Even. The shepherd has also re-read the draft finding nothing substantial. The write-up has been updated. Mostly noting that the document was sent back, updated and reviewed in a last call. |
2012-08-13
|
09 | Magnus Westerlund | New WG last call on changes based on IESG discussion. After this it will be sent to the AD again. |
2012-08-13
|
09 | Jinwei Xia | New version available: draft-ietf-avtext-splicing-for-rtp-09.txt |
2012-07-11
|
08 | Gonzalo Camarillo | State changed to IESG Evaluation::External Party from IESG Evaluation::AD Followup |
2012-07-09
|
08 | Stephen Farrell | [Ballot discuss] - The new REQ-7 seems to be saying that we are encouraging hosts on the Internet to fool one another and engineering our … [Ballot discuss] - The new REQ-7 seems to be saying that we are encouraging hosts on the Internet to fool one another and engineering our protocols to make it harder for some of them to figure out they are being fooled. That doesn't seem like a good goal to me. I still think you need to get rid of the "invisibility" concept entirely. (Or perhaps explain it as someone's bad idea.) - As discussed via mail, the sharing of the SA required for this only seems to be acceptable if you say that it mustn't affect any other RTP security. I don't think REQ-6 is there yet and I'm not sure how it can get there, other than if you say that you need some special setup for IPTV with ads that can't leak over into other RTP sessions. - Sorry, but I still don't get the loop problem. I think its needs to be better explained. |
2012-07-09
|
08 | Stephen Farrell | [Ballot comment] New comments on -08 - 4.1, 1st sentence says how this "should" be implemented. Be better to avoid 2119 language and say "could" … [Ballot comment] New comments on -08 - 4.1, 1st sentence says how this "should" be implemented. Be better to avoid 2119 language and say "could" there IMO. - I just can't parse this, from 4.2: "The mixer can also inform the main RTP sender or the substitutive RTP sender of the reception quality of the content reaches the mixer during the time when the content is not sent to the RTP receiver." (I didn't check these against -08) section 1: - s/into internet/into the Internet/ - s/changes to transport layer/changes to the transport layer/ - s/requirements of RTP splicing/requirements for RTP splicing/ - REQ-1, what environments other than unicast or multicast might exist? If this isn't a tautology then I don't know what's meant. - REQ-3, I'm not clear what backward compatible means here - the splicer seems to be talking RTP/RTCP for both main and current content in Figure 1, so what element of backward compatibility is meant here? - Is the reference to SCTE30 meant to be the 2001 version? I only found the 2009 version on scte.org, but didn't hunt much. For SCTE35 2007 is referenced, but there's a 2011. What's up there? Stable URLs for those and the ISMA document would be good. |
2012-07-09
|
08 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2012-07-09
|
08 | Stephen Farrell | [Ballot discuss] - From the above, it seems to me that if there are any security requirements here then the receiver needs to have a … [Ballot discuss] - From the above, it seems to me that if there are any security requirements here then the receiver needs to have a direct relationship with the splicer, as does the sender, so that e.g. any encrypted traffic is decrypted at the splicer, and then re-encrypted. - The new REQ-7 and the text in the 1st two paragraphs of 4.2 seem to be saying that we are encouraging hosts on the Internet to fool one another and engineering our protocols to make it harder for some of them to figure out they are being fooled? That doesn't seem like a good goal to me, without a lot more justification. - Changes to RTCP reports and loss values as suggested here would also seem to preclude any real e2e security. I just don't get why that is ok. - If so-called "user invisibility" is required (and there is no REQ-X for that) and it has the consequence of creating loops then that ought be described, and it isn't. - If "invisible" splicing were really possible, then how could any supposedly "secure" RTP session ever be trusted by a receiver? |
2012-07-09
|
08 | Stephen Farrell | [Ballot comment] (I didn't check these against -08) section 1: - s/into internet/into the Internet/ - s/changes to transport layer/changes to the transport layer/ … [Ballot comment] (I didn't check these against -08) section 1: - s/into internet/into the Internet/ - s/changes to transport layer/changes to the transport layer/ - s/requirements of RTP splicing/requirements for RTP splicing/ - REQ-1, what environments other than unicast or multicast might exist? If this isn't a tautology then I don't know what's meant. - REQ-3, I'm not clear what backward compatible means here - the splicer seems to be talking RTP/RTCP for both main and current content in Figure 1, so what element of backward compatibility is meant here? - Is the reference to SCTE30 meant to be the 2001 version? I only found the 2009 version on scte.org, but didn't hunt much. For SCTE35 2007 is referenced, but there's a 2011. What's up there? Stable URLs for those and the ISMA document would be good. |
2012-07-09
|
08 | Stephen Farrell | Ballot comment and discuss text updated for Stephen Farrell |
2012-07-09
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2012-07-09
|
08 | Jinwei Xia | New version available: draft-ietf-avtext-splicing-for-rtp-08.txt |
2012-05-16
|
07 | Magnus Westerlund | IETF state changed to WG Document from Submitted to IESG for Publication |
2012-05-10
|
07 | Magnus Westerlund | Sent a status question to the author. |
2012-05-10
|
07 | Magnus Westerlund | This document will need significant revision based on the IESG comments. A new WG last call should be before requesting processing again. |
2012-05-10
|
07 | Amy Vezza | State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation |
2012-05-10
|
07 | Russ Housley | Note changed to 'Magnus Westerlund (magnus.westerlund@ericsson.com) is the document shepherd.' |
2012-05-10
|
07 | Stewart Bryant | [Ballot discuss] Given that advertisement insertion in IPTV seems to be a deployed technology, and given that there are television SDOs working on IPTV, I … [Ballot discuss] Given that advertisement insertion in IPTV seems to be a deployed technology, and given that there are television SDOs working on IPTV, I would like to understand what input those SDOs and vendors had into this requirements set. Although this is a requirements specification, it seems to go into implementation detail, for example section 4.1 There needs to be considerably more thought given to the security model to protect both the content provider and the viewer. Given the large number of comments and discusses, I request that a future revision of this document is brought back to the IESG for review. |
2012-05-10
|
07 | Stewart Bryant | [Ballot Position Update] New position, Discuss, has been recorded for Stewart Bryant |
2012-05-10
|
07 | Sean Turner | [Ballot comment] I support the discuss positions from the other ADs. |
2012-05-10
|
07 | Sean Turner | [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner |
2012-05-10
|
07 | Adrian Farrel | [Ballot comment] In view of the large number of Discuss and Comment issues raised, I am not going to spend time reviewing this version of … [Ballot comment] In view of the large number of Discuss and Comment issues raised, I am not going to spend time reviewing this version of the document. If the document returns to a future telechat I will review it then. |
2012-05-10
|
07 | Adrian Farrel | Ballot comment text updated for Adrian Farrel |
2012-05-10
|
07 | Benoît Claise | [Ballot comment] Much has been said already with the multiple DISCUSS feedback on this draft. So, no need to repeat the information: I'll trust the … [Ballot comment] Much has been said already with the multiple DISCUSS feedback on this draft. So, no need to repeat the information: I'll trust the other ADs will take care of this one. |
2012-05-10
|
07 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2012-05-09
|
07 | Pete Resnick | [Ballot discuss] This document is nowhere near ready for the IESG. The large number of things that are so poorly edited as to be unclear … [Ballot discuss] This document is nowhere near ready for the IESG. The large number of things that are so poorly edited as to be unclear what the meaning is (i.e., not just grammatical mistakes which we see in all documents) indicates to me that it did not have sufficient review. I don't think REQ-2 is an actionable protocol requirement. Given section 4.3, it appears that what you mean by REQ-2 is something like, "Make the sound and picture change be smooth", in which case it's not a protocol requirement at all. Making the media transition be smooth involves a great deal of knowledge about the nature of the media being sent. You may need to do fading, or some other thing to make sure that the boundary between the main media and the substitutive media is seamless. There's nothing to be done in protocol for this; you have to know something about the media itself. And it is hard to reconcile this with the statement in section 4 which says, "splicing is not a very complicated processing". Presumably REQ-2 is not really about the buffering, which should not be an issue at all because you are presumed to already know when splicing begins and ends: The methods how Splicer learns when to start and end the splicing is out of scope for this document. So you should already know where you're going to start inserting your data into the stream. REQ-6 is not a requirement at all. First, as Stephen says, it conflicts with REQ-4. But even beyond that, the body of the requirement is basically saying, "Do it if it is convenient." The document does no analysis as to the effectiveness of the "trade-off" invisibility (simply maintaining RTP header params) to see if it's even worth doing so. I don't see what an implementer reading REQ-6 would do. |
2012-05-09
|
07 | Pete Resnick | Ballot discuss text updated for Pete Resnick |
2012-05-09
|
07 | Pete Resnick | [Ballot discuss] This document is nowhere near ready for the IESG. The large number of things that are so poorly edited as to be unclear … [Ballot discuss] This document is nowhere near ready for the IESG. The large number of things that are so poorly edited as to be unclear what the meaning is (i.e., not just grammatical mistakes which we see in all documents) indicates to me that it did not have sufficient review. I don't think REQ-2 is not an actionable protocol requirement. Given section 4.3, it appears that what you mean by REQ-2 is something like, "Make the sound and picture change be smooth", in which case it's not a protocol requirement at all. Making the media transition be smooth involves a great deal of knowledge about the nature of the media being sent. You may need to do fading, or some other thing to make sure that the boundary between the main media and the substitutive media is seamless. There's nothing to be done in protocol for this; you have to know something about the media itself. And it is hard to reconcile this with the statement in section 4 which says, "splicing is not a very complicated processing". Presumably REQ-2 is not really about the buffering, which should not be an issue at all because you are presumed to already know when splicing begins and ends: The methods how Splicer learns when to start and end the splicing is out of scope for this document. So you should already know where you're going to start inserting your data into the stream. REQ-6 is not a requirement at all. First, as Stephen says, it conflicts with REQ-4. But even beyond that, the body of the requirement is basically saying, "Do it if it is convenient." The document does no analysis as to the effectiveness of the "trade-off" invisibility (simply maintaining RTP header params) to see if it's even worth doing so. I don't see what an implementer reading REQ-6 would do. |
2012-05-09
|
07 | Pete Resnick | [Ballot comment] 4.1 - I don't see what the first paragraph is telling anyone. Presumably if you are a splicer, you know that you will … [Ballot comment] 4.1 - I don't see what the first paragraph is telling anyone. Presumably if you are a splicer, you know that you will need data to insert into the stream and that it will be coming from somewhere. What is the purpose of the first paragraph? Paragraph 2 starts, "Even if splicing does not begin". Do you simply mean, "Before splicing begins"? Otherwise, I don't understand what this sentence is saying. Also, unlike the rest of the paragraphs, it does not talk about "encapsulating". I assume it should, yes? Paragraph 3 only mentions a substitutive RTP stream and not local media. I agree with Barry that the pseudo code is useless, if not just confusing, and should be removed. The prior text should include all of the information that would have been in the pseudocode. Note that, the substitutive content should be outputted in the range of splicing duration. I do not understand the above sentence. 4.3 - If the time slot for substitutive RTP stream mismatches (shorter or longer than) the duration of the reserved main RTP stream for replacing, the media clipping may occur at the splicing point which usually is the joint between two independently decodable frames. I understood everything up to the word "which", but I don't understand the importance of what comes after that. But even before that, I'm not clear on whether you mean "clipping" or simply "truncation". The last paragraph of 4.3 seems to talk about true clipping, but the rest of this seems to be about extending media that does not fill a time slot or truncating media which overfills a slot and how to make those transitions look smooth. I wouldn't call all of these "clipping". |
2012-05-09
|
07 | Pete Resnick | [Ballot Position Update] New position, Discuss, has been recorded for Pete Resnick |
2012-05-09
|
07 | Wesley Eddy | [Ballot comment] I support Stephen's DISCUSS points. REQ-3 seems broad and unspecific given the range of RTP/RTCP extensions. REQ-4 is vague on what it really … [Ballot comment] I support Stephen's DISCUSS points. REQ-3 seems broad and unspecific given the range of RTP/RTCP extensions. REQ-4 is vague on what it really means technically, and REQ-5 is also vague in regards to what the performance consists of and lacks rationale for why it needs to be relayed back. REQ-6 seems misformatted. As written, I do not think this document is useful to be permanently published as an RFC. It starts with the assumption that splicing is necessary for some use case and doesn't consider whether other approaches can meet the same actual requirements (of the use case, NOT of the splicing solution chosen). It recommends a solution without clearly comparing any alternatives. |
2012-05-09
|
07 | Wesley Eddy | [Ballot Position Update] New position, Abstain, has been recorded for Wesley Eddy |
2012-05-09
|
07 | Stephen Farrell | [Ballot discuss] - REQ-4: What exactly does it mean to say that the splicer must be trusted by the receiver? I would have guessed that … [Ballot discuss] - REQ-4: What exactly does it mean to say that the splicer must be trusted by the receiver? I would have guessed that most receivers would not know of the splicer's existence. The reason this is a discuss is that I am worried that the consequences of treating a "transparent proxy" (as they're called in HTTP) as if it were "trusted" could be damaging to the Internet. - REQ-4 and REQ-6 seem to me to be in conflict. How can a receiver "trust" a splicer and yet be prevented from knowing what the splicer has done? - From the above, it seems to me that if there are any security requirements here then the receiver needs to have a direct relationship with the splicer, as does the sender, so that e.g. any encrypted traffic is decrypted at the splicer, and then re-encrypted. - Is the text in the 1st two paragraphs of 4.2 saying that we are encouraging hosts on the Internet to fool one another and engineering our protocols to make it harder for some of them to figure out they are being fooled? That doesn't seem like a good goal to me, without a lot more justification. - Changes to RTCP reports and loss values as suggested here would also seem to preclude any real e2e security. I just don't get why that is ok. - If so-called "user invisibility" is required (and there is no REQ-X for that) and it has the consequence of creating loops then that ought be described, and it isn't. - If "invisible" splicing were really possible, then how could any supposedly "secure" RTP session ever be trusted by a receiver? |
2012-05-09
|
07 | Stephen Farrell | [Ballot comment] section 1: - s/into internet/into the Internet/ - s/changes to transport layer/changes to the transport layer/ - s/requirements of RTP splicing/requirements … [Ballot comment] section 1: - s/into internet/into the Internet/ - s/changes to transport layer/changes to the transport layer/ - s/requirements of RTP splicing/requirements for RTP splicing/ - REQ-1, what environments other than unicast or multicast might exist? If this isn't a tautology then I don't know what's meant. - REQ-3, I'm not clear what backward compatible means here - the splicer seems to be talking RTP/RTCP for both main and current content in Figure 1, so what element of backward compatibility is meant here? - Is the reference to SCTE30 meant to be the 2001 version? I only found the 2009 version on scte.org, but didn't hunt much. For SCTE35 2007 is referenced, but there's a 2011. What's up there? Stable URLs for those and the ISMA document would be good. |
2012-05-09
|
07 | Stephen Farrell | [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell |
2012-05-09
|
07 | Ralph Droms | [Ballot Position Update] New position, No Objection, has been recorded for Ralph Droms |
2012-05-08
|
07 | Robert Sparks | [Ballot discuss] (Clearing up some minor typos to make these easier to read) It's not clear what a mixer implementer should be doing with the … [Ballot discuss] (Clearing up some minor typos to make these easier to read) It's not clear what a mixer implementer should be doing with the advice in the last full paragraph on page 12. How is that implementer supposed to apply something like RFC5348 or RFC5762? Is this feedback running between the mixer and the receiver, the mixer and the source, or something else? In any case, it should be made explicit that this isn't asking the mixer to begin transcoding. The pseudo code blocks each say "the timestamp of the current RTP packet increments linearly" and that is unclear. Is this trying to say that the mapping from the timestamp in the input packet to the mixer and the output packet be linear? The implementations considerations section says there is a potential issue with loop detection, but doesn't actually describe the issue, or how satisfying the user invisibility requirement makes it more likely to occur. The document should be explicit about the expected trust model if SRTP is used. I believe it is currently assuming that media from either source would be decrypted at the mixer and re-encrypted towards the receiver(s). The first paragraph in section 6 could be read to imply that the mixer is just forwarding SRTP packets. |
2012-05-08
|
07 | Robert Sparks | Ballot discuss text updated for Robert Sparks |
2012-05-08
|
07 | Robert Sparks | [Ballot discuss] It's not clear what a mixer implementer should be going with the advice in the last full paragraph on page 12. How is … [Ballot discuss] It's not clear what a mixer implementer should be going with the advice in the last full paragraph on page 12. How is that implementer supposed to apply something like RFC5348 or RFC5762? Is this feedback running between the mixer and the receiver, the mixer and the source, or something else? In any case, it should be made explicit that this isn't asking the mixer to begin transcoding. The pseudo code blocks each say "the timestamp of the current RTP packet increments linearly" is unclear. Is this trying to say that the mapping from the timestamp in the input packet to the mixer and the output packet be linear? The implementations considerations section says there is a potential issue with loop detection, but doesn't actually describe the issue, or how satisfying the user invisibility requirement makes it more likely to occur. The document should be explicit about the expected trust model if SRTP is used. I believe it is currently assuming that media from either source would be decrypted at the mixer and re-encrypted towards the receiver(s). The first paragraph in section 6 could be read to imply that the mixer is just forwarding SRTP packets. |
2012-05-08
|
07 | Robert Sparks | [Ballot comment] When considering the clarification for the first point above, consider making the first two paragraphs of section 4.2 clearer as well. CSRC is … [Ballot comment] When considering the clarification for the first point above, consider making the first two paragraphs of section 4.2 clearer as well. CSRC is typo'd as CRSC in a few places. |
2012-05-08
|
07 | Robert Sparks | [Ballot Position Update] New position, Discuss, has been recorded for Robert Sparks |
2012-05-07
|
07 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded for Ronald Bonica |
2012-05-07
|
07 | Martin Stiemerling | [Ballot discuss] Section 4.1., paragraph 3: > When splicing begins, mixer chooses the substitutive RTP stream as > input stream at splicing in … [Ballot discuss] Section 4.1., paragraph 3: > When splicing begins, mixer chooses the substitutive RTP stream as > input stream at splicing in point, and extracts the payload data > (i.e., substitutive content). After that, mixer encapsulates > substitutive content instead of main content as the payload of the > current media stream, and then outputs the current media stream to > receiver. Moreover, mixer may insert the SSRC of substitutive RTP > stream into CSRC list in the current media stream. What happens if the payload of the received substitutive RTP stream is larger than the maximum RTP payload of the outgoing RTP stream? |
2012-05-07
|
07 | Martin Stiemerling | [Ballot comment] General comment: This document is in need of a lot of language improvements, e.g., replacing 'Splicer' with 'the Splicer' all over … [Ballot comment] General comment: This document is in need of a lot of language improvements, e.g., replacing 'Splicer' with 'the Splicer' all over to improve readability. It seems that almost no arcticles have been used. This makes reading the text very, very hard, at least for me as non-native speaker. Section 1., paragraph 4: > So far [SCTE30] and [SCTE35] have standardized MPEG2-TS splicing > running over cable. The introduction of multimedia splicing into > internet requires changes to transport layer, but to date there is no > guideline for how to handle content splicing for RTP sessions > [RFC3550]. Curious to see what the required changes to the transport layer are?! I have not found any change required to the transport layer, e.g., TCP, UDP, DCCP, etc. Section 3., paragraph 4: > When RTP splicing begins, Splicer stops delivering the main content, > instead delivering the substitutive content to RTP receiver for a > period of time, and then resumes the main content when splicing ends. > The methods how Splicer learns when to start and end the splicing is > out of scope for this document. The RTP splicing may happen more > than once in case that substitutive content will be dispersedly > inserted in multiple time slots during the lifetime of the main RTP > stream. Trying to improve the readability by suggesting this: OLD: Splicer stops delivering the main content, NEW: the Splicer stops delivering the main content to the RTP receiver, Section 3., paragraph 7: > Splicer must operate in either unicast or multicast session > environment. Shouldn't this better read "The Splicer must support either unicast delivery or multicast delivery." or should the Splicer be able to support both modes at the same time and not just one at a time. If so, the sentence should read "The Splicer must support unicast delivery or multicast delivery." Section 3., paragraph 11: > Splicer must be backward compatible with RTP/RTCP protocols, and > its associated profiles and extensions to those protocols. For > example, Splicer must be robust to packet loss, network congestion > etc. I do not see what the relationship between "backward compatible with RTP/RTCP protocols " and robust to packet loss, etc is. Section 3., paragraph 15: > Splicer should allow the media source to learn the performance of > the downstream receiver when its content is being passed to RTP > receiver. What does this mean on the protocol level? Is this referring to support RTCP relaying, an out-of-band mechanism, or what? Section 4.1., paragraph 13: > the CSRC list of the current RTP may include SSRC of main RTP > stream; > } > Splicing may occur more than one time during the lifetime of main RTP > stream, this means mixer needs to output main content and > substitutive content in turn with its own SSRC identifier. From > receiver point of view, the only source of the current stream is > mixer wherever the content comes from. The last sentence is a potentially misleading, as the receiver can identify the last mixer wherever the content comes from. Section 4.2., paragraph 2: > According to the description in section 7.3 of [RFC3550], mixer > divides RTCP flow between media source and receiver into two separate > RTCP loops, media source probably has no idea about the situation on > receiver. Hence, mixer can use some mechanisms, allowing media > source to at least some degree to have some knowledge of the > situation on receiver when its content is being passed to receiver. The last sentence is not making any point, other saying that there is something which isn't specified here. Not sure if this sentence is needed and if yes, it should reworded to make clear that there are mechanisms and reference to those. Section 4.2., paragraph 3: > Because splicing is a processing that mixer selects one media stream > from multiple streams but neither mixing nor transcoding them, upon > receiving an RTCP receiver report from downstream receiver, mixer can > forward it to original media source with its SSRC identifier intact > (i.e., the SSRC of downstream receiver). Given that the number of I'm lost by this sentence, as I have difficulties in parsing it. It is too long and needs some re-wording. Section 4.2., paragraph 8: > If the substitutive content comes from local media file storage ( > i.e., mixer can be regarded as the substitutive media source), the > reception reports received from downstream relate to the substitutive > content should be terminated on mixer without any further processing. the reports **must** be terminated, instead of using **should*, on the mixer, if the content is served from a local file. Section 4.4., paragraph 1: > Provided that the substitutive content has somewhat different > characteristics to the main content it replaces (e.g., the more > dynamic content, the higher bandwidth occupation), or substitutive > content may be encoded with different codec and has different > encoding bitrate, some challenge raise to network capacity and > receiver buffer size. A more dynamic content or a higher encoding > bitrate stream might overload the network and possibly exceed the > receiver's media consumption rate, which might flood receiver's > buffer and eventually result in a buffer overflow. Either network > overload or buffer overflow would induce network congestion and > congestion-caused packet loss. overload is quite a generic term. Since you are pointing at causing congestion, it might be good to say that congestion can occur in the network due to sending the content. Section 4.4., paragraph 1: > Upon detection of above three types of RTCP reports during splicing, > mixer will treat them with three different manners as following: This sentence is really hard to parse. Do you mean to say: Section 4.4 > Once mixer learns that congestion is being experienced on its > downstream link by means of above three detection mechanisms, it > should adapt the bitrate of output stream in response to network > congestion. The bitrate adaptation may be determined by a TCP- > friendly bitrate adaptation algorithm specified in [RFC5348], or by a > DCCP congestion control algorithms defined in [RFC5762]. adapting the bitrate depending on the outcome of TCP-friendly rate control or DCCP congestion control might not be an option, if the content requires a certain bitrate. It might be worth mentioning it here that congestion may result in stopping the delivery completely. Section 6., paragraph 1: > If any payload internal security mechanisms (e.g., ISMACryp > [ISMACryp]) are used, only media source and RTP receiver can learn > the security keying material generated by such internal security > mechanism, any middlebox (e.g., mixer) between media source and RTP > receiver can't get such keying material. Only when regular transport > security mechanisms (e.g., SRTP, IPSec, etc) are used, mixer will > process the packets passing through it. COMMENT:A nit: IPSec is not a transport security mechanism. To be even more nitty: IPSec delivery might also block a mixer if the security association is set up between the media source and the RTP receiver. This is similar to payload internal security mechanism. |
2012-05-07
|
07 | Martin Stiemerling | [Ballot Position Update] New position, Discuss, has been recorded for Martin Stiemerling |
2012-05-04
|
07 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Sandra Murphy |
2012-05-04
|
07 | Samuel Weiler | Request for Telechat review by SECDIR is assigned to Sandra Murphy |
2012-05-04
|
07 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2012-05-03
|
07 | Gonzalo Camarillo | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-04-30
|
07 | Barry Leiba | [Ballot comment] Substantive but non-blocking comments; please adopt or respond to these: -- General -- I see from the mailing list discussion that there had … [Ballot comment] Substantive but non-blocking comments; please adopt or respond to these: -- General -- I see from the mailing list discussion that there had been some consideration of using an RTP translator, rather than an RTP mixer. It appears that mixer was chosen more or less by default -- there was a concrete proposal for it, and none for the other. Given that, it might be nice to have a few words (maybe a small section at the end, maybe an appendix, something like that) about the possibility of using an RTP translator, and why using a mixer is better. If the WG considered the issue, others are likely to as well. But feel free to respond, "Yes, it might, but that is not this document." :-) -- Abstract -- You talk about proposing the use of "an existing RTP level middlebox", and you do know what that middlebox is. I suggest saying so. Maybe like this: NEW and analyze whether an RTP mixer (an existing RTP level middlebox) can meet these requirements. Finally, we provide concrete guidelines for how the RTP mixer can work to handle RTP splicing. You might also mention this in the last paragraph of the Introduction. -- Section 4 -- Where is an "RTP mixer" defined? Should there be a reference? I don't see a definition in RFC 3550 -- the term is used there, but not defined. I also suggest expanding SSRC and CSRC on first use. -- Section 4.1 -- I really dislike the odd "pseudo-code" format to illustrate the process. It's already more prose than pseudo-code, and I strongly urge you to re-cast it as normal text. -- Security Considerations -- The first paragraph is a little fluffy about what the issue is. What makes "regular transport security mechanisms" different here... that is, what's the *real* point? Is it that end-to-end encryption makes it impossible for the middlebox to play with the stream, but hop-by-hop encryption allows it? I'd like to see this be clearer about what the conditions are that makes this feasible vs impossible, and then whether there are any security issues involved with allowing a middlebox to replace parts of the stream. (It's possible that there are none, when the trust model in the second paragraph is correct.) ======== Editorial suggestions. No need to respond to these; take them or modify them as you please: -- General -- There are numerous English-language issues with the document, too many to detail with OLD/NEW suggestions. The document would benefit from a pass by a native English speaker to fix the grammar, punctuation, and such, and I strongly suggest such an edit. That said, the document is readable as it is, and these are edits the RFC Editor will make if we don't do it before. (Note that this is a complaint against the WG, not against the editor. WGs should be addressing this sort of issue in their review, and should appoint a co-editor in cases where the primary editor needs help getting the English right.) -- Section 4.4 -- One language thing that I think really does have to be fixed now, for clarity: OLD In practice, during splicing, the real reason to cause congestion usually is the different characteristic of substitutive RTP stream (more dynamic content or higher encoding bitrate) with main RTP stream, and that stream transcoding or thinning on mixer is very inefficient and difficult operation. NEW In practice, the usual real causes of congestion during splicing are the differences in characteristics between the substitutive RTP stream and the main RTP stream -- when the former has more dynamic content or a higher encoding bitrate -- and that stream transcoding or thinning on the mixer is very inefficient and difficult. -- IANA Considerations -- I suggest adding a sentence asking the RFC Editor to remove this section before publication, which is usual practice for empty IANA Considerations sections. |
2012-04-30
|
07 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2012-04-30
|
07 | Gonzalo Camarillo | Placed on agenda for telechat - 2012-05-10 |
2012-04-30
|
07 | Gonzalo Camarillo | State changed to Waiting for AD Go-Ahead from IESG Evaluation |
2012-04-30
|
07 | Gonzalo Camarillo | State changed to IESG Evaluation from Waiting for AD Go-Ahead |
2012-04-30
|
07 | Gonzalo Camarillo | Ballot has been issued |
2012-04-30
|
07 | Gonzalo Camarillo | [Ballot Position Update] New position, Yes, has been recorded for Gonzalo Camarillo |
2012-04-30
|
07 | Gonzalo Camarillo | Ballot writeup was changed |
2012-04-30
|
07 | Gonzalo Camarillo | Created "Approve" ballot |
2012-04-03
|
07 | (System) | State changed to Waiting for AD Go-Ahead from In Last Call |
2012-03-22
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Wassim Haddad |
2012-03-22
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Wassim Haddad |
2012-03-22
|
07 | Amanda Baber | We understand that this document doesn't require any IANA actions. |
2012-03-21
|
07 | Martin Stiemerling | Request for Early review by TSVDIR is assigned to Cullen Jennings |
2012-03-21
|
07 | Martin Stiemerling | Request for Early review by TSVDIR is assigned to Cullen Jennings |
2012-03-20
|
07 | Amy Vezza | Last call sent |
2012-03-20
|
07 | Amy Vezza | State changed to In Last Call from Last Call Requested The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: … State changed to In Last Call from Last Call Requested The following Last Call Announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Subject: Last Call: (Content Splicing for RTP Sessions) to Informational RFC The IESG has received a request from the Audio/Video Transport Extensions WG (avtext) to consider the following document: - 'Content Splicing for RTP Sessions' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo outlines RTP splicing. Splicing is a process that replaces the content of the main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to receiver for a period of time. This memo provides some RTP splicing use cases, then we enumerate a set of requirements and analyze whether an existing RTP level middlebox can meet these requirements, at last we provide concrete guidelines for how the chosen middlebox works to handle RTP splicing. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-for-rtp/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-for-rtp/ballot/ No IPR declarations have been submitted directly on this I-D. |
2012-03-20
|
07 | Gonzalo Camarillo | Last call was requested |
2012-03-20
|
07 | Gonzalo Camarillo | Ballot approval text was generated |
2012-03-20
|
07 | Gonzalo Camarillo | Ballot writeup was generated |
2012-03-20
|
07 | Gonzalo Camarillo | State changed to Last Call Requested from Publication Requested |
2012-03-20
|
07 | Gonzalo Camarillo | Last call announcement was generated |
2012-02-21
|
07 | Amy Vezza | Shepherd writeup for Content Splicing for RTP Sessions (draft-ietf-avtext-splicing-for-rtp-07) requested to be published as Informational RFC. (1.a) Who is the Document Shepherd … Shepherd writeup for Content Splicing for RTP Sessions (draft-ietf-avtext-splicing-for-rtp-07) requested to be published as Informational RFC. (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? Magnus Westerlund is the document shepherd. (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 had okay number of reviews in the WG. There has been no review outside of the WG to my knowledge. No significant concern over the amount of review. (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. (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 and no IPR disclosure has been submitted. (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 was significant amount of discussion around the direction of the approach that is recommended. This resulted in the end a strong consensus and many active WG participants has particpated in that part. (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 the Internet-Drafts Checklist 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? Yes. (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]. Yes, it has a split list. Although that isn't necessary considering it is an informational document. (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? Yes, it is correct. (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? No formal language. (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 memo outlines how to perform RTP splicing. Splicing is a process that replaces the content of the main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to receiver for a period of time. This memo provides some RTP splicing use cases, then we enumerate a set of requirements and analyze whether an existing RTP level middlebox can meet these requirements, at last we provide concrete guidelines for how the chosen middlebox works to handle RTP splicing. Working Group Summary This document has firm WG consensus behind it and has been advequate reviewed. Document Quality The sheperd is unaware of any specific implementation but expect this functionality to be implemented in the field. How well they follow the proposed method is unknown. |
2012-02-21
|
07 | Amy Vezza | Draft added in state Publication Requested |
2012-02-21
|
07 | Amy Vezza | [Note]: 'Magnus Westerlund (magnus.westerlund@ericsson.com) is the document shepherd.' added |
2012-02-20
|
07 | Magnus Westerlund | Publication request sent in by email. Writeup has been added. |
2012-02-20
|
07 | Magnus Westerlund | IETF state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2012-02-20
|
07 | Magnus Westerlund | Changed protocol writeup |
2012-02-19
|
07 | (System) | New version available: draft-ietf-avtext-splicing-for-rtp-07.txt |
2012-02-17
|
07 | Magnus Westerlund | WG last call has ended and all issues raised has been resolved. |
2012-02-17
|
07 | Magnus Westerlund | IETF state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2012-02-17
|
06 | (System) | New version available: draft-ietf-avtext-splicing-for-rtp-06.txt |
2012-02-07
|
05 | (System) | New version available: draft-ietf-avtext-splicing-for-rtp-05.txt |
2011-12-31
|
04 | (System) | New version available: draft-ietf-avtext-splicing-for-rtp-04.txt |
2011-12-23
|
03 | (System) | New version available: draft-ietf-avtext-splicing-for-rtp-03.txt |
2011-12-14
|
07 | Keith Drage | WGLC extended to 23rd December 2011 due to absence of comments on original call |
2011-12-14
|
07 | Keith Drage | Annotation tag Other - see Comment Log set. |
2011-11-16
|
07 | Magnus Westerlund | WG last call started today. Ends 7th of December. |
2011-11-16
|
07 | Magnus Westerlund | IETF state changed to In WG Last Call from WG Document |
2011-11-15
|
02 | (System) | New version available: draft-ietf-avtext-splicing-for-rtp-02.txt |
2011-10-20
|
01 | (System) | New version available: draft-ietf-avtext-splicing-for-rtp-01.txt |
2011-10-08
|
00 | (System) | New version available: draft-ietf-avtext-splicing-for-rtp-00.txt |