Wednesday, March 13, 2013
SIPREC
09:00 09:05 |
5 mins |
Chairs |
Administrative |
Blue Sheets, Note takers, Jabber scribes Etc |
09:05 09:15 |
10 mins |
Chairs |
WG Status Update |
|
09:15 09:45 |
30 mins |
Charles Eckel |
RTP Aspects |
|
09:45 10:15 |
30 mins |
Alan Johnston |
SIPREC Protocol |
|
10:15 10:45 |
30 mins |
Paul Kyzivat |
SIPREC Metadata |
|
10:45 11:15 |
30 mins |
Paul Kyzivat |
SIPREC Call Flows |
RTP Aspects (Charles Eckel):
http://tools.ietf.org/html/draft-ietf-siprec-protocol-09
Media Delivery from SRC to SRS
RTP Session Usages: SUpport multiple m=lines and mixing. (No SSRC multiplexing)
Added RTP session Usage by SRS (section 8.4)
SRS that supports recording an audio CS MUST support SRC usage of separate audio m-lines in SDP, one per CS media direction
SRS that supports recording a video CS MUST support SRC usage of separate video m-lines in SDP, one per CS media direction
Examples:
---- SRS supporting audio call MUST support receiving at least two audio m-lines
---- SRS supporting audio and video call, MUST support receiving at least four total m-lines in the SDP, two audio m-lines and two video m-lines
These requirements allow implementation of SRS that supports:
video only
recording only one direction of one stream in a CS
E.g. record security cameras that only send (not receive) video without any audio
Discussion:
PK: Requiring to do mixed
Hadriel: This is whats mandatory. Optional to support mixed streams
PK: Do you expect SRS to support a diversity of SRCs?
Hadriel: product decision. Minimum is separate m-lines for each participant.
PK: how many m-lines to you support. If you support 2, you automatically support 1.
Hadriel: Yes, single directional.
Brian: don't want to assume client has to mix
PK: some clients want to mix. SRS can tell SRC to do mixed or mixed.
Charles: have way for SRC to tell if option is not supported (e,g., multiple m-lines returned with port 0, then you can fallback. We define mechanisms for individual, mixed streams, etc. but support at a minimum (per slide 4)
PK: what does in mean "not supported"
Hadriel: can't prevent this, but doesn't recognize as separate participants. If it recognizes two participants then must do two separate m-lines.
Charles: you would still have all the recorded audio, but can't separate out participants
hadriel : this is implementation details. Just need mandatory to implement minimum. Why would it want to mix? Isn't a BW issue.
PK: conference focus
Charles: these requirements came from unmixed use case.
Hadriel: if SRC claims each as separate participants, mixing could be a problem. All that's mandated is that it supports unmixed streams. This requirement is on the SRC already.
Action Item: Charles. make sure that's the case.
Follow-up: Req is on SRC.
Conclusion: Add text to SRS for this.
Follow-up Discussion :
PK: 2nd issue. don't need SRC to support both ways. Thus, SRC only needs to support one. But, SRS needs to support both mixed and unmixed.
Charles: that works. Products will support the mixing. This would change structure. SRC is fine. Need to add req to SRS to support both.
ACtion: bring this to mailing list for discussion.
Roni: Assume you want is for SRC to handle what's users want. Why is req. one m-line for video. EP to EP with video, you have two m-lines.
Charles: You may have SRCs or SRSs that don't support that.
Conclusion: add text that minimum is supported - this means all media may not be recorded
Authentication and authorization
MUST support TLS mutual authenticatio on SRS and SRC
May support additional
SRC and SRS may support additional:
Media Protection
Might want to use EKT
SRC MAY use same or different keys in RS than in CS
Discussion:
Jonathan L: If they encrypt diff data with same parms and same keys, an attacker could get info. If you encrypt/decrypt, must use two separate keys.
Charles: can change this to a MUST use different key
Action: take this discussion to the mailing list.
Action: Ask Richard Barnes to re-review the security recommendations (and this particular point)
SIPREC Protocol - Non-RTP (Alan Johnston):
One open Issue: Hold/Resume
Does Hold/Resume on CS have anything to do with RS?
Call flows shows this (but probably shouldn't)
Discussion:
PK: Not sure there is a conclusion.
Charles: issue was mixing of terminology (hold versus mute). Should be able to fix this.
Note: Partha - protocol document (and not call flows) need updating
Action: confirm this on the mailing list (and update doc to reflect)
PK: discussion on list about what happens when two SRSs send metadata that refer to a single element (same ID). Is that okay? Need to add text to protocol document (and not metadata document).
Action: add the text
Conclusion: update document and then WGLC.
SIPREC Metadata (Paul):
Open issues:
Reason Code:
Currently is text. Suggestion to support SIP reason header format.
Agreement (per list): support SIP reason header format (equivalent to SIP Reason header in XML).
Can have reasons from multiple dialogs.
Action: Exact Format (for multiples with protocol=SIP) to be discussed on the list
Clarification regarding use of Common UUID from multiple SRC
⁃ Propose to add text to 6.10: multiple SRCs can refer to the same element/UUID (how they know that is out of scope)
Conclusion: Update doc per agreement on open issues and then WGLC
SIPREC Call Flow (Paul):
Open issues:
- Do you want callflows to show SIP?
- Add more callflows?
PK: to exercise each piece of schema
MB: suggestion to do call flows for use cases
This is lots of work - need real implementation flows.
Note: Nena interop for this later this year.
Charles: there is SuperOp in April
Gonzalo: confirmed that there was no SIPREC testing at SIPit30
Olle (Jabber): SIPit 31
Hum for this as WG document.
Conclusion: agreed as WG document