Subject: [siprec] FW: IETF 80 SIPREC meeting notes

From: "Elwell, John" <[email-masked]>
Date: Thu, 31 Mar 2011 11:31:24 +0200

Ken's notes from the meeting - I will produce minutes in due course.

John

________________________________
From: Ken Rehor (krehor) [mailto:[email-masked]]
Sent: 31 March 2011 10:28
To: Elwell, John
Subject: IETF 80 SIPREC meeting notes

SIPREC

Architecture - Andy Hutton

-01 about to expire, -02 in preparation, will be published shortly

Interaction with MEDIACTRL

·         Proposal: do not need another figure to show the SRC case

·         Partha will provide a diagram that he proposes for discussion on the list

Interaction with Conference Focus

·         Request for diagram

·         Will be included in -02 draft

"Metadata supported" indication

·         Remove the statement from architecture draft, more of a protocol issue rather than architecture issue

Metadata content

·         Remove this list and refer to metadata model document

Metadata delivery

·         Remove this list and refer to

·         Continue to allow non-SIP means

·         ==> Hadrial agrees, but not include specific implementation details (such as INVITE or UPDATE), defer to protocol spec

·         ==> Keith Drage agreed

Security Considerations

·         Remove comments about decryption

·         Remove requirement for SRTP

Metadata model
Partha

Updated draft to be submitted after this meeting

Open item: optional start/stop time attribute to be added?

Paul Kyzivat:

JRE: don't tie SIP session level to Recording Session level so that updating

Joe Hildebrand:  is there something that indicates the final 'end' of the recording session?

Paul: only if we tie the end of the SIP session to the Recording Session

Brian: how do we know we're done updating metadata?

JRE: end time of recording session doesn't make sense

Charles Eckel: fuzzy for persistent recording session; start/stop must address this.

Joe: even if not persistent, there's no end time because other metadata might continue to flow

Hadriel:  eventually the Recording Session will end (with a BYE, timer, etc.)

JRE: continue discussion on the list

Paul: maybe this means we have the model wrong; all the items contained within might be wrong

Communication Session Group start/stop time
JRE: a group of CSs together, do we need a start/stop for the group?
BR: solution is the same as the previous issue

Communication Session start/stop time
JRE:  "YES" we need CS start/stop time

Session State Attribute
BR: not useful
Hadriel: agree. However, we need to figure out what STOP time is:  BYE, etc.?

JRE: conclusion we won't include it

Participant
JRE: how do we have indication a participant left? How do we know they're contributing media streams?
Paul: we don't distinguish between a participant in the CS vs media streams

Media Stream
Same as Participant
Need codec params of Recording Session SDP; continue discussion on list
Open item: Include model of metadata of media *not* recorded
Ken: suggest that we need this requirement

NEXT STEPS

·         Request for review of metadata-00 on the mailer

·         WGLC

·         Align metadata format draft with metadata model draft
===================================================================================

Metadata format

Partha

Leon: what is the lifetime of the unique ID?
BR: please add a better example
Paul: IDs must be globally unique for all time
Hadriel: "most horrible thing I've ever seen" - large, and forces a particular database structure
JRE: still an individual draft, so please propose another solution

Partial XML update
(lots of discussion, continue on mailing list)

Extension Data Element Example

BR: <structure> and <whatever> won't work, must be part of a namespace
Joe: depends on implementation
Peter Saint-Andre:

·         Overall need better examples

Open issue: ID generation scope

Open issue: codec parameters in stream element

Duplicate RS SDP in Stream XML?

JRE: in general I don't like duplication, but it may be useful for applications
Paul: direction attribute may not be explicit enough
Hadriel:
Leon:

·         Continue discussion on the list

Open issue: multiplexing different participants' streams on the same port

(postpone until protocol discussion)

Next Steps
Create Milestone for this topic?
Hadriel: combine metadata model with metadata format
JRE: (consensus)
Paul: suggest merging metadata model with architecture;  merge format and protocol
BR: continue discussion on list - what makes the most sense for content of various documents
JRE: key is to gain agreement on the metadata model and updates, and extension data; identifiers for both

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

Protocol

Leon Portman

Partial metadata support:
INVITE and UPDATE for metadata transport

è  UPDATE for mid-session updates

Metadata snapshot support

Partha:  REINVITE instead of UPDATE?
Leon:  yes
JRE: benefit of UPDATE is not requirement of offer/answer
Partha: REINVITE or UPDATE?
Hadriel: why reinvite? If SDP chnages it can be updated
BR: is there a reason any particular method can't be used?
Hadriel: why not INFO?

Not all implementations of INFO

Paul: if we require INFO, then we would have to require an INFO package
Hadriel: packages for INFO were defined for this
Charles: still need INFO for complete metadata?
Leon: will use UPDATE

Multiplexing multiple streams

Charles: important to not mandate one mechanism or another
JRE: but mandating something provides interop
Hadriel: 2 or more ways of doing something guarantees non-interop; the other benefits are edge cases
Paul: might already have this issue e.g. case of conference
Hadriel: disagree.   (discussion of whether the RS gets the conference roster)
Paul: this is an explicit way of representing a participant by cname
Hadriel: Need to clarify "what is the model" the SRC - SRS?  Translator, Mixer, Endpoint?
Leon: but in the architecture doc or protocol?

è  Take to list

Recording Awareness

JRE: on media level or session/dialog level?
Paul: legal precedence are about audio. What about video for hearing impaired people? There are different ways of alerting people.
BR: list discussion
Andy: need this at the SIP layer as well as SDP layer
Charles: at the SDP layer it may not be appropriate, so should be at SIP layer.

Recording Indications

BR: just like 'hold' - currently use SDP to cause indication, but also possible to do at SIP layer
JRE: consensus that this is only on the media layer but will confirm on list

Recording Preferences

Charles: can we reduce the number of options?
Leon: the words carry specific semantic meanings
Hadriel:  SDP are not commands
Paul: if per media, must be in the SDP
JRE: media or session level?  Consensus is that we must be able to allow a user to say they'd permit recording of audio but not video (for example)

OPEN ITEMS;

JRE: not quite ready for WG item yet, but maybe at the next meeting
BR: any big issues with this?  No room comments so it seems we're heading towards making this a WG item

JRE: next virtual meeting middle of May

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html