Subject: [avtext] Some comments on draft-ietf-avtext-splicing-notification-04

From: Magnus Westerlund <[email-masked]>
Date: Wed, 2 Mar 2016 13:50:23 +0100

Hi,

This are some comments that came out of my review as an IANA expert for 
the RTP Header Extensions and RTCP Control Packet Types, and which of 
some is not related to the IANA expert review role. However, I have 
noted that several of these, issues 1,2,3, and 5, are related to 
protocol clearness as well as correct usage of RTP which are review 
criteria for the RTP header extension registry.

1. Section 1.1 and 3.1:

What the NTP timestamp included in the extensions represent are not 
being sufficiently made clear. I think it must be made clear that the 
NTP timestamp represents the Main RTP senders wall clock timestamp 
corresponding to these splicing in and out points. The main RTP senders 
time base may have nothing with any formal time basis distributed by the 
NTP protocol.

2. Section 3.1:

If the 7 octets splicing-out NTP timestamp is smaller
    than the lower 7 octets splicing-in NTP timestamp, it implies a wrap
    of the 64-bit splicing-out NTP timestamp which will then be
    calculated by the 7 octets splicing-out NTP timestamp plus
    0x100000000.

So I think "smaller" is a underspecified operation here. Although I 
think loading the 7 octets into one 64 bit unsigned integer respectively 
and perform a lesser than comparison will actually work.

3. Section 3.1:

This section is not clear on what is the data part of the header 
extension format. As it is not the header extension that can determine 
if there will be usage of one-byte vs two-byte format that will be used, 
this needs to be defined in a more un

4. Section 3.2:
The RTCP splicing notification message can be appended to RTCP SR the
    main RTP sender generates in compound RTCP packets, and hence follows
    the compound RTCP rules defined in Section 6.1 in [RFC3550].

I think the use of "append to RTCP SR" is unfortunate. I believe what 
would be the right messages is to say that the splicing notification 
messages is included in the same RTCP compound packet as the RTCP SR for 
the main RTP stream. Using the SSRC values to relate the two. This is 
important because there should be no formal requirement on ordering 
between individual RTCP packets within a compound packet.

5. Section 3.2:

This format is
       similar to the RTCP Sender Report (Section 6.4.1 of [RFC3550])

Why is it only similar and not the same as in RFC  3550?

6. Section 3.2:

    If the use of non-compound RTCP [RFC5506] was previously negotiated
    between the sender and the splicer, the RTCP splicing notification
    message may be sent as non-compound RTCP packets.

I wonder over this, I wonder if this RTCP packet type really should be 
sent in an RTCP non-compound packet without the corresponding RTCP SR 
packet? The reason I state this is that the RTP main sender has to use 
SR/RR report block LSR field to determine which is the latest received 
RTCP SR packet for the SSRC in the splicing RTCP packet. And due to 
timing of RTCP packet transmission that can be old information.  Thus, 
the splicer can operate on RTP to NTP Timestamps that are not current. 
Thus, I think it would be a recommendation to include the RTCP SR with 
the splicing packet. It can still be a non-compound as one could leave 
out the SDES CNAME items.

7. Section 6.2:

    Only codecs that are supported both by the main RTP stream and the
    substitutive RTP stream could be negotiated with SDP O/A. And the
    splicer MUST choose the same codec for both of these two streams.

So this payload type restriction is in my view in the wrong place and 
not clear enough. So, to be able to splice into one consistent outgoing 
stream there is a basic requirement that the RTP Payload Types used are 
having the same clock rate, otherwise RFC 7160 applies, as uncertainty 
about how RTP maps to NTP and splicing appears to be a bad mix.

Further if one is going to express this in this more restrictive way of 
demanding the same codes, then I do wonder if one actually don't need to 
go as far as saying that the same payload type configurations needs to 
be possible to us in both main and substitute streams.

8. Section 7:

I find a significant short coming in this security consideration. That 
is the failure to discuss the importance for the splicer to be able to 
trust the splicing interval information from the main RTP sender. This 
information really should be authenticated and integrity protected 
between the main RTP sender and the splicer.

Thus, I am quite worried about this paragraph:

    Since the mechanism introduced in this document is not dependent on
    any RTP payload-level hints for finding the splicing in and out
    points, Secure Real-Time Transport Protocol (SRTP) [3711] can be used
    to provide confidentiality of the RTP payload while leaving the RTP
    header in the clear so that the splicer can still carry out splicing
    without keying materials. However, for a malicious endpoint without
    the key, it can observe the splicing time in the RTP header, and it
    can intercept the substitutive content and even replace it with a
    different one if the substitutive stream does not use any security
    like SRTP and the splicer does not authenticate the main and
    substitutive content sources.

In the end it hints towards the need for authentication of the streams. 
But that really should be worded in a stronger way as a requirement for 
security.

I do understand that this is really a case where two layers of security 
would be good. One between the main and substitute sender and the 
intended receiver, and an outer layer for sender to splicer. However, I 
don't argue that such a solution needs to be created. I think having the 
splicer as a trusted entity is more likely to be a reasonable deployment 
model.

I do note that splicing do have the issue from key-management 
perspective that both main and substitute sender needs to use the same 
key if the security is from sender to receiver, rather than splicer to 
receiver.

In the end I think what needs to be changed are:

A. Clarify need for source authentication and integrity verification
B. The potential issues with having main and substitute stream sender 
use the same keys end-to-end for the same SSRC. This can be problematic 
from two-time pad perspective.
C. Likely be clear that a security model with a trusted splicer is the 
one that are easiest to realize without two layer security.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 3 Mar 2016 10:51:10 +0000

Hi Magnus,

Thank you so much for your careful review and valuable comments. It helps us to further improve the document quality.
Please see my replies inline.

BR,
Rachel

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Wednesday, March 02, 2016 8:50 PM
> To: [email-masked]; Ben Campbell;
> [email-masked]
> Subject: Some comments on draft-ietf-avtext-splicing-notification-04
> 
> Hi,
> 
> This are some comments that came out of my review as an IANA expert for the
> RTP Header Extensions and RTCP Control Packet Types, and which of some is
> not related to the IANA expert review role. However, I have noted that several
> of these, issues 1,2,3, and 5, are related to protocol clearness as well as
> correct usage of RTP which are review criteria for the RTP header extension
> registry.
> 
> 
> 1. Section 1.1 and 3.1:
> 
> What the NTP timestamp included in the extensions represent are not being
> sufficiently made clear. I think it must be made clear that the NTP timestamp
> represents the Main RTP senders wall clock timestamp corresponding to these
> splicing in and out points. The main RTP senders time base may have nothing
> with any formal time basis distributed by the NTP protocol.

[Rachel]: You're right. So how about changing the "splicing interval" in section 1.1 to the following:

"
Splicing Interval:

The NTP-format timestamps, representing the main RTP sender wallclock time, for the Splicing-In point and Splicing-Out point per [RFC6828] allowing the splicer to know when to start and end the RTP splicing.
"
As for the ones in section 3.1, is it okay to just keep the "NTP-format timestamps", since we clarify it in the terminology?

> So I think "smaller" is a underspecified operation here. Although I think loading
> the 7 octets into one 64 bit unsigned integer respectively and perform a lesser
> than comparison will actually work.

[Rachel]: So how about expressing it like this

OLD
"
The top 8 bits of the splicing-out NTP timestamp are inferred from the top 8 bits of the splicing-in NTP timestamp. This is unambiguous, under the assumption that the splicing-out time is after the splicing-in time, and the splicing interval is less than 2^25 seconds. If the 7 octets splicing-out NTP timestamp is smaller than the lower 7 octets splicing-in NTP timestamp, it implies a wrap of the 64-bit splicing-out NTP timestamp which will then be calculated by the 7 octets splicing-out NTP timestamp plus 0x100000000. Otherwise, the top 8 octets of splicing-out NTP timestamp is equal to the top 8 octets of splicing-in NTP timestamp.
"

NEW
"
The top 8 bits of the splicing-out NTP timestamp are inferred from the top 8 bits of the splicing-in NTP timestamp. This is unambiguous, under the assumption that the splicing-out time is after the splicing-in time, and the splicing interval is less than 2^25 seconds. Therefore, if the 7 octets splicing-out NTP-format timestamp is smaller than 64-bit splicing-out NTP-format timestamp modulo 56 bits range, it implies a wrap of the 64-bit splicing-out NTP-format timestamp which will then be calculated by the 7 octets splicing-out NTP timestamp plus 2^64. Otherwise, the top 8 octets of splicing-out NTP timestamp is equal to the top 8 octets of splicing-in NTP timestamp.
"

> 
> 3. Section 3.1:
> 
> This section is not clear on what is the data part of the header extension
> format. As it is not the header extension that can determine if there will be
> usage of one-byte vs two-byte format that will be used, this needs to be
> defined in a more un

[Rachel]: I don't understand this. The editing seems unfinished. The splicing RTP header extension uses one-byte format with the fixed bit pattern 0xBEDE.

> I think the use of "append to RTCP SR" is unfortunate. I believe what would be
> the right messages is to say that the splicing notification messages is included
> in the same RTCP compound packet as the RTCP SR for the main RTP stream.
> Using the SSRC values to relate the two. This is important because there should
> be no formal requirement on ordering between individual RTCP packets within
> a compound packet.

[Rachel]: Good point. How about changing to 

"
The RTCP splicing notification message can be included in the RTCP compound packet together with RTCP SR generated at the main RTP sender, and hence follows the compound RTCP rules defined in Section 6.1 in [RFC3550].
"

> Why is it only similar and not the same as in RFC  3550?

[Rachel]: Actually it's the same. Bad wording:(.

> I wonder over this, I wonder if this RTCP packet type really should be sent in an
> RTCP non-compound packet without the corresponding RTCP SR packet? The
> reason I state this is that the RTP main sender has to use SR/RR report block
> LSR field to determine which is the latest received RTCP SR packet for the SSRC
> in the splicing RTCP packet. And due to timing of RTCP packet transmission that
> can be old information.  Thus, the splicer can operate on RTP to NTP
> Timestamps that are not current.
> Thus, I think it would be a recommendation to include the RTCP SR with the
> splicing packet. It can still be a non-compound as one could leave out the SDES
> CNAME items.

[Rachel]: Maybe I got it wrong. But are you saying that the accuracy of mapping RTP timestamp to NTP timestamp, which should be deduced by the information in the RTCP SR that should be as close as the splicing starts? But the RTCP splicing message is sent far ahead of the splicing happens, and should be sent more than once to increase robustness. For example, may be several RTTs ahead. So in a non-compound case, it is possible that a RTCP SR will be sent after a RTCP splicing message, hence it seems no meaning to include RTCP SR with RTCP splicing messages. 

> So this payload type restriction is in my view in the wrong place and not clear
> enough. So, to be able to splice into one consistent outgoing stream there is a
> basic requirement that the RTP Payload Types used are having the same clock
> rate, otherwise RFC 7160 applies, as uncertainty about how RTP maps to NTP
> and splicing appears to be a bad mix.

[Rachel]: Actually, this has been described in Section 2, 3rd paragraph. It says

"
To ensure the Splicing Interval is valid for both the main RTP sender and the substitutive RTP sender, the two senders MUST share a common reference clock so that the splicer can achieve accurate splicing. The requirements for the common reference clock (e.g. resolution, skew) depend on the codec used by the media content.
"

> 
> Further if one is going to express this in this more restrictive way of demanding
> the same codes, then I do wonder if one actually don't need to go as far as
> saying that the same payload type configurations needs to be possible to us in
> both main and substitute streams.

[Rachel]: So you're suggesting that we delete this sentence?

> 
> 8. Section 7:
> 
> I find a significant short coming in this security consideration. That is the failure
> to discuss the importance for the splicer to be able to trust the splicing interval
> information from the main RTP sender. This information really should be
> authenticated and integrity protected between the main RTP sender and the
> splicer.
> 
> I do understand that this is really a case where two layers of security would be
> good. One between the main and substitute sender and the intended receiver,
> and an outer layer for sender to splicer. However, I don't argue that such a
> solution needs to be created. I think having the splicer as a trusted entity is
> more likely to be a reasonable deployment model.

[Rachel]: Okay. How about Add a new paragraph after the 3rd paragraph in Section 7?

"
To avoid above security issue, the authentication of the main and substitutive content sources in the splicer SHOULD be considered. However, separating the security mechanism between senders and the splicer from the end-to-end one may complicate the whole system deployment. In such a case, having the splicer as a trusted entity is likely to be a reasonable deployment model.
"

> 
> I do note that splicing do have the issue from key-management perspective
> that both main and substitute sender needs to use the same key if the security
> is from sender to receiver, rather than splicer to receiver.

[Rachel]: Yes. I plan to add a sentence in the paragraph 3 like this:

OLD
"
Since the mechanism introduced in this document is not dependent on any RTP payload-level hints for finding the splicing in and out points, Secure Real-Time Transport Protocol (SRTP) [RFC3711] can be used to provide confidentiality of the RTP payload while leaving the RTP header in the clear so that the splicer can still carry out splicing without keying materials.
" 

NEW
"
Since the mechanism introduced in this document is not dependent on any RTP payload-level hints for finding the splicing in and out points, Secure Real-Time Transport Protocol (SRTP) [RFC3711] can be used to provide confidentiality of the RTP payload while leaving the RTP header in the clear so that the splicer can still carry out splicing without keying materials. This implies that either the main and substitutive sender use the same SRTP key, or the splicer decrypts and re-encrypts with a single key.
"

> A. Clarify need for source authentication and integrity verification B. The
> potential issues with having main and substitute stream sender use the same
> keys end-to-end for the same SSRC. This can be problematic from two-time pad
> perspective.
> C. Likely be clear that a security model with a trusted splicer is the one that are
> easiest to realize without two layer security.

[Rachel]: See above proposed modifications.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 18 Mar 2016 13:39:09 +0100

Hi,

Sorry for being a bit late in responding on this. I hope you have time 
to submit this before the cut-off on Monday.

Den 2016-03-03 kl. 11:51, skrev Huangyihong (Rachel):
> Hi Magnus,
>
> Thank you so much for your careful review and valuable comments. It
> helps us to further improve the document quality. Please see my
> replies inline.
>
> BR, Rachel
>
>
>> -----Original Message----- From: Magnus Westerlund
>> [mailto:[email-masked]] Sent: Wednesday, March 02,
>> 2016 8:50 PM To: [email-masked]; Ben Campbell;
>> [email-masked] Subject: Some
>> comments on draft-ietf-avtext-splicing-notification-04
>>
>> Hi,
>>
>> This are some comments that came out of my review as an IANA expert
>> for the RTP Header Extensions and RTCP Control Packet Types, and
>> which of some is not related to the IANA expert review role.
>> However, I have noted that several of these, issues 1,2,3, and 5,
>> are related to protocol clearness as well as correct usage of RTP
>> which are review criteria for the RTP header extension registry.
>>
>>
>> 1. Section 1.1 and 3.1:
>>
>> being sufficiently made clear. I think it must be made clear that
>> the NTP timestamp represents the Main RTP senders wall clock
>> timestamp corresponding to these splicing in and out points. The
>> main RTP senders time base may have nothing with any formal time
>> basis distributed by the NTP protocol.
>
> " Splicing Interval:
> The NTP-format timestamps, representing the main RTP sender wallclock
> time, for the Splicing-In point and Splicing-Out point per [RFC6828]
> allowing the splicer to know when to start and end the RTP splicing.
> " As for the ones in section 3.1, is it okay to just keep the
> "NTP-format timestamps", since we clarify it in the terminology?
>

Yes, I think so.

>>
>> 2. Section 3.1:
>>
>> If the 7 octets splicing-out NTP timestamp is smaller than the
>> lower 7 octets splicing-in NTP timestamp, it implies a wrap of the
>> 64-bit splicing-out NTP timestamp which will then be calculated by
>> the 7 octets splicing-out NTP timestamp plus 0x100000000.
>>
>> think loading the 7 octets into one 64 bit unsigned integer
>> respectively and perform a lesser than comparison will actually
>> work.
>
> OLD " The top 8 bits of the splicing-out NTP timestamp are inferred
> from the top 8 bits of the splicing-in NTP timestamp. This is
> unambiguous, under the assumption that the splicing-out time is after
> the splicing-in time, and the splicing interval is less than 2^25
> seconds. If the 7 octets splicing-out NTP timestamp is smaller than
> the lower 7 octets splicing-in NTP timestamp, it implies a wrap of
> the 64-bit splicing-out NTP timestamp which will then be calculated
> by the 7 octets splicing-out NTP timestamp plus 0x100000000.
> Otherwise, the top 8 octets of splicing-out NTP timestamp is equal to
> the top 8 octets of splicing-in NTP timestamp. "
>
> NEW " The top 8 bits of the splicing-out NTP timestamp are inferred
> from the top 8 bits of the splicing-in NTP timestamp. This is
> unambiguous, under the assumption that the splicing-out time is after
> the splicing-in time, and the splicing interval is less than 2^25
> seconds. Therefore, if the 7 octets splicing-out NTP-format timestamp
> is smaller than 64-bit splicing-out NTP-format timestamp modulo 56
> bits range, it implies a wrap of the 64-bit splicing-out NTP-format
> timestamp which will then be calculated by the 7 octets splicing-out
> NTP timestamp plus 2^64. Otherwise, the top 8 octets of splicing-out
> NTP timestamp is equal to the top 8 octets of splicing-in NTP
> timestamp. "

Hmm, this appears to be wrong about the wrapping. The wrapping that is 
the concern here that when the 56-bit value of the out is smaller than 
the 56-bit value of the splicing in point then a wrap of the 56-bit 
value has happened which will result in that one need to add 0x01 to the 
top 8-bit value copied from the splicing in point to the splicing out 
top 8-bit value.

>> extension format. As it is not the header extension that can
>> determine if there will be usage of one-byte vs two-byte format
>> that will be used, this needs to be defined in a more un
>
> [Rachel]: I don't understand this. The editing seems unfinished. The
> splicing RTP header extension uses one-byte format with the fixed bit
> pattern 0xBEDE.

Sorry, what is missing is: The definition of the data field need to be 
done in a way that is agnostic to if 1 or 2-byte headers are being used 
in the header extension.

>
>>
>> 4. Section 3.2: The RTCP splicing notification message can be
>> appended to RTCP SR the main RTP sender generates in compound RTCP
>> packets, and hence follows the compound RTCP rules defined in
>> Section 6.1 in [RFC3550].
>>
>> I think the use of "append to RTCP SR" is unfortunate. I believe
>> what would be the right messages is to say that the splicing
>> notification messages is included in the same RTCP compound packet
>> as the RTCP SR for the main RTP stream. Using the SSRC values to
>> relate the two. This is important because there should be no formal
>> requirement on ordering between individual RTCP packets within a
>> compound packet.
>
> " The RTCP splicing notification message can be included in the RTCP
> compound packet together with RTCP SR generated at the main RTP
> sender, and hence follows the compound RTCP rules defined in Section
> 6.1 in [RFC3550]. "
>

Yes, that would work.

I realized now that you haven't expanded RTCP SR on its first use. 
Please do.

>>
>>
>> 5. Section 3.2:
>>
>> This format is similar to the RTCP Sender Report (Section 6.4.1 of
>> [RFC3550])
>>
>> If the use of non-compound RTCP [RFC5506] was previously
>> negotiated between the sender and the splicer, the RTCP splicing
>> notification message may be sent as non-compound RTCP packets.
>>
>> I wonder over this, I wonder if this RTCP packet type really should
>> be sent in an RTCP non-compound packet without the corresponding
>> RTCP SR packet? The reason I state this is that the RTP main sender
>> has to use SR/RR report block LSR field to determine which is the
>> latest received RTCP SR packet for the SSRC in the splicing RTCP
>> packet. And due to timing of RTCP packet transmission that can be
>> old information.  Thus, the splicer can operate on RTP to NTP
>> Timestamps that are not current. Thus, I think it would be a
>> recommendation to include the RTCP SR with the splicing packet. It
>> can still be a non-compound as one could leave out the SDES CNAME
>> items.
>
> [Rachel]: Maybe I got it wrong. But are you saying that the accuracy
> of mapping RTP timestamp to NTP timestamp, which should be deduced by
> the information in the RTCP SR that should be as close as the
> splicing starts? But the RTCP splicing message is sent far ahead of
> the splicing happens, and should be sent more than once to increase
> robustness. For example, may be several RTTs ahead. So in a
> non-compound case, it is possible that a RTCP SR will be sent after a
> RTCP splicing message, hence it seems no meaning to include RTCP SR
> with RTCP splicing messages.

So, yes things will work as long as the RTP to NTP mapping the in the 
splicer is correct. However, in some cases situations can occur that 
will modify the RTP to NTP mapping between the a previous sending of the 
Splicing message and the actual splicing start or stop.

So when does the RTP to NTP mapping change?

1. If the Payload Type changes and the clock rate changes and the system 
does not follow the recommendations in RFC 7160. However this is likely 
the least likely reason.

2. The more common reason will be clock drift. If the system wall clock 
progresses at a rate that is not matching the RTP timestamp rate, then 
periodically adjustments may occur. Thus changing the RTP to NTP mapping.

The issue with changing mapping is that one needs to know if it is the 
RTP timeline or the NTP wall clock that is the most relevant for when 
the splicing should occur. If it is the RTP one, due to that a specific 
amount of media samples needs to have been processed. In other words the 
boundary in the actual content is known and determines when the splice 
should happen. This I find likely for pre-recorded content.

But, I think I actually misrepresented the issue. I agree that it is not 
necessary that one have the SR and splicing messages in the same 
compound or reduced size RTCP packet. It is that one acknowledge what 
occurs if one do receive or not receive an update if the mapping has 
been updated between initial splicing information transmission and the 
implementation.

Different outcomes occur depending on which timescale is the primary one 
for when the splicing should occur.

If RTP timeline is the important. Then an update of the RTP to NTP 
mapping requires an updated NTP formated splicing point. In this case 
the best that one can do is send both Splicing info and RTCP SR. You 
need both to correctly splice.

If the NTP timeline is the one that matters, then an updated RTP to NTP 
mapping only needs the new values in the RTCP SR, no new splicing 
message is needed.

To conclude, what might be needed is actually rather a comment on that 
updated information may occur, and in certain cases both the splicing 
interval and the RTCP SR is needed to correctly splice.

>> So this payload type restriction is in my view in the wrong place
>> and not clear enough. So, to be able to splice into one consistent
>> outgoing stream there is a basic requirement that the RTP Payload
>> Types used are having the same clock rate, otherwise RFC 7160
>> applies, as uncertainty about how RTP maps to NTP and splicing
>> appears to be a bad mix.
>
> " To ensure the Splicing Interval is valid for both the main RTP
> sender and the substitutive RTP sender, the two senders MUST share a
> common reference clock so that the splicer can achieve accurate
> splicing. The requirements for the common reference clock (e.g.
> resolution, skew) depend on the codec used by the media content. "
>
>>
>> Further if one is going to express this in this more restrictive
>> way of demanding the same codes, then I do wonder if one actually
>> don't need to go as far as saying that the same payload type
>> configurations needs to be possible to us in both main and
>> substitute streams.
>

Yes, the section you quote above already have a restriction using RFC 
2119 terms. Isn't that sufficient?

>
>>
>> 8. Section 7:
>>
>> I find a significant short coming in this security consideration.
>> That is the failure to discuss the importance for the splicer to be
>> able to trust the splicing interval information from the main RTP
>> sender. This information really should be authenticated and
>> integrity protected between the main RTP sender and the splicer.
>>
>> Since the mechanism introduced in this document is not dependent
>> on any RTP payload-level hints for finding the splicing in and out
>> points, Secure Real-Time Transport Protocol (SRTP) [3711] can be
>> used to provide confidentiality of the RTP payload while leaving
>> the RTP header in the clear so that the splicer can still carry out
>> splicing without keying materials. However, for a malicious
>> endpoint without the key, it can observe the splicing time in the
>> RTP header, and it can intercept the substitutive content and even
>> replace it with a different one if the substitutive stream does not
>> use any security like SRTP and the splicer does not authenticate
>> the main and substitutive content sources.
>>
>> In the end it hints towards the need for authentication of the
>> streams. But that really should be worded in a stronger way as a
>> requirement for security.
>>
>> I do understand that this is really a case where two layers of
>> security would be good. One between the main and substitute sender
>> and the intended receiver, and an outer layer for sender to
>> splicer. However, I don't argue that such a solution needs to be
>> created. I think having the splicer as a trusted entity is more
>> likely to be a reasonable deployment model.
>
>
> " To avoid above security issue, the authentication of the main and
> substitutive content sources in the splicer SHOULD be considered.
> However, separating the security mechanism between senders and the
> splicer from the end-to-end one may complicate the whole system
> deployment. In such a case, having the splicer as a trusted entity is
> likely to be a reasonable deployment model. "

No, I don't think this addresses the issue. The second paragraph already 
describes the trust model, of the trusted splicer. Especially as no 
alternative do yet exist. Although PERC WG exists and working on a model 
with end-to-end confidentiality, which could possibly work. That is not 
a great match either for what I think are the security requirements for 
services that uses splicing.

I think what needs to occur is to rewrite the third paragraph from the 
perspective that the splicer is trusted. Especially as the stream the 
splicer forwards will not match the received one from a perspective of 
number of packets and bytes, thus requiring RTCP changes. This is why a 
translator or mixer model is required. Thus, the packet forwarded from 
the splicer to the receiver will not be consistent with either the 
original or the substitution stream. For the authentication and 
integrity protection to not blow up the SRTP keys will be needed. A 
division of the roles of integrity versus confidentiality and you are 
back into PERC territory.

Thus, the discussion of header extension encryption is mote. Rather 
discuss that the splicer should use authenticated and integrity 
protected streams to prevent third parties from controlling the splicing 
as well as the substitution content.

>> perspective that both main and substitute sender needs to use the
>> same key if the security is from sender to receiver, rather than
>> splicer to receiver.
>
> OLD " Since the mechanism introduced in this document is not
> dependent on any RTP payload-level hints for finding the splicing in
> and out points, Secure Real-Time Transport Protocol (SRTP) [RFC3711]
> can be used to provide confidentiality of the RTP payload while
> leaving the RTP header in the clear so that the splicer can still
> carry out splicing without keying materials. "
>
> NEW " Since the mechanism introduced in this document is not
> dependent on any RTP payload-level hints for finding the splicing in
> and out points, Secure Real-Time Transport Protocol (SRTP) [RFC3711]
> can be used to provide confidentiality of the RTP payload while
> leaving the RTP header in the clear so that the splicer can still
> carry out splicing without keying materials. This implies that either
> the main and substitutive sender use the same SRTP key, or the
> splicer decrypts and re-encrypts with a single key. "
>

As I said above due to the SRTP keys for confidentiality and integrity 
are coming from a common master key, it is not possible to define a 
solution as indicated by the new text above.

I am sorry if I mislead you into the two layer security solution. It is 
a possibility, but require a lot of spec work. Because PERC will most 
likely not be sufficient for this usage.

Cheers

