[siprec] Notes

["Elwell, John" <[e-mail]>]

Michael Proctor's notes from meeting - I will produce minutes in due course.

John

================================

SIPREC - Thursday 9am (Barcelona)
=================================

draft-ietf-siprec-req - Ken Rehor
Ken presented his slides, with minor clarifications from John Elwell.
No other comments.

draft-ietf-siprec-architecture - Andy Hutton
Andy presented his slides:
Open issue: Figure to show how to decompose SRC?
  Parthasarathi: 
    Makes decomposition more obvious? - Would like picture of SRC like SRS.
    Will supply ascii art for review on list in next few days.
Request for Conference Focus Interaction diagram (act as SRC)
  Andy to produce and update in next version.
Proposal: Remove metadata supported indication statement?
  No objections.
Proposal: Remove list of metadata content, reference the model instead
  No objections.
Proposal: List INVITE/UPDATE + non-SIP means only for metadata delivery?
  Hadriel Kaplan: Agrees, but don't mention specific methods
    (e.g. INVITE/UPDATE)
  Keith Drage: Clarified that this repeats stuff in the protocol document.
Proposal: Remove section of Security Considerations
  No objections.
Proposal: Remove requirement for SRTP from Security Considerations
  No objections.

draft-ram-siprec-metadata - Parthasarathi R
Partha presented his slides.
Open item:  Optional start/stop time attribute for Recording Session?
  Paul Kyzivat: Expressed similar concerns.
  Joe Hildebrand: Updates to metadata may have no known last event.
  Chair summary: Endtime doesn't make sense - we can never figure it out.
  Hadriel Kaplan: How is there not a 'stop time' for the recording session?
  Chair: Take this to the list.  Dispute over whether a recording session
    can have a meaningful stop time.
  Paul Kyzivat: Does this mean we have the model wrong?
  Chair: That will make an interesting list discussion!
Open item: Optional start/stop time attribute for Communication Session Group?
  No opinions expressed. Same problems as previous item.
Open item: Optional start/stop time attribute for Communication Session?
  No objections to saying YES.
Open item: Should session state attribute indicate trying/proceed/early/confirmed/terminated?
  Brian Rosen(as person): Doesn't seem useful.
  Hadriel Kaplan: Agrees, but notes that session stop time needs to be
    defined (on BYE, or 200 to BYE etc).
  Consensus to not include session state attribute.
Open item: Optional start/stop time attribute for Participant?
  John Elwell(as person): How do we know a participant has left?
  Paul Kyzivat: You can start/stop relationships to other entities,
    not necessarily stop a participant?  Need to capture all nuances.
  Brian Rosen(as person): Need to be clear this is session start/stop
    for this participants.  Other indications for media etc.
  Was consensus reached? ~~~ Check audio ~~~
Open item: Media stream: Codec params text change
  Not clear - taken to mailing list.
Open item: Media stream: Need to model unrecorded media streams (offered certain types, not accepted by SRS)?
  Ken Rehon: Yes
  Consensus is yes.

draft-ram-siprec-metadata-format - Parthasarathi R
Partha presented his slides.
Discussion on recording metadata example:
  Leon: What is the lifetime of the ids?
  Brian Rosen: Add example for metadata example.
  Paul Kyzivat: IDs are UUIDs - universal lifetime.
  Hadriel Kaplan: Insanely complicated.  Forces particular data 
    representation on implementors.
  Joe Hildebrand: Still deciding XML processing semantics - nailing down
    syntax best done after this.  UUIDs can be invented on sending side
    which allows updates before waiting for a round trip for allocation.
  Paul Kyzivat: Different key strategies have been considered, scope for
    alternative approaches and a beauty contest.
  Chair: Does anyone other than Hadriel have concerns?
  Hadriel Kaplan:  To reiterate - this forces a particular data
    representation on the database, not simply a beauty contest.
  Chair: Tentatively proceed with rest of slides/issues - partial consensus.
Partial XML update:
  Hadriel Kaplan: Use a single UUID for the parent element, not one ID for
    each leaf.
  Paul Kyzivat: This will prevent referring to an element in a completely
    different context.  No requirement for this yet, but...
  Joe Hildebrand:  Hadriel's approach requires coordination for creation
    of simple short ids - UUIDs means you can forget this problem.
  Hadriel Kaplan: Paul's problem can be handled by referring to the parent
    id and then the sub-id.  Think namespaces.
  Joe Hildebrand: Can use other URIs if you want? ~~~ Check audio ~~~
Extension Data Element Example:
  Brian Rosen: That won't work.
  Joe Hildebrand: 
  Paul Kyzivat: Type of parent is not clear from just a UUID.  Implies
    painful database type.
  John Elwell: More mailing list discussion required.
  StPeter: XML problems defining the extensiondata
  Paul Kyzivat: Consider it an expression of intent
  Joe Hildebrand: ~~~ Check audio ~~~
  StPeter: Thinks the examples are just wrong.
  John Elwell: More mailing list discussion required.
Open issue: ID generation scope
  Chair: Repetition of previous discussion
