Subject: [siprec] Items needing more discussion

From: "Elwell, John" <[email-masked]>
Date: Fri, 24 Jun 2011 11:58:42 +0200

>From yesterday's meeting, the following items need to be brought to the list or continued on the list:

Protocol:
- Usage of the SDP recording attribute in offer/answer (raised by Cullen)
- Meaning of the SDP recording attribute (applicable to sending, receiving or both) (raised by Cullen)
- Impact on the SDP recording attribute of two SRCs on the CS path (raised by Paul)
- The need for a no preference value for the recordpref SDP attribute, and the default value of that attribute (old discussion needs reviving)
- Obligations of a UA that indicates Supported: record-aware, e.g., whether a UA is obliged to provide some form of indication to the user when it receives the recording SDP attribute (e.g., a PSTN gateway would need to provide an in-band tone or announcement).
- Text needed on mandating that participants be notified of recording.
- What to put in the message header to indicate that a snapshot is request.

Metadata model:
- The need for an explicit start and stop time in a CSG element (in particular Partha had a concern).
- The need for an explicit start and stop time in a Participant element.

Metadata format:
- Options for globally unique IDs, along with pros and cons (Partha to initiate)
- Codec parameters in stream elements (issues on metadata format slide 10).

RTP
- Continue discussion on draft-eckel-siprec-rtp-rec-00, with particular attention to Section 4 on roles.

Documents authors should kick-off these discussions.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jun 2011 10:37:51 -0400

> - Options for globally unique IDs, along with pros and cons (Partha to initiate)

I'm not Partha, but I'll comment. Some possibilities:

A) A generic URN, with added constraint that equality is
    based only on lexical equivalence (as defined in rfc 2141)

B) UUID URN (rfc 4122)

C) UUID encoded more densely than the UUID URN
    (e.g. radix64 of the binary uuid form defined in 4122)

Pros/cons of these:

A) Pro: very flexible for the SRC. It has many options for
    how to create and encode IDs.

    Pro: ease of generation, assuming the SRC chooses wisely.

    Con: Difficult for the SRS. It must deal with variable
    unbounded length ID. Doesn't easily fit in databases.

    Con: Somewhat inefficient wire encoding:
    there is minimum length of "URN:" plus NID (namespace identifier).

    Pro/Con: Wire efficiency varies depending on SRC choices.
    Could be very good or very bad, depending on what NID is chosen.

B) Pro: very flexible for the SRC. 4122 provides multiple ways of
    generating the UUID. One of them (the name based one) would
    allow generating a UUID from the same strings you might use
    for (A), so its at least as flexible as (A).

    Pro: easy of generation. Like (A), but then requires an SHA-1
    computation. So not as easy as (A).

    Pro: Simple for SRS. The UUID can be easily extracted from
    the URN and converted to a fixed length (16 bytes) binary value.
    That value then can be stored in databases, compared, etc.

    Con: Somewhat inefficient wire encoding. The urn encoding is
    45 bytes.

    Pro: Flexible to future extension to other sorts of URNs
    (e.g. (A)) due to the use of the URN syntax.

C) Pro: very flexible for the SRC. (Identical to (B))

    Pro: easy of generation. Virtually the same as (B).
    (The final textual formatting is different from (B), but
    similar (insignificant) computationally.)

    Pro: Simple for SRS. Virtually the same as (B).
    (The final textual formatting is different from (B), but
    similar (insignificant) computationally.)

    Pro: Efficient wire encoding.
    (Radix 64 takes 22 bytes to represent the 16 binary bytes.)

For the metadata these would probably all be wrapped in XML in 
comparable ways, so none has an advantage over another in that respect.

Please feel free to propose other alternatives.

As a specific example, for the UUIDs, one could use the 4122 "name 
based" approach, where the "name" is just a binary integer counter.

	Thanks,
	Paul