Subject: [siprec] Draft minutes

From: "Elwell, John" <[email-masked]>
Date: Wed, 26 Jan 2011 21:59:00 +0100

Please let me have any corrections by end of next week (2011-02-04).

John

Minutes of the SIPREC WG Interim Virtual Meeting
2011-01-25, 15.00-17.00 GMT/UTC and
2011-01-25, 14.00-16.00 GMT/UTC
===============================================
Meeting chaired by Brian Rosen and John Elwell.

Participants (session 1): Brian Rosen, John Elwell, Ken Rehor, Leon Portman, Henry Lum, Ram
Mohen, Andy Hutton, Alan Johnston, Gonzalo Camarillo, Paul Kyzivat, Dave Smith, Parthasarathi, Dan Romascanu, Alissa Cooper, Charles Eckel

Participants (session 2): Brian Rosen, John Elwell, Ken Rehor, Leon Portman, Henry Lum, Ram
Mohen, Andy Hutton, Alan Johnston, Paul Kyzivat, Dave Smith, Parthasarathi, Dan Romascanu,  Charles Eckel

Minutes produced by John Elwell.

Webex chat: See end of these minutes (used in session 1 only). Jabber was not used.

Recording (session 1): https://workgreen.webex.com/workgreen/ldr.php?AT=pb&SP=MC&rID=8263017&rKey=19329980a044b45b

Recording (session 2): https://workgreen.webex.com/workgreen/ldr.php?AT=pb&SP=MC&rID=8280267&rKey=b1c328313c4a985d

Session 1 started at 15.02 on 2011-01-25

Topic - Administrivia (chairs)
==============================
Slides: http://kenrehor.com/ietf/siprec/IETF79.2/Chairs.pdf

No changes to published agenda.

Topic - Requirements (Ken Rehor)
draft-ietf-siprec-req-06
================================
Draft: https://datatracker.ietf.org/doc/draft-ietf-siprec-req/
Slides: http://kenrehor.com/ietf/siprec/IETF79.2/IETF-79.2-SIPREC-Req-2011-01-25.pdf

Slide 4  - proposal to delete REQ-015/016. It was noted that these requirements talk about "cancel and discard". After some discussion, there seemed to be agreement that the "cancel" part was covered by other requirements (e.g., you can pause and not resume, effectively cancelling). So the main issue concerned the "discard" part. It was noted that previous agreements relating to privacy had reached the conclusion that the retention of recordings is an issue for the SRS, and outside the scope of SIPREC. There was no objection to deleting the two requirements.

Although the main focus of the requirements is on what happens on the SRC-SRS interface, Dave Smith brought up the question of whether a participant, whose SIP UA might not be collocated with the SRC, can request the pausing / stopping of a recording, or even request deletion of the recording. This would be a requirement impacting the CS, as opposed to the RS, and it was noted that none of the solution work has touched on that (although the earlier draft from Alan Johnston did have  provision for an indication on the CS signalling path that recording is taking place, but this was not brought forward into the present protocol draft). Dave was invited to raise on the list any fresh requirements concerning what CS participants might be able to request.

Slide 5 - proposed new requirement on multiple media streams for the same media type. It was observed that REQ-010 was probably intended to cover this case, and Ken will propose words to enhance REQ-010 to make it clearer.

Slide 6 - removal of REQ-021.  There was no objection to removal.

Ken will try to seek resolution of the issues above and then publish -07, which should be very close to being ready to submit to the IESG.

Topic - Metadata model (Ram Mohan)
draft-ram-siprec-metadata-03
================================================
Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata/
Slides: http://kenrehor.com/ietf/siprec/IETF79.2/SIPREC%20Metamodel%20-%20Virtual%20Interim-Jan25_2011.ppt

