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

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 May 2013 19:45:35 +0000

Hi,

After couple of initial questions, related to the bundle-only attribute:

Q1: You are adding m- lines with a zero port value into a BUNDLE group. RFC 5888  (SDP grouping framework) currently explicitly forbids that, we have discussed it on the MMUSIC list, and the outcome (eventhough there weren't too many expressing their opinion) was that we were not going to allow zero port m- lines in BUNDLE groups.

Of course, we can always change that decision, but that would mean modifying RFC 5888.

Q2: It is indicated that devices that do not support BUNDLE will reject the bundle-only m- lines, by setting the port value to zero in the SDP Answer. That is probably true. But, what if the device DOES support BUNDLE as such, but does NOT want to use the same port number? I think that e.g. a gateway could act that way.

In my opinion, as BUNDLE now uses 2 offer/answer transactions, the device could be allowed to return different port values. Then the offerer, when sending the second offer, can decide whether it wants to keep them.

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Adam Roach
Lähetetty: 7. toukokuuta 2013 21:31
Vastaanottaja: [email-masked]
Aihe: [rtcweb] Plan A, respun

In order to facilitate discussion between the two SDP format alternatives we're considering, I've put together a document that more clearly spells out the Plan A approach as we originally envisioned it. 
Note that this is a slightly different approach than Cullen outlined in Orlando. I fear the Orlando approach may have suffered from its attempts to incorporate some elements of Plan B in an attempt to appease proponents of that approach; and, in doing so, lost some of its clean architecture.

The cleaned up, new-and-improved description of the Plan A approach is available here:

http://www.ietf.org/id/draft-roach-rtcweb-plan-a-00.txt

Note that we've omitted discussion of glare reduction from that document, as I believe that mid-session glare can be completely avoided by applications implementing a set of non-normative behaviors. These behaviors are described in the a separate companion document:

http://www.ietf.org/id/draft-roach-rtcweb-glareless-add-00.txt

Thanks.

/a
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 May 2013 20:39:20 +0000

Hi,

One more question, regarding the bundle-only attribute:

Q3: Assume the answerer supports BUNDLE, and return an SDP answer with identical port numbers, as shown in section 7.1. I guess the second offer will then replace the zero port lines with the actual port value that the offerer uses for the multiplexing?

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Christer Holmberg
Lähetetty: 7. toukokuuta 2013 22:46
Vastaanottaja: Adam Roach; [email-masked]
Aihe: Re: [rtcweb] Plan A, respun - bundle-only attribute

Hi,

Regards,

Christer

-----Alkuperäinen viesti-----
Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Adam Roach
Lähetetty: 7. toukokuuta 2013 21:31
Vastaanottaja: [email-masked]
Aihe: [rtcweb] Plan A, respun

Thanks.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 07 May 2013 15:46:28 -0500

> Q3: Assume the answerer supports BUNDLE, and return an SDP answer with identical port numbers, as shown in section 7.1. I guess the second offer will then replace the zero port lines with the actua…

I don't think it really matters, since the port number in these 
subsequent offers don't convey any additional information, but I'm 
perfectly happy with the behavior you describe. I'm also happy keeping 
them set to zero, or specifying that they should be floor(pi * 10000) or 
any other arbitrary value.

Yeah, I'm pretty sure it doesn't actually matter.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 May 2013 21:00:43 +0000

Hi,

>> Q3: Assume the answerer supports BUNDLE, and return an SDP answer with identical port numbers, as shown in section 7.1. I guess the second offer will 
>> then replace the zero port lines with the actual port value that the offerer uses for the multiplexing?
>
> I don't think it really matters, since the port number in these subsequent offers don't convey any additional information, but I'm perfectly happy with 
> the behavior you describe. I'm also happy keeping them set to zero, or specifying that they should be floor(pi * 10000) or any other arbitrary value.

Good - I just wanted to make sure that we stick to the agreed way forward on BUNDLE, which is based on sending a second offer with the actual port value.

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 8 May 2013 15:37:26 -0400 (EDT)

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.

Erratum:  You state "you can always have more than one bundle", but
the example in section 6 does not contain an "a=group" attribute.

It seems that an offered bundle consists of:

- one or more m= lines offering non-zero ports

- zero or more m= lines offering zero ports but with "a=bundle-only"

Question:  Is it true that there must be at least one m= line with a
non-zero port, or can *all* the m= lines be bundle-only (if the UA is
willing to have none of the media streams if the other UA doesn't
support bundling)?  If all may have zero ports, what port is to be
used for transport?

Question:  If there is more than one m= line offering non-zero ports,
are identical port numbers required/permitted/forbidden?  It would
appear from backward-compatibility considerations that the answer is
"forbidden", but that is not stated.

An answered bundle consists of:

- zero or more m= lines that are rejected by containing a zero port

- one or more m= lines that are accepted by containing a non-zero port

Question:  If there is more than one m= line offering non-zero ports,
are identical port numbers required/permitted/forbidden?  You state
that the answer is "permitted", but that seems problematic:

Question:  It is clear what the intended transport association is if
both the offer and answer contain only one non-zero port number.  What
is the intended transport association(s) in other cases?

Question:  It is possible that the only accepted m= lines in the
bundle are ones that were offered with zero ports and
"a=bundle-only".  This results in an intended packet flow that does
not correspond to the offered/answered port for any single one of the
m= lines.  This may cause problems with intermediate devices.

Question:  If several m= lines are offered with different ports and
they are accepted (with the same port), what is the intended transport
association?  It seems that in any case, there will be an m= line with
an offered/answered port pair that will not receive any traffic, which
may cause problems with intermediate devices.

Question:  There can be an m= line offered with a zero port that is
answered with a non-zero port.  This contravenes the legacy
offern/answer rules and may cause problems with intermediate devices.

As an additional matter, there is this statement:

   An old endpoint simply rejects the bundle-only m-lines by responding
   with a 0 port.  (This isn't a normative statement, just a description
   of the way the older endpoints are expected to act.)

Why is this characterized as "isn't a normative statement"?  By legacy
offer/answer rules, the endpoint is *required* to respond to an
offered zero port with a zero port.

Dale

---

From: Martin Thomson <[email-masked]>
Date: Wed, 8 May 2013 14:56:10 -0700

> 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.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 8 May 2013 19:08:49 -0700

> Q3: Assume the answerer supports BUNDLE, and return an SDP answer with identical port numbers, as shown in section 7.1. I guess the second offer will then replace the zero port lines with the actua…

Yes, I think that would be the best thing to do. It would be consisted with our direction on allowing things looking at the SDP to get the correct port

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 8 May 2013 19:16:08 -0700

Hmm - most of this seems to just be the same as bundle. At least that was how I read the draft. 

On May 8, 2013, at 12:37 PM, Dale R. Worley <[email-masked]> wrote:

> non-zero port,

There must be at least one is how I read the draft when coupled with current bundle draft 

> or can *all* the m= lines be bundle-only (if the UA is

Uh, I read this as it is the bundle draft 

> is the intended transport association(s) in other cases?

whatever bundle says

> m= lines.  This may cause problems with intermediate devices.

Seems like the clean up O/A in bundle would clean this up - so same as bundle 

> may cause problems with intermediate devices.

This is the same as bundle

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 9 May 2013 11:12:26 -0400 (EDT)

> From: Martin Thomson <[email-masked]>
> 

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.

Dale

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 May 2013 08:58:39 -0700

> problems that result if draft-roach-rtcweb-plan-a is added to it.

Right.  I didn't intend to trivialize this, but I'd prefer to try to
keep the issues as separate as possible.  That probably means that we
solve bundle first.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 9 May 2013 22:01:20 -0400 (EDT)

Dale

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 10 May 2013 10:48:21 -0600

> 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?