Magnus Westerlund

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Mon, 21 Mar 2016 10:15:29 +0000

Hi Magnus,

Thanks for the response. I haven't checked the mail last weekend. Hope I can still have time to submit it^^. Please see inline.

BR,
Rachel

> Sent: Friday, March 18, 2016 8:39 PM
> To: Huangyihong (Rachel); [email-masked]; Ben Campbell;
> Subject: Re: Some comments on draft-ietf-avtext-splicing-notification-04
> 
> Hi,
> 
> Sorry for being a bit late in responding on this. I hope you have time to submit
> this before the cut-off on Monday.
> 
> >> However, I have noted that several of these, issues 1,2,3, and 5, are
> >> related to protocol clearness as well as correct usage of RTP which
> >> are review criteria for the RTP header extension registry.
> >>
> >>
> >> 1. Section 1.1 and 3.1:
> >>
> >> corresponding to these splicing in and out points. The main RTP
> >> senders time base may have nothing with any formal time basis
> >> distributed by the NTP protocol.
> >
> >> If the 7 octets splicing-out NTP timestamp is smaller than the lower
> >> 7 octets splicing-in NTP timestamp, it implies a wrap of the 64-bit
> >> splicing-out NTP timestamp which will then be calculated by the 7
> >> octets splicing-out NTP timestamp plus 0x100000000.
> >>
> >> respectively and perform a lesser than comparison will actually work.
> >
> > the lower 7 octets splicing-in NTP timestamp, it implies a wrap of the
> > 64-bit splicing-out NTP timestamp which will then be calculated by the
> > 7 octets splicing-out NTP timestamp plus 0x100000000.
> Hmm, this appears to be wrong about the wrapping. The wrapping that is the
> concern here that when the 56-bit value of the out is smaller than the 56-bit
> value of the splicing in point then a wrap of the 56-bit value has happened
> which will result in that one need to add 0x01 to the top 8-bit value copied from
> the splicing in point to the splicing out top 8-bit value.

[Rachel]: You're right. The previous proposal is completely messed up. Here's the new proposal:

"
The top 8 bits of the splicing-out NTP timestamp are inferred
from the top 8 bits of the splicing-in NTP timestamp. This is
unambiguous, under the assumption that the splicing-out time is after
the splicing-in time, and the splicing interval is less than 2^25
seconds. Therefore, if the 7 octets splicing-out NTP-format timestamp
is smaller than the value of 7 low octets splicing-out NTP-format, it implies a wrap of the 56-bit splicing-out NTP-format	
timestamp which means the top 8-bit value of the 64-bit splicing-out is equal to the top 8-bit value of splicing-in NTP
Timestamp plus 0x01. Otherwise, the top 8 bits of splicing-out
NTP timestamp is equal to the top 8 bits of splicing-in NTP
Timestamp.
"
> >> determine if there will be usage of one-byte vs two-byte format that
> >> will be used, this needs to be defined in a more un
> >
> Sorry, what is missing is: The definition of the data field need to be done in a
> way that is agnostic to if 1 or 2-byte headers are being used in the header
> extension.
>

[Rachel]: I don't understand why should this extension to be agnostic for extension header types. There's no such limitation in [RFC5285] if I read it correctly. And based on [RFC5285], it says:

"
   There are two variants of the extension: one-byte and two-byte
   headers.  Since it is expected that (a) the number of extensions in
   any given RTP session is small and (b) the extensions themselves are
   small, the one-byte header form is preferred and MUST be supported by
   all receivers.  A stream MUST contain only one-byte or two-byte
   headers: they MUST NOT be mixed within a stream.  Transmitters SHOULD
   NOT use the two-byte form when all extensions are small enough for
   the one-byte header form.
"

For splicing extension, it can be classified into a) case. That's why we uses one-byte header, and it is preferred and mandated by receivers. So I can't imagine any other cases to use 2-byte header. And by the way, [RFC6051] also only defines one-byte header.
 
> I realized now that you haven't expanded RTCP SR on its first use.

[Rachel]: Will do.

> interval and the RTCP SR is needed to correctly splice.

[Rachel]: Okay. I get your point. So how about adding some texts as following in Section 3.2, the last 2nd paragraph?

"
In cases of the mapping from RTP timestamp to NTP timestamp changes, e.g., clock drift happening before the splicing event, it may be required to send RTCP SR or even updated Splicing Interval information timely to update the timestamp mapping for accurate splicing.
"

> as well as the substitution content.

[Rachel]: Here's my proposal to rewrite 3rd paragraph to discuss the authentication between splicer and receiver. Is it what you're looking for?
"
Since splicer works as a trusted entity, any RTP-level or outside security mechanism, such IPsec[RFC4301] or Datagram Transport Layer Security [RFC6347], will use a security association between the splicer and the receiver. When using the Secure Real-Time Transport Protocol (SRTP) [RFC3711], the splicer could be provisioned with the same security association as the main RTP sender.
"

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Mon, 21 Mar 2016 13:52:05 +0000

Hi Magnus,

There're still some typos to be fixed in the first answer:

"
Therefore, if the 7 octets splicing-out NTP-format timestamp
is smaller than the value of 7 low octets splicing-out NTP-format,...
"

Should be 

" Therefore, if the value of 7 octets splicing-out NTP-format timestamp
is smaller than the value of 7 lower octets splicing-in NTP-format,..."

Apologize for my carelessness.

BR
Rachel

-----邮件原件-----
发件人: Huangyihong (Rachel) 
发送时间: 2016年3月21日 18:15
收件人: Magnus Westerlund; [email-masked]; Ben Campbell; [email-masked]
主题: RE: Some comments on draft-ietf-avtext-splicing-notification-04

Hi Magnus,

BR,
Rachel

> Subject: Re: Some comments on 
> draft-ietf-avtext-splicing-notification-04
> 
> Hi,
> 
> > The NTP-format timestamps, representing the main RTP sender 
> > wallclock time, for the Splicing-In point and Splicing-Out point per 
> > [RFC6828] allowing the splicer to know when to start and end the RTP splicing.
> >> lower
> > unambiguous, under the assumption that the splicing-out time is 
> > after the splicing-in time, and the splicing interval is less than 
> > 2^25 seconds. If the 7 octets splicing-out NTP timestamp is smaller 
> > calculated by the
> > Otherwise, the top 8 octets of splicing-out NTP timestamp is equal 
> > to the top 8 octets of splicing-in NTP timestamp. "
> >
> > unambiguous, under the assumption that the splicing-out time is 
> > after the splicing-in time, and the splicing interval is less than 
> > 2^25 seconds. Therefore, if the 7 octets splicing-out NTP-format 
> > timestamp is smaller than 64-bit splicing-out NTP-format timestamp 
> > modulo 56 bits range, it implies a wrap of the 64-bit splicing-out 
> > NTP-format timestamp which will then be calculated by the 7 octets 
> > splicing-out NTP timestamp plus 2^64. Otherwise, the top 8 octets of 
> > splicing-out NTP timestamp is equal to the top 8 octets of 
> > splicing-in NTP timestamp. "
> 
> value has happened which will result in that one need to add 0x01 to 
> the top 8-bit value copied from the splicing in point to the splicing out top 8-bit value.

