Subject: Re: [siprec] Normative Statements in draft-ietf-siprec-protocol-13

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 12 Aug 2014 21:43:24 +0000

Hi Alan,

Thanks for the valuable comments. Please see my proposed resolution for each inline.

From: Alan Johnston <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 25, 2014 at 7:50 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [siprec] Normative Statements in draft-ietf-siprec-protocol-13

Here's a few comments on some normative statements in draft-ietf-siprec-protocol-13.

"In order to communicate most effectively, the Session Recording Client (SRC), the Session Recording Server (SRS), and any Recording aware User Agents (UAs) SHOULD utilize the mechanisms provided by RTP in a well-defined and predicable manner."

I question whether this statement should have normative language, since it isn't testable at all.

I agree. Let’s change to “should”.

"Using the FIR command to recover from errors is explicitly disallowed, and instead the PLI message SHOULD be used."

The use of "disallowed" seems like a MUST NOT, but then PLI is a SHOULD which is confusing.  I'd suggest using normative language instead of disallowed.

This was taken from RFC 5104, which reads as follows, "Using the FIR command to recover from errors is explicitly disallowed, and instead the PLI message defined in AVPF [RFC4585] should be used.  The PLI message reports lost pictures and has been included in AVPF for precisely that purpose.”

Section 8.1.7.2 of the SIP protocol drafts currently reads as follows, "Picture Loss Indication (PLI), as defined in [RFC4585], informs the encoder of the loss of an undefined amount of coded video data belonging to one or more pictures.  Using the FIR command to recover from errors is explicitly disallowed, and instead the PLI message SHOULD be used.  FIR SHOULD be used only in situations where not sending a decoder refresh point would render the video unusable for the users.”

How about we change to, "Picture Loss Indication (PLI), as defined in [RFC4585], informs the encoder of the loss of an undefined amount of coded video data belonging to one or more pictures.  [RFC4585] recommends using PLI instead of FIR to recover from errors. FIR is appropriate only in situations where not sending a decoder refresh point would render the video unusable for the users.”

There are a bunch of normative statements that are repeated twice in different sections.  For example:

"If packet loss occurs from the UA to the SRC, the SRC SHOULD detect and attempt to recover from the loss."

This statement appears in 8.2.2 and 8.2.3 for mixer and endpoint scenarios.  There are similar things in 8.3.1 and 8.3.2.   Do we really want to repeat this text?  If not, perhaps we could consolidate these two sections into three:

- Section with normative statements that apply to both mixing and endpoint
- Section with normative for mixing only
- Section with normative for endpoint only

Or, if we do want to keep the existing structure, maybe the normative statements could be prefixed with "For RTP mixing..." or "For RTP endpoint..." so each normative statement is unique.

Section 8.2 deals with 4 types of RTP entities:

  1.  Forwarding translator
  2.  Transcoding translator
  3.  Mixer
  4.  Endpoint

There is a subsection for each, and as you noted, there is normative language regarding packet loss within each subsection. Normative language exists in each subsection. Each subsection is structured similarly, and as you noted, there is duplicated of normative language within each. I thought this helped with readability from the perspective of someone implementing the spec, but there are tradeoffs. We could pull packet loss into its own subsection that deals with all 4 types of RTP entities. This might read as follows:

"Section 8.x. Packet Loss

If packet loss occurs from the UA to the SRC, the SRC, if acting as an  RTP mixer or RTP endpoint, SHOULD detect and attempt to recover from the loss. If acting as an RTP translator (either forwarding or transcoding), the SRC does detect or attempt to recover from the loss. It simply forwards the associated RTP and RTCP packets. In such cases, as well as if packet loss occurs from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the loss.”

Note that this still leaves other normative language in the individual subsection. Is this okay/better?
Something similar could be done for section 8.3, which describes different RTP session usages:

  1.  SEC using multiple m-lines
  2.  SRC using mixing

I made a couple attempts at this prior to sending this e-mail, but I was not happy with the end results. I’m inclined to leave as is, but am open to it being reworked as well.

Cheers,
Charles

- Alan -

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 15 Aug 2014 13:33:21 +0000

Alan,

Could you let us know if you are happy with the changes Charles suggests.

We would like to get this draft submitted to the IESG.

Regards
Andy

