Subject: [siprec] comments on draft-ietf-siprec-protocol-03

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sat, 24 Mar 2012 10:11:22 -0700

Section 4.1, fifth paragraph describes an SRC using a single RS to
record multiple CSs. However, it some places it uses "calls" instead of
"CS". I think these should be changed to "CS".

Section 4.2 reads, "Subsequent metadata updates can be represented as a
stream of events in INVITE and UPDATE requests". Here and elsewhere in
this section, I suggest avoiding this use of "stream". Perhaps replace
with, "Subsequent metadata updates can be communicated in subsequent
INVITE or UPDATE requests."
Also, last sentence, change SRS to SRC.

Figure 3: Delivering metadata via SIP UDPATE.
The initial metadata deliver is via INVITE. Perhaps label simply as
"Delivering metadata".

Section 5.1 and 5.2, we do not use the From/To to identify the SRS/SRC.
We use feature tags. The use of the feature tag +sip.src and +sip.src
mean the SRC/SRS is capable of acting as an SRC/SRS, not that it is in
this call. Perhaps use Accept-Contact: *;require;+sip.src or
Accept-Contact: *;require;+sip.srs to indicate that the answerer must
act as an SRC/SRS?

Figure 4, second video m-line is labeled as audio.

Section 8.1, I find the description of the partial update sending
scenarios by the SRC to be very confusion. Isn't if sufficient to say
that snapshot requires SDP and partial may not?

Section 10.2.1, definition of paused, 
s/progress by media/progress but media

The last sentence read, "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."
I suggest replacing with, "This attribute is not used to negotiate which
SRC in the call path will perform recording."

Section 11.2.1 and 11.2.2
Is the appropriate value really "boolean"?
Also, I think have the SRC include the +sip.src in INVITEs for CSs being
useful to indicate to UAs that the call can be recorded.

Section 11.3, why is this needed?

Section 11.4.1, should "rs-metadata" be "rs-metadata+xml" instead?

Cheers,
Charles

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 28 Mar 2012 06:53:27 -0700

-----Original Message-----
From: [email-masked] on behalf of Charles Eckel (eckelcu)
Sent: Sat 3/24/2012 1:11 PM
To: [email-masked]
Subject: [siprec] comments on draft-ietf-siprec-protocol-03

[hlum] Right, I'll make this change: s/call/CS

[hlum] Thanks for catching this.

[hlum] Agreed.

[hlum] Originally what I want to mention is that the From/To identifies the SRC/SRS which is not the participants in the CS. The participants are identified in the metadata and we want to make sure that the SRC/SRS don't use From/To in the recording session to identify the participants. Perhaps this needs a bit of word-smithing to separate from the use of the feature tags.

[hlum] thanks for catching this. It should read:
m=video 22458 RTP/AVP 98

[hlum] A snapshot actually requires SDP offer in an INVITE/UPDATE request, while partial does not require SDP and can be in a response. Perhaps we can simplify the wording a little bit:

"A partial update represents an
   incremental update since the last metadata update sent by the SRC.  A
   partial update sent by the SRC can be an INVITE or UPDATE request or response containing
   a "recording-session" disposition, with or without SDP."

[hlum] Okay this is simpler.

[hlum] It's a boolean to note whether the the UA is a SRC/SRS or not, just like +sip.isfocus which is also a boolean as well.

[hlum] It's for SRC or SRS to provide declare content that applies to recording session only; specifically it is the metadata and metadata snapshot request.

[hlum] Yes that needs to be fixed.

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

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 29 Mar 2012 10:26:05 -0700

> From: Henry Lum [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2012 3:53 PM
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: RE: [siprec] comments on draft-ietf-siprec-protocol-03
> 
> 
> 
> 
> [hlum] Originally what I want to mention is that the From/To
identifies
> the SRC/SRS which is not the participants in the CS. The participants
> are identified in the metadata and we want to make sure that the
> SRC/SRS don't use From/To in the recording session to identify the
> participants. Perhaps this needs a bit of word-smithing to separate
> from the use of the feature tags.

I see. I agree that To/From should not be used to identify participants.
That may be worth mentioning. That said, To/From should not be used as
SRS/SRC identifiers either.
I agree with separating from feature tags. My Accept-Contact comment
should be applied the existing feature tag section instead.

> [hlum] A snapshot actually requires SDP offer in an INVITE/UPDATE
> request, while partial does not require SDP and can be in a response.
> Perhaps we can simplify the wording a little bit:
> 
>    partial update sent by the SRC can be an INVITE or UPDATE request
or
> response containing

I can live with that.

> [hlum] It's a boolean to note whether the the UA is a SRC/SRS or not,
> just like +sip.isfocus which is also a boolean as well.

Okay.

> [hlum] It's for SRC or SRS to provide declare content that applies to
> recording session only; specifically it is the metadata and metadata
> snapshot request.

Okay. I still don't understand it completely, but will take your word on
it.

Cheers,
Charles