Minutes of the
Meeting: MMUSIC Working Group at IETF 87
The MMUSIC working group of the IETF met at
IETF #87 in Berlin, Germany.
The MMUSIC WG met on Tuesday July 30, 2013 from
13:00 to 15:00 and on Wednesday July 31, 2013 from 13:00 to 15:00.
The meeting was chaired by Flemming Andreasen
and Ari Keranen.
Keith Drage, Christer Holmberg and the chairs
took notes both days.
Jonathan Lennox acted as Jabber relay on July
30, and Ole Johansen acted as Jabber relay on July 31.
The meetings were broadcast live and recorded
by the Meetecho team. The recordings of the sessions are available at
the following URLs:
Below is the final agenda with
links to the relevant sub-sections below:
Tuesday, July 30, 2013
13:00-13:15 Introduction and
13:15-13:25 Mobility with ICE
13:25-13:40 Happy Eyeballs
Extension for ICE
13:40-13:55 Negotiating Human
Language Using SDP
13:55-14:10 Trickle ICE:
Incremental Provisioning of Candidates for the Interactive Connectivity
Establishment (ICE) Protocol
Session Initiation Protocol (SIP) usage for Trickle ICE
14:10-14:25 The Session
Description Protocol (SDP) Application Token Attribute
14:25-14:40 Economical Use of the
Offer/Answer Model in Sessions with Multiple Media Sources
14:40-14:50 A Framework for SDP
Attributes when Multiplexing
14:50-15:00 Meta-data Attribute
signaLling with ICE
Wednesday, July 31, 2013
Negotiation Using Session Description Protocol (SDP) Port Numbers
13:40-14:20 A Unified Plan for
Using SDP with Large Numbers of Media Flows
14:20-15:00 Plan Discussion and
Decision on Path Forward
Jabber relay: Jonathan Lennox
- Keith Drage:
- Christer Holmberg
20 years of MMUSIC; Henning Schulzrinne was there
from the beginning.
Agenda approved (nobody opposed).
- IESG review of SDP-CS draft resulted in
correlation mechanisms being mandatory and that is problematic for
- Gonzalo: Status is the draft defines 3
correlation mechanisms; IESG decided they should all be mandatory.
Discussion on the list but apparently people didn’t have time to catch
up. Subsequently, some people had concerns with that.
- Gonzalo: Will probably pull out of RFC editor
queue and find a way forward (maybe do another IETF Last Call). Will
report what to do.
RFC 2326bis: GEN-ART review comments that would
benefit from WG input.
Publication has been requested for
delayed-duplication and duplication-grouping drafts.
The chairs noted that there has been very little
interest in working on the draft, and that the WG needs to make a
decision on whether to continue the work:
- The draft was originally WGLC’d in
- Limited interest and updates since then
- Subsequent questions on scope and
technical concerns have been raised (e.g., references to MIDCOM
The Chairs asked about the WG’s interest to
continue working on the draft:
- 6 people in the room indicated they have read
the draft in the last 2 years
- Nobody in the room indicated
interest in it
- Nobody in the room indicated
willingness to contribute to it
Decision: Based on the
above feedback, the chairs called that
the middleboxes draft milestone will be removed in accordance with what
has previously been noted on the list. The authors are free to pursue
the document as an individual effort outside the WG. There were
no objections to this.
The “SDP negotiation for DataChannel Sub-protocols” draft
authors have asked people to review SDP extension aspects of the draft.
Comments should be directed to the DISPATCH list at this point.
3GPP Liaison Request on missing SDP attributes for
- Cullen Jennings asked for clarification on why
we would register etag and not mtag?
- Answer is because it applies to RTSP 1.0 (RFC
2326). Registration would be for RFC 2326 only.
RTP Payload Types Registry
MMUSIC list discussion suggesting the “Reference”
section should include “[RFC5761]”:
- Roni Even (AVTCORE co-chair): Another problem is
that the registry has been closed so need to see what is the procedure.
- Flemming: And the
discussion should continue in the AVTCORE
- Roni Even: Agreed
Decision: AVTCORE will
handle this as it is an RTP issue.
Compared to ICE restart, MICE avoids new TLS
handshake, round trips for candidate discovery, and SIP server
Offer/Answer. Trickle ICE needs support from both endpoints (MICE does
- Bullet is kind of misleading; agree that trickle
ICE alone wouldn't work that well for mobility, however it would make a
lot of sense for MICE to explain how it would work a lot better with
- Tiru agrees and will update accordingly in the
- People read the latest version: 8 people.
- Anybody still having concerns with ICE restart:
- Still think there are some interaction issues
but too busy with other stuff right now to engage.
- Unidentified also said he was too busy right
- Working group has a lot of work going on right
now. Taking hum on WG adoption of the work at this point in time. Very
weak support. Chairs calling not enough support at this time.
Multihomed host has many IPv6 addresses which
should have high priority (based on RFC 5245) which results in delay
with broken IPv6. Proposing algorithm to promote candidates from the
less preferred IP-address family to be tested earlier.
New ICE-option has been introduced that indicates
how to promote candidates.
- Both endpoints have to do it in the same order
for this to work (was raised last time).
- Does not believe current draft addresses the
fact what happens if only one endpoints supports this.
Tiru: This algorithm only kicks in if both
endpoints support it
- Why isn't changing the candidate priorities
- Tiru: Thought about that but problem is that
policy table on each host may be quite different. Will send examples
showing the issue.
- Lennox: Signaling
precedence values should solve that.
Jonathan Lennox: Confusion with attribute versus
Martin Thomson: Looking at RFC 5245, don't see any
reason to need extra signaling. IPv6 preference is only recommendation.
Bernard Adoba: moving things with changing
priorities works fine; have been doing it for years
Jonathan Lennox: recommendation of 5245 should be
able to be changed in backward compatible way.
Flemming: seem to be going through the same
discussion as last meeting. Is it just clarification to 5245bis or do
we need stand-alone spec?
Tiru: Think we need more than just clarification,
can show example on the list.
- Still think 5245bis should be updated to be more
clear on how candidates should be prioritized; IPv6 prioritized higher
even if we know it doesn’t work
Tiru: simply changing candidate priorities is not
enough; need to adjust the candidate pair list.
- Isn’t it sufficient if both endpoints do the
same (new) prioritization?
- Need more clarification and examples. Tiru to
send to the list.
- Good point that the RFC 5245 algorithm doesn’t
allow pushing server reflexive pairs above host-only pairs. Type
preference overrides individual preferences. Justification to do
something for this.
agreement that clarifications and more discussion are needed for
5245bis. Authors believe that we need more than just clarification of
existing ICE procedures. Authors will send mail to the list to initiate
Want to enable matching capabilities and language
preferences of a user that is making a call with the capabilities of
the called party to use those languages and medium. Particularly useful
e.g., with emergency calls, where there is no context between the
caller and callee. SDP stream attribute with language tags.
Open issues: how much need for language
preferences? Is SDP right choice? Complexity vs. completeness.
Randall noted that the issue of whether to use SDP
for this or not has been re-opened.
- Reopened the SDP debate.
- Always a tension between the signaling and media
part. Original idea was that call routing would be done by signaling
(e.g. SIP), whereas media parameters would be handled by SDP. If media
parameters were to influence routing, we then had caller preferences
developed for SIP (i.e. a signaling level solution). And this
seems like preference since you don’t want the call to fail if the
preferences are not met.
- SDP is more of "sorry, I can't speak your codec".
- Agree it's a per-media issue, but except for a
few border cases, you don't really have different languages for
- Henning's proposal would be to see if we can
make caller preferences work for this instead. If that doesn't work,
then let's look at other options. The fact that we have SIP indications
in here suggests that we are on the wrong track.
- Looked at caller preferences originally.
- The call doesn’t necessarily fail as how the
draft is currently written
Henning responding we are fundamentally breaking
the SDP model with this.
- Not fixed on particular way on doing this. If
other people are convinced some other way is good, we should do that.
- Caller preferences seem to be the right way.
- RFC 3840 provides this capability. If that’s not
sufficient, we can define new media feature tags.
- If you want the call to fail in case receiver
doesn’t speak language, should use option tag with require header
- SIP stuff needs to be more than a hint.
- As DISPATCH co-chair,
it seems like we should bring up the two different architectural ways
to deal with the problem to DISPATCH and
then take it from there to the right WG
- There are some 3GPP requirements for this and
use cases floating around (not communicated formally).
- Think there are more cases than we are alluding
to. Sign language is one of them.
- When you looked at caller preferences, what were
the problems you encountered? If it’s just about prettiness or
Randall: No decisions
were made on prettiness.
Conclusion: Discussion to
continue in DISPATCH.
Main open issue: How do we handle candidate
There is currently a failure scenario that can
be resolved in two different ways.
1) We forget about freezing
- Slim (?) chance of timeouts if STUN &
2) We preserve component order; e.g., don’t send
RTP candidates before we have the RTCP candidates
- May slow delay ICE processing a bit in some
Emil asking for any preference opinion
- 3rd possibility;
vanilla ICE arbitrarily assigns an order to candidates with the same foundation across components. I think it would work if we kept that high level algorithm but changed what we mean by "first", based on trickled first (first one you hear is the highest priority one)
- The order of discovery may not be what you
think. Host candidates come in first. TURN candidates come in later.
Attempting to think about sequencing does not make sense.
- Not suggesting a solution; just exploring the
- And also need to try at the same time at both
parties. Otherwise checks fail.
- Question of what you want to freeze.
- In RFC5245 you have frozen list and waiting
list. Stuff goes inevitably in different order to waiting list. Believe
the frozen algorithm can be adapted pretty cleanly.
- Going back to the 2 suggested algorithms. Do not
believe the first proposal works. Not convinced the second proposal
- Do believe the problem is solvable.
- Maybe you could say host candidates never come
in trickle ICE (always know those).
- Can make assumptions on total number of things
and the narrowest window firewalls leave open for checks
- Believe more work and analysis is needed.
- ICE does not discriminate between different
candidates based on the time they came in.
- Does believe second option works; it’s basic RFC
5245. Asking Cullen to explain why it won't (off-line).
- Sent some comments to list.
- Number of candidates can exist in transit which
means both ends can have a different idea about the candidates.
- Believe safe choice is the last one. May not get
the optimizations, but believe it will work.
- In RTCWEB context there’s only one component
- With one component bundle total it makes it a
- Multiple ports for media is getting more rare
Emil asked people to also review Trickle ICE SIP
document since it has open issues.
- Could raise a point that raises
some concerns with the second option
option to be investigated further. Cullen and Ekr raised concerns that
should be discussed. Also need people to review “Trickle
ICE SIP” document.
Need mechanism for mapping single source identified
by SSRC to application logic.
Colin Perkins (slide 3):
- Second bullet point: change "can" to "must";
will need to do all three (or at least "some signaling" and RTP).
Colin Perkins (slide 5):
- How can you change the camera without changing
the video coding context?
- Roni: All the cameras use the same encoding
- Colin: Always assumed the SSRC would change if
the camera changes
- Jonathan Lennox clarified the media source
(camera) doesn't change (see slide 4, camera 2). Whether it's the left
or the right camera is what changes.
- In unified type plan context these were under
- Don’t understand how application ID can have
image resolution associated; other things seem OK
- m-line would negotiate with a=image
attribute resolution of all cameras; app-id just an identifier
- As co-author, was trying to cover both Plan A
and Plan B scenario. Draft was written before the Unified
Plan document. Layer of indirection
that you negotiate app-id instead of SSRCs
- Not sure you get
this functionality in WEBRTC without some API changes. Relying on fact
this gets through with no packet loss etc.
- Seems to be an application specific mapping that
we put down in the media path layer. We already have the SSRC. Why
don't we use that.
- You could do that, but would have to send at
several second intervals information that this SSRC is for this purpose
- Seems like a good thing that can solve a bunch
of problems. Keep working on it.
- To Uwe’s question, second application for this
is RTCWeb. Need something similar for this for WebRTC / unified anyway.
- Think there is a use case for some way of
mapping an RTP stream to some high level concept of a stream. This
seems like a reasonable starter, but looks overly complicated; believe
it can be simplified
- Suggest to decouple it from the different plan
proposals and make it independent of the plans. Should be able to
simplify signaling and make it plan-independent.
to continue working on the draft and update based on feedback received
Main reason to use SDP is legacy interoperability,
and many of the common issues are already hashed out. How about beyond
- SDP is about setting up and configuring RTP
- XCON, RFC 4575, WebRTC JS, and CLUE are not
about SDP; the examples are not motivating
Roni Even (commenting on slide 4):
- This is not enough; the receiver won’t
know how many streams to receive.
- Need at least max-ssrc
- How do you differentiate between multiple SSRCs
that are switched vs. displayed simultaneously?
- Implementation dependent (for video at least).
- Depends what experience is delivered to end user.
- For audio, it's not implementation dependent;
pretty universal that it means one at a time.
- There are things that work and are fairly
- It actually works without being standardized.
It's ok that one system renders one way and another system renders it
- For audio, agree we need agreement for
- Not suggesting that you should not do something
like unified plan (A)
- Suggesting you may also do something different
Martin Thomson (commenting on slide 7):
- Sort of arguing a number of things. Trying to
get to "what semantics does SDP carry”
- What are the assumptions you are making ?
- Different perspectives: Cullen wants SDP to be
prescriptive, Bernard wants it to be looser.
- There are two long-standing different
interpretations as to what are the proper semantics
- Thought this presentation was about "can MMUSIC
agree on a common set of semantics for an m= line" as opposed to a plan
- If we have to solve the problem of what the
right semantics are, can MMUSIC agree on common set of semantics for
SDP and say either it fits or we need to extend it.
- Trying to get everyone agree on one single set
of semantics is virtually impossible
- Trying to get to:
- If I say nothing, then it means I can do
only audio and video
- If I say I can do multiple m-lines, it means
I can do unified plan
- If I use max-ssrc, I can have multiple
streams on singe m-line
- Getting into syntactic sugar
- The big question is should SDP grow or provide
- Would like to get to interoperability between
two devices with arbitrary number of cameras and displays.
- Maybe the specifications don’t meet that need,
but they ought to
- Real question is do we think can SDP provide
sufficient description of media?
Flemming (as chair):
- Getting into discussion of Wednesday [Unified
Plan, etc.]. Need to think about what should be in discussion tomorrow.
Don't try and solve everything in last 5 minutes.
- People have different understanding what SDP
- Has changed quite a bit from one audio and one
- The different mental models generalize in
- Problem is offer/answer. People interpreted that
- Proposals are trying to put some information on
the intended semantics
- To Ekr, lots of things will break, but not the
specific things you mentioned.
- What Ekr said is important; how much semantics
does it need to carry? Enough to make it work in a consistent manner.
- Colin put it well; people come with different
- 1 view: when you come with 3 video streams,
there is no need to have them show up the same way. Another view is
that you should care. Maybe we do need to care about that.
- What are the use cases we are trying to drive
and how do we express those?
- We have a well defined concept of a media
stream, SSRC. App will know it's receiving two media streams based on
- If you are receiving two streams of media you
should make sensible decision about what to do with them.
- CLUE found it didn't make sense to do it on top
of SDP, so did layer something on top
- In Ekr's case, maybe you shouldn’t layer
something on top
- If you don't have some way of conveying what
should happen with those cameras, you are not likely to get a good
- For RTCWEB simple cases, maybe you don't need
anything else, in other cases you may need
Update on where we are now. One open issue: how to
categorize encapsulating attributes? 65% has been reviewed, can we make
this WG doc?
- Support the work but object to the document
recommending for or against use of certain attributes (only if
recommendations are due to multiplexing)
- Suhas: Comment was made last time and has
already been incorporated.
- This WG has already far too much work; but
Bundle depends on this
- Reason I didn’t want to do Bundle was that I
didn’t want to do all this work, so thank you for doing this since we
decided to do bundle
- Don’t care if this is separate doc or appendix
Flemming (as chair): we are over time so need to
continue discussion on the list
[Tuesday session ran out of time and the draft was
Christer presented his slides.
Christed has received a few off-line
comments suggesting some of the issues are outside the scope of bundle;
intent is to clarify open issues including if they are out of scope.
Slide 4 Questions (Q1, Q2, Q7)
- Q1: “Can we agree
that, within a BUNDLE group (including all m- lines associated with the
group), any given PT value can only be used for a single codec
- Q2: “If Q1, do we
agree that we need EXPLICIT text somewhere*, as there are opinions that
simply referencing RFC 3550 might not be clear enough?”
- Q7: “Within a
BUNDLE group, do we allow the usage of the same PT value in multiple
RTP m- lines, for the SAME codec configuration?”
Should we say anything in Bundle about this, and
if so what ?
- H.264 sprop parameters use case; both H.264 but
with different parameters. Would that be different values or not ?
Should think about how we want to handle that (e.g. do we allow same PT
- Related to Roni's question about what is a
- If there is something you think you can vary
from one m-line to another about a payload type configuration. You have
to be able to tell which m-line a payload type is associated with.
Christer suggests discussing further on the list.
Cullen objects; reason
for these meetings is to discuss solution rather than deferring to
Martin Thomson asking if we need more people to
answer “yes” to these questions ?
- Answer is yes, with more clarification needed on
what constitutes a codec configuration. H.264 use case is a specific
- Proposal to say same rtpmap and fmtp.
- Mo Zanaty brings up other parameters, e.g.
- Jonathan Lennox says it should be something that
affects the decoder.
- Mo: imageattr is not a decoder property
Codec configuration strawman proposal from
- rtpmap and fmtp. Use that as starting point (put
text in draft and discuss further)
- Concerned if you want to change some of the
parameters later on in a subsequent offer; would then have to change
the payload type.
- Christer: Rule applies to all offer/answers
- Agree with Cullen and Lennox; nail it.
- If you can figure it out from the RTP it is not
a codec parameter
- Also need to look at Opus sprop parameters.
Conclusion on Q1, Q2 and Q7:
Q2: Yes, Lennox will send suggested text to
clarify the term “codec configuration”.
Slide 5 (Mapping RTP data to
- Q3: “Do we need to
specify a default mechanism for mapping RTP data to m-lines?”
- Q4: If Q3, do we mandate
applications to support, and use (unless applications are made aware of
other mechanisms supported by all endpoints) PT for mapping received
Christer noted that he had received off-line
comments that it was addressed at the Interim meeting; Christer didn't
see it in minutes though, so want to re-confirm.
Q3: Christer suggests answer is no
- Believe we made a decision at the interim that
is consistent with the unified plan proposal.
- Should it live in the unified plan or here ?
- Cullen: Believe it should be in the bundle
document, but depends on unified plan. So that text part of unified
plan would move to this document.
- All this talk about a default seems to be making
a distinction where none is needed. Can't see a use case where we need
the distinction (there shouldn't be a conflict between SSRC and payload
- Christer: Mo had specified that if you had the
same payload type for multiple m-lines, there may be in issue (which
m-line does it belong to ?).
- Colin believes we can provide rules
- Signaled SSRC: use that
- Unique payload types: use those
- Colin: Two questions here: 1) Mandating it's
possible. 2) How to do it.
Not taking a position on the mandatory part. It's easy to write up a
mechanism for how to do it.
- Unified plan has much more on this; suggest we
defer discussion until we have gone through Adam's slides.
- Paul believes they are orthogonal; would like to
discuss further now, but agree to defer for now.
- The information is there in the SDP; you can
choose to either use it or not.
Conclusion on Q1 & Q4: Defer
further discussion until we have gone through the unified plan slides.
Slide 6 (Q5)
- Q5: “Within a SIP
session, once both endpoints have indicated support of BUNDLE, do we
allow an Offerer to assign an address:port to multiple m- lines, before
the Answerer has selected that address:port as a BUNDLE address?”
- Q6: “If Q5, do we
allow an Offerer to assign an address:port to multiple m- lines before
the Answerer has, within the SIP session, indicated that it supports
BUNDLE? A typical example would be assigning an address:port to
multiple m-lines already in the initial SDP Offer for a SIP session.”
Christer suggests we allow it
Justin Uberti: What is the difference between Q5
and Q6 ?
- Q6 is the initial offer
- Q5 is the reInvite (new offer)
Q6: Christer suggests not to discuss
Q5: Christer suggests to allow in reInvite
- Should be able to do in first offer.
- Disagrees with Justin
- Q5 and Q6 are confusing on the slide - ignore
- If you know it is equal to the reInvite, i.e you
know somehow out-of-band the receiver’s capabilities to support Bundle,
then it shouldn't be prohibited to do that.
- Agree with Justin. Should absolutely be allowed
- If your initial offer uses different port
numbers, then there has to be a second offer with same port numbers
- If you are in a session and doing a reInvite and
you know Bundle is supported, then there is no need to do the separate
- For existing m-lines,
doing a reINVITE when you know Bundle is supported, you do not need to
use separate port numbers (single O/A exchange is OK).
Eric Rescorla then asking about new m-lines.
- For new m-lines in reINVITE where you know other
end supports bundle. Can use the same port number on the new m-line.
- Not forbidding to send m-line with different
ports (i.e. could do either).
- If the answerer wanted to accept, he can reject
and then reInvite back unbundled.
Conclusion: Can include
same ports; different ports allowed but with consequences as
pointed out in the discussion.
- When not using SDP can do whatever want, but
when using SDP then need to know what is wanted. The first offer in SDP
offer/answer needs to have unique ports.
The above was seen by some as re-opening a
previously agreed upon decision in Bundle. Several people were lined up
to comment further however the chairs needed to move along the meeting
to ensure sufficient time for the Unified Plan discussion.
There was a request for a quick hum on Cullen’s
last statement above which was then done by the chairs; the hum was
Conclusion: Need to
get closure on port number uniqueness requirement for very first offer
(initial Offer) when using SDP Offer/Answer in a session.
The chairs first summarized the background for
this work, noting that:
- The RTCWeb WG has asked MMUSIC for a solution to
better handle large numbers of media flows in SDP
- Requirements are outlined in the
- RTCWeb urgently needs progress from MMUSIC,
but problem/solution space applies beyond RTCWeb
- We have explored a number of different and
competing proposals since 2011
- We now have a combined and unified proposal
from the two previously competing proposal camps at this point
The chairs then asked people to focus on the
following for the presentation:
- Any technical objections to the overall proposal
- It is understood, that further work is
needed (open issues in the current document)
- Any use cases that are not supported ?
- Anything people cannot live with in the proposal
Following that, the different topics
covered by the plan were presented by Adam Roach. Adam indicated that
the intent is not to publish this as a standalone document. It points
to work done in other documents, in other Working groups, and possibly
even other SDOs.
During the presentation, the following points were
Requirements and Solution Outline
- Roni Even: Need to support more than
point-to-point; multipoint must be supported as well.
- Adam: Intend to support offer/answer. Do support
star topologies as well (via multiple point-to-point)
- Bernard Adoba: There is a context problem here.
May have different opinions of document depending on whether this is:
- Profile for RTCWeb
- Overarching architecture for MMUSIC
- Guiding future work.
- Unified plan is a response to the RTCWeb request
and should be read in the context of that
- Do we use this for other things as well or not ?
- Ted: Suggest we go through the rest of the
SDP: Semantics and Existing Use -
- Need something that says: I think of this in
philosophy A and therefore would like to do it the following way;
another one may follow philosophy B and therefore would like to do it a
different way. Both will need to be able to fall back to something.
- Requesting we allow presentation to conclude
first, and then get into discussion.
Flemming (as chair):
- Clarifying questions OK during presentation;
full-fledged discussion should wait till end.
Glare Reduction (slide 14)
- Not sure if SDP is describing send or receive
capabilities the way it's described.
- Adam: Not changing existing SDP.
- Roni was referring to a different slide.
- Adam asking Roni to point to places in the draft
where he says potential issues; were not intending to make any changes
to existing definitions at least.
- Is there any suggestion around use of "sendonly"
and "recvonly" to further reduce the change of glare.
- Adam: can look further into that; please propose
on the list.
- How does it work if only one side supports
partial O/A ?
- Adam: Would have to be supported by both and
- What do you mean by "remove"; Lennox pointed out
the same issue (should be set port to zero instead).
- Adam will fix.
Simulcast Example (slide 17)
[Note: slide shows simulcast done with a single m=
- Draft from Magnus previously shows how you can
do simulcast with separate m-lines; haven't done in a single m-line
previously (didn't really work).
Bernard and Justin would like to discuss further.
Adam asked to revisit discussion if time.
- Some of the older FEC specs do somewhat weird
things with the signalling; should take a closer look at those.
- Cullen Jennings: Believe Suhas' draft marks
those as "don't use with bundle".
Matching RTP Streams to m-lines (slide
Adam: This was written before the app-id draft [and
vice versa] (Roni Even/Jonathan Lennox draft).
Colin Perkins: RTP header extension; can use RTCP
SDES as a fallback.
- One race it doesn't solve is sending multiple
SSRCs per m-line.
- Don't want this mechanism to be separate from
the app-id solution.
- Need a=ssrc so can set up RTX, etc.
Plan Discusion and
Decision on Path Forward
The chairs asked for comments on the unified-plan
proposal with intent to use it as the baseline for large number of
media flows in SDP going forward.
- Do we always mandate some mechanism to map SSRC
to m-line ?
- Plea from RTCWeb chairs is to treat this as
identifying stuff that is broken. This is not a last call for the
- Are there dependencies between bundle and
unified-plan so we can't discuss one without agreeing on the other ?
- Adam: More work needed, but one RTP stream per
m-line use grandfathers a lot of the others.
- Clarifying question on simulcast. A mechanism
was defined (a=simulcast group). Didn't define an equivalent construct
for layered coding.
- Cullen: Intention was to use layered codecs as
the current RFCs do them. Believe the existing ones can be used.
- Bernard: Not convinced.
- Adam: Trying not to change existing mechanisms.
Simulcast is more greenfield, so saw a need to define something.
- Proposal makes sense for what RTCWeb is trying
- Bundle mechanism is more general than WebRTC,
and would encourage that it continues to be that way.
- Bundle should be generic in scope.
- OK with one RTP stream per m-line.
- Have the same concern as Colin. Basically talks
about a WebRTC environment; MSID for example is a WebRTC thing.
- Should have a document that is generic (not
RTCWeb specific). Maybe split the document in two: 1) general MMUSIC
draft; 2) specific "profiles".
- One of the customers for Bundle was CLUE. CLUE
usage is to be able to use existing SIP based deployments. In that
context, this does not apply.
- Hadriel asking if there is an update to
Adam does not believe it would be an update to Offer/Answer. Partial
offer/answer is not an update to RFC 3264. Would need an extension of
course (but not an update to RFC 3264).
- Hadriel: Is this for WebRTC, or is the goal
beyond WebRTC ?
- On using multiple offer/answers to get X videos
instead of 1; Once you have chosen to use a line bidirectionally, it's
hard to make it unidirectional.
- Glare: Have mechanisms for dealing with that in
- Need to consider implications of trickle ICE and
- Adam: Partial offers in webrtc: application
needs to explicitly request a partial offer.
- Share concern about partial offers
- Asking for clarification on use of port zero; do
we still intend to signal port=0 to indicate bundle only m= lines ?
- Adam: In initial offer, port=0 has a special
- Bi-directionality: Do we expect the default mode
to be send/receive and what is the control surface ?
- Adam asking for clarification on but believes
this is more of a W3C question.
- Believes the unified-plan proposal is
technically sound and we should proceed with it.
- Question on scope. Is the unified plan proposal
only for bundle media or also for SDP in general ? Mo supports the
- How do we deal with general versus RTCWeb
- Adam suggests splitting across multiple groups.
- Suhas agreed.
There were more people wanting to comment and ask
questions, however as the meeting was nearing the end, the chairs had
to end further discussion. Based on the comments received so far, the
chairs asked the WG for a hum on the following:
Adopt the unified-plan proposal as the
baseline approach for large number of media flows in SDP:
- The scope is currently limited to
- Still need to resolve open issues
identified and further refine overall solution.
There was strong WG consensus in favor of the above
and hence the unified-plan proposal will form the baseline for large
number of media flows in SDP. The scope is currently limited to RTCWeb.
Expansion of the scope beyond RTCWeb is not precluded but will require
The chairs will discuss further with the Area
Directors and other relevant WG chairs (RTCWeb, AVTEXT and possibly
others) to identify the list of topics and documents that need to be
developed in accordance with the unified-plan proposal.