Subject: [siprec] WGLC on draft-ietf-siprec-protocol-10

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 9 Sep 2013 08:23:04 +0000

We would like to start a working group last call of http://tools.ietf.org/html/draft-ietf-siprec-protocol-10

Please send comments by the end of the day on September 22nd (Two weeks).

The deadline for requesting a meeting during IETF88 (Vancouver) is Sept 23rd and whether or not there are WGLC comments on this draft may determine whether we need a SIPREC meeting in Vancouver.

Regards
Andy (SIPREC Co-Chair).

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Sep 2013 17:57:48 -0400

I hadn't read this all the way through for a long time. (I've just been 
looking at the diffs.) It is instructive to read it all. I found a lot 
of relatively minor stuff, and one thing that is going to require more 
thought and discussion.

Many places containing ABNF:

The operator "/=" is being used, but the correct operator is "=/".
This suggests that a syntax verification of the ABNF is called for.
There is a tool for that. But to do it right requires extracting all the 
ABNF, merging with the referenced ABNF, and then running the tool.

The remaining comments follow the order of text in the document.

Section 5:

    Section 6 describes SIP the handling in a recording session between a
    SRC and a SRS, and the procedures for recording-aware user agents
    participating in a CS.

I can't parse the beginning of this sentence. I think you might mean:

    Section 6 describes the SIP handling in a recording session between
    a SRC and a SRS, ...

Section 6.1.1.1:

    In addition, when an SRC sends a REGISTER request
    to a registrar, the SRC MUST include the '+sip.src' feature tag to
    indicate the that it is a SRC.

This could be misinterpreted. And I'm not sure it should always be true.

Consider an ordinary UA that sometimes or always acts as an SRC to 
record its own calls. Why would it want to indicate this to a registrar. 
That might be a good thing, if a caller wants to use callerprefs to 
select a callee UA that can record calls. But that is an odd thing to do.

It could be a good thing if there is a pool of B2BUAs that are 
registered to a common AOR. It would allow recruiting one by sending an 
INVITE to it. But this is also very obscure usage. Normally B2BUAs are 
selected more overtly, and not by the UAC.

Its especially bad if this is taken literally by a box that is don't 
registrations of contact URIs other than its own. For instance, a PBX 
B2BUA box that is an SRC, but that also registers contact URIs on behalf 
of its endpoints. It would not want to do this on behalf of those 
endpoints.

So can someone refresh my memory about why this is a good thing?

If this is to be kept, then it would be better if it is worded as:

    When the URI of an SRC is included in a REGISTER request to a
    registrar, then the '+sip.src' feature tag SHOULD be included in the
    contact URI for the SRC.

Section 6.2:

Similar issue to the one above for section 6.1.1.1.

    In addition, when
    an SRS sends a REGISTER request to a registrar, the SRS MUST include
    the '+sip.srs' feature tag to indicate that it is a SRS.

