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

From: Brian Rosen <[email-masked]>
Date: Mon, 2 Jun 2014 12:26:29 -0400

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Jun 2014 14:38:41 -0400

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.

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.)

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.

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?

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.

Section 7.3.2:

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

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.

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/

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

Section 11.3:

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

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.

	Thanks,
	Paul

On 6/2/14 12:26 PM, Brian Rosen wrote:
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sat, 14 Jun 2014 04:51:40 +0000

Thanks for reviewing Paul. Please see inline.

>perhaps we should have a section on this in the Security Considerations

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?

>course the SRS could choose to refuse such sessions, or set them to

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?

>    media stream as sendonly.

Okay with me.

>changed from on->paused or paused->on?

I think so.

>    paused:  Recording is in progress but media is paused.

Good idea.

>suggested above for section 7.1.2.

Sounds good.

>    and what the SRC sends on the RS.

I like it.

>s/In doing to/In doing so/

Good catch.

>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.

>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)

>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

>> 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