Re: [MMUSIC] 10 BUNDLE questions

On Apr 19, 2013, at 3:05 PM, Martin Thomson <martin.thomson@gmail.com> wrote:

> This clarifies things for me.  I hope that these are captured effectively.
> 
> On 19 April 2013 09:19, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>> On Mar 15, 2013, at 2:51 PM, Justin Uberti <juberti@google.com> wrote:
>>>      • From 6.1, list 1 - are conditions 2, 5, 7 really necessary? (MUST use same c=, add rtcp-mux, same a=fingerprint)
>> 
>> on fingerprint, I don't think this impacts the bundle but it seems like it make simplify the code that matches the fingerprint to the DTLS connection. Be interested in hearing EKR's thoughts.
> 
> I'm not EKR, but I don't see any way that having multiple sets of
> credentials would be useful.  That implies multiple handshakes.

well, this would only be for the initial offer and if bundle is not selected, there will be multiple handshakes. I can't think of a reason that the multiple handshakes can't have the same certificate so I think I agree with you

> 
> a=fingerprint pertains to the transport and as such needs to be the same.
> 
> You *could* add fingerprints from different lines as alternative valid
> (in the same way that two a=fingerprint can be added to a single
> line).  Since this is more likely to be mistake than something
> intentional, better to require that every block in a bundle have the
> same a=fingerprint.
> 
>>>      • From 6.1, list 2 - is condition 6 right? Why would we use different SDES keys for a single RTP session?
>> 
>> This is confusing in what you do in first is this, but once you know what you are doing, you put what you are using which will result in same not different keys. This needs series review from crypto experts.
> 
> In theory you can use multiple keys.  And it doesn't have any real
> consequences.  That's not necessarily a useful property though.

I just want to make sure there is not chance for a two time pad problem but I assume that will not be a problem and we can use the same sdes key when bundle does not get negotiated 

> 
>>>      • If you start with a m= line with one SDES config (e.g. 32-bit MAC), and then BUNDLE with another SDES line with a different (non overlapping) SDES config (e.g. 80-bit MAC), what happens? (assume fail)
>> 
>> Lets say can not do that and if you do it, it is a fail.
> 
> See above - it's *possible* to have this particular example work.  But
> not useful and therefore inadvisable.
> 
> I think that a good requirement is that new m= lines are entered into
> a bundle when they are added to the session and that bundle can't
> change.  That means you can't move m= lines in and out of bundles.
> That also keeps the rules with respect to properties constant for any
> given m= line.
> 
> Sure, you could make a complicated system where this was possible, but
> it probably wouldn't interoperate.

+1

> 
> 
>>>      • If you add a m= line to an existing BUNDLE, can the recipient reject that BUNDLEing (assume no)
>> 
>> agree it should be no
> 
> On first impressions, I was inclined to agree that it makes no sense
> to allow for unbundling on new m= lines, but this is exactly the same
> sort of scenario that an initial offer has to deal with.  Offer the
> addition of a stream in a bundle, but allow for the fact that peer
> might not support bundling.  So, I'm actually inclined to disagree
> here.
> 
> That said, without a use case, such a capability complicates things.
> I'll get to the use case below.
> 
>> Also imagine case where
>> 
>> Alice offers A, B, and C and offers to bundle them all
>> 
>> Bob wants to accept A and B in a bundle and C separate
>> 
>> When I talked to Justin this, I was convinced we don't want to bother to support this as it complicated gathering ports for future offers. So what it comes down to the device receive the offer can either accept the bundle or not. (and separate accept or reject each m line in the bundle but can't refactor the bundling).
> 
> This is actually the same sort of problem as the above.  The question
> is whether the bundle is negotiated as a whole, or whether answers can
> differentiate on per-line basis.  I can appreciate the desire to
> simplify, but you have to examine use cases.
> 
> Example: Alice offers A and B bundled, Bob accepts the bundling.
> Later, Alice adds C to the bundle.  How can Bob get that m= line
> routed over a different path?  Do we require that Bob reject the line
> and offer the same line, potentially inverted, without bundling in a
> subsequent offer?
> 
> I'm thinking here about a case where a session escalates from audio to
> audio+video and there might be a middlebox involved.  I guess in that
> case the middlebox needs to drive the addition.
> 
> I can probably live with the simplification, but this needs to be
> crystal clear.  A more complete discussion of the implications of this
> particular choice would be really helpful.

+1 on we need to be crystal clear. 

I think I am leaning towards once a bundle is set up, a new update to it can offer things in the bundle or not it the bundle. And if offered in the bundle, the answer can choose to put it in the bundle or not. But I want to avoid all things like the answer can move a m-line from one one bundle to another bundle or something like that. It's too complicated and I don't see the need for it. 

> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic