Re: [rtcweb] Plan A, respun - bundle-only attribute

[Cullen Jennings <[e-mail]>]

On May 9, 2013, at 9:12 AM, Dale R. Worley <[e-mail]> wrote:

>> From: Martin Thomson <[e-mail]>
>> 
>> On 8 May 2013 12:37, Dale R. Worley <[e-mail]> wrote:
>>> This is a promising proposal, but I think a lot more care needs to be
>>> taken in defining how port numbers are to be used in this technique.
>>> I can't tell what particular uses of port numbers are allowed and what
>>> ones are not allowed.  And it seems that the intended patterns could
>>> result in problematic behaviors from intermediate devices.
>> 
>> Thankfully, that's a problem that bundle is going to solve, not this
>> document.  The only statements that this draft needs to make is with
>> respect to zero vs. non-zero port numbers, and only in the context of
>> a=bundle-only.
> 
> OK, I hadn't grasped the degree to which draft-roach-rtcweb-plan-a is
> intended to be just an amendment to
> draft-ietf-mmusic-sdp-bundle-negotiation.  But it still does introduce
> new patterns of use of port numbers in m= lines (e.g., an answer can
> have a non-zero port number for an m= line which had a zero port
> number in the offer), so we can't just wave our hands and say
> "draft-bundle-negotiation will solve that" -- it's a substantial
> change to what bundle-negotiation is proposing and solving the
> problems that are apparent in bundle-negotiation won't solve all the
> problems that result if draft-roach-rtcweb-plan-a is added to it.

I agree - good point to think about. I think a key part of this is that this only happens in the case of "new" endpoints that explicitly signal support for the new RFC that bundle would turn into. Do you think it would be better if all the text about 0 ports in an offer, and how in the bundle case they can change in the answer should be put in the bundle draft?