Re: [MMUSIC] Bundle offer with different ports - where to expect media?

[Christer Holmberg <[e-mail]>]

Hi,

>Lots of discussion here; is this an accurate summary of the discussed behavior?
>
>1) BUNDLE offerers must be able to receive on any port (until they get a BUNDLE-compatible answer)
>2) Once the answer is received, bundling is activated, and BUNDLEs use the port of the first non-rejected m= line in the offer
>2a) at this point, the other ports can be discarded

Well, if there is an intermediary, I would say that BUNDLE offerers must be able to receive on any port until they have sent an offer (and received an associated answer) with identical BUNDLE ports.

>3) All m= lines offered in a BUNDLE must be present in the answer, unless they are rejected

All m= lines must of course be present in the answer even if they are rejected :)

But, the question has been whether rejected m= lines shall be within the BUNDLE group. There has been suggestions that they should (which means we would have to update the grouping framework, which currently forbids it).

>3a) no selective unbundling/BUNDLE splitting is permitted

So, if I understand you correctly, when an offer with bundled m= lines is sent, in the answer:

1) ALL m= lines bundled in the offer must also be bundled in the answer (the port may be set to zero for rejected ones); OR

2) NO m= line bundled in the offer is bundled in the answer - the case when the answerer doesn't support bundle to begin with.

Then, if the answerer wants to remove m= lines from a bundle, and/or add m= lines to a bundle, it must do so using a new offer.

Regards,

Christer



On Tue, May 21, 2013 at 10:57 AM, Paul Kyzivat <[e-mail]> wrote:
On 5/21/13 4:45 AM, Emil Ivov wrote:
Hey Paul,

On 20.05.13, 18:09, Paul Kyzivat wrote:
On 5/20/13 10:51 AM, Emil Ivov wrote:
Hey Christer,

On 20.05.13, 17:16, Christer Holmberg wrote:
Hi,
What happens when the offerer knows the answerer has bundle
support, sends all m-lines with the same port, then the
answerer splits the first line away from the bundle? Would the
answerer still send everything to the same port?

We discussed this week,
Yes, sorry, I didn't follow this closely.
and the outcome (at least my read of it :) was that the answerer
is not allowed to split any m- lines away from the bundle in this
case. Instead the answerer will have to send a new offer for the
split, allowing new ports to be negotiated at both ends.

OK, so shouldn't the same thing happen in the case with different
ports?

I suggested that it should never be allowed to split an m- line from
a bundle group in an answer, but others had other opinions.

I don't see how we could allow it in one case and disallow it in the
other. The only difference between the two cases is how informed the
offerer is about the answerers bundle support capabilities and I don't
really understand why this would influence the decision to allow
splitting bundles one way or the other.

It is a different case because the same port *can't* both be used as the
bundle port and a port for an unbundled m-line.

Why not? Obviously the offerer was prepared to demultiplex traffic
there. Why wouldn't it be able to continue doing so even if the answerer
would prefer to receive it separately?

The point of wanting the one line unbundled is so that it can be *received* on a different address/port. Perhaps there is a separate device or process that will be supporting that one, that must be reached at its own addr/port.

Unless you expect that this would have a common addr/port on the offering side and different addr/ports on the answering side. But we investigated that approach early in the bundle discussions, and gave it up.

Note that I am not defending such an approach. I'd much prefer that
splitting is only allowed when re-offering.
HOWEVER, it would still not help in the case where the 1st m- line is
rejected.

Well, how about looking at it this way: the offerer specifies a bundle
port in the first m=line. This also happens to be the port for the first
media line but the two are different things and just happen to have the
same value for reasons related to syntax and convenience.

A bundle supporting answerer should understand this. After receiving the
offer that answerer has learned the bundle port number. Rejecting the
first m=line in the answer does not change this.

There are many reasons that an answerer may reject an m-line.
It is *possible* that it is rejecting it because it has a problem with
the address (c=) for the m-line in the offer. If so, then if you insist
on using it as the bundle address, even if the m-line is refused, then
there is no way for the answerer to refuse it.

(*Why* it would have a problem is an open question. Maybe its IPv6 and
the answerer can't use it, or maybe its an FQDN and it can't be
resolved. I realize this is unlikely. But making the assumption that the
address must be acceptable to the answerer is IMO not a good idea.)

Aha! That's a good point.

Still, the thing that I don't quite understand is: if the answerer has a
problem with the c= line, how could that problem only apply to the first
m= line and not to the entire bundle?

Presumably this would only happen if the c= for were not all the same in the offer. Certainly that is possible. When allocating "ports" for each m-line one might also end up with different addresses.

Of course the answer would come with the first m=line having a 0 port
but the offerer would then just learn the bundle port number at the
first m=line with a non-zero port.

I presume you must have a motivation for wanting to go this way.
Are you thinking this will simplify the implementation?

No. The implementation is going to be slightly more complicated indeed
because instead of having one bundle demuxing socket and two regular
ones (well ... if rtcp demuxing counts as regular) you would have three
of them. I don't think this would be particularly horrifying in terms of
complexity though.

Still, I think being consistent about the ports where one could get
multiplexed data is a good thing, and it could help (humans) when
analysing traffic and debugging network issues.

Consistency is good. But isn't it just as consistent to say that the first *accepted* m-line defines the bundle addr/port as it is to say that the first offered m-line?

        Thanks,
        Paul


_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic