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

From: Henry Lum <[email-masked]>
Date: Wed, 16 Oct 2013 03:05:46 +0000

Hi Paul - Sorry I have been really behind in updating the draft to
incorporate your comments. I'll have an update this week.

Please see my comments inline.

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charles Eckel (eckelcu)
Sent: September-19-13 6:50 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [siprec] WGLC on draft-ietf-siprec-protocol-10

Hi Paul,

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

On 9/10/13 2:57 PM, "Paul Kyzivat" <[email-masked]> wrote:

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

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

[hlum] I'll work on running a tool against the ABNF.

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

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

[hlum] will fix this.

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

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

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

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

[hlum] I think the strength of the wording for registration applies more
for an SRS since we need an SRC to find where the SRS is, but I agree that
UAs that have multiple duties using the same AOR should not be limited to
always include this tag. I will change it to MAY for SRC and SHOULD for
SRS.

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

Works for me.

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

Sounds good.

[hlum] good for me. thanks

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

Yes, I that is how more clear.

[hlum] will fix
 
>
>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.

Works for me.

[hlum] I agree the wording isn't clear here; the intention is not to force
another offer/answer every time a recordpref appears. Let's try rewording
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. If the SRC makes a change in recording state, then
   the SRC reports the recording state in the a=record attribute in the
   SDP answer or in a subsequent SDP offer/answer.

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

[hlum] I think this is really up to the B2BUA to decide what recording
indicator and recording preference to expose to SRC2 if SRC1 is recording
the call. I don't think we can really mandate a specific behaviour for
B2BUA. Let's say B2BUA decides to pass on a:record=on to SRC2, SRC2 may
still decide to record the call again since it is an SRC and it should be
able to do so. If the B2BUA chooses not not pass on this indicator then
there is nothing SRC2 and UA2 can do to know that the call is actually
being recorded.

If we look at a simple case where two UA in a CS are also SRC and are both
recording the call, then the SDP offer/answer sent by both UA will include
a=record:on. The UA that receives the initial INVITE with a=record:on may
still decide to record the call even if another SRC is already recording
the call. I don't see a conflict with this.

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

[hlum] I don't think there is a need to keep track of the number of
recordings in the call chain. All an end-user need to know is whether the
call is being recorded or not. How many recorders are recording the call
is irrelevant to the user. If an element in the call chain is an SRC that
receives an SDP offer with a=record:off but this SRC is still recording
the call, the SRC should still convey that the call is being recorded.

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

[hlum] recordpref is actually similar to recording indicator. Let's say a
user needs to pause the recording, the UA sends an SDP offer with
recordpref=pause. As long as the call chain passes on the SDP offer with
the same preference all the way through, the all SRCs in the call chain
would end up honoring that request to pause the recording.

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

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

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

I think so.

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

Yep.

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

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.

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

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

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

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.

>
>Section 8.4:
>
>IIUC, normal draft style is to indent notes relative to the surrounding
>text.

Okay with me, but probably better to replace "Note that these Š" with
"These Š"
[hlum] fixed.

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

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

[hlum] You are right that the statement did not cover the offerless INVITE
from the SRS that could result in a response with both SDP and metadata.
The new wording definitely provides more clarity than the existing one;
I'll update that.

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

Agreed.

[hlum] fixed.

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

[hlum] I agree this sentence sounds better.

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

[hlum] Right this is a good point; the current wording is too restrictive.

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

[hlum] Agreed.

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

[hlum] sent a message to Leon asking for an update.

>
>Section 12:
>
>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

>
>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
>>
>
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec

_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

00錟츫
⿨Ф臨˿NSJZMBX03.msg.int.genesyslab.com>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Oct 2013 10:10:59 -0400

I'm just following up on my "big" issue here, inline.

> there is nothing SRC2 and UA2 can do to know that the call is actually

If we give the B2BUA discretion about this, then we are giving it 
discretion about informing SRC2 that recording is going on.

