Subject: Re: [siprec] Text on how often(soon) SRC should send metadata/updates to SRS in protocol draft

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 13 Feb 2014 00:48:46 +0000

We never reached a conclusion on this. I agree with Ram that section 9.1
is the place to address this. The current text in section 9.1 contains
some redundancy and does not flow all that well. I had a difficult
inserting new text into it. I propose replacing with the following, which
also addresses the issue raised by Paul and Ram.
--------

9. Metadata

Some metadata attributes are contained in SDP, and others are contained in
a new content type
"application/rs-metadata". The format of the metadata is described as part
of the mechanism in [I-D.ietf-siprec-metadata]. A new "disposition-type"
of Content-Disposition is defined for the
purpose of carrying metadata. The value is "recording-session", which
indicates the "application/rs-metadata" content contains metadata to be
handled by the SRS.

9.1 Procedures at the SRC

The SRC MUST send metadata to the SRS in an RS. The SRC SHOULD send
metadata as soon as it becomes available and whenever it changes.

Metadata sent by the SRC is categorized as either a full metadata snapshot
or a partial update. A full metadata snapshot describes all metadata
associated with the RS. The SRC MAY send a full metadata snapshot at any
time. The SRC MAY send a partial update only if a full metadata snapshot
has been sent previously.

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

When a SIP message contains both an SDP offer and metadata, the request
body MUST have content type multipart/mixed, with one subordinate body
part containing the SDP offer and another containing the metadata. When a
SIP message contains only an SDP offer or metadata, the multipart/mixed
container is optional.

The SRC SHOULD include a full metadata snapshot in the initial INVITE
request establishing the RS. If metadata is not yet available (e.g an RS
established in absence of a CS), the SRC SHOULD send a full metadata
snapshot as soon as metadata becomes available.

If the SRC receives a snapshot request from the SRS, it MUST immediately
send a full metadata snapshot.
--------------

Comments welcome.

Cheers,
Charles

On 12/17/13 7:50 AM, "Ram Mohan R (rmohanr)" <[email-masked]> wrote:

>When Paul and me were reviewing the metadata draft we were discussing on
>how quickly a SRC has to send updates to SRS. The updates can any
>update(of CS changes ) from SRC from SRS. Currently we don't have any
>recommendation / text on this in Protocol or Metadata draft.
>
>
>For example, Suppose there is a sequence of changes on a single
><participantstreamassoc> XML element as below:
>
>T1: associate-time (A participant starts contributing to a stream)
> -- snapshot 1 sent from SRC to SRS
>T2: disassociate-time ((A participant stops contributing to a stream)
>T3: associate-time (starts contributing again)
>-- snapshot 2
>T4: disassociate
>T5: associate
>T6: disassociate
>-- snapshot 3
>
>
>Any of the above can happen. Ideally an SRC is expected to send snapshot
>updates as soon as possible (i.e after every transaction of CS). We have
>discussed this point earlier in mailing list.
>
>The question is - Should we mandate this (MUST ?) with some text or just
>add it as RECOMMENDATION. I am inclined with having it as RECOMMENDATION
>and leave it to the implementors on deciding how soon they want to send
>the updates from SRC to SRS.
>
>In any case we need some text and I believe section 9 of Protocol draft
>that talks about 
>
>Sending metadata from SRC to SRS is the right place to have this text.
>
>Comments ?
>
>Regards,
>Ram
>
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Feb 2014 10:50:41 -0500

I think this sounds pretty good. The one thing I wonder if whether we 
should add some discussion of conditions that might justify not 
following the SHOULD in "The SRC SHOULD send metadata as soon as it 
becomes available and whenever it changes."

Some things that come to mind are:

- Can't, or don't want to, send a new update until the prior one has
   completed. (If accompanied by an O/A you can't. Otherwise, using
   UPDATE you *can* but might not want to.)

- desire to generally constrain the signaling rate on the RS

- simplifying the SRC implementation by only sending updates when
   certain key events occur, not every event that *could* be
   reflected in an update.

- desire to suppress certain metadata out of concern for privacy
   and perceived lack of need for it to be included in the recording.
   (This is fundamentally different from the others.)

I'm not suggesting I believe all of the above are *good* justifications, 
I'm just trying to be exhaustive.

	Thanks,
	Paul