MMUSIC WG virtual interim meeting May 23rd, 2013
WebEx Recording at:
https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=68477572&rKey=0db0b50b02f4f1b6
Note taker: Ted Hardie
Meeting started at 7:06 A.M. PDT
Chairs showed Note Well
The agenda focused on Open Bundle Issues outside of A/B
Open Bundle issues
- Where to expect media
- Bundle SDP answer restrictions
- How to (de)multiplex RTP media
AOB
Christer Holmberg presented “Where to
Expect Media”:
http://www.ietf.org/proceedings/interim/2013/05/23/mmusic/slides/slides-interim-2013-mmusic-2-0.pdf
He started by re-iterating that these issues should be independent of Plan A vs. Plan B.
Jonathan Lennox noted that there might be requirements coming from Plan A vs. Plan B to Bundle; Christer agreed, but he believes that the issues under discussion today do not touch on those issues. The result is that not all of Bundle is under discussion.
Paul Kyzivat asked a clarification about “on which port” to confirm that we mean “address, port” pair. Jonathan said that he believed that it is actually “set of ICE candidates”; Paul responded that ICE candidates are salient, but that for this purpose, we really do mean the m=line context. For that context, you can have the same port on different m- lines, but associated with different candidate addresses.
On the topic “How do Indicate bundle port?”
(when different port values in offer)
Discussing whether to use offer or answer port as the bundle port, Jonathan raised a concern for the condition in which the offer m-line was rejected. Paul and Justin agreed with this concern. Cullen noted that he felt the use of a=bundle-port SDP attribute was just too much added complexity. Jonathan noted that he felt that semantics based on order seems fragile to him; the horse might be out of the barn. Justin agreed and said he preferred an explicit control surface instead of an implicit. Randall said that he also preferred that, as it was easier to get right. Discussion of whether all groups were composed of a group of mids, and the response was that this was specified in RFC 5888. Emil felt that there was value in letting the answerer to specify what port s/he wanted to receive media; Christer felt that there might be a case in which you could only do Bundle on a specific port and would not bundle otherwise.
Dale Worley would not like the text to say that we do it differently in the case in which the ports don’t match. That increases the logic needed, and he would prefer to avoid that. He then discussed the alternatives and he felt that both bundle-port SDP attribute and a=group mechanism are complex.
Christer stepped back and said that we should first agree whether it was the offerer or the answerer that decides where to receive the media (which port(s) to use). Jonathan agreed that this was a valuable property, but since m-lines contain multiple pieces of information, you might reject without wanting to reject the port for bundle. Cullen asked if this was a new requirement or a hypothetical? Jonathan said that he simply wanted it clarified. Roni Even then said he had the same confusion. But the question is if the m-line is rejected, why would you be changing it? The answer appears to be that middle boxes might reject it, and this also might end up changing other aspects of the port semantics.
Paul asked if we can call the question to see if the group could get consensus on using the “First” mid in the bundle group (in the answer) that identifies a non-zero port that has not been rejected. Jonathan said that he has something that he believes is semantically equivalent (The answerer picks one of the m-lines with this property), but rather than having it implicit in the order, but having an explicit marker. Cullen asks what happens if that line is removed but the bundle group isn’t? That sort of thing happens in SBCs whenever we have correlation across pieces--syntactic sugar tends to cause pain and suffering?
Andy asked if we still agree that middle boxes that pass bundle on without understanding are broken? General agreement that the result was yes, but still safer to avoid the cross-correlation problem.
Flemming asked that we put up a slide with the current text. The resulting text was:
The transport tuple in the “First” mid in the bundle SDP group attribute, in the answer, that identifies an m-line, in the answer, that has a non-zero port (that has not been rejected.)
Andy asked what that meant for ICE processing? The connectivity checks would be focused only on that port. Jonathan said he thinks when we say “port” we really mean transport information in general. Justin Uberti agreed.
Justin asked for clarification that the ordering was significant . Mo said that the bundle answerer should honor that. Harald noted that you had to handle both cases, since the answerer *could* change the order.
Conclusion
Next issue: Bundle SDP Answer Restrictions.
In an SDP answer, what are the rules?
-A bundle group must not be created, unless it was included in the associated offer,
-An m-line must not be added to a bundle group, unless it was included in a bundle group in the associated offer
-an m-line must not be added to another bundle group that the group in which it was included.
Are those agreed? (basically, yes)
Mo Zonatay said that the semantics in RFC 5888 seem to work here -- the only thing permitted is removing an m-line from a grouping; no other actions are permitted. Christer said that these are a re-statement of RFC 5888, and he feels that it is useful to restate them (but will add a pointer stating the relationship).
An m-line must not be removed from a bundle group, if it was included in a bundle group in the associated offer.
Always?
Only when identical m- line port values were used in the associated offer
Mo noted that there are two things -- removing something from the bundle and rejecting the media; for the latter, you do this by setting the port to zero. Christer asks: in the case where the answerer wants to use media but remove it from the bundle, is he allowed to do that in an answer, or must he send a new offer? The issue doesn’t arise in a first offer, because multiple ports are available for disambiguation; it could occur in a second offer. Clarification from Cullen: so the media was accepted in a bundle in an initial offer, but you want to unbundle it in the second offer? Yes. Then the question then arises of whether we want the same thing in the first offer?
Cullen raised the two-bridge scenario (one video and one audio) and believes this will be a common use case. That means pushing this to require a new offer, rather than manipulating it in the answer, would add too much latency. Paul and Martin noted that since you could reject the bundle entirely (and thus taking all m-lines from the bundle), that taking one single m-line from the bundle should be possible.
The group discussed how to wordsmith this. “port” here is a shorthand for “transport attributes” -- an implementer can assume that if there is a different address/port pair that the rest of the transport attributes are also unique.
Martin suggested "an offerer that uses a unique address/port pair for an m-line in BUNDLE group MUST also ensure that all other transport parameters are unique for that m-line." There may be an exception that if there is a privacy marker (in the Trickle-ICE sense), it is always must be unique.
Result of discussion: you are allowed to remove an m-line from a bundle; if you reject an m-line using port 0, you must also remove it from the bundle group, pending an update to RFC 5888.
Ports in Bundle Answer
The group moved on to discussing issues related to the ports in a Bundle answer. Christer notes that if the answerer wants to use a single port, an identical port value must be used for each m- line within the Bundle group.
What if the answerer does not want to use a single port, but wants to allow the offerer to use a single port? (This is a half-Bundle proposal) Discussion of whether this is sensible. Martin felt it was non-sensical. Justin doesn’t see any benefit to this and notes that it adds a lot of ICE-related issues. Mo asks what the benefit would be to the multiplexing side of this half-Bundle? Flemming asked for the use case for this. Christer is thinking about the browser to legacy gateway case. But the use case benefit for browser doesn’t seem to be high enough to put this much complexity. Randell agreed with Justin that this does not seem to be an important case to optimize for. Harald: As a browser person “Just say no”; as a standards guy “if we ever allow it, we can never un-allow, where we can always allow it later”. “Just say no”. Cullen +1’ed that sentiment.
Conclusion: There was broad agreement that half-bundle (where one side is bundling and the other is not) should not be supported at this time.
Paul Kyzivat believes that we need to say somewhere that if you’re going to add something to a common bundle, you have to add them to the common port. If you are going to change anything related to the ports, you need to send a new offer, almost like a new invite (that is return to the initial offer state). Taken from the webex chat:
“if you have A and B bundled, and you want to add C to that bundle, C must use the existing bundled port, meaning that the answerer can't unbundle C. Right?
from Martin Thomson to Everyone:
Say we have a session with a bundle of A, B and C. Round 1 offer has different ports, round 2 (the fixup) puts them on the same port. If you wanted to add D, then you can probably assume that the other side is OK with bundling. The problem is that adding D with the same port assumes that the other side wants to bundle it. That's where I think this breaks down.
from suhas to Everyone:
If Answer wants to Unbundle it should reject C and send another Offer … ?
from Martin Thomson to Everyone:
Yeah, I don't like that as much Suhas. You need some sort of information on whether bundling always is acceptable.
from Cullen Jennings to Everyone:
Martin, I get your comment on lexical
from Cullen Jennings to Everyone:
+1 martin"
Mo and Martin discussed whether or not there was a need for an attribute saying “I’m willing to bundle anything, don’t bother sending me new transport parameters”. Jonathan asked whether plan a and plan b had different characteristics; it seemed to him that it was less of a problem to spin up new transport parameters in plan b than plan a. There was some discussion of this point. Martin asked if there was a way to have a capability that included: “always bundle, never bundle, you choose, limit the bundle to N”. Group said that creating a grammar for this not a problem, but questionable benefit for very general grammar. Jonathan said that the more choices you give implementers, the more interop failures you will get.
Jonathan suggested that we go with “always” -- new m-lines in a bundle group inherit its characteristics. Martin suggested that we allow people to choose. He believes the semantics would be the same initial offer/answer in that case. Mo notes that this is not really a static capability or preference, that it could be a dynamic situation where you need to split a bundle for whatever reason (sending new media type to a new mixer).
Cullen suggested a rule: we suggest that in the case you have ICE/DTLS negotiated on a particular transport block, continue to use that. Jonathan: is this must or should? Cullen: for the code you need to write, it makes no difference. But effectively, you’re going to have a worse product if you don’t do this.
Martin proposes “When adding a new m-line to a BUNDLE group in an offer, an offerer can choose to provide new transport parameters or to reuse the transport parameters that were previously negotiated for the BUNDLE group”
Justin notes that he’d be happy to cut down the scope, so that we could be done? Is anyone sad if we say only re-use the transport parameters? Martin said: I think we just said we’d be sad, that’s why we’re having the discussion. Copies from the chat:
from Martin Thomson to Everyone:
If new transport parameters are provided, then the answerer MAY reject the bundling and use the m-line unbundled. If the bundling is accepted, then a second offer/answer exchange is used to fix up the middleboxes. The answerer MUST NOT select the newly added transport parameters for the BUNDLE group.
from Martin Thomson to Everyone:
If existing transport parameters are used for the new m-line, then the line cannot be unbundled by the answerer. It can only be rejected or accepted.
Paul believed that Martin is right, and that we can come up with a way to make the rules the same for initial and subsequent.
Result: Wordsmithing on the list, but the basic agreement is around this text:
If new transport parameters are provided, then the answerer MAY reject the bundling and use the m-line unbundled. If the bundling is accepted, then a second offer/answer exchange is used to fix up the middleboxes. The answerer MUST NOT select the newly added transport parameters for the BUNDLE group, unless all m- lines using the old transport parameters are rejected.
from Martin Thomson to Everyone:
extra text: if all existing m-lines are rejected, the new m-lines form a new BUNDLE.
How to demux RTP Media
The group then looked at Christer’s slides on demuxing RTP media. Methods available for demux: payload type, SSRC, RTP header extension, and some combinations of those above.
Dale noted that you could also use an extension to RTCP to indicate SSRC: this gives something like the RTP header extension, but with a higher correlation cost. Jonathan asked when you need to know this--the RTCP might arrive later than needed. Dale said you could theoretically emit the RTCP first, but the two flow types are independently subject to packet loss.
Colin asked if we could talk about what the different purposes of demux are. Paul says that at the RTP level, the SSRC is enough because it gives you the decoder to send it to, but it is fundamentally about the SDP, not the RTP alone, because you want to associate it to the SDP m-line and to pass it up to an application correctly. So “decoder” but this is a “an instance of a decoder bound to an input and output” where the input and output are application-determined.
Jonathan notes that this has implications -- the RTCP demux, for example, won’t work well, because the binding needs to occur before RTCP demux information is available. Colin notes that you could make this more rapid by combining RTCP and Header extensions. Jonathan agreed.
Cullen said that where this boils down to, you look at some whack of bits and use them to determine which processing pipeline this gets fed into. Colin says that this is still a multi-layered demuxing (multiple RTP sessions vs. one RTP session), so it makes it difference. Cullen agreed, but says that it really boils down to: you demux on what you know. A particular use case (e.g. RTCWEB) may always use one thing, SSRC for example, but that MMUSIC should allow you to demux on whatever you know. What if it is ambiguous? You can’t do anything until it becomes unambiguous. Colin: we can design this to avoid the ambiguity from the start.
Cullen: that restarts the shim discussion, and we went there in the past and rejected. It doesn’t make a difference whether we do them before or after the headers, it boils down to adding bits, like shim.
Colin: No it doesn’t mean it is the same; shim would change the basic packet format for all time, where this header extension is adding to a subset as needed.
Colin argues for an approach where the SSRC is definitive, but the RTP header extension is added as needed.
After further discussion, Cullen presented a set of
slides:
http://www.ietf.org/proceedings/interim/2013/05/23/mmusic/slides/slides-interim-2013-mmusic-2-2.pdf
It’s a cocktail approach: if the PT is unique, use it. If the applications knows the SSRC, use it. If future defines new thing (e.g. header extension), applications can use them too. Dale asks if this is a prioritized list? Cullen agrees that there needs to be an order, but doesn’t care what it is. Jonathan says that it might be more concrete to talk about this in terms of requirements on the senders. Martin has a slightly different spin: every single stream has an SSRC, so you can use that as a demux point; you can use the PT if unique if you don’t know the SSRC. Paul: knowing the SSRC doesn’t tell you the mapping to the m-line.
Harald: We’re trying the associate metadata with a RTP flow, the use of PT does that
Cullen says that it is not true that the SSRCs are unique and don’t change.
Harald: didn’t argue that, there’s always a mapping.
(Got too involved in discussion, here’s some related stuff from the chat):
From Justin Uberti to Everyone:
You can know whether there will be an audio or video session before the call is finally answered, just like DTLS or ICE info.
from Alan Turing to Everyone:
ISTM this whole thing has gotten out of hand - BUNDLE was *just* an optimization to avoid multiple transport streams due to ICE, so why do we care about one particular app needing more than 127 PT numbers?? Make that app use two transport 5-tuples (ie not bundle more than 127 PTs
From Randell Jesup to Everyone:
How many PT's do we have given RTP/RTCP muxing?
from Martin Thomson to Everyone:
96
from Alan Turing to Everyone:
Right, so if you need more than 96, use two transport 5-tuples, or more. Your app can't bundle more than 96 in one transport. Boohoo.
from Justin Uberti to Everyone:
Some of us find Boohoo unacceptable.
from Randell Jesup to Everyone:
that assumes re-using the "static" ones, I assume
from Jonathan Lennox to Everyone:
Depends whether you're Plan A or Plan B.
from Roni to Everyone:
Not really since static till 34 are assigned and may confuse some implemetation
from Ted to Everyone:
Who is speaking as Alan Turing, for the notes?
from Jonathan Lennox to Everyone:
With Plan B making each m-line distinguishable by payload type is fine. With Plan A it's problematic.
from Martin Thomson to Everyone:
I'm going to guess that it's Adam
[In private chat, Hadriel Kaplan noted he was using “Alan Turing” as his handle for this]
Cullen ended up with text like this:
1 If future RFCs define new things (like RTP header extension) application uses them.
2) If application knows the SSRC and has not already demuxed, use those
3) If the payload type is unique, and has not already demuxed, use that.
Martin and Emil discussed a corner case on 100+ streams where you want to render them before getting SSRCs.
The group had a general discussion of the SSRC approach; Paul made a suggestion, summarized here by Martin:
I like Paul's suggestion: offer + answer MUST include information sufficient to associate SSRCs with meta-information (m-line or otherwise). The answer MAY include sufficient information, or negotiation for the provision thereof (whether that be unique PT, an RTP header extension, or RTCP SDES extension).
CNAME is not sufficient, nor is it immune to loss.
What are the next steps: get the header extension draft through (thought there was strong support for not mandating completion of this for getting Bundle out). Cullen was opposed to requiring RTP header extensions for bundle use. Martin noted that we cannot mandate it for use anyway, because RTP header extensions and RTCP SDES extensions can be lost anyway..
Action item to get Cullen’s text into Bundle proposed. Martin preferred a stand-alone draft. We’ll start with an email to the list, and then decide.
On the RTP header extension draft, the chairs will discuss with AVTEXT about the right place to do that work, if we want to.
Attendees showing on Webex: Flemming Andreasen, Christer Holmberg, Alan Johnston, Andy Hutton, Ari Keränen, Bert Greevenbosch, Colin Perkins, Cullen Jennings, Dale Worley, Dan Romascanu, Emil Ivov, Ernst Horvath, Giri Mandyam, Gonzalo Camarillo, Jonathan Lennox, Justin Uberti, Keith Drage, Magnus Westerlund, Maire Reavy, Mallinath, Mark Duckworth, Mary Barnes, Mo Zanaty, Paul Kyzivat, Randell Jesup, Roni Evans, Suhas, Thomas Stach, Uwe Rauschenbach, Ted Hardie, Harald Alvestrand, Martin Thomson, Shida Schubert, Hadriel Kaplan