At least it is more likely that an SRC might be sending an INVITE to an 
AOR in order to reach an SRS, so this might have some utility. (But 
would an AOR used to describe SRSs have any registrations for non-SRSs? 
And some of the problem cases I mentioned re SRCs are less likely for 
SRSs. But I still recommend the analogous text change here:

    When the URI of an SRS is included in a REGISTER request to a
    registrar, then the '+sip.srs' feature tag SHOULD be included in the
    contact URI for the SRS.

Section 6.3:

    A recording-aware UA MUST be prepared to provide recording indication
    to the end user through an appropriate user interface an indication
    whether recording is on, off, or paused for each medium.

I can't parse this sentence. How about:

    A recording-aware UA MUST be prepared to provide a recording
    indication to the end user through an appropriate user interface,
    indicating whether recording is on, off, or paused for each medium.

Section 7.1.1.1:

The following is slightly ambiguous:

    Note that a CS
    itself may change the media stream direction by updating the SDP, for
    example, by setting a=inactive for SDP hold.  Media stream direction
    changes in CS are conveyed in the metadata by the SRC.  The SRC MUST
    NOT modify the 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.

In the last sentence above, it isn't clear which media stream is being 
referenced in "The SRC MUST NOT modify the media stream". So I suggest 
changing this to:

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

Section 7.1.3:

    When the SRC receives the a=recordpref SDP in an SDP offer or answer,
    the SRC chooses to honor the preference to record based on local
    policy at the SRC.  Whether or not the SRC honors the recording
    preference, the SRC MUST update the a=record attribute to indicate
    the current state of the recording (on/off/paused).

Its unclear to me what the MUST means. The following are some things 
that might be done:

- if the a=recordpref is received in an offer, put the resulting
   a=record setting in the answer.

- if the a=recordpref is received in an offer or answer, send a new
   offer *soon* to all CS legs with the resulting a=record.

- same as above. Unconditionally send to leg that changed a=recordpref,
   but don't send again to other legs if recording state remains
   as it was.

Also, ISTM that once a UA has put a=recordpref in its SDP, it will 
probably leave it there, unchanged, through subsequent O/A cycles. That 
means, for the above, every time it sends an offer or answer, it will be 
sending a=recordpref again. It would be unfortunate if that forced the 
SRC to send *another* offer. (It could lead to an infinite o/a loop.)

I *don't* think it is a good idea to treat this as a one-time request.

So I suggest that both a=recordpref and a=record should be viewed as 
*state* that is announced in every offer or answer. As long as the state 
remains unchanged, it is just put into each offer or answer when they 
are required for other purposes. When one of them changes state, then an 
offer or answer must be sent asap to announce the change.

Section 7.3: (THE BIG ISSUE IS HERE)

This section brings up the situation where there are multiple SRCs in 
the CS. That presents some other issues that I don't think we have 
considered. Suppose we have:

UA1 ----- SRC1 ---- B2BUA ---- SRC2 ----- UA2

(UA1, B2BUA, and UA2 all indicate they are recording aware.)

Now suppose SRC1 is recording, and SRC2 is not recording. What sort of 
recording indications do we have in the CS signaling?

Initially
- SRC1 would send a=recording:on to UA1 and B2BUA
- SRC2 would send a=recording:off to UA2 and B2BUA
- B2BUA would propagate a=recording:on to SRC2
   and propagate a=recording:off to SRC1 ???

Then, what do SRC1 and SRC2 do when they receive these values from the 
B2BUA?

This is actually quite a mess. I think *somebody* needs to keep a count 
of recordings. Either we put the count into the attributes, or we make 
some of the components keep the count. The latter might be easier. I 
think only recording aware B2BUAs and conference foci (including those 
that are SRCs) would need to do this. They would need to keep a count 
over all their legs. (And an SRC B2BUA would include its own recording 
in this count.) When the count is zero the recording state is off, else 
it is on. (Need more analysis for what to do with pause.)

Some similar treatment is probably required for recordpref. My head 
hurts now, so I'm not doing it here.

I think we need some list discussion on this! Note that the solution to 
this will probably invalidate the suggestion I made for 7.1.3.

Section 8.1.5.1:

Do we want to reference the new mechanism for chooseing CNAME that has 
been proposed by EKR? (I forget the draft name, or if it has become and 
RFC.)

Section 8.2:

First paragraph:

    There are numerous ways in which an SRC may do this is, including but
    not limited to, appearing as a UA within a CS, or as a B2BUA between
    UAs within a CS.

s/do this is/do this/

Section 8.3:

    An SRC may
    choose to use one or more of the RTP session usages within a single
    RS.  For the purpose of base interoperability between SRC and SRS, an
    SRC MUST support separate m-lines in SDP, one per CS media direction.

I find the above confusing. (But maybe just because I don't understand 
enough about RTP.) Isn't the SRC the one that is deciding what usage to 
employ? If so, and if it must support separate m-lines, then under what 
circumstance would it employ anything else?

Is the intended to be determined by configuration during deployment?
Or my multiple o/a attempts? Or by CAPNEG? Or what?

Section 8.3.1:

    Additionally, the SRC SHOULD map each
    unique combination of CNAME/SSRC within the CSs to a unique CNAME/
    SSRC within the RS.

Isn't it ok to map both CNAME1/SSRC1 and CNAME1/SSRC2 in the CS to 
CNAMEn/SSRCn in the RS? The above statement seems to suggest not.

Section 8.4:

IIUC, normal draft style is to indent notes relative to the surrounding 
text.

Section 9.1:

    When the SRC sends a full metadata snapshot, the SRC MUST
    send an INVITE or an UPDATE request ... A
    partial update sent by the SRC can be an INVITE request or response
    with an SDP offer, or an INVITE/UPDATE request or response containing
    a "recording-session" disposition, or an INVITE request containing
    both an SDP offer and the "recording-session" disposition.

I find the above confusing.

For one thing, disposition is associated with a body part, not a 
request. A request can have multiple body parts, each with its own 
disposition. Offers and answers are carried in body parts with 
disposition "session". (Its the default, so you don't often see it 
written.) There could also be other body parts. We don't care about 
those so we ignore them. In principle a given body part with a 
particular disposition might be valid with any of a variety of content 
types. But in practice, session always contains application/sdp and 
recording-session always contains application/rs-metadata or 
application/rs-metadata-request. So we can simply talk about the 
possibilities in terms of the content types it contains. In the case of 
SDP, it may be either an offer or answer. That is only determined by 
context - you cant tell by looking at a single message.

AFAIK we have the following valid sip signaling possibilities on the RS:

- INVITE by SRC:   offer-sdp, metadata
   response by SRS: answer-sdp
- INVITE by SRC:   offer-sdp
   response by SRS: answer-sdp
- INVITE by SRS:
   response by SRC: offer-sdp, metadata
- INVITE by SRS:
   response by SRC: offer-sdp
- UPDATE by SRC:   offer-sdp, metadata
   response by SRC: answer-sdp
- UPDATE by SRC:   offer-sdp
   response by SRS: answer-sdp
- UPDATE by SRS:
   response by SRC:
- UPDATE by SRS:   offer-sdp
   response by SRC: answer-sdp
- UPDATE by SRS:   metadata-request
   response by SRC:

Of those, only three carry metadata:

- INVITE by SRC:   offer-sdp, metadata
- INVITE by SRS:
   response by SRC: offer-sdp, metadata
- UPDATE by SRC:   offer-sdp, metadata

That is independent of whether the metadata is a snapshot or a partial.
The special case for a snapshot request is:

- UPDATE by SRS:   metadata-request
   response by SRC:

and followed by one of the two above initiated by the SRC:

- INVITE by SRC:   offer-sdp, metadata
- UPDATE by SRC:   offer-sdp, metadata

So how to say all that in a comprehensible way? How about replacing that 
entire paragraph with the following:

"Metadata sent by the SRC can be categorized as either a full metadata 
snapshot or partial update.  A full metadata snapshot describes all the 
recorded streams and all metadata associated with the recording session. 
The SRC MAY send a full metadata snapshot at any time. The SRC MAY send 
a partial update if a full metadata snapshot has previously been sent. 
If the SRC receives a snapshot request from the SRS, then it MUST 
immediately send a full metadata snapshot.

The SRC MAY send metadata (either a full metadata shapshot or a partial 
update) in either an INVITE request, an UPDATE request, or in the final 
(200) response to an offerless INVITE from the SRS. If any of the 
metadata being sent contains a reference to any SDP labels, then the 
request containing the metadata MUST also contain an SDP offer that 
defines those labels.

When an INVITE or UPDATE request contains both an SDP offer and 
metadata, then the request body has content type multipart/mixed, with 
one subordinate body part containing the SDP offer and another 
containing the metadata. When an INVITE contains only an SDP offer or 
metadata, then the multipart/mixed container is optional."

Figure 11:

(A nit) there is no need for "application/rs-metadata" in the Accept. 
(This only describes what can be *received*, and the SRC will never 
receive this.)

Section 9.2:

    When the SRS explicitly requests for a full metadata snapshot, the
    SRS MUST send an UPDATE request without an SDP offer.  A metadata
    snapshot request contains a content with the content disposition type
    "recording-session". ...

The above is at least awkward. How about:

    The SRS MAY explicitly request a full metadata snapshot by sending
    an UPDATE request. This request MUST contain a body with a content
    disposition type "recording-session", and MUST NOT contain an SDP
    body part. ...

Then further into this section:

    When the SRC receives the request for a metadata snapshot, the SRC
    MUST provide a full metadata snapshot in a separate INVITE or UPDATE
    transaction, along with an SDP offer.  All subsequent metadata
    updates sent by the SRC MUST be based on the new metadata snapshot.

Most of the time SDP will be required. But its possible that there are 
currently no media streams, and hence no references to SDP. In that case 
the SDP isn't needed. (To avoid the SDP, the metadata would need to be 
sent in an UPDATE.) I covered the cases where SDP must be sent in my 
proposed changes above, so it doesn't really need to be mentioned here.