Slide 4: Ram explained why an association between Media Stream and CS had been introduced, because of the injection of things like music on hold, leading to a media stream without participant. Charles wondered why music on hold could not be considered a participant. Ram and Paul explained there were also conference cases where a participant might host a conference on his device, but those behind the conferencing device might not be considered CS participants. Charles asked why the conference focus could not be considered a participant. Paul explained that the SRC could obtain, using the conference event package, a list of participants from the focus, and those participants would contribute to the media stream, but those participants would not be part of the CS - that would be the role of the focus. Henry thought a mixer might be considered a participant, but Paul explained that if you can obtain a roster of people behind the mixer, those might be considered participants rather than the mixer. So there can be participants in the media that are not participants in the CS. Charles was worried that some media streams might not have any identified participants who are generating the stream. Paul explained that, assuming the media from the participants are mixed, you would see one media stream and a list of participants. One participant might be joined to the CS and the others would not be. Paul thinks we need to explore some use cases and see how they would be represented using this model. So if people have particular use cases, make them known and we can check how they would be represented. Ram will solicit use cases. Partha also had concerns similar to those of Charles, but Charles was beginning to see how the present model might work if you can get information about non-CS participants who are generating a media stream. Paul pointed out that the model does cater for a participant that is not part of a CS. Charles was invited to post his continued concerns / scenarios to the list, but Paul thinks the use cases concerned are already covered by the model.

Slide 6 (CS Group): Nobody on list had come up with a reason for having more than one CSG associated with a single CS, and the conclusion reached on the list seems to stand.

Slide 7 (CS): No comments on CS slide, except that forced deletion is to be removed in line with the requirements discussion.

Slide 8 (Participant): Clarified that the multiple AORs are aliases, in the sense of P-Asserted-Identity being able to carry aliases.

Concerning the issue of whether participant role is needed as an attribute, Leon suggested it could be done in application data, but asked whether we would then publish some application data dictionary. Paul suggested that application data is just some additional XML in some other namespace, so some other group could get together and define it. Leon was concerned that without some sort of standardization, different vendors would implement it differently. John suggested we need to decide what things are needed by 80% of deployments and standardize those in this group, so if that is the case for participant role, we should standardize it. Partha wanted to include participant role, even though there might be some cases where it is not available. Paul pointed out that we had had considerable list discussion on the difficulties of figuring out the role: UAC/UAS is transaction specific, inbound/outbound is problematic, and incoming/outgoing, whilst it might work in some cases, it will not always work. Perhaps those focused on call centres can say what might/might not work. In conclusion, this has to be taken back to the list. Without repeating the old arguments, those wanting to include participant role should indicate what are the likely mechanisms that might support it.

Slide 10 (Media Stream): How to model media streams that are not recorded (rejected by SRS or no capability at SRS). Dave thought it was important that you have some information in the metadata that there was media that was available for recording but couldn't be recorded, but there are two cases: where you don't want to record, or where, because of a temporary limitation, you are unable to record but might want to record later. Paul agreed, but was concerned about the details, although that is very much down to the mechanism, e.g., does the SRC need to keep offering the stream?

Partha asked a question on start time and end time. Ram clarified that these are start and end times of the CS media. It was pointed out that we have wall clock time in the metadata, and other times can be relative. Leon suggested there may be a need to retransmit wall clock time occasionally, to compensate for drift.

Henry asked whether media stream reference should be part of the mechanism rather than an attribute.

Slide 10 (Application data): Leon agreed with the extensible approach, based on different namespaces. Paul said that he would be tempted to stop calling it application data and call it extension data. John (from the floor) questioned whether it really is an object, or just attributes of other objects. Paul said it was just an artefact of how the model is drawn, but in the solution it would just be extensibility data. The authors will rework this with these comments in mind.

On next steps, people are asked to review and submit further comments on -03, and -04 will be produced in due course, after which we might be consider adoption as a WG item. In particular, we need closure on the long discussion of media stream relationships.

Topic - Protocol (Henry Lum / Leon Portman)
draft-portman-siprec-protocol-02
================================================
Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/
Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20-
%20virtual%20interim%20Dec%2016%202010.pdf

Slide 4 (Persistent recording): Leon pointed out that the whole idea of persistent recording is not to spend time negotiating m-lines when a CS starts - so he prefers the second option on the slide. For SRCs that support a large number of parallel CSs, the SRC could pre-negotiate a large number of m-lines (perhaps based on licensing), rather like provisioning trunks. Paul felt that the other option should be kept open - a slight delay in negotiating a new m-line could be handled by transmitting the data slightly delayed, without losing any. Henry also mentioned the possibility of the offer-answer failing. It was questioned whether there needs to be something in the protocol to indicate the delay. This issue should be brought to the list.

Session 1 wrap-up
================================