If it was an SRC, then it would be obligated to report that recording is 
on. As a B2BUA, it effectively encapsulates the behavior of everything 
behind it. So again it should be obligated to report.

> the call. I don't see a conflict with this.

My concern is not about an SRC deciding if it needs to record.
My concern is that UAs know when they are being recorded, so that they 
may report that fact to their users.

> the call, the SRC should still convey that the call is being recorded.

Perhaps "counting" implies more work than I mean. In the case of a B2BUA 
with two "sides", all it needs to do is keep track of the recording 
state on each side, and report that to the other side.

But in the case of a a conference focus, more record keeping is 
required, since any of the participants could be recording. Counting is 
one way. OR, the focus could be more sophisticated, and only indicate 
recording to a participant if the media to/from that participant is 
being recorded.

> would end up honoring that request to pause the recording.

The analysis is similar to that for the record indicator. All the 
different preferences for recording need to be aggregated and made 
available to all the SRCs. (Or the SRC needs to do the aggregation.)

> the same CS.

Treat what as a separate RS? The RSs are clear. But the UAs don't have 
visibility to the RSs, only to the indicators.

  If we are an endpoint in such a CS, you may receive different
> an XOR of the recording indications from an MCU (in an MCU hosted

I think you mean OR, not XOR.

If the MCU (focus) maintains a separate recording state for each leg, 
then it can OR those together to get the aggregate state at any point in 
time. Then it needs to report state changes to each leg. Counting is one 
way to do that. But I agree there are other ways.

My point is that there is a real obligation here, to preserve the 
essential properties of these indicators. So I think we need to include 
some normative behavior about it.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 16 Oct 2013 19:47:06 +0000

My assumption on the recording indicator is that the recording indicator
is not per RS but rather set to true if any RS is known to be recording
the RS. So in the cases described below, the SRC would propagate a
record:on regardless of whether or not it was recording. The only way it
would change this to record:off is if it stopped providing the media or
the UA on whose behalf it is acting, in which case that users media is
truly no longer being recorded.

Cheers,
Charles

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Oct 2013 16:19:53 -0400

> truly no longer being recorded.

I think we agree conceptually on what needs to be done.
We just need to be sure the text says that.

I think this means that boxes that join multiple UAs (B2BUAs and 
focuses) need to keep a recording state for each leg, and then "mix" the 
state from those legs to the other legs. And if the box is also a SRC 
then it has to mix in its own recording state too.

My earlier mention of "counting" was a poor man's way of doing that. But 
it might not even work.

	Thanks,
	Paul

---

From: Henry Lum <[email-masked]>
Date: Thu, 17 Oct 2013 02:47:46 +0000

I am okay adding a MUST statement to ensure that the recording indicator
is presented to the user even when the call is traversed through some
B2BUA or conference focus.

Let me try to reword section 7.3.1:

  When a recording-aware UA receives an SDP offer or answer that
  includes the a=record attribute, the UA MUST provide the recording
  indication to the end user whether the recording is on, off, or
  paused for each medium based on the most recently received a=record
  SDP attribute for that medium.

  When a CS is traversed through multiple UAs such as a B2BUA or a
conference
  focus, each UA involved in the CS that is aware that the CS is being
recorded
  MUST provide the recording indication through the a=record attribute to
all 
  other parties in the CS.
  
  It is possible that more than one SRC can be in the call path recording
the 
  same CS, but the recording indication attribute does not provide any
hint as 
  to which SRC is actually performing the recording. This means that an
endpoint 
  only knows that the call is being recorded through the recording
indicator. 
  This attribute is also not used as an indication to negotiate which SRC
in
  the call path will perform recording and is not used as a request to
  start/stop recording if there are multiple SRCs in the call path.

Regards,
Henry

On 2013-10-16 4:19 PM, "Paul Kyzivat" <[email-masked]> wrote:

>>>> [hlum] recordpref is actually similar to recording indicator. Let's
>>>>say
>>>> a

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 17 Oct 2013 15:08:38 -0400

Henry,

Thanks. This seems sufficient to me.

	Paul