Also, subsequent partial updates could depend on future full snapshots, 
not just this one.

So how about changing the above to:

    When the SRC receives a request for a metadata snapshot, it MUST
    immediately provide a full metadata snapshot in a separate INVITE or
    UPDATE transaction. Any subsequent partial updates will not be
    dependent on any metadata sent prior to this full metadata snapshot.

Section 9.2.1:

The ABNF references TEXT-UTF8-TRIM, but doesn't specify where this is 
defined. (It comes from 3261.)

Section 11.5.1, 11.5.2:

These list Leon with his Nice email address. This should probably be 
changed.

Section 12:

Have we had a security review yet?

Section 12.2:

Authors Addresses:

Lean is still shown at Nice.

That's all.

	Thanks,
	Paul

On 9/9/13 4:23 AM, Hutton, Andrew wrote:
> We would like to start a working group last call of
> _http://tools.ietf.org/html/draft-ietf-siprec-protocol-10_
> Please send comments by the end of the day on September 22^nd (Two weeks).
> The deadline for requesting a meeting during IETF88 (Vancouver) is Sept
> 23^rd and whether or not there are WGLC comments on this draft may
> determine whether we need a SIPREC meeting in Vancouver.
> Regards
> Andy (SIPREC Co-Chair).
>
>
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 19 Sep 2013 22:50:21 +0000

Hi Paul,

I appreciate review careful review of the draft in its entirety. Please
see comments inline.

>ABNF, merging with the referenced ABNF, and then running the tool.

Sounds worthwhile. I did not add the ABNF and I'm not familiar with the
tool. Any volunteers?

>    Section 6 describes the SIP handling in a recording session between

How about "Š describes the SIP communication in a recording Š"

>So can someone refresh my memory about why this is a good thing?

Sorry, not sure. Seems it could be useful in some cases, but MAY seems
more appropriate than MUST.

>    registrar, then the '+sip.src' feature tag SHOULD be included in the

Fine by me, but unless someone knows why it should be stronger, MAY seems
more appropriate to me.

>    registrar, then the '+sip.srs' feature tag SHOULD be included in the

Works for me.

>    indicating whether recording is on, off, or paused for each medium.

Sounds good.

>    since this operation is reserved for pausing the RS media, ...

Yes, I that is how more clear.
 
>offer or answer must be sent asap to announce the change.

Works for me.

>this will probably invalidate the suggestion I made for 7.1.3.

Why not treat each as a separate RS, resulting in multiple recordings of
the same CS. If we are an endpoint in such a CS, you may receive different
recording indications from each of your peers (in a peer to peer CS), or
an XOR of the recording indications from an MCU (in an MCU hosted
conference).

>been proposed by EKR? (I forget the draft name, or if it has become and

I think so.

>    not limited to, appearing as a UA within a CS, or as a B2BUA between

Yep.

>circumstance would it employ anything else?

An SRC could mix both direction into a single mixed stream. If the SRS
does not support this, it could fall back to separate streams.

>Or my multiple o/a attempts? Or by CAPNEG? Or what?

config - probably
multiple o/a attempts - potentially
CAPNEG - doubt it

>CNAMEn/SSRCn in the RS? The above statement seems to suggest not.

It is okay, but they the RS looses the ability to distinguish between the
two. If two CNAME/SSRC combinations are combined by the SRC, the SRS will
not be able to pull them back apart.

>IIUC, normal draft style is to indent notes relative to the surrounding

Okay with me, but probably better to replace "Note that these Š" with
"These Š"

>metadata, then the multipart/mixed container is optional."

Sounds reasonable, but I defer to others who have more experience with
this mechanism.

>(This only describes what can be *received*, and the SRC will never

Agreed.

>Have we had a security review yet?

I asked Richard Barnes to review specific sections in the past, but I am
not aware of a full security review.

Cheers,
Charles