It was agreed that on the second day we will start by completing the Protocol topic and then do the metadata format topic.

Session 1 was closed at 17.00.

Session 2 started at 14.02 on 2011-01-26

Topic - Administrivia (chairs)
==============================
Agenda as agreed at close of session 1

Topic - Protocol (continued) (Henry Lum / Leon Portman)
draft-portman-siprec-protocol-02
================================================
Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/
Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20-
%20virtual%20interim%20Dec%2016%202010.pdf

Slide 5 (Transporting metadata): Question of whether we want just one mechanism (INVITE/UPDATE or INFO) or two. Paul thinks metadata needs to go in messages with offer/answer, which means INVITE or UPDATE, the latter also being suitable for exchanging metadata without offer/answer. Brian agreed. Henry had some concerns as to how errors in the metadata might be dealt with using UPDATE, and in particular whether it would mean that offer/answer would need to be considered to have failed if metadata is in error. After considerable discussion, it was agreed that the authors should explore the use of re-INVITE/UPDATE further as the sole mechanism (i.e., not using INFO), taking into account Henry's concerns.

Paul thinks we will also need to consider how big the metadata can be, and therefore whether SIP is the most appropriate transport. Brian suggested we might need to pass a reference, and Paul suggested we might need a separate channel if this was going to be a regular occurrence. However, we first need to see whether there is indeed a problem (see also discussion under the next agenda item concerning partial metadata). It was noted that the message would probably need to go TCP end-to-end. Partha asked whether it could be broken up when it exceeds the max. MTU size. The issue of needing TCP was noted, but this is not a problem unique to SIPREC. John referred to the overnight mailing list discussion on multiple parallel CSs per RS, arising from the discussion during session 1. Brian does not want to limit on basis of XML body size, but John was more concerned about the impact on SDP. It was agreed that in such circumstances you can create another SRS - we probably don't need a fixed rule. Partha suggested a possible error message to say the size limit has been exceeded.  Discussion to be moved to the list.

Slide 7 (Error handling): There was no objection to the assertion that we need a mechanism for SRS to report an error in metadata. The other question is how soon the response needs to come, i.e., in the SIP response or later. Charles can see it working either way, with appropriate referencing. Henry pointed out that sequencing is also an issue if we don't send complete metadata every time and you need to build a snapshot. Paul raised the question of whether all metadata transmissions are acknowledged or only those in error. Partha asked why an SRS might want to defer processing and therefore defer its response. Charles and Paul pointed out that a timely response is needed to UPDATE, and you need to cater for doing metadata processing on a different thread at the SRS. Partha suggested re-INVITE would allow a slower response. Paul suggested it could be problematic if it takes a long time.

Henry came back to case where the offer is OK but the metadata is in error. For example, can recording proceed without good metadata until the metadata is sorted out? So would this be a case for separating metadata update from offer-answer? Paul says this relates to the persistent recording problem Leon had brought up, where the media is already established and the metadata arrives later. Paul suggested we might need flexibility as to whether to respond immediately (in SIP response) or later. Alan re-iterated the SIP transaction rules, and noted that we probably need to do responses at a layer above SIP. Henry observed that his original proposal for INFO would achieve a complete separation. Glare issues were also mentioned - glare could occur if there is a need to send UPDATE from SRS to SRC for sending an error. Partha mentioned using re-INVITE and sending SDP without offer. But others pointed out that the UAS will then generate an offer - we can't use re-INVITE for an offerless transaction, unlike UPDATE. re-INVITE would be possible, but can only be used in accordance with RFC 3261, e.g., for transferring the session.

Slide 10 (Recording-aware UA on CS requesting no-record before start of session - REQ-017). John thought this would not be in line with the semantics of option tags. Leon suggested using SDP, which would allow no-record to be done on a per medium basis. This should be taken to the list.

Slide 11 (Indicating to recording-aware UA on CS that session is being recorded - REQ-018): Paul suggested that an SDP-based solution should be explored for this too. Partha asked about whether we need to specify anything concerning how we notify in audio. The consensus seemed to be that there is nothing we can standardize here.

The authors should explore solutions to REQ-017 and REQ-018 further.

Topic - Metadata Format (Partha)
draft-portman-siprec-protocol-02
================================================
Draft: https://datatracker.ietf.org/doc/draft-ram-siprec-metadata-format/
Slides: http://kenrehor.com/ietf/siprec/IETF79.2/SIPREC%20Metamodel%20Format-%20Interim-Jan25&26-2010.pdf

Slide 3 (Issue of JSON for compressed XML): Paul thinks it is not so well standardized yet and the extensibility mechanisms (very important to us) are not understood so well, but he is willing to be educated if somebody has greater insight. Henry felt that it might be hard to make it interoperable. Paul had been told by an XML expert in his company and in IETF that if XML is too big, use GZIP - no other compression scheme will achieve interoperability. As a working assumption we will proceed with XML.

Slide 6 (group element): Ram noted that according to very recent list discussion, the Initiator element should be moved to appdata.

Slide 8 (participant element); Ram clarified that the "recv" element was added to address the case of side conversations, where some streams are received only by some participants.

Slide 10 (appdata element): Paul pointed out it would be good if we can get an XML expert who is also active in SIPREC - he is not sure if xs:any is an appropriate and sufficient extensibility mechanism.

Slide 11 (Container elements): Again Paul would like XML expertise on this.

Slide 12 (Open issue on id generation): Ram  thinks it might be better if the id, or part of it, is generated by the SRS, to make it more useful for subsequent retrieval. Partha stated that this would not be possible for the group id, which would need to be generated by the SRC. Ram agrees for the group id, but for other elements prefers the SRS. Paul is trying to understand the scope of the identifiers. So if scope is a single SRC, what Ram says is reasonable - the SRS can generate part of every id, i.e., the part that identifies the SRC. What concerns Paul is if there is anything that needs to be referenced by things created by two different SRCs - he doesn't think there is at present. But we might need an extensible mechanism so that such cases can be handled if they arise in the future.

Leon mentioned multiple SRSs. Paul wanted to know whether these are independent or with shared data - if completely independent, it doesn't matter - it only complicates things if the SRC includes something like a seed obtained from the SRS and then talks to an independent SRS. Leon wanted to know why the SRC can't produce the ID anyway. Paul says this is doable, even if the id's need to be globally unique, but do we need it? It will make the keys bigger and put more work on the SRC.

Slide 15 (Partial metadata in XML): Paul thinks this is the elephant in the room - a huge issue. Henry thinks the main concern is that if we always send an entire snapshot, the SRS has to figure out what has changed. Also the SRC has to remember history in order to construct the entire metadata each time it sends. Charles thinks it is not scalable for big conferences. So there seems to be an opinion that we need a mechanism to send partial information. It is perhaps simpler than some applications in that you never delete (e.g., even if a party drops out, you add the fact he has dropped out). Charles asked about querying the metadata - it was noted that this is currently out of scope. There seems to be no disagreement we that need to have some partial updating mechanism. Partha will investigate possible mechanisms.

Next steps slide:  The most pressing issues are finding a proposal for partial metadata and understanding the scope of identifiers. On the question of whether we should keep the format and model drafts separate, it was suggested we could even have more than one format. At least for now they should be kept separate.

Session 2 wrap-up
================================
In summary, John reflected that we had brought the requirements draft near to completion, that the metadata model draft was close to a point where we could consider adoption as a WG item (subject to clarifying a few issues), and really useful early discussions were held on the protocol and metadata format drafts. The architecture document is basically on hold, awaiting progress on the other drafts before finalising it. Much now needs to be done on the mailing list, and no need was seen for a further interim virtual meeting (unless anything crops up that prevents us getting the requirements document out of the door in a timely manner). The chairs will request a 2 hour slot in Prague.

Session 2 was closed at 15.48.

Day 1 chat log
===============================
January 25, 2011            3:19:58 PM      from Alissa Cooper
 to Everyone:   I'm not in a place where I can speak in the audio, but I think we decided not to have requirements related to what happens to the recording after it has been made.

January 25, 2011            3:30:32 PM      from Alissa Cooper
 to Everyone:   it seems like there are cases where the hints are valuable even if they aren't always honored

January 25, 2011            3:39:51 PM      from Alissa Cooper
 to Everyone:   it's old, I'll take it to the list

January 25, 2011            4:59:32 PM      from Kenneth Rehor
 to Everyone:   Unfortunately I have to drop off now. TTY tomorrow.