Subject: [rtcweb] IETF#93: Minutes from 1st RTCWEB session

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Jul 2015 18:59:59 +0000

Hi,

Below are my notes from the 1st RTCWEB session.

Regards,

Christer

--------------------------------------------------

Topic:           JSEP

Presenter:       Eric Rescorla & Justin Uberti

Draft:           draft-ietf-rtcweb-jsep

The presenters went through the list of open issues in the draft, and presented suggestions on how to solve the issues.

#162: LS

Proposal: edge case - document that this is currently unsupported. The callee can accept what caller wanted or reject the call.

There were two hums. The first hum was about who understands the problem, with very little response. The second hum was whether to NOT agree to the suggested proposal, with a single objection.

Outcome: The issue will be re-visited on Friday. Harald Alvestrand will provide pseudo code for an alternative solution.

#158: (imageattr and CVO)

Proposal: always use a single SDP imageattr attribute.

Outcome: The proposal was agreed.

#122: AS->TIAS conversion

Proposal: The following formula for calculating the TIAS from the AS was proposed:

TIAS = AS * 0.95 - packet_rate * hfr_size

packet_rate = 50

hdr_size = 40

If more accurace is wanted, use TIAS instead of AS.

Outcome: The proposal as such was agreed, but the formula will be fixed, so that the same units are used for all variables.

#125: BUNDLE and SDP mangling

Proposal: Do not support this

Outcome: The proposal was agreed.

#155: Selecting between multiple aspect ratios

Proposal: Implementations SHOULD pick imageattr with highest q= value that doesn't require upscaling.

Outcome: The proposal was agreed, but SHOUDLD will be changed to MUST.

#143: Can you call CreateOffer in remote-pranswer

Proposal: Simplest option - just allow this.

Outcome: The proposal was agreed.

#149: SSRC and clock rate

RFC 7160 prohibits changing of the clock rate within a given SSRC. Currently only a single SSRC value is provided per m- line, but an m- line can contain multiple codes, with different clock rates.

Proposal: document the limitation ad move on

- note that when changing between codes with different clock rates, you will get wacky RTP timestamps

- can revisit moving away from usage of SSRC in the future once MID and ESID behaviours are better understood

It was discussed whether we should signal multiple SSRCs (one for each clock rate), and allow re-usage of SSRCs that have been previously used.

HUM:

      1) You must not switch between clock rates

      2) You are allowed to switch, but the impacts must be described

Not a clear consensus.

Outcome: Author is requested to provide some text, which will be provided to the mailing list.

#169 multiple a=fingerprint lines

Proposal:

- Generate a=fingerprint line for each certificate

- Ensure received certification matches a=fingerprint line with corresponding hash

Outcome: The proposal was agreed.

#15 Early Transport Warmup

Randall J indicated that he is willing to provide an alternative solution.

Outcome: Will be re-visited on Friday. Randall J will provide some details on his alternative solution.