Re: [siprec] Working Group Last Call on -protocol

["Charles Eckel (eckelcu)" <[e-mail]>]

Thanks for reviewing Paul. Please see inline.

On 6/3/14, 11:38 AM, "Paul Kyzivat" <[e-mail]> wrote:

>I just did a reasonably careful review of the document.
>In general I think it is in very good shape. I found a few things that
>need fixing, or at least discussing:
>
>Section 6.1.2:
>
>We debated the language in this section extensively, and IMO we chose
>the proper level of requirement. But I anticipate we will have some
>(maybe a lot) of difficulty over this with the IESG - with some no doubt
>arguing that this isn't strong enough.
>
>I wonder if we ought to anticipate this, and include a note explaining
>our thinking. (The point of concern is for "in the absence ...) Or
>perhaps we should have a section on this in the Security Considerations
>section.

I see it as we are providing a new and hopefully better indication that
recording is occurring. We are not removing or blocking existing
indications, and we require the existing indications to still be used when
the new indication cannot. We could add a warning that in the presence of
an implementation that is not compliant with this specification recording
may occur without any explicit indication, but that does not seem very
useful. Did you have something else in mind?

>
>Section 7.1.1.1:
>
>Upon reading this again, I realized that we don't say anything about
>media streams that don't have labels, or that have labels without a
>corresponding reference in the metadata.
>
>I guess the first question is whether we think this is an acceptable
>thing to do. IMO it is. This could be used to "park" a media stream that
>isn't currently needed for recording. Then it could be reused later. (Of
>course the SRS could choose to refuse such sessions, or set them to
>inactive.)

The way I read section 7.1.1, there must always be a label, regardless of
whether the media line is actively being recorded.

"The SRC sends recorded streams of participants to the SRS, and the
   SRC MUST provide a label attribute (a=label), as per [RFC4574], on
   each media stream in order to identify the recorded stream with the
   rest of the metadata.²

Do we need to added complexity of having non-labelled media lines?

>
>While I understand the intent of the following sentence, it could be
>confusing:
>
>                                                        ... The SRC MUST
>    NOT modify the RS media stream with a=inactive for SDP hold on the CS
>    since this operation is reserved for pausing the RS media, however,
>    an SRC can have a local policy to pause the RS media when the CS is
>    placed on hold.
>
>The second half seems to almost contradict the first half. How about the
>following
>
>    When a CS media stream is changed to/from inactive, the effect on the
>    corresponding RS media stream is governed by SRC policy. The SRC
>    MAY have a local policy to pause an RS media stream when the
>    corresponding CS media stream is inactive, or it MAY leave the RS
>    media stream as sendonly.

Okay with me.

>
>Section 7.1.2:
>
>I wonder if:
>
>    Whenever the recording
>    indication needs to change, such as termination of recording, then
>    the SRC MUST initiate a reINVITE or UPDATE to update the SDP a=record
>    attribute.
>
>is a little too strong. Is it mandatory to notify that the state has
>changed from on->paused or paused->on?

I think so.

>
>Editorial comment on following:
>
>    on Recording is in progress.
>
>    off  No recording is in progress.
>
>    paused  Recording is in progress but media is paused.
>
>I think the terms should be set of from the definitions. E.g.,
>
>    on: Recording is in progress.
>
>    off:  No recording is in progress.
>
>    paused:  Recording is in progress but media is paused.

Good idea.

>
>Section 7.3.2:
>
>I suggest that the definitions of 'on', 'off', ... be revised as I
>suggested above for section 7.1.2.

Sounds good.

>
>Section 8.2.1.2:
>
>    When acting as a transcoding translator, an SRC MAY perform
>    transcoding (e.g., from one codec to another), and this may result in
>    a different rate of packets between what the SRC receives and what
>    the SRC sends.
>
>Note that the SRC is transmitting on both CS and RS. I think the
>following would be clearer:
>
>    When acting as a transcoding translator, an SRC MAY perform
>    transcoding (e.g., from one codec to another), and this may result in
>    a different rate of packets between what the SRC receives on the CS
>    and what the SRC sends on the RS.

I like it.

>
>Section 8.3.2:
>
>Last sentence in 2nd paragraph has a typo:
>
>    In doing to, the
>    SRC acts as an RTP mixer.
>
>s/In doing to/In doing so/

Good catch.

>
>Firgure 10 also has a typo. The SSRC of the video session between SRC
>and SRS should be Sv, not Sa.

Your comment has a type (s/Firgure/Figure), so I propose we leave it as
is. Just kidding. VERY good catch.

>
>Section 11.3:
>
>This content disposition is used for both metadata and for snapshot
>requests. But snapshot requests aren't mentioned here.

How about this:

OLD

recording-session the body describes the metadata information about
the recording session


NEW
recording-session: the body describes either:
 - the metadata information about the recording session or
 - the reason for a metadata snapshot request
as determined by the MIME value indicated in the Content-Type (see section
11.4)



>
>Sections 11.5.1 and 11.5.2:
>
>Do we want these individual contact anmes and email addresses, or
>something more generic? The email address for Leon is no longer correct.

We can and should update Leon¹s address to match that in the author list.
Not sure what to do beyond that.

Cheers,
Charles

>	Thanks,
>	Paul
>
>On 6/2/14 12:26 PM, Brian Rosen wrote:
>> This email announces a 3 week working group last call on
>>draft-ietf-siprec-protocol-12.
>>
>> Please send comments to the list.  If you have read the latest draft,
>>and believe it is ready to publish, please say so affirmatively.
>>
>> Chairs
>> _______________________________________________
>> siprec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/siprec
>>
>
>_______________________________________________
>siprec mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/siprec