Administrative and WG Status Update - RFC editor queue for architectural draft - protocol and metadata hopefully close - proposed a charter update - restricted to SIP-based and nothing else - proposed some additional milestones to cover the additional work - AD (Alissa Cooper) - talked with chairs before the session - given PM discussions in various places in IETF - some rumblings within IESG re SIPREC - be aware that this is something on people's mind - Keith G - why MSRP not real-time text - Chairs - already covered - could add to this - we will add to "real-time text to the charter update text" - ACTION ITEM. ** 3 types of tea in tins for Gonzales Charles Eckel SIPREC Protocol http://tools.ietf.org/html/draft-ietf-siprec-protocol-12 (see slides) - very familiar protocol draft - hopefully we can wrap up the last remaining things - included the changes discussed at the last IETF - no review comments other than from my co-author - we need more eyes on this - small changes so easy to review - want to call out - added a normative statement SRC MUST report the new recording state … - a more significant change in section 9 re metadata - more information on how quickly changes needed to made available in the metadata - trying to add, discovered that the existing text about signaling made it difficult to add so restructured a bit - won't read through here - encourage everyone to read through section 9 - need to make sure that we got it right Open Issue #1 - Lossless Recording - added something to the architecture draft - added the possibility of SIPREC protocol level capabilities in SRC and SRS - could add buffering or something in SRC - now left for quality of implementation decision - if leave as such - need to make it clearer that this is an issue - curious for thoughts Chair - a presentation on this at the end of the agenda - we can decide whether to tackle that problem or not and whether a separate draft Open Issue #2 - FIR vs. SIP INFO - how to deal with IDR requests - RFCs 4585 and 5108 and 5168 (informational) - what we currently have - mention both methods - but really mention the SIP INFO for backward compatibility and recommend FIR - seemed fine with everyone until testing at NENA event - feedback was that there are interoperability issues - is this quality of implementation or do we need to do something - a couple of options e.g. support both and what are the implications if wanting to record for UA - or allow FRC to choose which one it wants - can it use both and mix and match depending on the UA? complications and the last one is to provide recommendations and leave as quality of implementation issue Chair - asking for feedback Discussion: - Paul K - no brainer, SRS is the powerful box - that is the place to put requirements - 2 is preferable to 1 - 2 vs. 3, I'm not sure, kind of inclined for 2 but not sure - Chair: definitive is best for implementation - Charles: option 3 is my suggestion (as the draft is), but could leave with option 2 - would appreciate some help with the text - need to think about use cases - if a UA is capable of dealing with both, it can simplify for the SRS, but depends on capabilities of the SRC and SRS - if we can do better that is great - Chair: let's have more list discussion because missing people - but in favour of documenting one and generally in favour of having the server do the work - tentatively think going in the direction of option 2 Next steps: Chairs - plea for those who are interested, to look carefully at the draft - a complete review would be appreciated - will try to get NENA related guys not in the room to do a review - we pretty much done so full reviews could be go - should be done before the next meeting Paul Kyzivat, Metadata http://tools.ietf.org/html/draft-ietf-siprec-metadata-15 - mostly small editorial changes (language) - asked to updates ecurity considerations and did that - one place where we decided to borrow the representation of capabilities of schema from RFC 4235 (about two lines) - no open items - ready for WG Last Call Chairs - great, let's do it - will start after the meeting and get people to do it - ask all participants to go through last call and raise any issues now - there have been a lot of comments going through it Kevin ? - issues with facilitating all the features in the model in implementation (vendors) - one doesn't understand or implement as close as possible and get stuck in certain scenarios - model does not fit in certain scenarios - got into problems Chair - this is likely to come up more and more - spinning the document won't help - perhaps informational with use cases will be needed Paul - 2 issues - (1) not understanding (2) not working (but falls within scope) Chair - hear when map application in metadata choices - there are multiple ways to do it Kevin ? - conference with 120 participants - in and out - have to update the participant list which goes to everyone - more or less killing the application server Paul - would appreciate last call comments on this - maybe if understood the tweak we made and understood it then maybe the problem would go anyway - perhaps not obvious Kevin ? - other scenario - 2 inband conferences that join - how to use the group attribute to do that Chair - bring to the list Keith - resolve before last call Chair - agree - see what comment is and then go forward - better to surface these issues before going to last call Paul Kyzivat, Conference Recording http://tools.ietf.org/html/draft-yan-siprec-msrp-recording-00 - proposals for extension to SIPREC for conference recording - did charter and milestone stuff - re dates for milestones - did not update - Alissa - in earlier slide - last milestone was different Chair - need to resolve the difference - need to go back and look which one Chair - was content and .. RFC 4796 Alissa - go with that one - is it constrained to whatever content is defined by 4796? Chair - limit to document and application sharing not generic content - so limiting is a good idea - not sure whether to bring in the specific mechanism now - clearly we need to agree on this before going ahead - will resolve it on the list Paul - if share an application on the screen and record it as a video, want the metadata to tell you it was PowerPoint or something Chair - we will figure this out Richard B - q re privacy - wiretapping concerns - so where one endpoint is consenting - focused on end to end point calls Paul - allows conferences but doesn't have special metadata re what they are doing in the conference Richard - with conference recording - what it none of endpoints did not consent - owner of the bridge wants to record and no one else - Paul - already there Chair - need some discussion about this Paul - fuzzing of notice already Charles - no explicit consent from everyone but explicit notification - SIP signaling or endpoint to convey its own way Chair - need to check the wording Ekr - sympathic to Richard's concern but I fear that the ship has already sailed - the entire premise of the WG is to standardize that Chair - can't record without the client knowing - here Ekr - not impressed with must statements Chair - want to do want Ekr - sad by the whole thing Paul - ignoring bad guys in the sky - no different from calling a call centre Chair - and an emergency case Keith - legal intercept - they are not participants in the room - so my understanding is that the legal requirements in different countries are what define this - places like Germany - all people need to be informed and only one needs to consent Chair - that is the model that we have Paul - nothing to do with the new work - does not change Alissa - except the conferencing thing Paul - we already had that Chair - I don't think we have a explicit mechanism to notify all parities to the conference - only 2 ends of a conversation - might have to add Chris - need to go back and look - thought a whole bunch of notifications - need to clarify Chair - I think it mandates that all participants are notified Chris - I need to check Chair - take to list [no name] - don't call confidentiality or privacy - just courtesy - what about false expectations if receive no notification Chair - notification is just intended to be notification - can't control UA - it is a piece of protocol mechanism so does not matter what it is called Chair - protocol has existed for 2 years or more Paul - notice in signaling that recording is occurring Keith - not a courtesy - it is mandatory in certain countries Paul - we are not protocol police [no name] - presumably there are protocol police in some countries, e.g. telco regulators Next steps: Chair - need to fix the bottom milestone so can't move to adopt milestones but could make subject to that Alissa - and the dates Chair - bump the dates Chair - put the exact language and dates on the list - but is everyone in the room okay to adopt the milestones with that - any objections to doing that - can say yes or no on the list (no objections in the room) Chair - now remember why we changed the milestone last time - Chair - bring that to the list http://tools.ietf.org/html/draft-kyzivat-siprec-conference-use-cases-01 updated - and some editorial - inline with what we discussed last time - contains these use cases (see slides) - the first few aren't really conference sharing - less mechanisms than use cases - audio/video is not a new use case (included for completeness, don't propose to do anything new for this, only to fit in overall assemblage) - multi-user chat that you want to record and then full-blown multimedia conferencing Chair - only discussion at last meeting about audio/video recording, that's why added this last point John - mentioned this before - where is the blue ball at any given time Paul - left this out intentionally to bound the scope - I see the value of it - can also see that you don't need it in a lot of cases - John - if in solution and Paul - BFCP if want Chair - recording of BFCP is out of scope but who recorded in the metadata is in scope Paul - MSRP stream - no way to do that right now in SIPREC - using audio/video to record and metadata to separate and describe the audio and video are there for those purposes Paul (slide 9) - using video is quite straightforward - (slide 10) - re MSRP recording, since last time we submitted an individual draft as a start on doing this - still and empty shell more than a complete proposal - metadata is likely to be different and archictecural for how to get SRS in Brian (individual) - RTP instant message and then transcode from that, like 4103 Paul - not work so well for file transfers Keith - are you recording file transfers, if so difficult to convert to RTP Brian - do we record file transfer? Paul - MSRP - can put in RC and RS - then negotiation when you set up the channel Adam R - this sounds a little untenable - TCP over RDP to make this work - can do that, but don't! Paul - can do RTP over TCP, but people say it is usually a bad thing - but we could talk about lossless recording Michael (jabber room) - BSPC is important - Chair - send text and do a draft draft Paul (slide 11) - open framework right now - how to make MRSC sessions - (see slides for options) - most extreme possibility is to multiplex - throwing out the possibilities - no choice made yet, for discussion - a q in my mind, recording indicator thing - in some cases we say need to be prepared if can't send because no SIPREC aware endpoint - what happens? Chair - have to do an equivalent - in the RTP - have to figure this out [no name[ file transfer is harder Chair - take this to the list Paul - participant info gets messy - need to figure this out Michael (jabber) - option 2 might be preferable - not need real time like audio/video Paul - Brian already asked - is there anything different about file transfer - pick some stuff up and put in the metadata - but nothing special Keith - file transfer around in GMSA specs - points to a drop box - not sure if you want to include - a mechanism that exists in the world Chair - send a message to the list with a reference to the document so we have it Paul - not having seen it , fine, send URL to the recording Chair - SRS and dereference a URL Richard - dropboxing a recording is out of scope Chair - objection to send a URL in metadata that is referenced in the conference, server to decide what to do? [no name] - without more not useful - labeling needed Alissa - what about access control around the URL Chair - thought of because of background material (e.g. agenda) - but labelled seems useful Paul - obvious would be content type Alissa - more complicated than it seems Richard - let's stick to recording the conference itself - not context - if URL turns up in chat - avoid creep to record everything in the metadata Chair - is this ready to be adopted as a WG item yet? Paul - use cases, approaching Chair (Brian) - approaching what I need - speaking personally, exactly what I wanted to see in this work Paul - want more discussion on the list - it is a framework at this stage - time to speak up - no strong preference - Chair - please read the documents and send comments to the list - we want to move this document along Gerben Stam Lossless Recording (see slides) - statement in the architecture document - to the customer, lossless - recording is a priority - regulators demand proof of 100% recording (not just best effort) - a single pt of failure should not affect recording - we face, customers need to understand how lossless is achieved to feel comfortable (given the legal environment) - use case (see slides for details) - SRS failure SIP (covered) - if failure in recording session, the SRS is gone - the RP will still flow as long as session timer not expired … in the trading world the sessions stay open all day (so not call based) - continuous recording sessions (see slides) - SRS failure RTP (lossless?) - what if lose the media server? - RTCP reporting indicating loss but loss is simply not accepted - so in current implementation … (SIPREC should advise how to do this) 2 completely independently recording sessions and servers and it works - but storage keep one or two? - works okay - currently in the standerd, if it is trading - some small variations (1 recording session and two streams (left, right) - draft for it (2 m lines) but this is not really based on the standard - a vendor specific implementation - the first is the easiest and the best - a lot of implementations do not allow triple stream - SRS Failure RTP (good and bad) - see slides setting out pros and cons - negatives could be stronger if add video (cost) - SRS Failure RTP (options) - see slides - what is the advice to customers - include 2N implementation for RS/SRP in SIPREC or work towards a buffering option at SRC - [no name and no mike] until you run out of buffering - or no change and leave it up to the vendor (this is where we are now) Discussion: Charles - not a real strong preference for which way we go - does not belong in the protocol spec - needs to be clear that it is optional G - more in the nature of advice Charles - separate document would be best Paul - first reaction, you say lossless but no such thing .. we can avoid loss from these failures (i.e. not everything) - start to capture the use cases and the different types of failures that are being addressed - solutions may differ depending on the failures - then this could be an informative or best practices document unless we find something missing from the basic mechanism Arthur? [jabber] - buffering in SRC not acceptable Michael - not allowed directly G - buffering would be hard to do - the 2N is probably the best, but if we are hitting video then the 2N becomes very expensive Chair - expensive in what? - can do something with complexity or through bandwidth at it, guess which we do in the IETF [people talking over each other] Chair - where do we go from here? Chair - not a bad idea to create an information draft as to how to create quality recording G - a lot of SRC have implemented SIPREC but not coping with 2 recordings Chair - if want this to work - do it this way Paul? - start with an individual draft Chairs - agree - way forward is to write a draft [off mike] - if want people to partner with you, just ask AOB - adjourned