Wednesday, March 13, 2013


09:00 09:05

5 mins



Blue Sheets, Note takers, Jabber scribes Etc

09:05 09:15

10 mins


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):

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


---- 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


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


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)


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