Open issue: Codec parameter in stream element
  John Elwell (as person): In general, dislikes duplication.  Not much
    of an issue here - we can solve this.
  Paul Kyzivat: Direction attribute is most concerning.  Maybe draw some
    inferences, but not explicit enough to know.  SRS could convert info
    from SDP.
  John Elwell: Let's have that discussion offline.
  Hadriel Kaplan: Asking for conflicts with SDP.
  Leon Portman: ~~~ Check audio ~~~
  Chair: Running out of time - continue discussion on list re relationship
    between metadata in XML and SDP from recording session.
Open issue: Multiplexing different participants' streams on same port
  Chair: Is this premature before discussing the protocol?
Create milestone for this topic?
  Brian Rosen: Should we merge model and format in one document?
  Hadriel Kaplan: Yes
  Paul Kyzivat: Conceptually, model should merge with architecture, and
    maybe format and protocol should merge.  Doesn't much care.
  Brian Rosen:  What would a newbie expect?  What would make most sense?
Chair: Too early to consider adopting.
  Home in on questions of identifiers and metadata model/updates, and extension data.

draft-portman-siprec-protocol - Leon Portman
Leon presented his slides.
Partial Metadata Support: INFO will be removed from next version.
Metadata Snapshot Support:
  Parthi: Can we use reINVITE instead of UPDATE?
  Leon: Yes.
  John Elwell: reINVITE forces SDP renegotiation, which is sometimes
    useful but not always.
  Hadriel Kaplan: This should be a SIP layer decision, not a SIPREC decision.
  Brian Rosen: Is there a reason we should restrict e.g. OPTIONS for metadata?
  Hadriel Kaplan: No
  Paul Kyzivat:  Using INFO would require info-package, but we wouldn't use
    same package for INVITE/UPDATE etc, hence extra work.
  Hadriel Kaplan: ~~~ Check audio ~~~
  Charles?: Do we need INFO to request full snapshot?
  Leon: No - other mechanisms exist.
  Parthi: ~~~ Check audio ~~~
Multiplexing media streams:
  Charles?: We shouldn't mandate one mechanism or another.
  John Elwell: Not mandating anything leads to non-interop.
  Hadriel Kaplan: 2 ways to do something leads to non-interop.  Not seen
    good reasons to require multiplexing.
  Parthi: Just a negotiation.
  (many): Not it isn't
  John Elwell: Not sure there is an explicit negotiation for this.
  Paul Kyzivat: We haven't introduced a new issue.
  Hadriel Kaplan: Disagrees.
  (stopped following the nuances of the argument here - sorry)
  Paul Kyzivat: Can we get the relationship between roster and CNAMEs?
    Would be nice to pass this information if you ever have it?
  John Elwell: Clarifying which session we are talking about SSRCs/CNAMEs
  Hadriel Kaplan: What is your RTP model? Translator or endpoint?
  Chairs: We need to sort this out - good list discussion.
  Charles?: Hoping SRC wouldn't need to transcode.  Wouldn't rule it out
    but doesn't want to force it.
  Brian Rosen: Need to define what SRS must accept, and what SRC could use.
  Gonzalo: Let's make sure rtcweb,clue and siprec are all on the same page.
  Brian Rosen: Cope with what is thrown at us, not dictate.
Recording awareness: SDP attribute a=recording-aware
  John Elwell: Is this SDP or SIP layer?
  Paul Kyzivat: What about accessibility?  'Tones' for deaf ppl using sign language?
  Brian Rosen: Is there a way to indicate recording other than by in-band media?
  More list discussion.
  Andy Hutton: Def need at SIP layer, maybe at SDP layer too.
  More list discussion.
  Charles?: Need at SIP layer, because SDP layer implies in-band - like PaulK's comments.
    A recording-aware UA would be able to alert the user in a more appropriate manner.
  More list discussion.
Recording indications: on/off/paused: session or media level?
  Brian Rosen: Analgous to 'hold' which is done by sendrecv at media level
  Consensus for media level
Recording preferences: record/norecord/pause/resume: session or media level?
  Charles?: Wants to minimise sdp attributes.
  John Elwell: Let's focus on which level we want it at?
  Hadriel Kaplan: Is this a command?  If so, it doesn't belong in SDP.
  Paul Kyzivat: If per medium, realistically needs to be SDP.  SDP has things
    that are declared or negotiated.
  John Elwell: Let's focus on which level we want it at?
  Brian Rosen: Does anyone think it isn't media level?
  No dissenting opinions.
  Brian Rosen: Seek expert advice on whether it is appropriate for SDP.
Open Items: Sync/Async error handling
  No substantive discussion.
Open Items: Session Timer usage
  No substantive discussion.
Open Items: Metadata support discovery
  No substantive discussion.
John Elwell: More items to tie down, not in a position to adopt just yet.
Brian Rosen: Is anyone planning another draft? Is there any question of 'if'
  this will become a wg item.  No response, so assuming this is a case of
  'when' not 'if' this becomes a wg item.
John Elwell: Planning another virtual meeting in May.