Skip to main content

RTP Stream Pause and Resume
RFC 7728

Yes

(Alissa Cooper)
(Ben Campbell)

No Objection

Alvaro Retana
(Alia Atlas)
(Brian Haberman)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Terry Manderson)

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

Alvaro Retana
No Objection
Alissa Cooper Former IESG member
Yes
Yes (for -08)

                            
Ben Campbell Former IESG member
(was Discuss, Yes) Yes
Yes (for -09)

                            
Spencer Dawkins Former IESG member
Yes
Yes (2015-08-18 for -08)
This draft was really easy for me to read (with some background in RTP/RTCP, but I'm no expert on the topic). Thank you for the work on it - the results show.

I have some questions, but nothing is a show-stopper.

In this text:

3.3.  RTP Mixer to Media Sender in Point-to-Multipoint

   In this use case there are several receivers of a stream and special
   care must be taken as not to pause a stream that is still wanted by
   some receivers.
   
I'm assuming that the Mixer is taking special care, but this is passive enough that I'm filling in blanks. If you like passive voice, perhaps something like

   In this use case there are several receivers of a stream and special
   care must be taken by the Mixer so as not to pause a stream that is 
                      ^^^^^^^^^^^^^^^
   still wanted by some receivers.
   
would be easier to parse.

If you can do active voice, perhaps 

   In this use case there are several receivers of a stream and the 
   Mixer must take special care so as not to pause a stream that is still 
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   wanted by some receivers.
   
In this text:

8.  Message Details

   Any references to PAUSE, PAUSED, RESUME and REFUSED in this section
   SHALL be taken to apply to the extent possible also when TMMBR/TMMBN
   are used (Section 5.6) for this functionality.  TMMBR/TMMBN MAY be
                                                               ^^^
   used instead of the messages defined in this specification when the
   effective topology is point-to-point.  If either sender or receiver
   learns that the topology is not point-to-point, TMMBR/TMMBN MUST NOT
   be used for pause/resume functionality.  If the messages defined in
   this specification are supported in addition to TMMBR/TMMBN by all
   involved parties, pause/resume signaling MUST use messages from this
   specification.  If the topology is not point-to-point and the
   messages defined in this specification are not supported, pause/
   resume functionality with TMMBR/TMMBN MUST NOT be used.
   
All of this makes sense to me, except that I'm not understanding why TMMBR/TMMBN is a MAY. There's a lot of text that says you really need to use the messages from this specification in this case, and in that case, and ... but here, you MAY do something else.

I understand that TMMBR/TMMBN works in a point-to-point topology, but is there a reason to prefer TMMBR/TMMBN in that topology? If so, it would probably be good to explain why.

And as I read futher, I see this, in section 9:

      Note: When TMMBR 0 / TMMBN 0 are used to implement pause and
      resume functionality (with the restrictions described in this
      specification), signaling rtcp-fb attribute with ccm tmmbr
      parameter is sufficient and no further signaling is necessary.
      There is however no guarantee that TMMBR/TMMBN implementations
                       ^^^^^^^^^^^^
      pre-dating this specification work exactly as described here when
      used with a bitrate value of 0.
      
and that really makes me wonder why this specification is also describing TMMBR/TMMBN. I'm sure there's a good reason, but can you understand my confusion?

Finally, I see this, in section 9.1,

   If both "pause" and "tmmbr" are present in the offer, both MAY be
   included also in the answer, in which case TMMBR/TMMBN MUST NOT be
   used for pause/resume purposes (with a bitrate value of 0), to avoid
   signaling ambiguity.
   
and in section 9.2,

   If both "pause" and "tmmbr" are present in the SDP, TMMBR/TMMBN MUST
   NOT be used for pause/resume purposes (with a bitrate value of 0), to
   avoid signaling ambiguity.
   
I'm now wondering if the description of TMMBR/TMMBN in this specification just for interworking with older implementations that don't support PAUSE/RESUME but figured out how to get a similar effect with TMMBR/TMMBN? 

I'm guessing, of course :-)

In this text:

8.5.  Transmission Rules

   o  PAUSE SHOULD use Early or Immediate timing, except for
      retransmissions that SHOULD use Regular timing.
      
^ I understand this one.

   o  The first transmission of PAUSED for each (non-wrapped) PauseID
      SHOULD be sent with Immediate or Early timing, while subsequent
      PAUSED for that PauseID SHOULD use Regular timing.  Unsolicited
      PAUSED (sent when entering Local Paused State (Section 6.4))
      SHOULD always use Immediate or Early timing, until PAUSED for that
      PauseID is considered delivered at least once to all receivers of
      the paused RTP stream, after which it SHOULD use Regular timing.

^ I'm wondering why these are SHOULDs. Are they MUSTs except that some implementations don't do it, or recommendations but nothing breaks if you don't do them, or something else?

   o  RESUME SHOULD always use Immediate or Early timing.

^ I wonder why this is SHOULD. Is there any guidance you can provide about why RESUME would use Regular timing?

   o  The first transmission of REFUSED for each (non-wrapped) PauseID
      SHOULD be sent with Immediate or Early timing, while subsequent
      REFUSED for that PauseID SHOULD use Regular timing.

^ I am, of course, wondering about the corresponding SHOULDs for REFUSED.

In this text:

9.  Signaling

   When signaling a config value other than 1, an implementation MUST
   ignore non-supported messages on reception, and MAY omit sending non-
   supported messages.
   
is this saying that an implementation might send non-supported messages? I'm confused here.
Alia Atlas Former IESG member
No Objection
No Objection (for -08)

                            
Barry Leiba Former IESG member
No Objection
No Objection (2015-08-19 for -08)
I have a meta-question about why this "updates" 5104.  It appears to be an extension to 5104, using normal extension mechanisms -- someone implementing 5104 and not intending to implement this would have no reason to look at this document, as far as I can tell.  I don't see anything that describes a *change* to 5104 (though perhaps I've missed it).  What's the reasoning behind specifying "updates"?
Brian Haberman Former IESG member
No Objection
No Objection (for -08)

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -08)

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -08)

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -08)

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-08-18 for -08)
The SecDir review brought up a couple of attack types and at least the first should be mentioned in the security considerations section, replay protection.  For the second, does it apply?

https://www.ietf.org/mail-archive/web/secdir/current/msg05921.html

Thank you.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -08)

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2015-08-19 for -08)
- 58 pages! There is quite a bit of repetition here but too
late to change now. 

- I see there are 2 IPR declarations, both with possible
royalty/fee and neither that I can see actually specifying
what patent (or other property) is involved despite both
declarations being some years old.  (And there was me thinking
remote controls were almost older than me, but I guess what do
I know and the USPTO must always be right;-) Anyway, can
someone point me at where the working group said they were ok
with this situation?  (The shepherd write up says that
happened so I hope it's not hard to get that pointer.)

- Section 7: in a multiparty call, say participant#1 hits
pause with PauseID = 0x0001, and stuff is resumed some time
later, is participant#2 supposed to use a PauseID of 0x0002
subsequently? In other words does the SHALL there apply to
everyone on the call or just to the participant who sent out
the last PAUSE message?  If the former, does that create a
race condition? Or maybe that's a harmless race? I guess you
could reduce the probability of a race by recommending that
PauseID be randomly selected between last-PauseID-seen and
last-PauseID-seen+(2^14) or something like that?  (And
apologies if all this is obvious to someone expert in RTP, I
am not that person:-)
Terry Manderson Former IESG member
No Objection
No Objection (for -08)