"
The top 8 bits of the splicing-out NTP timestamp are inferred from the top 8 bits of the splicing-in NTP timestamp. This is unambiguous, under the assumption that the splicing-out time is after the splicing-in time, and the splicing interval is less than 2^25 seconds. Therefore, if the 7 octets splicing-out NTP-format timestamp
is smaller than the value of 7 low octets splicing-out NTP-format, it implies a wrap of the 56-bit splicing-out NTP-format	
timestamp which means the top 8-bit value of the 64-bit splicing-out is equal to the top 8-bit value of splicing-in NTP Timestamp plus 0x01. Otherwise, the top 8 bits of splicing-out NTP timestamp is equal to the top 8 bits of splicing-in NTP Timestamp.
"
> > splicing RTP header extension uses one-byte format with the fixed 
> > bit pattern 0xBEDE.
> 
> done in a way that is agnostic to if 1 or 2-byte headers are being 
> used in the header extension.
>

"

[Rachel]: Will do.

> > of mapping RTP timestamp to NTP timestamp, which should be deduced 
> > by the information in the RTCP SR that should be as close as the 
> > non-compound case, it is possible that a RTCP SR will be sent after 
> > a RTCP splicing message, hence it seems no meaning to include RTCP 
> > SR with RTCP splicing messages.
> 
> will modify the RTP to NTP mapping between the a previous sending of 
> the Splicing message and the actual splicing start or stop.
> 
> 1. If the Payload Type changes and the clock rate changes and the 
> system does not follow the recommendations in RFC 7160. However this 
> is likely the least likely reason.
> 
> 2. The more common reason will be clock drift. If the system wall 
> clock progresses at a rate that is not matching the RTP timestamp 
> rate, then periodically adjustments may occur. Thus changing the RTP to NTP mapping.
> 
> the splicing should occur. If it is the RTP one, due to that a 
> specific amount of media samples needs to have been processed. In 
> other words the boundary in the actual content is known and determines 
> when the splice should happen. This I find likely for pre-recorded content.
> 
> But, I think I actually misrepresented the issue. I agree that it is 
> not necessary that one have the SR and splicing messages in the same 
> Different outcomes occur depending on which timescale is the primary 
> one for when the splicing should occur.
> 
> If the NTP timeline is the one that matters, then an updated RTP to 
> NTP mapping only needs the new values in the RTCP SR, no new splicing 
> message is needed.
> 

"

> > deployment. In such a case, having the splicer as a trusted entity 
> > is likely to be a reasonable deployment model. "
> 
> No, I don't think this addresses the issue. The second paragraph 
> already describes the trust model, of the trusted splicer. Especially 
> as no alternative do yet exist. Although PERC WG exists and working on 
> a model with end-to-end confidentiality, which could possibly work. 
> That is not a great match either for what I think are the security 
> requirements for services that uses splicing.
> 
> number of packets and bytes, thus requiring RTCP changes. This is why 
> a translator or mixer model is required. Thus, the packet forwarded 
> from the splicer to the receiver will not be consistent with either 
> the original or the substitution stream. For the authentication and 
> protected streams to prevent third parties from controlling the 
> splicing as well as the substitution content.

> > carry out splicing without keying materials. This implies that 
> > either the main and substitutive sender use the same SRTP key, or 
> > the splicer decrypts and re-encrypts with a single key. "
> >
> 
> I am sorry if I mislead you into the two layer security solution. It 
> is a possibility, but require a lot of spec work. Because PERC will 
> most likely not be sufficient for this usage.
> 
> 
> Cheers
> 
> 
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 Mar 2016 15:27:49 +0100

Hi,

Please see inline. I have removed issues that I think are all fine and
you can simply incorporate them. From my perspective, I think it is best 
that you submit an update prior to the dead-line, then we all can review 
the changes prior to the meeting. And if any changes are needed, you can 
update in 2 weeks time.

Please see inline.

Den 2016-03-21 kl. 11:15, skrev Huangyihong (Rachel):
>> [mailto:[email-masked]] Sent: Friday, March 18,
>> 2016 8:39 PM To: Huangyihong (Rachel); [email-masked]; Ben
>> Campbell; [email-masked] Subject:
>> Re: Some comments on draft-ietf-avtext-splicing-notification-04
>>
>> Hi,
>>
>> Sorry for being a bit late in responding on this. I hope you have
>> time to submit this before the cut-off on Monday.
>>
> " The top 8 bits of the splicing-out NTP timestamp are inferred from
> the top 8 bits of the splicing-in NTP timestamp. This is unambiguous,
> under the assumption that the splicing-out time is after the
> splicing-in time, and the splicing interval is less than 2^25
> seconds. Therefore, if the 7 octets splicing-out NTP-format
> timestamp is smaller than the value of 7 low octets splicing-out
> NTP-format, it implies a wrap of the 56-bit splicing-out NTP-format
> timestamp which means the top 8-bit value of the 64-bit splicing-out
> is equal to the top 8-bit value of splicing-in NTP Timestamp plus
> 0x01. Otherwise, the top 8 bits of splicing-out NTP timestamp is
> equal to the top 8 bits of splicing-in NTP Timestamp. "

Yes, with the correction you added I think this is fine.

>>
>>
>>
>>>
>>>>
>>>> 3. Section 3.1:
>>>>
>>>> This section is not clear on what is the data part of the
>>>> header extension format. As it is not the header extension that
>>>> can determine if there will be usage of one-byte vs two-byte
>>>> format that will be used, this needs to be defined in a more
>>>> un
>>>
>>> [Rachel]: I don't understand this. The editing seems unfinished.
>>> The splicing RTP header extension uses one-byte format with the
>>> fixed bit pattern 0xBEDE.
>>
>> Sorry, what is missing is: The definition of the data field need to
>> be done in a way that is agnostic to if 1 or 2-byte headers are
>> being used in the header extension.
>>
>
> [Rachel]: I don't understand why should this extension to be agnostic
> for extension header types. There's no such limitation in [RFC5285]
> if I read it correctly. And based on [RFC5285], it says:
>
> " There are two variants of the extension: one-byte and two-byte
> small, the one-byte header form is preferred and MUST be supported
> by all receivers.  A stream MUST contain only one-byte or two-byte
> headers: they MUST NOT be mixed within a stream.  Transmitters
> SHOULD NOT use the two-byte form when all extensions are small enough
> for the one-byte header form. "
>
> For splicing extension, it can be classified into a) case. That's why
> we uses one-byte header, and it is preferred and mandated by
> receivers. So I can't imagine any other cases to use 2-byte header.
> And by the way, [RFC6051] also only defines one-byte header.

So this debate do gets us into RFC5285 update country. However the issue 
is that although a particular RTP header extension has a preference or 
requirement for which format to use. The actual format used in an actual 
RTP packet will be depending on the union of all the requirement for 
header extension format. For example the SDES header extension is one 
that can require to use the 2-byte format due to the SDES item's length 
(>16 bytes). If that header extension and yours needs to be in the same 
packet, then also yours need to use the 2-byte header format in this 
particular packet.

This is issue that needs to be clarified in RFC 5285 update, and 
hopefully to allow a particular SSRC to switch between formats on a 
packet by packet basis. If not then we end up in a situation where hard 
choices will have to be done when conflicting requirements occur.

The above issue is from my perspective that if one defines a header 
extension in such a way that it is clear on what is the data part and 
don't lock down the format to use, then it will work with the updated spec.

>>>>
>>>> 6. Section 3.2:
>>>>
>
> [Rachel]: Okay. I get your point. So how about adding some texts as
> following in Section 3.2, the last 2nd paragraph?
>
> " In cases of the mapping from RTP timestamp to NTP timestamp
> changes, e.g., clock drift happening before the splicing event, it
> may be required to send RTCP SR or even updated Splicing Interval
> information timely to update the timestamp mapping for accurate
> splicing. "
>

Yes, this at least raises the issue.

>>>
>>>>
>>>> 8. Section 7:
>>>>
>>>> I find a significant short coming in this security
>>>> consideration. That is the failure to discuss the importance
>>>> for the splicer to be able to trust the splicing interval
>>>> information from the main RTP sender. This information really
>>>> should be authenticated and integrity protected between the
>>>> main RTP sender and the splicer.
>>>>
>>>> Since the mechanism introduced in this document is not
>>>> dependent on any RTP payload-level hints for finding the
>>>> splicing in and out points, Secure Real-Time Transport Protocol
>>>> (SRTP) [3711] can be used to provide confidentiality of the RTP
>>>> payload while leaving the RTP header in the clear so that the
>>>> splicer can still carry out splicing without keying materials.
>>>> However, for a malicious endpoint without the key, it can
>>>> observe the splicing time in the RTP header, and it can
>>>> intercept the substitutive content and even replace it with a
>>>> different one if the substitutive stream does not use any
>>>> security like SRTP and the splicer does not authenticate the
>>>> main and substitutive content sources.
>>>>
>>>> streams. But that really should be worded in a stronger way as
>>>> a requirement for security.
>>>>
>>>> security would be good. One between the main and substitute
>>>> sender and the intended receiver, and an outer layer for sender
>>>> to splicer. However, I don't argue that such a solution needs
>>>> to be created. I think having the splicer as a trusted entity
>>>> is more likely to be a reasonable deployment model.
>>>
>>>
>>> " To avoid above security issue, the authentication of the main
>>> and substitutive content sources in the splicer SHOULD be
>>> considered. However, separating the security mechanism between
>>> senders and the splicer from the end-to-end one may complicate
>>> the whole system deployment. In such a case, having the splicer
>>> as a trusted entity is likely to be a reasonable deployment
>>> model. "
>>
>> already describes the trust model, of the trusted splicer.
>> Especially as no alternative do yet exist. Although PERC WG exists
>> and working on a model with end-to-end confidentiality, which could
>> possibly work. That is not a great match either for what I think
>> are the security requirements for services that uses splicing.
>>
>> I think what needs to occur is to rewrite the third paragraph from
>> the perspective that the splicer is trusted. Especially as the
>> stream the splicer forwards will not match the received one from a
>> perspective of number of packets and bytes, thus requiring RTCP
>> changes. This is why a translator or mixer model is required. Thus,
>> the packet forwarded from the splicer to the receiver will not be
>> consistent with either the original or the substitution stream. For
>> the authentication and integrity protection to not blow up the SRTP
>> keys will be needed. A division of the roles of integrity versus
>> confidentiality and you are back into PERC territory.
>>
>> Thus, the discussion of header extension encryption is mote.
>> Rather discuss that the splicer should use authenticated and
>> integrity protected streams to prevent third parties from
>> controlling the splicing as well as the substitution content.
>
> [Rachel]: Here's my proposal to rewrite 3rd paragraph to discuss the
> authentication between splicer and receiver. Is it what you're
> looking for? " Since splicer works as a trusted entity, any RTP-level
> or outside security mechanism, such IPsec[RFC4301] or Datagram
> Transport Layer Security [RFC6347], will use a security association
> between the splicer and the receiver. When using the Secure Real-Time
> Transport Protocol (SRTP) [RFC3711], the splicer could be provisioned
> with the same security association as the main RTP sender. "

Yes, it is at least what I believe to be most important. This as we are 
currently lacking the tools for doing a model where the splicer is only 
semi-trusted.

Cheers

Magnus Westerlund

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 21 Mar 2016 09:36:17 -0500

On 21 Mar 2016, at 9:27, Magnus Westerlund wrote:

> From my perspective, I think it is best that you submit an update 
> prior to the dead-line, then we all can review the changes prior to 
> the meeting. And if any changes are needed, you can update in 2 weeks 
> time.

I agree.

Thanks,

Ben.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Mon, 21 Mar 2016 16:06:51 +0000

Hi Magus,

Thank you for the quick response. I think below is the only issue that we're discussing. I'll submit a new version to reflect the issues you have.

BR,
Rachel

>> be done in a way that is agnostic to if 1 or 2-byte headers are being 
> for extension header types. There's no such limitation in [RFC5285] if 
> I read it correctly. And based on [RFC5285], it says:
>
> NOT use the two-byte form when all extensions are small enough for the 
> one-byte header form. "
>

So this debate do gets us into RFC5285 update country. However the issue is that although a particular RTP header extension has a preference or requirement for which format to use. The actual format used in an actual RTP packet will be depending on the union of all the requirement for header extension format. For example the SDES header extension is one that can require to use the 2-byte format due to the SDES item's length
(>16 bytes). If that header extension and yours needs to be in the same packet, then also yours need to use the 2-byte header format in this particular packet.

[Rachel]: The RFC5285 update already permits to use 1-byte and 2-byte format in the same RTP stream. You're saying the case they're used in one RTP packet. For splicing header extension, it only appears a number of RTP packet instead of all the RTP packets. So I'm just curious the possibility of the 2 kinds of extensions must be in the same packet. 

This is issue that needs to be clarified in RFC 5285 update, and hopefully to allow a particular SSRC to switch between formats on a packet by packet basis. If not then we end up in a situation where hard choices will have to be done when conflicting requirements occur.

The above issue is from my perspective that if one defines a header extension in such a way that it is clear on what is the data part and don't lock down the format to use, then it will work with the updated spec.

[Rachel]: It's no harm to include a 2-byte format in this version to avoid the case that you mentioned. And I'll do it right now.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 22 Mar 2016 11:35:37 +0100

