Minutes of the SIPREC WG Meeting, IETF#82, Taipei Thursday, November 17th 2011, 1520-1720 Afternoon Session II (Room 101C) ========================================================================= Meeting chaired by Brian Rosen and Andy Hutton. Minutes produced by Andy Hutton based on notes from Thomas Stach and Alan Johnston Jabber log: http://www.ietf.org/jabber/logs/siprec/2011-11-17.html Meetecho Recording: http://www.meetecho.com/ietf82/recordings#SIPREC (For Individual Agenda Items See below). Meeting started at 15:20 Topic - Administrivia (chairs) ============================== Meetecho: http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=siprec_IETF82&chapter=part_1 Slides: http://tools.ietf.org/agenda/82/slides/siprec-1.pdf No changes to published agenda. Two interims held since IETF#81 - 2011-09-19 & 2011-09-23 http://www.ietf.org/proceedings/interim/2011/09/19/siprec/proceedings.html Milestones have recently been updated. Done - Use Cases and Requirements now an Informational RFC Feb 2012 - Architecture to IESG as Informational RFC May 2012 - Submit Metadata model and format to IESG as Proposed Standard RFC Jun 2012 - Submit protocol draft to IESG as Proposed Standard RFC SIPREC Architecture - Leon Portman ---------------------------------- Slides: http://tools.ietf.org/agenda/82/slides/siprec-3.pdf Meetecho: http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=siprec_IETF82&chapter=part_5 Andy asked whether to explicitly include SDP into Figure 1 (and other). It was agreed that this is not necessary. Open Issue: how to identify CS in SRS initiated recording Proposal: Private agreement between SRC and SRS about Request-URI parameters Hadriel Kaplan: What type of information could be used to identify the CS? This will help answer the question. Paul: Private agreement is not ruled out Alan Johnston: Could use Join Leon: Doesn't help in persistent recording session Charles Eckel: How do we know request succeeded Andy: This draft just needs to point out that the INVITE can come from SRS and leave the details to the protocol draft. Paul: We are deciding not to do this now we could specify this at a later date. Hadriel: If we are deferring, then don't put anything in this document. Don't constrain the future. Andy: There has been no real discussion on this the current text in the architecture document was just to initiate discussion. Chairs: take to the list for further discussion we would like to get to WGLC soon but need an update. SIPREC Protocol - Leon Portman ------------------------------- Slides: http://tools.ietf.org/agenda/82/slides/siprec-4.pdf Meetecho: http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=siprec_IETF82&chapter=part_3 Issue 1: srs and src feature tags Paul: Rename to '+sip.src' and '+sip.srs'. RFC 3840 is not clear, but feature tags should really be used for capabilities Alan: Similar to isfocus which works well, suggest we keep using these tags Hadriel: What are we trying to accomplish? Andy: Means I am an SRS and I want you to be an SRC, and vice versa Hadriel: I'm OK with this This was accepted. Issue 2: siprec option tag Proposal: two option tags srs and src Hadriel: Not sure use of feature tags is broken, and have feature tags Paul: Needed if we don't do feature tags Hadriel: Since we have feature tags, stay with siprec Since feature tags were already agreed, usage of two options tag was rejected. Issue 3: RTP multiplexing support Partha Ravindran: Things are changing today in AVT Hadriel: Someone could interpret this text a different way, might need a shim header to do this Magnus Westerland: Need to be careful. Some fine and others still being discussed. Paul: Thought multiplexing meant multiple SSRCs Charles: RTP draft is generic, but doesn't deal with this Magnus: If media mix, could do different things Support for RTP multiplexing. This should probably be left out of scope. More discussion needed Support for RTP and RTCP multiplexing to maintain NAT bindings. This would be ok. To be reconfirmed. Chairs: No resolution need more discussion regarding what to say about multiplexing in the protocol draft. Issue 4: recordpref Support for "recordpref" on session level as well Same for "record" ? Presenter's proposal accepted. Additional Open Items Request of full metadata state Problem is that a full metadata snapshot may need also SDP. This cannot go into SIP 200OK response of an offerless UPDATE request. In order to avoid multiple options, only (re-)INVITE could be used. However usage of UPDATE (or possibly multiple UPDATEs) also has some advantages. Decision? Hadriel: Can't send offer in 200 OK to UPDATE Hadriel: Are we mandating UPDATE Leon: No, INVITE or UPDATE is defined in the spec Hadriel: Pick only one solution and stick with it Partha: Can use reINVITE Hadriel: can use UPDATE if it has an SDP offer Paul: Argument has nothing to do with UPDATE. Can send update request in reINVITE Hadriel: Fine, just pick one we don't want optionality. Charles: Only send UPDATE with no offer to request a metadata snapshot. SRC can then send metadata. Chairs: no agreement RTP & RTCP Considerations for SIPREC- Charles Eckel. ---------------------------------------------------- Slides: http://tools.ietf.org/agenda/82/slides/siprec-0.pdf Meetecho: http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=siprec_IETF82&chapter=part_4 RTP Recommendations for SIPREC - Charles Eckel Multiplexing of media streams Paul: If receive them, do you need to support them Magnus: There are new capabilities from VoIP world, so have new requirements. How many streams? Hadriel: Don't open this can of worms. No port shortage Paul: Could have hundreds of m= lines in SDP, so we need this Magnus: This is tricky Leon: Do you mean N independent CS Paul: I did mean N separate CS Hadriel: This is problematic combining these in a single RS Leon: Should only do this for related CS, for lots of reasons Hadriel: This will break many things, for example RTCP Charles: This draft warns about RTCP issues Lots more discussion of the models and RTP issues. Actual work in AVTcore about multiplexing should probably left out of scope. However, section 4.3 needs more text about various usages of RTP by mixers/translators. --> send text. SIPREC Metadata - Ran Mohan --------------------------- Slides: http://www.ietf.org/proceedings/82/slides/siprec-2.pptx Meetecho: http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=siprec_IETF82&chapter=part_4 Issue 1 Any objections to allow a participant to be associated with *zero* or more sessions, rather than one or more ? Addresses certain persistent RS cases (e.g. Agent Phone (SRC) to SRS). It gives flexibility for XML representation (*possible* to represent a participant in XML with no associations to sessions. ) Already discussed on list, --> Accepted. Issue 2 Any objections to allow a stream to be associated with *zero* or more sessions, rather than one or more? Addresses persistent RS cases (e.g. Agent Phone (SRC) to SRS) It gives flexibility for XML representation (*possible* to represent a stream in XML with no associations to sessions. ) Already discussed on list, --> Accepted. Issue 3 Any objections to allow a CS to have zero or more participants ? Already discussed on list, --> Accepted. Open Item - Communication Session Current draft has associate/disassociate time These must be attributes of association of CS to RS. Any objections ? --> Accepted. There was a comment to include start/Stop time also. Is it needed ? Start time seems to makes since RS may have started only after CS was started. Stop time seems to be problematic in case of missing association. Problem to define start/stop time since a CS may include multiple SIP dialogs. Leon: start is useful, but there is a problem with stop - how is stop sent? Ram: Are there any use cases? Paul: Can do it for a dialog, but not for a CS which can be many dialogs, so not clear how you would define when the start time was but can identify when participants join and leave. Brian: What do we need this for? Is there a need to track the times a CS is part of CS-Group ? Leon: This is needed for snapshot Paul: Example could be supervisor who joins a call center call to listen or whisper might need to now when this happens. - might need this. Chairs: Need more discussion on use cases and whether this needs to be specified or wherther it is an extension. Open Item: Metadata Model: Participant / Carry CNAME as participant attribute Any objections to having a new attribute in Participant class to represent CNAME? This could be useful, but might not work in more complicated cases (e.g. recordings of conferences). Paul: You need something. Magnus: It is a good idea but maybe not the main use case at the moment. Hadriel: Could have two different CNAMEs for the same endpoint if they are not sync so not a participant identifier. Ram: Useful for correlation Charles: We are not using it as participant ID, but could be used to map to a participant. Paul: It can get complicated Brian: Doesn't mean we can't try Hadriel: Can hurt if people expect this information Brian: We aren't chartered to come up with identifier for multiple devices or users Hadriel: This is not really a solution to this problem Paul: Defer this as it needs more investigation Charles: Andy: Needs more discussion Open issue - Metadata Format: Attributes of association This requires change to linkage in the model to allow a participant to be associated with Zero or more sessions ( to keep in consistent with XML) When one of the element in the association ends the association element also ends With this approach it is easy to interpret and update the association properties as it is a separate XML element. Any objections go with this approach ? Already discussed on list, --> Accepted. Open Issue - Metadata Format: representing send, recv attributes in XML In the current XML schema send, recv are XML elements inside . Since these are attributes of association of participant to a Stream this must be inside participantStreamAssoc XML element. Any objections ? --> Accepted.