From: siprec [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: 12 August 2014 22:43
To: Alan Johnston; [email-masked]
Subject: Re: [siprec] Normative Statements in draft-ietf-siprec-protocol-13

Hi Alan,

I agree. Let's change to "should".

This was taken from RFC 5104, which reads as follows, "Using the FIR command to recover from errors is explicitly disallowed, and instead the PLI message defined in AVPF [RFC4585] should be used.  The PLI message reports lost pictures and has been included in AVPF for precisely that purpose."

Section 8.1.7.2 of the SIP protocol drafts currently reads as follows, "Picture Loss Indication (PLI), as defined in [RFC4585], informs the encoder of the loss of an undefined amount of coded video data belonging to one or more pictures.  Using the FIR command to recover from errors is explicitly disallowed, and instead the PLI message SHOULD be used.  FIR SHOULD be used only in situations where not sending a decoder refresh point would render the video unusable for the users."

How about we change to, "Picture Loss Indication (PLI), as defined in [RFC4585], informs the encoder of the loss of an undefined amount of coded video data belonging to one or more pictures.  [RFC4585] recommends using PLI instead of FIR to recover from errors. FIR is appropriate only in situations where not sending a decoder refresh point would render the video unusable for the users."

  1.  Forwarding translator

If packet loss occurs from the UA to the SRC, the SRC, if acting as an  RTP mixer or RTP endpoint, SHOULD detect and attempt to recover from the loss. If acting as an RTP translator (either forwarding or transcoding), the SRC does detect or attempt to recover from the loss. It simply forwards the associated RTP and RTCP packets. In such cases, as well as if packet loss occurs from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the loss."

  1.  SEC using multiple m-lines
  2.  SRC using mixing
I made a couple attempts at this prior to sending this e-mail, but I was not happy with the end results. I'm inclined to leave as is, but am open to it being reworked as well.

Cheers,
Charles

- Alan -

---

From: Alan Johnston <[email-masked]>
Date: Fri, 15 Aug 2014 09:30:07 -0500

Charles,

Thanks for the reply.   I'm fine with your suggestions.

- Alan -

On Fri, Aug 15, 2014 at 8:33 AM, Hutton, Andrew <[email-masked]>
wrote:

> *From:* siprec [mailto:[email-masked]] *On Behalf Of *Charles
> Eckel (eckelcu)
> *Sent:* 12 August 2014 22:43
> *To:* Alan Johnston; [email-masked]
> *Subject:* Re: [siprec] Normative Statements in
> draft-ietf-siprec-protocol-13
>
>
>
> Hi Alan,
>
>
>
> *From: *Alan Johnston <[email-masked]>
> *Date: *Friday, July 25, 2014 at 7:50 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[siprec] Normative Statements in draft-ietf-siprec-protocol-13
>
>
>
> "In order to communicate most effectively, the Session Recording Client
> (SRC), the Session Recording Server (SRS), and any Recording aware User
> Agents (UAs) SHOULD utilize the mechanisms provided by RTP in a
> well-defined and predicable manner."
>
>
>
> "Using the FIR command to recover from errors is explicitly disallowed,
> and instead the PLI message SHOULD be used."
>
>
>
> The use of "disallowed" seems like a MUST NOT, but then PLI is a SHOULD
> which is confusing.  I'd suggest using normative language instead of
> disallowed.
>
>
>
> This was taken from RFC 5104, which reads as follows, "Using the FIR
> command to recover from errors is explicitly disallowed, and instead the
> PLI message defined in AVPF [RFC4585] should be used.  The PLI message
> reports lost pictures and has been included in AVPF for precisely that
> purpose.”
>
>
>
> Section 8.1.7.2 of the SIP protocol drafts currently reads as follows,
> "Picture Loss Indication (PLI), as defined in [RFC4585], informs the
> encoder of the loss of an undefined amount of coded video data belonging to
> one or more pictures.  Using the FIR command to recover from errors is
> explicitly disallowed, and instead the PLI message SHOULD be used.  FIR
> SHOULD be used only in situations where not sending a decoder refresh point
> would render the video unusable for the users.”
>
>
>
> How about we change to, "Picture Loss Indication (PLI), as defined in
> [RFC4585], informs the encoder of the loss of an undefined amount of coded
> video data belonging to one or more pictures.  [RFC4585] recommends using
> PLI instead of FIR to recover from errors. FIR is appropriate only in
> situations where not sending a decoder refresh point would render the video
> unusable for the users.”
>
>
>
>
>
> This statement appears in 8.2.2 and 8.2.3 for mixer and endpoint
> scenarios.  There are similar things in 8.3.1 and 8.3.2.   Do we really
> want to repeat this text?  If not, perhaps we could consolidate these two
> sections into three:
>
>
>
> Or, if we do want to keep the existing structure, maybe the normative
> statements could be prefixed with "For RTP mixing..." or "For RTP
> endpoint..." so each normative statement is unique.
>
>
>
>  There is a subsection for each, and as you noted, there is normative
> language regarding packet loss within each subsection. Normative language
> exists in each subsection. Each subsection is structured similarly, and as
> you noted, there is duplicated of normative language within each. I thought
> this helped with readability from the perspective of someone implementing
> the spec, but there are tradeoffs. We could pull packet loss into its own
> subsection that deals with all 4 types of RTP entities. This might read as
> follows:
>
>
>
> If packet loss occurs from the UA to the SRC, the SRC, if acting as an
>  RTP mixer or RTP endpoint, SHOULD detect and attempt to recover from the
> loss. If acting as an RTP translator (either forwarding or transcoding),
> the SRC does detect or attempt to recover from the loss. It simply forwards
> the associated RTP and RTCP packets. In such cases, as well as if packet
> loss occurs from the SRC to the SRS, the SRS SHOULD detect and attempt to
> recover from the loss.”
>
>
>
>  I made a couple attempts at this prior to sending this e-mail, but I was
> not happy with the end results. I’m inclined to leave as is, but am open to
> it being reworked as well.
>
>
>
> Cheers,
>
> Charles
>
>
>
>
>
> - Alan -
>
>
>
>
>
>
>
>