Den 2016-03-21 kl. 17:06, skrev Huangyihong (Rachel):
> Hi Magus,
>
> Thank you for the quick response. I think below is the only issue
> that we're discussing. I'll submit a new version to reflect the
> issues you have.
>
> BR, Rachel
>
>>>>>
>>>>> 3. Section 3.1:
>>>>>
>>>>> header extension format. As it is not the header extension
>>>>> that can determine if there will be usage of one-byte vs
>>>>> two-byte format that will be used, this needs to be defined
>>>>> in a more un
>>>>
>>>> [Rachel]: I don't understand this. The editing seems
>>>> unfinished. The splicing RTP header extension uses one-byte
>>>> format with the fixed bit pattern 0xBEDE.
>>>
>>> Sorry, what is missing is: The definition of the data field need
>>> to be done in a way that is agnostic to if 1 or 2-byte headers
>>> are being used in the header extension.
>>>
>>
>> [Rachel]: I don't understand why should this extension to be
>> agnostic for extension header types. There's no such limitation in
>> [RFC5285] if I read it correctly. And based on [RFC5285], it says:
>>
>> headers.  Since it is expected that (a) the number of extensions
>> in any given RTP session is small and (b) the extensions themselves
>> are small, the one-byte header form is preferred and MUST be
>> supported by all receivers.  A stream MUST contain only one-byte or
>> two-byte headers: they MUST NOT be mixed within a stream.
>> Transmitters SHOULD NOT use the two-byte form when all extensions
>> are small enough for the one-byte header form. "
>>
>> For splicing extension, it can be classified into a) case. That's
>> why we uses one-byte header, and it is preferred and mandated by
>> receivers. So I can't imagine any other cases to use 2-byte
>> header. And by the way, [RFC6051] also only defines one-byte
>> header.
>
> So this debate do gets us into RFC5285 update country. However the
> issue is that although a particular RTP header extension has a
> preference or requirement for which format to use. The actual format
> used in an actual RTP packet will be depending on the union of all
> the requirement for header extension format. For example the SDES
> header extension is one that can require to use the 2-byte format due
> to the SDES item's length (>16 bytes). If that header extension and
> yours needs to be in the same packet, then also yours need to use the
> 2-byte header format in this particular packet.
>
> [Rachel]: The RFC5285 update already permits to use 1-byte and 2-byte
> format in the same RTP stream. You're saying the case they're used in
> one RTP packet. For splicing header extension, it only appears a
> number of RTP packet instead of all the RTP packets. So I'm just
> curious the possibility of the 2 kinds of extensions must be in the
> same packet.

No, that is not what I try to say. I am saying that within one RTP 
stream, i.e. under one SSRC. Then in one packet one might need to use 
the 2-byte format due to that an additional RTP header extension is 
added to the one with Splicing information. In a later packet where 
there is need to send a splicing RTP header extension, there might not 
be any other RTP header extension, nor one that requires the two-byte 
header extension. Thus, this packet can be sent with the 1-byte format.

> packet by packet basis. If not then we end up in a situation where
> hard choices will have to be done when conflicting requirements
> occur.
>
> [Rachel]: It's no harm to include a 2-byte format in this version to
> avoid the case that you mentioned. And I'll do it right now.

Yes, that is one way of doing it. The point I tried to made is that one 
can define ones RTP header extension is such a way that it becomes 
agnostic to if 1-byte or 2-byte format is used for the header 
extensions. This should be the recommended practice unless the format 
requires the 2-byte format.

I will have to review the RFC 5285 update to see if this has sufficient 
clarifications in this area. I would recommend that also the rest of the 
WG do take a look on the document update.

cheers

Magnus Westerlund

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 23 Mar 2016 09:29:21 +0000

Hi Magnus,

Inline please.

BR,
Rachel

> Sent: Tuesday, March 22, 2016 6:36 PM
> Subject: Re: 答复: Some comments on draft-ietf-avtext-splicing-notification-04
> 
> > Thank you for the quick response. I think below is the only issue that
> > we're discussing. I'll submit a new version to reflect the issues you
> > have.
> >
> > BR, Rachel
> >
> >>>>>
> >>>>> 3. Section 3.1:
> >>>>>
> >> headers: they MUST NOT be mixed within a stream.
> >> Transmitters SHOULD NOT use the two-byte form when all extensions are
> >> small enough for the one-byte header form. "
> >>
> > used in an actual RTP packet will be depending on the union of all the
> > requirement for header extension format. For example the SDES header
> > extension is one that can require to use the 2-byte format due to the
> > SDES item's length (>16 bytes). If that header extension and yours
> > needs to be in the same packet, then also yours need to use the 2-byte
> > header format in this particular packet.
> >
> No, that is not what I try to say. I am saying that within one RTP stream, i.e.
> under one SSRC. Then in one packet one might need to use the 2-byte format
> due to that an additional RTP header extension is added to the one with Splicing
> information. In a later packet where there is need to send a splicing RTP header
> extension, there might not be any other RTP header extension, nor one that
> requires the two-byte header extension. Thus, this packet can be sent with the
> 1-byte format.

[Rachel]: Yes, I understand you point. And that's all what RFC5285 update is talking about, see below

"
A stream MUST contain only one-byte or two-byte
headers unless it is known that all recipients support mixing, either
by offer/answer negotiation (see section 6) or by out-of-band
knowledge.  One-byte and two-byte headers MUST NOT be mixed in a
single RTP packet.
"

> > hard choices will have to be done when conflicting requirements occur.
> >
> Yes, that is one way of doing it. The point I tried to made is that one can define
> ones RTP header extension is such a way that it becomes agnostic to if 1-byte
> or 2-byte format is used for the header extensions. This should be the
> recommended practice unless the format requires the 2-byte format.

[Rachel]: We design the splicing header extension in a bit-saving way, because the length of data field is fixed.

> clarifications in this area. I would recommend that also the rest of the WG do
> take a look on the document update.
> 
> cheers
> 
> Magnus Westerlund
>

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 29 Mar 2016 16:18:56 -0500

Hi,

Where have we landed with this? Will a new revision be required?

Thanks!

Ben.

On 23 Mar 2016, at 4:29, Huangyihong (Rachel) wrote:

>> Subject: Re: 答复: Some comments on 
>>> that
>>>>> to
>>>> agnostic
>>>> by
>>>> are
>>>> why
>>> the
>> stream, i.e.
>>> don't lock down the format to use, then it will work with the 
>>> updated
>>> spec.
>>>
> [Rachel]: We design the splicing header extension in a bit-saving way, 
> because the length of data field is fixed.
>
>>

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 30 Mar 2016 00:45:56 +0000

Hi Ben,

A new version has been already submitted to reflect all the comments from Magnus, which already includes a solution for the following issue. He will check if it addresses all his concerns.

BR,
Rachel

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, March 30, 2016 5:19 AM
> To: Huangyihong (Rachel); Magnus Westerlund
> Cc: [email-masked]; [email-masked]
> >>>>> to be done in a way that is agnostic to if 1 or 2-byte headers are