Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02

From: Bo Burman <[email-masked]>
Date: Mon, 1 Sep 2014 11:51:10 +0000

Hello Christian, see inline below
Cheers,
Bo

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: den 27 augusti 2014 08:50
> To: Bo Burman; [email-masked]
> Subject: Re: [avtext] WGLC for draft-ietf-avtext-rtp-stream-pause-02
> 
> Hello Bo,
> 
> Please see below.
> 
> Regards, Christian
> 
> On 22/08/2014 10:35 PM, Bo Burman wrote:
> > ..snip..
> >> 2) Clause 9: Use of PAUSE and PAUSED: I must admit I find the
> >> distinction between these two parameters really confusing. Especially when the draft says that they are different
> functions but that "pause"
> >> encompasses "paused". It is really necessary to have two parameters?
> >> It seems that a node can do the following with respect to the messages:
> >> a) Both send and receive PAUSE, RESUME, PAUSED and REFUSE
> >> b) Send PAUSE, RESUME and receive PAUSED and REFUSE only
> >> c) Receive PAUSE, RESUME and send PAUSED and REFUSE only
> >> d) Do not receive messages but send a PAUSED only.
> >>
> >> The issue seems to come when considering the local PAUSE functionality.
> >> As the draft notes that "pause" contains the full "paused"
> >> functionality", I could assume that a) b) and c) contain the local
> >> PAUSE functionality. d) would also have to contain the local PAUSE
> >> functionality. However I'm not sure b) would be valid because the
> >> node would have to be able to send PAUSED as a result of clause 5.3. Whilst the intent is that 'pause' and 'paused' are
> different functions there would appear to be interactions. e.g. It would be strange to set 'pause=recvonly' and
> 'paused=recvonly'.
> >>
> >> I think the usage at least needs to be clarified as there appears to
> >> be some overlap and inconsistencies with other sections. Preferably it would be good to try to use one parameter.
> > [BoB]: Good catch and good analysis!
> >
> > To go back to the design intent of "paused" and if I remember correctly, I believe it was to allow for a very restricted
> implementation that supports/knows _only_ "local pause" functionality, and additionally (with the dir= parameter) allow
> for just a) sending the indication, b) just receiving it, or c) both. This is however not motivated or required by any of the
> currently included use cases. It seems that some parts of the current text, for example clause 5.1, confuses the use of
> "paused" with what is actually solved by the direction parameter of "pause".
> >
> > I think the following two main options are reasonable ways forward:
> >
> > 1) Remove the "paused" SDP parameter entirely, and with it the
> > possibility to implement support of only the local pause indication
> >
> > 2) Make the text consistently express that "paused" refers to capability for that limited functionality. For SDP
> offer/answer, we then have a few more choices regarding the relation between "pause" and "paused":
> >
> > 	a)  an offer expressing support for this specification MUST contain only one of "pause" or "paused", and an offer
> with "pause" is possible to restrict by answering with "paused", but an offer with the limited "paused" cannot be
> upgraded to "pause" in the answer. May possibly cause problems with declarative use; guidance appreciated.
> >
> > 	b) "pause" and "paused" are kept separate (what current text mostly
> > does, except for some confusion that must be corrected throughout if
> > this option is chosen); the offer MAY contain either or both, while
> > the answer MUST choose one and MUST NOT add anything that was not in
> > the offer
> [CNG] I wasn't following this closely when 'paused' was added so I'm not sure about removing it. It would simplify things
> if it was removed.
> I think what would need to be added if local pause was supported without signalling is that a node supporting this draft
> must at minimum support the reception of a 'paused' indication and the sending of 'paused' if the node supports a
> paused state. There would probably need to be an extra value in direction indicating that PAUSE/RESUME is not sent or
> received.
[BoB] You mean using additional direction signaling for pause instead of the tag "paused"? I don't see how that goes with your statement "supported without signaling" a few sentences back, since that is then also explicit signaling?

> 
> Maybe an option 2c: If local pause is kept and it needs to be supported by signalling there actually appears to be 8
> combinations of sent and received messages. I assume a node supporting the sending and/or reception of PAUSE must
> also support RESUME. A node supporting the reception of PAUSE/RESUME must also support sending PAUSED and
> REFUSED.
[BoB] An observation: I see you more or less consistently using "REFUSED" instead of the currently defined tag "REFUSE". This is actually consistent with it being an indication/response rather than a command, and thus probably a better name. Do you suggest that we change the name to "REFUSED" in the draft?

> The combinations a Node can support are:
> 
> 1) Send(PAUSE,RESUMED,PAUSED,REFUSE) Receive (PAUSED,RESUMED,PAUSED,REFUSED)
> 2) Send(PAUSE, RESUME, PAUSED) Receive (PAUSED, REFUSED)
> 3) Send(PAUSED,REFUSED) Receive (PAUSE, RESUME, PAUSED)
> 4) Send(PAUSED,REFUSED) Receive (PAUSE, RESUME)
> 5) Send(PAUSE, RESUME) Receive (PAUSED, REFUSED)
> 6) Send(PAUSED) Receive(PAUSED)
> 7) Send() Receive(PAUSED)
> 8) Send(PAUSED) Receive()
> 
> Would it be easier to simply signal the messages that are supported rather than two parameters with a direction
> parameters? e.g. the draft could have the above list of values. If a node supported both the sending and reception of
> PAUSE/RESUME/PAUSED/REFUSED then it could signal e.g. a=rtcp-fb:98 ccm pause config=1 . Part of the confusion
> comes from the interaction between the parameters. This would remove the interaction.
> 
> It might make describing the SDP O/A procedures easier.
> e.g.
> On receiving an Offer with:
> config=1 the answerer may reply with config=1, 2, 3, 4, 5, 6, 7 or 8.
> config=2 the answerer may reply with config=3, 4, 5, 6, 7 or 8.
> config=3 the answerer may reply with config=2, 4, 5, 6, 7 or 8.
> config=4 the answerer may reply with config=5, 6, 7 or 8.
> config=5 the answerer may reply with config=4, 6, 7 or 8.
> config=6 the answerer may reply with config=6, 7 or 8.
> config=7 the answerer may reply with config=8
> config=8 the answerer may reply with config=7 In all cases the answerer may reply with a completely removed "pause"
> parameter.
> 
> An answerer cannot add extra messages to what is provided in the Offer.
> For example: If an Offer indicates config=6 an Answer cannot reply with
> config=3 indicating that it has the capability to receive PAUSE and RESUME. An answerer may remove messages that it
> does not support. For
> example: if an Offer indicates config=6 an Answer may reply with
> config=7 indicating that it can only receive PAUSED.
[BoB] I get your point. There is significant inherent complexity in this that your proposal makes explicit and clarifies. I would like to simplify and clarify this further by reducing the allowed configurations to be 1, 4, 5 and 6:

1) Full support of sending and receiving all messages ("ccm pause" without direction)
	As you say above, acceptable Answers include 1, 4, 5 or 6, or (of course) removing "ccm pause" entirely
4) Pause command receiver, sending result indications ("ccm pause dir=recvonly")
	Acceptable Answers include 5, 6, or removing ccm pause entirely
5) Pause command sender, receiving result indications ("ccm pause dir=sendonly")
	Acceptable Answers include 4, 6, or removing ccm pause entirely
6) Local pause support only ("ccm paused", and I then suggest removing direction from paused; either you support it or you don't)
	Acceptable Answers include 6 or removing ccm paused entirely

If those clarifications you list above on O/A and what messages are sent and/or received are made in the document, do you still think we need to introduce the "config" concept, or will the direction parameter to "pause" (as indicated in my shortened list above) be clear enough?

I wonder, is it rather the notion of "direction" that becomes confusing, since "recvonly" actually includes sending messages, only those messages are not "PAUSE" and "RESUME"? In that case, could we call it something else than "direction"; like "dir=sendonly" -> "command-only" and "dir=recvonly" -> "indication-only"?

> 
> 
> 
> >> 3) Clause 5.1 indicates "/<The> Capability to understand PAUSED
> >> indication is defined separately from the others to support partial
> >> implementation, which is specifically believed to be feasible for the
> >> RTP Mixer to Media Sender use case (Section 3.2)./" I guess the important thing is that its the media sender that must
> at least support the PAUSED indication, the mixer needs to support PAUSE.
> > [BoB]: As said above, signaling for the mixer case is a bit confused in 5.1, and better dealt with (and covered) by having
> either dir=sendonly or dir=recvonly to pause parameter, depending on desired functionality restriction. Only supporting
> local PAUSED, indicated by "paused" SDP parameter, is a separate issue and should be made clearer, if not removed (see
> above).
> >
> >> 4) Clause 10.1 paragraph below the figure. Indicates "/includes the
> >> "nowait" sub-parameter for both "pause" and "paused" parameters/"
> >> however the nowait parameter is only specified in the example offer
> >> for pause + nowait is not defined for paused in the ABNF syntax.
> > [BoB]: Correct. Only "pause" should be in the sentence above.
> >
> >> The last paragraph in clause 9.1 also indicates that possibility to
> >> support "nowait" for "paused" i.e. "/The answerer MUST NOT add
> >> "nowait" on the "pause" line in the answer unless it is present on the "paused" line in the offer./" This isn't possible
> due to the syntax.
> > [BoB]: Correct. Probably a typo; "paused" -> "pause".
> >
> >> 5) Clause 9.1 paragraph 2: "/In other words, an offer for "paused
> >> dir=sendonly" means that the offerer intends to send PAUSED
> >> indications whenever it pauses RTP stream delivery in any of its streams./" Would a pause in one stream require
> sending a PAUSED indication in multiple streams?
> > [BoB]: No, only for the actually paused stream; unclear wording. What about simply "...intends to send PAUSED
> indications for paused RTP streams"?
> [CNG] OK
> >
> >

---

From: Christian Groves <[email-masked]>
Date: Tue, 02 Sep 2014 10:45:26 +1000

Hello Bo,

Please see my replies below.

Regards, Christian

> [BoB] You mean using additional direction signaling for pause instead of the tag "paused"? I don't see how that goes with your statement "supported without signaling" a few sentences back, since th…
[CNG] Yes an additional direction. I was thinking about how to specify 
"local pause" where the endpoint didn't support sendonly,recvonly or 
sendrecv. It wouldn't be correct for the endpoint to send "a=rtcp-fb:* 
ccm pause" because the default is "sendrecv".
> [BoB] An observation: I see you more or less consistently using "REFUSED" instead of the currently defined tag "REFUSE". This is actually consistent with it being an indication/response rather than…
[CNG] I wasn't proposing the change, I guess I just aligned "paused" and 
"refused". I'd be OK with changing it.
> 	Acceptable Answers include 6 or removing ccm paused entirely
[CNG] So to remove 2 and 3 the assumption must be that local pause is 
not supported by a sendonly or receive only endpoint. Is that correct? 
It would seem that if local pause was to be supported then 2 and 3 
should be selected rather than 4 and 5.
       To remove 7 and 8 the assumption must be that endpoints 
supporting this draft must support local pause? Otherwise there's no way 
of saying "I won't send anything but if you do a local pause let me know".
> If those clarifications you list above on O/A and what messages are sent and/or received are made in the document, do you still think we need to introduce the "config" concept, or will the directio…
[CNG] I think having "paused" as a separate parameter as in your 
proposal 6 just complicates things. Once you have two parameters then we 
come back to specifying the interaction between them. E.g. If A sends 
SDP "a=rtcp-fb:* ccm pause" if B only supports local pause does it reply 
back with a different parameter "a=rtcp-fb* ccm paused"? If so then it 
wouldn't make sense for an endpoint to send both "pause" and "paused".
> I wonder, is it rather the notion of "direction" that becomes confusing, since "recvonly" actually includes sending messages, only those messages are not "PAUSE" and "RESUME"? In that case, could w…
[CNG] Yes I think the direction is confusing considering that for pause 
it's opposite the RTP flow direction, for paused its the same. To 
support pause an endpoint will send and receive messages. I don't think 
"command-only"/"indication-only" help because they again relate to a 
direction. e.g. to support "sendonly" an endpoint sends commands 
PAUSE/RESUME and receives indications PAUSED/REFUSEd. I think being 
explicit makes the description much easier.

..snip..

---

From: Bo Burman <[email-masked]>
Date: Fri, 5 Sep 2014 09:43:53 +0000

Hi Christian,

More inline.

As a summary, I must conclude that Christian's proposal has consistency and clarity benefits in SDP signaling compared to what is currently in the text, and suggest that the text should be changed accordingly:

* The "dir" parameter of "ccm pause" is replaced by "config" as suggested below.
* The separate "ccm paused" parameter is removed, since support of PAUSED will instead be indicated through "config"

BR
/Bo

> Sent: den 2 september 2014 02:45
> > 2) Make the text consistently express that "paused" refers to
> > capability for that limited functionality. For SDP
> >>> 	a)  an offer expressing support for this specification MUST contain
> >>> only one of "pause" or "paused", and an offer
> >> with "pause" is possible to restrict by answering with "paused", but
> >> an offer with the limited "paused" cannot be upgraded to "pause" in the answer. May possibly cause problems with
> declarative use; guidance appreciated.
> >> [CNG] I wasn't following this closely when 'paused' was added so I'm
> >> not sure about removing it. It would simplify things if it was removed.
> >> I think what would need to be added if local pause was supported
> >> without signalling is that a node supporting this draft must at
> >> minimum support the reception of a 'paused' indication and the
> >> sending of 'paused' if the node supports a paused state. There would probably need to be an extra value in direction
> indicating that PAUSE/RESUME is not sent or received.
> > [BoB] You mean using additional direction signaling for pause instead of the tag "paused"? I don't see how that goes
> with your statement "supported without signaling" a few sentences back, since that is then also explicit signaling?
> [CNG] Yes an additional direction. I was thinking about how to specify "local pause" where the endpoint didn't support
> sendonly,recvonly or sendrecv. It wouldn't be correct for the endpoint to send "a=rtcp-fb:* ccm pause" because the
> default is "sendrecv".

[BoB] Thinking this through again. It is possible to make the currently proposed signaling in the draft consistent, but only if capability and indication of pause and local pause are changed to be totally independent functions. The 8 configurations you list are then possible to express, using direction parameter of both pause and paused ([] indicates optional).

1) Send(PAUSE,RESUMED,PAUSED,REFUSE) Receive (PAUSED,RESUMED,PAUSED,REFUSED)
a=rtcp-fb:* ccm pause [dir=sendrecv]
a=rtcp-fb:* ccm paused [dir=sendrecv]

2) Send(PAUSE, RESUME, PAUSED) Receive (PAUSED, REFUSED)
a=rtcp-fb:* ccm pause dir=sendonly
a=rtcp-fb:* ccm paused [dir=sendrecv]

3) Send(PAUSED,REFUSED) Receive (PAUSE, RESUME, PAUSED)
a=rtcp-fb:* ccm pause dir=recvonly
a=rtcp-fb:* ccm paused [dir=sendrecv]

4) Send(PAUSED,REFUSED) Receive (PAUSE, RESUME)
a=rtcp-fb:* ccm pause dir=recvonly
a=rtcp-fb:* ccm paused dir=sendonly

5) Send(PAUSE, RESUME) Receive (PAUSED, REFUSED)
a=rtcp-fb:* ccm pause dir=sendonly
a=rtcp-fb:* ccm paused dir=recvonly

6) Send(PAUSED) Receive(PAUSED)
a=rtcp-fb:* ccm paused [dir=sendrecv]

7) Send() Receive(PAUSED)
a=rtcp-fb:* ccm paused dir=recvonly

8) Send(PAUSED) Receive()
a=rtcp-fb:* ccm paused dir=sendonly

That split would however also mean there is a possibility to support PAUSE but not PAUSED, which I believe is an undesirable side-effect and definitely not in line with the current text.

As a summary, I must agree that your proposal to use a "config" parameter with an explicit listing of supported messages and directions is indeed much easier to describe and is beneficial for text clarity.

> >
> >> Maybe an option 2c: If local pause is kept and it needs to be
> >> supported by signalling there actually appears to be 8 combinations
> >> of sent and received messages. I assume a node supporting the sending
> >> and/or reception of PAUSE must also support RESUME. A node supporting the reception of PAUSE/RESUME must also
> support sending PAUSED and REFUSED.
> > [BoB] An observation: I see you more or less consistently using "REFUSED" instead of the currently defined tag
> "REFUSE". This is actually consistent with it being an indication/response rather than a command, and thus probably a
> better name. Do you suggest that we change the name to "REFUSED" in the draft?
> [CNG] I wasn't proposing the change, I guess I just aligned "paused" and "refused". I'd be OK with changing it.
[BoB] Unless someone else objects, I will change REFUSE to REFUSED throughout, to better reflect that it is an indication, not a command.

> >> Would it be easier to simply signal the messages that are supported
> >> rather than two parameters with a direction parameters? e.g. the
> >> draft could have the above list of values. If a node supported both
> >> the sending and reception of PAUSE/RESUME/PAUSED/REFUSED then it could signal e.g. a=rtcp-fb:98 ccm pause
> config=1 . Part of the confusion comes from the interaction between the parameters. This would remove the interaction.
> >>
> >> config=8 the answerer may reply with config=7
> >> In all cases the answerer may reply with a completely removed "pause"
> >> parameter.
> >>
> >> config=3 indicating that it has the capability to receive PAUSE and
> >> RESUME. An answerer may remove messages that it does not support. For
> > [BoB] I get your point. There is significant inherent complexity in this that your proposal makes explicit and clarifies. I
> would like to simplify and clarify this further by reducing the allowed configurations to be 1, 4, 5 and 6:
> >
> [CNG] So to remove 2 and 3 the assumption must be that local pause is not supported by a sendonly or receive only
> endpoint. Is that correct?
> It would seem that if local pause was to be supported then 2 and 3 should be selected rather than 4 and 5.
>        To remove 7 and 8 the assumption must be that endpoints supporting this draft must support local pause? Otherwise
> there's no way of saying "I won't send anything but if you do a local pause let me know".

[BoB] I agree the 8 configurations you list makes sense to keep. They reflect the current text better than what I suggested.

> > If those clarifications you list above on O/A and what messages are sent and/or received are made in the document, do
> you still think we need to introduce the "config" concept, or will the direction parameter to "pause" (as indicated in my
> shortened list above) be clear enough?
> [CNG] I think having "paused" as a separate parameter as in your proposal 6 just complicates things. Once you have two
> parameters then we come back to specifying the interaction between them. E.g. If A sends SDP "a=rtcp-fb:* ccm pause"
> if B only supports local pause does it reply back with a different parameter "a=rtcp-fb* ccm paused"? If so then it

[BoB] As said above, just signaling ccm pause would have to mean that paused is not supported, so there would be no way to fall back to local pause, which is undesirable. Your "config" is better.

> >
> > I wonder, is it rather the notion of "direction" that becomes confusing, since "recvonly" actually includes sending
> messages, only those messages are not "PAUSE" and "RESUME"? In that case, could we call it something else than
> "direction"; like "dir=sendonly" -> "command-only" and "dir=recvonly" -> "indication-only"?
> [CNG] Yes I think the direction is confusing considering that for pause it's opposite the RTP flow direction, for paused its
> the same. To support pause an endpoint will send and receive messages. I don't think "command-only"/"indication-only"
> help because they again relate to a direction. e.g. to support "sendonly" an endpoint sends commands PAUSE/RESUME
> and receives indications PAUSED/REFUSEd. I think being explicit makes the description much easier.
[BoB] Agree

---

From: Bo Burman <[email-masked]>
Date: Mon, 15 Sep 2014 14:29:49 +0000

Christian, Roni, all,

Please find enclosed a draft update implementing Christian's suggested changes below. Affected sections are 9 and 10.1.
Please have a look and let me know if the changes are acceptable and consistent with our discussions.

Cheers,
/Bo

> From: avtext [mailto:[email-masked]] On Behalf Of Bo Burman
> Sent: den 5 september 2014 11:44
> To: Christian Groves; [email-masked]
> As a summary, I must conclude that Christian's proposal has consistency and clarity benefits in SDP signaling compared to
> what is currently in the text, and suggest that the text should be changed accordingly:
> 
> > >>> 	a)  an offer expressing support for this specification MUST
> > >>> contain only one of "pause" or "paused", and an offer
> > >> with "pause" is possible to restrict by answering with "paused",
> > >> but an offer with the limited "paused" cannot be upgraded to
> > >> "pause" in the answer. May possibly cause problems with
> > >>> 	b) "pause" and "paused" are kept separate (what current text
> > >>> mostly does, except for some confusion that must be corrected
> > >>> throughout if this option is chosen); the offer MAY contain either
> > >>> or both, while the answer MUST choose one and MUST NOT add
> > >>> anything that was not in the offer
> > >> [CNG] I wasn't following this closely when 'paused' was added so
> > >> I'm not sure about removing it. It would simplify things if it was removed.
> > >> sending of 'paused' if the node supports a paused state. There
> > >> would probably need to be an extra value in direction
> > > [BoB] You mean using additional direction signaling for pause
> > > instead of the tag "paused"? I don't see how that goes
> > sendrecv. It wouldn't be correct for the endpoint to send "a=rtcp-fb:* ccm pause" because the default is "sendrecv".
> 
> [BoB] Thinking this through again. It is possible to make the currently proposed signaling in the draft consistent, but only
> if capability and indication of pause and local pause are changed to be totally independent functions. The 8 configurations
> you list are then possible to express, using direction parameter of both pause and paused ([] indicates optional).
> 
> That split would however also mean there is a possibility to support PAUSE but not PAUSED, which I believe is an
> undesirable side-effect and definitely not in line with the current text.
> 
> As a summary, I must agree that your proposal to use a "config" parameter with an explicit listing of supported messages
> and directions is indeed much easier to describe and is beneficial for text clarity.
> 
> > >
> > >> of sent and received messages. I assume a node supporting the
> > >> sending and/or reception of PAUSE must also support RESUME. A node
> > >> supporting the reception of PAUSE/RESUME must also
> > > [BoB] An observation: I see you more or less consistently using
> > > "REFUSED" instead of the currently defined tag
> > "REFUSE". This is actually consistent with it being an
> > indication/response rather than a command, and thus probably a better name. Do you suggest that we change the
> name to "REFUSED" in the draft?
> > >> config=8 the answerer may reply with config=7 In all cases the
> > >> answerer may reply with a completely removed "pause"
> > >> parameter.
> > >>
> > > [BoB] I get your point. There is significant inherent complexity in
> > > this that your proposal makes explicit and clarifies. I
> > > 6) Local pause support only ("ccm paused", and I then suggest
> > > removing direction from paused; either you support it or
> > you don't)
> > supporting this draft must support local pause? Otherwise there's no way of saying "I won't send anything but if you do
> a local pause let me know".
> 
> > > If those clarifications you list above on O/A and what messages are
> > > sent and/or received are made in the document, do
> > you still think we need to introduce the "config" concept, or will the
> > direction parameter to "pause" (as indicated in my shortened list above) be clear enough?
> > proposal 6 just complicates things. Once you have two parameters then we come back to specifying the interaction
> between them. E.g. If A sends SDP "a=rtcp-fb:* ccm pause"
> > if B only supports local pause does it reply back with a different
> > parameter "a=rtcp-fb* ccm paused"? If so then it wouldn't make sense for an endpoint to send both "pause" and
> "paused".
> 
> [BoB] As said above, just signaling ccm pause would have to mean that paused is not supported, so there would be no
> way to fall back to local pause, which is undesirable. Your "config" is better.
> 
> > >
> > > I wonder, is it rather the notion of "direction" that becomes
> > > confusing, since "recvonly" actually includes sending
> > messages, only those messages are not "PAUSE" and "RESUME"? In that
> > case, could we call it something else than "direction"; like "dir=sendonly" -> "command-only" and "dir=recvonly" ->
> "indication-only"?
> > [CNG] Yes I think the direction is confusing considering that for
> > pause it's opposite the RTP flow direction, for paused its the same. To support pause an endpoint will send and receive
> messages. I don't think "command-only"/"indication-only"
> > help because they again relate to a direction. e.g. to support
> > "sendonly" an endpoint sends commands PAUSE/RESUME and receives indications PAUSED/REFUSEd. I think being
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: Christian Groves <[email-masked]>
Date: Tue, 16 Sep 2014 13:14:09 +1000

Hello Bo,

Thanks for the updates. A few comments:

1) Cl.6.3: Text was added to the Paused state regarding keepalives. Do 
we also need that text in clause 6.4 on local paused state?

2) Cl.2.2: The term "REFUSED notification" is used but elsewhere 
"REFUSED indication" is used.

3) Cl.9 Para.1: With respect to the use of the rtcp-fb attribute I think 
the text should say "/MUST only be used as an SDP media attribute and 
MUST NOT be provided at the session level/". The use of "Recommended" 
implies an option however there's a must against the use at session 
level, so really there is no option.

4) General Nit: Sometimes "hold off period" is used, sometimes "hold off 
time" is used. Could be consistent.

5) Cl.9 Config value 5: " /streams it sends.  It will send PAUSED and 
REFUSED as needed.  It does not support pausing received RTP streams, 
and thus does not send any PAUSE and RESUME requests/
". Could we modify it to read "/It does not support sending PAUSE and 
RESUME requests to pause received RTP streams.../"? It makes it clearer 
that the draft is talking about a sending action rather than a local pause.

6) Cl.9 last para pg 28: "/All implementations of this specification 
MUST be able to receive all//
//   messages defined in Section 8/". Given that the config parameter 
allows partial implementation then this statement isn't true.

7) Cl.9 Fig.7: I'm not sure if "1"-"8" is valid range syntax for ABNF? 
Cl.3.4/RFC5234 seems to imply that: pause-config-value = %x31-38 would 
be equivalent to "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8".
Also rather than having to enforce a once only usage for nowait and 
config could the ABNF be updated to make sure, e.g.
rtcp-fb-ccm-param =/ SP "pause" [SP pause-config] [SP "nowait"]

With respect to the extension token, the current form wouldn't allow 
something like foo=bar in the future as "=" isn't a token character. 
Firstly is it needed? if so then would something like [SP byte-string] 
be more appropriate?

8) Cl.9.2: " /First, the "config" attribute and its message directions are//
//   interpreted based on the node receiving the SDP./" Should this be 
the node "providing" the SDP as per cl.9.1?

9) Cl.11: Does the config parameter need to be included here? Also 
perhaps 4) and 5) should say "pause feedback type" as per the 
description of the "type" element.

Regards, Christian

---

From: Bo Burman <[email-masked]>
Date: Tue, 16 Sep 2014 09:12:33 +0000

Hi Christian,

Thank you for good and constructive comments! My responses inline.

Note that I need guidance on whether or not defined 'config' attribute values need to be somehow mentioned in IANA section, and in that case how to describe it. A reference to the table in Figure 6? Examples from other RFCs are welcome!

Also, while editing the first part of section 9, I started to wonder if this specification can really promise that existing 'ccm tmmbr' signaling means TMMBR and TMMBN with value 0 is supported and will be treated correctly in all existing implementations? Should we not at least say there is no guarantee TMMBR and TMMBN implementations pre-dating this specification work exactly as described when used with a bitrate value of 0?

Cheers,
/Bo

> Sent: den 16 september 2014 05:14
> 1) Cl.6.3: Text was added to the Paused state regarding keepalives. Do we also need that text in clause 6.4 on local
> paused state?
[BoB] I guess that does not harm. I'll add it.

> 
> 2) Cl.2.2: The term "REFUSED notification" is used but elsewhere "REFUSED indication" is used.
[BoB] Good catch. I'll change to "indication".

> 
> 3) Cl.9 Para.1: With respect to the use of the rtcp-fb attribute I think the text should say "/MUST only be used as an SDP
> media attribute and MUST NOT be provided at the session level/". The use of "Recommended"
> implies an option however there's a must against the use at session level, so really there is no option.
[BoB] I agree that "recommend" and "must" do not match. The current text in that sentence is a bit poorly written. I think it tries to both describe what is said in RFC 4585 and 5104 about the rtcp-fb attribute in general, as well as saying that it applies also for this specification. That statement is redundant. RFC 4585 section 4.2 is totally clear: "The 'rtcp-fb' attribute MUST only be used as an SDP media attribute and MUST NOT be provided at the session level". I think the sentence can be removed.

> 
> 4) General Nit: Sometimes "hold off period" is used, sometimes "hold off time" is used. Could be consistent.
[BoB] There are also sometimes "wait period" or "wait time". I'll change to "hold-off period" throughout.

> 
> 5) Cl.9 Config value 5: " /streams it sends.  It will send PAUSED and REFUSED as needed.  It does not support pausing
> received RTP streams, and thus does not send any PAUSE and RESUME requests/ ". Could we modify it to read "/It does
> not support sending PAUSE and RESUME requests to pause received RTP streams.../"? It makes it clearer that the draft is
> talking about a sending action rather than a local pause.
[BoB] OK

> 
> 6) Cl.9 last para pg 28: "/All implementations of this specification MUST be able to receive all//
[BoB] My intent was to require that all implementations are able to at least receive _and ignore_ all messages from section 8, regardless of config. That would be in line with section 4.2 of RFC 4585: "RTP senders MUST be prepared to receive any kind of RTCP FB messages  and MUST silently discard all those RTCP FB messages that they do not understand", but is thus strictly redundant. I suggest to simply remove the sentence since it does not add anything.

> Cl.3.4/RFC5234 seems to imply that: pause-config-value = %x31-38 would be equivalent to "1" / "2" / "3" / "4" / "5" / "6" /
> "7" / "8".
[BoB] You are right. I'll change it.

> Also rather than having to enforce a once only usage for nowait and config could the ABNF be updated to make sure, e.g.
[BoB] OK. The fact that you by that require a strict ordering of attributes is probably not limiting.

> 
> With respect to the extension token, the current form wouldn't allow something like foo=bar in the future as "=" isn't a
> token character.
> Firstly is it needed? if so then would something like [SP byte-string] be more appropriate?
[BoB] I think extensibility to be a good thing in general. Agree that byte-string is better.

> the node "providing" the SDP as per cl.9.1?
[BoB] No. Declarative use of SDP seems to have this difference in interpretation of the SDP. First, see section 3.4 of RFC 4566 on Multicast Session Announcement that says "remote participants can use the session description to start the tools required to participate in the session". Second, compare with section 6 of RFC 4566 where a=recvonly is described as "specifies that the tools should be started in a receive-only mode". This indicates to me that the text currently in 9.2 is correct.

> 
> 9) Cl.11: Does the config parameter need to be included here? Also perhaps 4) and 5) should say "pause feedback type"
> as per the description of the "type" element.
[BoB] 'config' should be in 3, yes. Don't know about config values. Guidance appreciated!

> >> As a summary, I must conclude that Christian's proposal has
> >> consistency and clarity benefits in SDP signaling compared to what is currently in the text, and suggest that the text
> should be changed accordingly:
> >>
> >>>>>> throughout if this option is chosen); the offer MAY contain
> >>>>>> either or both, while the answer MUST choose one and MUST NOT add
> >>> [CNG] Yes an additional direction. I was thinking about how to
> >>> specify "local pause" where the endpoint didn't support
> >> [BoB] Thinking this through again. It is possible to make the
> >> currently proposed signaling in the draft consistent, but only if
> >> capability and indication of pause and local pause are changed to be totally independent functions. The 8
> configurations you list are then possible to express, using direction parameter of both pause and paused ([] indicates
> optional).
> >>
> >> That split would however also mean there is a possibility to support
> >> PAUSE but not PAUSED, which I believe is an undesirable side-effect and definitely not in line with the current text.
> >>
> >> As a summary, I must agree that your proposal to use a "config"
> >> parameter with an explicit listing of supported messages and directions is indeed much easier to describe and is
> beneficial for text clarity.
> >>
> >>>>> supported by signalling there actually appears to be 8
> >>>>> combinations of sent and received messages. I assume a node
> >>>>> supporting the sending and/or reception of PAUSE must also support
> >>>>> RESUME. A node supporting the reception of PAUSE/RESUME must also
> >>> indication/response rather than a command, and thus probably a
> >> [BoB] Unless someone else objects, I will change REFUSE to REFUSED
> >> throughout, to better reflect that it is an indication, not a command.
> >>
> >>>>> Would it be easier to simply signal the messages that are
> >>>>> supported rather than two parameters with a direction parameters?
> >>>>> e.g. the draft could have the above list of values. If a node
> >>>>> supported both the sending and reception of
> >>>>> PAUSE/RESUME/PAUSED/REFUSED then it could signal e.g. a=rtcp-fb:98
> >>>>> ccm pause
> >>> config=1 . Part of the confusion comes from the interaction between
> >>> the parameters. This would remove the
> >> interaction.
> >>>>> config=3 indicating that it has the capability to receive PAUSE
> >>>>> and RESUME. An answerer may remove messages that it does not support.
> >>>>> For
> >>> [CNG] So to remove 2 and 3 the assumption must be that local pause
> >>> is not supported by a sendonly or receive only endpoint. Is that correct?
> >>> supporting this draft must support local pause? Otherwise there's no
> >>> way of saying "I won't send anything but if you do
> >> [BoB] I agree the 8 configurations you list makes sense to keep. They
> >> reflect the current text better than what I suggested.
> >>
> >>> you still think we need to introduce the "config" concept, or will
> >>> the direction parameter to "pause" (as indicated in my shortened list above) be clear enough?
> >>> proposal 6 just complicates things. Once you have two parameters
> >>> then we come back to specifying the interaction
> >> [BoB] As said above, just signaling ccm pause would have to mean that
> >> paused is not supported, so there would be no way to fall back to local pause, which is undesirable. Your "config" is
> better.
> >>
> >>> case, could we call it something else than "direction"; like
> >>> "dir=sendonly" -> "command-only" and "dir=recvonly" ->
> >> "indication-only"?
> >>> pause it's opposite the RTP flow direction, for paused its the same.
> >>> To support pause an endpoint will send and receive
> >>> "sendonly" an endpoint sends commands PAUSE/RESUME and receives
> >>> indications PAUSED/REFUSEd. I think being

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Sep 2014 21:53:08 -0700

Section 1
 
   This document describes several
   scenarios in multimedia communication where a conferencing node or
   participant chooses to temporarily pause an incoming RTP [RFC3550]
   stream and later resume it when needed.  The receiver does not need
   to terminate or inactivate the RTP session and start all over again
   by negotiating the session parameters, for example using SIP
   [RFC3261] with SDP Offer/Answer [RFC3264].
 
  Centralized nodes, like RTP Mixers or MCUs, which either uses logic
   based on voice activity, other measurements, or user input could
   reduce the resources consumed in both the sender and the network by
   temporarily pausing the RTP streams that aren't required by the RTP
   Mixer.
 
[BA] There is another potential use case for a centralized node.  Could stream pause/resume also be used to enable a centralized node to notify a receiver that it has chosen to pause a stream on its own (without being asked)?  For example, there are situations where an multi-stream SFU may wish to drop a layer (RTCP RRs or PLI indicates congestion).  Today this is handled via codec-specific messages (e.g. SEI layer drop).   However, if it was desired to handle this in a codec-independent way, could a centralized node send an unsolicited PAUSED (e.g. TMMBN = 0) message?
 
Section 4.2

   It is the responsibility of an RTP stream receiver, who wants to
   pause or resume a stream from the sender(s), to transmit PAUSE and
   RESUME messages.  An RTP stream sender who likes to pause itself, can
   simply do it.  Any indication that an RTP stream is paused is the
   responsibility of the RTP stream sender and may in some cases not
   even be needed by the stream receiver.
 
[BA] Not sure I agree with this for the multi-stream transmission case.  If a sender stops sending a layer with no notification, then the receiver could be adversely affected.  For example, it could be waiting for a spatial enhancement layer that never shows up.   That is why we have SEI layer drop messages, right? 
 
Section 4.4
 
An RTP stream sender should not pause an SSRC that some receiver   still wishes to receive.  The reason is that in RTP topologies where   the stream is shared between multiple receivers, a single receiver on   that shared network, independent of it being multicast, a mesh with   joint RTP session or a transport Translator based, must not single-   handedly cause the stream to be paused without letting all other   receivers to voice their opinions on whether or not the stream should   be paused.  A consequence of this is that a newly joining receiver,   for example indicated by an RTCP Receiver Report containing both a   new SSRC and a CNAME that does not already occur in the session,   firstly needs to learn the existence of paused streams, and secondly   should be able to resume any paused stream.  Any single receiver   wanting to resume a stream should also cause it to be resumed. 
 
[BA] In many simulcast and MST implementations, the centralized unit utilizes sender-based congestion control, which means that it decides which streams to send based on indications from the receiver such as packet loss, etc.   If there is substantial loss, the sender will adjust the streams it is sending.  In implementations where the SFU uses a distinct SSRC for each simulcast stream (as opposed to using the same SSRC but adjusting the resolution/framerate), it may pause sending one SSRC and resume sending another (lower bandwidth one).  Where MST is in use, the sender may pause an enhancement layer and subsequently resume sending it when it has reason to believe that there is sufficient bandwidth to handle it.  Whether receiver "wishes to receive" a stream doesn't really enter into the sender's decision if it determines that there isn't sufficient bandwidth available to send it successfully.

---

From: Christian Groves <[email-masked]>
Date: Wed, 17 Sep 2014 16:21:01 +1000

Hello Bo,

Regards, Christian

> Also, while editing the first part of section 9, I started to wonder if this specification can really promise that existing 'ccm tmmbr' signaling means TMMBR and TMMBN with value 0 is supported and…
[CNG] The later seems a safer assumption.
> ..snip
[CNG] OK
[CNG] OK
[CNG] OK
> [BoB] No. Declarative use of SDP seems to have this difference in interpretation of the SDP. First, see section 3.4 of RFC 4566 on Multicast Session Announcement that says "remote participants can…
[CNG] Yes, seems you're right.
> [BoB] 'config' should be in 3, yes. Don't know about config values. Guidance appreciated!
[CNG] You may want to be more formal in the way the updates are 
specified to make it clear to IANA what exactly they have to do, e.g. 
similar to RFC5104.

11. IANA Considerations
This specification requests the following registrations from IANA

1) A new value for media stream pause / resume to be registered with 
IANA in the "FMT Values for RTPFB Payload Types" registry located at the 
time of publication at:
http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml

       Value:            9
       Name:             PAUSE RESUME
       Long Name:        Media Pause Resume
       Reference:        This RFC.

2) A new value "pause" to be registered with IANA in the "Codec Control 
Messages" registry located at the time of publication at:
http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml#sdp-parameters-19

    Name           Long Name                         Value  Reference
    -------------- --------------------------------- -----  ---------
    PAUSERES       Pause / Resume Media Sending        9    This RFC

With regards to the "no wait" and "config" parameters I don't think you 
need a registry for these are they don't need to be extensible. RFCs 
4585 and 5104 don't register these types of sub-parameters.

For 4 & 5 'pause' Types, I'm not sure a registry is needed for these. I 
would assume that any new value would be as a result of a revision to 
the pause/resume RFC. If you set up a registry for these 'pause' types 
then you have to specify the process used in order to update it.

---

From: Bo Burman <[email-masked]>
Date: Wed, 17 Sep 2014 07:15:44 +0000

Responses inline
/Bo

From: avtext [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: den 17 september 2014 06:53
To: [email-masked]
Subject: [avtext] Review of draft-ietf-avtext-rtp-stream-pause-02

Section 1

   This document describes several
   scenarios in multimedia communication where a conferencing node or
   participant chooses to temporarily pause an incoming RTP [RFC3550<https://tools.ietf.org/html/rfc3550>]
   stream and later resume it when needed.  The receiver does not need
   to terminate or inactivate the RTP session and start all over again
   by negotiating the session parameters, for example using SIP
   [RFC3261<https://tools.ietf.org/html/rfc3261>] with SDP Offer/Answer [RFC3264<https://tools.ietf.org/html/rfc3264>].

[BA] There is another potential use case for a centralized node.  Could stream pause/resume also be used to enable a centralized node to notify a receiver that it has chosen to pause a stream on its own (without being asked)?  For example, there are situations where an multi-stream SFU may wish to drop a layer (RTCP RRs or PLI indicates congestion).  Today this is handled via codec-specific messages (e.g. SEI layer drop).   However, if it was desired to handle this in a codec-independent way, could a centralized node send an unsolicited PAUSED (e.g. TMMBN = 0) message?
[BoB] Yes, that is the intention. I could add some text in the introduction about that. This is fully in line with the rest of the document. See for example first part of section 5.3 "Media Sender Pausing";
   An RTP stream sender can choose to pause the stream at any time.
   This can either be as a result of receiving a PAUSE, or be based on
   some local sender consideration.  When it does, it sends a PAUSED
   indication, containing the available PauseID.  If the stream was
   paused by a TMMBR 0, TMMBN 0 is used as PAUSED indication.  What is
   said on PAUSED in the rest of this paragraph apply also to the use of
    TMMBN 0, except for PAUSED message parameters.
Do you think that the text need further clarification? I see no problem adding explicit text regarding unsolicited sending of TMMBN 0.

Section 4.2

It is the responsibility of an RTP stream receiver, who wants to pause or resume a stream from the sender(s), to transmit PAUSE and RESUME messages. An RTP stream sender who likes to pause itself, can simply do it. Any indication that an RTP stream is paused is the responsibility of the RTP stream sender and may in some cases not even be needed by the stream receiver.

[BA] Not sure I agree with this for the multi-stream transmission case.  If a sender stops sending a layer with no notification, then the receiver could be adversely affected.  For example, it could be waiting for a spatial enhancement layer that never shows up.   That is why we have SEI layer drop messages, right?
[BoB] If you refer to the sentence marked in red above, it was intended to highlight a fact that was there already before this draft, not to specifically allow something that was previously disallowed. Maybe that sentence could be changed into something like "An RTP stream sender who likes to pause itself can often simply do it, but sometimes this will adversely affect the receiver and an explicit indication that the RTP stream is paused may then help"?

Section 4.4

[BA] In many simulcast and MST implementations, the centralized unit utilizes sender-based congestion control, which means that it decides which streams to send based on indications from the receiver such as packet loss, etc.   If there is substantial loss, the sender will adjust the streams it is sending.  In implementations where the SFU uses a distinct SSRC for each simulcast stream (as opposed to using the same SSRC but adjusting the resolution/framerate), it may pause sending one SSRC and resume sending another (lower bandwidth one).  Where MST is in use, the sender may pause an enhancement layer and subsequently resume sending it when it has reason to believe that there is sufficient bandwidth to handle it.  Whether receiver "wishes to receive" a stream doesn't really enter into the sender's decision if it determines that there isn't sufficient bandwidth available to send it successfully.
[BoB] Fully agree that bandwidth availability has higher precedence than any receiver's wishes. This is a typical case where "local considerations" override RTP stream receivers, as described in section 5.4. That is also one of the very reasons to include the REFUSED indication in the draft. This scenario is also viable when using TMMBR/TMMBN; a RESUME signaled through TMMBR>0 can be REFUSED using TMMBN 0 (likely indicating the RTP stream sender itself owning the bitrate restriction), as described in section 5.5. I realize that the text is not clear on using the RTP stream sender's own SSRC as the one owning the restriction in TMMBR/TMMBN signaling whenever "local considerations" apply, which I believe is useful here. I should probably add text about that in a few places. Agree?

---

From: Bo Burman <[email-masked]>
Date: Wed, 17 Sep 2014 14:13:36 +0000

Thank you! I'll amend the text accordingly, including the additional text in the note on TMMBR/TMMBN in section 9 and the IANA section.

> Sent: den 17 september 2014 08:21
> > Note that I need guidance on whether or not defined 'config' attribute values need to be somehow mentioned in IANA
> section, and in that case how to describe it. A reference to the table in Figure 6? Examples from other RFCs are welcome!
> >
> > Also, while editing the first part of section 9, I started to wonder if this specification can really promise that existing 'ccm
> tmmbr' signaling means TMMBR and TMMBN with value 0 is supported and will be treated correctly in all existing
> implementations? Should we not at least say there is no guarantee TMMBR and TMMBN implementations pre-dating this
> specification work exactly as described when used with a bitrate value of 0?
> >> 3) Cl.9 Para.1: With respect to the use of the rtcp-fb attribute I
> >> think the text should say "/MUST only be used as an SDP media attribute and MUST NOT be provided at the session
> level/". The use of "Recommended"
> > [BoB] I agree that "recommend" and "must" do not match. The current text in that sentence is a bit poorly written. I
> think it tries to both describe what is said in RFC 4585 and 5104 about the rtcp-fb attribute in general, as well as saying that
> it applies also for this specification. That statement is redundant. RFC 4585 section 4.2 is totally clear: "The 'rtcp-fb'
> attribute MUST only be used as an SDP media attribute and MUST NOT be provided at the session level". I think the
> sentence can be removed.
> [CNG] OK
> >
> > [BoB] My intent was to require that all implementations are able to at least receive _and ignore_ all messages from
> section 8, regardless of config. That would be in line with section 4.2 of RFC 4585: "RTP senders MUST be prepared to
> receive any kind of RTCP FB messages  and MUST silently discard all those RTCP FB messages that they do not
> understand", but is thus strictly redundant. I suggest to simply remove the sentence since it does not add anything.
> [CNG] OK
> > ..snip..
> >
> >>
> > [BoB] No. Declarative use of SDP seems to have this difference in interpretation of the SDP. First, see section 3.4 of RFC
> 4566 on Multicast Session Announcement that says "remote participants can use the session description to start the tools
> required to participate in the session". Second, compare with section 6 of RFC 4566 where a=recvonly is described as
> "specifies that the tools should be started in a receive-only mode". This indicates to me that the text currently in 9.2 is
> correct.
> [CNG] You may want to be more formal in the way the updates are specified to make it clear to IANA what exactly they
> have to do, e.g.
> similar to RFC5104.
> 
> 11. IANA Considerations
> 1) A new value for media stream pause / resume to be registered with IANA in the "FMT Values for RTPFB Payload
> Types" registry located at the time of publication at:
> 2) A new value "pause" to be registered with IANA in the "Codec Control Messages" registry located at the time of
> publication at:
> With regards to the "no wait" and "config" parameters I don't think you need a registry for these are they don't need to
> be extensible. RFCs
> For 4 & 5 'pause' Types, I'm not sure a registry is needed for these. I would assume that any new value would be as a
> result of a revision to the pause/resume RFC. If you set up a registry for these 'pause' types then you have to specify the
> process used in order to update it.
> 
> 
> >
> >>
> >> Regards, Christian
> >>
> >>
> >>> Please find enclosed a draft update implementing Christian's
> >>> suggested changes below. Affected sections are 9 and
> >> 10.1.
> >>>> consistency and clarity benefits in SDP signaling compared to what
> >>>> is currently in the text, and suggest that the text
> >>>> * The separate "ccm paused" parameter is removed, since support of
> >>>> PAUSED will instead be indicated through
> >> "config"
> >>>> BR
> >>>> /Bo
> >>>>
> >>>>>>>> either or both, while the answer MUST choose one and MUST NOT
> >>>>>>>> add anything that was not in the offer
> >>>>> sendonly,recvonly or sendrecv. It wouldn't be correct for the
> >>>>> endpoint to send "a=rtcp-fb:* ccm pause" because the
> >> default is "sendrecv".
> >> configurations you list are then possible to express, using direction
> >> parameter of both pause and paused ([] indicates optional).
> >>>> That split would however also mean there is a possibility to
> >>>> support PAUSE but not PAUSED, which I believe is an undesirable side-effect and definitely not in line with the
> current text.
> >>>>
> >>>> parameter with an explicit listing of supported messages and
> >>>> directions is indeed much easier to describe and is
> >>>>>>> supporting the sending and/or reception of PAUSE must also
> >>>>>>> support RESUME. A node supporting the reception of PAUSE/RESUME
> >>>>>>> must also
> >>>>>>> PAUSE/RESUME/PAUSED/REFUSED then it could signal e.g.
> >>>>>>> a=rtcp-fb:98 ccm pause
> >>>>> config=1 . Part of the confusion comes from the interaction
> >>>>> between the parameters. This would remove the
> >>>> interaction.
> >>>>>> [BoB] I get your point. There is significant inherent complexity
> >>>>>> in this that your proposal makes explicit and clarifies. I
> >>>>>> 	As you say above, acceptable Answers include 1, 4, 5 or 6, or
> >>>>>> (of
> >>>>>> course) removing "ccm pause" entirely
> >>>>> supporting this draft must support local pause? Otherwise there's
> >>>>> no way of saying "I won't send anything but if you do
> >>>> [BoB] I agree the 8 configurations you list makes sense to keep.
> >>>> They reflect the current text better than what I suggested.
> >>>>
> >>>>>> If those clarifications you list above on O/A and what messages
> >>>>>> are sent and/or received are made in the document, do
> >>>>> parameter "a=rtcp-fb* ccm paused"? If so then it wouldn't make
> >>>>> sense for an endpoint to send both "pause" and
> >>>> "paused".
> >>>>
> >>>> [BoB] As said above, just signaling ccm pause would have to mean
> >>>> that paused is not supported, so there would be no way to fall back
> >>>> to local pause, which is undesirable. Your "config" is
> >> better.
> >>>>> messages, only those messages are not "PAUSE" and "RESUME"? In
> >>>>> that case, could we call it something else than "direction"; like

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 17 Sep 2014 08:15:39 -0700

Comments below. 

From: [email-masked]
To: [email-masked]; [email-masked]
Subject: RE: [avtext] Review of  draft-ietf-avtext-rtp-stream-pause-02
Date: Wed, 17 Sep 2014 07:15:44 +0000

Responses inline
/Bo

From: avtext [mailto:[email-masked]]
On Behalf Of Bernard Aboba

To: [email-masked]

 

Section 1

   Mixer.

[BA] There is another potential use case for a centralized node.  Could stream pause/resume also be used to enable a centralized node to notify a receiver that it has chosen to pause a stream on its own (without being asked)?  For example, there are situations
 where an multi-stream SFU may wish to drop a layer (RTCP RRs or PLI indicates congestion).  Today this is handled via codec-specific messages (e.g. SEI layer drop).   However, if it was desired to handle this in a codec-independent way, could a centralized
 node send an unsolicited PAUSED (e.g. TMMBN = 0) message?
[BoB] Yes, that is the intention. I could add some text in the introduction about that. This is fully in line with the rest of the document. See for example
 first part of section 5.3 “Media Sender Pausing”;
   An RTP stream sender can choose to pause the stream at any time.
   This can either be as a result of receiving a PAUSE, or be based on
   some local sender consideration.  When it does, it sends a PAUSED
   indication, containing the available PauseID.  If the stream was
   paused by a TMMBR 0, TMMBN 0 is used as PAUSED indication.  What is
   said on PAUSED in the rest of this paragraph apply also to the use of
    TMMBN 0, except for PAUSED message parameters.
Do you think that the text need further clarification? I see no problem adding explicit text regarding unsolicited sending of TMMBN 0.
[BA] Yes, some clarification might be helpful in the case where the PAUSED is unsolicited.  For example, is there any reply to an unsolicited TMMBN 0?

Section 4.2

It is the responsibility of an RTP stream receiver, who wants to pause or resume a stream from the sender(s), to transmit PAUSE and RESUME messages.
An RTP stream sender who likes to pause itself, can simply do it. Any indication that an RTP stream is paused is the responsibility of the RTP stream sender and may in some cases not even be needed by the stream receiver.

[BA] Not sure I agree with this for the multi-stream transmission case.  If a sender stops sending a layer with no notification, then the receiver could be adversely affected.  For example, it could be waiting for a spatial enhancement layer that never shows
 up.   That is why we have SEI layer drop messages, right? 

[BoB] If you refer to the sentence marked in red above, it was intended to highlight a fact that was there already before this draft, not to specifically
 allow something that was previously disallowed. Maybe that sentence could be changed into something like “An RTP stream sender who likes to pause itself can often simply do it, but sometimes this will adversely affect the receiver and an explicit indication
 that the RTP stream is paused may then help”?
[BA] That would be helpful, yes. 

Section 4.4

An RTP stream sender should not pause an SSRC that some receiver still wishes to receive. The reason is that in RTP topologies where the stream is shared between multiple receivers, a single receiver on that shared network, independent of it being multicast,
 a mesh with joint RTP session or a transport Translator based, must not single- handedly cause the stream to be paused without letting all other receivers to voice their opinions on whether or not the stream should be paused. A consequence of this is that
 a newly joining receiver, for example indicated by an RTCP Receiver Report containing both a new SSRC and a CNAME that does not already occur in the session, firstly needs to learn the existence of paused streams, and secondly should be able to resume any
 paused stream. Any single receiver wanting to resume a stream should also cause it to be resumed.

[BA] In many simulcast and MST implementations, the centralized unit utilizes sender-based congestion control, which means that it decides which streams to send based on indications from the receiver such as packet loss, etc.   If there is substantial loss,
 the sender will adjust the streams it is sending.  In implementations where the SFU uses a distinct SSRC for each simulcast stream (as opposed to using the same SSRC but adjusting the resolution/framerate), it may pause sending one SSRC and resume sending
 another (lower bandwidth one).  Where MST is in use, the sender may pause an enhancement layer and subsequently resume sending it when it has reason to believe that there is sufficient bandwidth to handle it.  Whether receiver "wishes to receive" a stream
 doesn't really enter into the sender's decision if it determines that there isn't sufficient bandwidth available to send it successfully.

[BoB] Fully agree that bandwidth availability has higher precedence than any receiver’s wishes. This is a typical case where “local considerations” override
 RTP stream receivers, as described in section 5.4. That is also one of the very reasons to include the REFUSED indication in the draft. This scenario is also viable when using TMMBR/TMMBN; a RESUME signaled through TMMBR>0 can be REFUSED using TMMBN 0 (likely
 indicating the RTP stream sender itself owning the bitrate restriction), as described in section 5.5. I realize that the text is not clear on using the RTP stream sender’s own SSRC as the one owning the restriction in TMMBR/TMMBN signaling whenever “local
 considerations” apply, which I believe is useful here. I should probably add text about that in a few places. Agree?
[BA] Yes, I agree.

---

From: Bo Burman <[email-masked]>
Date: Fri, 19 Sep 2014 15:00:28 +0000

Bernard,

Please find attached a draft -03 version that tries to address your concerns, describing local pause a bit better and trying to clean up the text on use of TMMBR/TMMBN. There are multiple edits, which is why I choose to attach the entire text. It should be possible to use the diff tool on the IETF tools page to better see what I've done compared to -02. Note that there are also edits based on comments other than yours in the text, compared to -02 version.

Do you think that your concerns are sufficiently covered? Further comments are of course welcome!

Cheers,
/Bo

From: Bernard Aboba [mailto:[email-masked]]
Sent: den 17 september 2014 17:16
To: Bo Burman; [email-masked]
Subject: RE: [avtext] Review of draft-ietf-avtext-rtp-stream-pause-02

Comments below.
________________________________
From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [avtext] Review of draft-ietf-avtext-rtp-stream-pause-02
Date: Wed, 17 Sep 2014 07:15:44 +0000
Responses inline
/Bo

From: avtext [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: den 17 september 2014 06:53
To: [email-masked]<mailto:[email-masked]>
Subject: [avtext] Review of draft-ietf-avtext-rtp-stream-pause-02

Section 1

Section 4.2

Section 4.4

[BA] Yes, I agree.