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

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 May 2013 11:43:30 +0000

Hi,

Currently BUNDLE defines that the first offer is sent with separate port numbers (later, if the answerer has indicated support of BUNDLE, the offerer will send a second offer, with identical port numbers).

Some people have indicated that the offerer shall be able to receive data already when the first offer has been sent. The question is on which port(s) it needs to be able to receive media.

-          Some have suggested the port of the first non-zero m- line within the offered bundle group.

-          Some have suggested ANY port

The issue with assuming the first non-zero m- line is that the answerer in the answer may reject it (put the port to zero), or remove it from the bundle group (which people seem to want to allow). In both cases it would be strange to assume the first m- line.

Now, in case e.g. ICE is used, the offerer will be able to send the second offer before any media is received to begin with. But, the offerer could still receive STUN connectivity checks on any of the ports, until the second offer has been sent.

We need text in BUNDLE about this, so comments/inputs are welcome :)

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Mon, 20 May 2013 15:12:38 +0300

Hey Christer,

On 20.05.13, 14:43, Christer Holmberg wrote:
> Hi, 
> 
> Currently BUNDLE defines that the first offer is sent with separate port
> numbers (later, if the answerer has indicated support of BUNDLE, the
> offerer will send a second offer, with identical port numbers).
> 
> Some people have indicated that the offerer shall be able to receive
> data already when the first offer has been sent. The question is on
> which port(s) it needs to be able to receive media.

Do we really have a choice here? We send the offer with different port
numbers so that it would work with endpoints that have no knowledge of
bundle. Such endpoints can start streaming media to any port. Bundled
devices can, on the other hand, start streaming media on the bundle port.

So in other words, the offerer need to expect media arriving on any port
just as it needs to expect any stream arriving on the bundle port.

This would be consistent with what we do for rtcp-mux.

Emil

> The issue with assuming the first non-zero m- line is that the answerer
> in the answer may reject it (put the port to zero), or remove it from
> the bundle group (which people seem to want to allow). In both cases it
> would be strange to assume the first m- line.
> 
>  
> 
> Now, in case e.g. ICE is used, the offerer will be able to send the
> second offer before any media is received to begin with. But, the
> offerer could still receive STUN connectivity checks on any of the
> ports, until the second offer has been sent.
> 
>  
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
https://jitsi.org

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 20 May 2013 13:14:45 +0000

Agree with Emil but think maybe the question was meant to be on which port(s) it needs to be able to receive bundled media.

This is covered by the last para in section 6.3 which states that the answerer MUST use the port and everything else relating to the 1st m= line. So far I thought this to be reasonable and even if the 1st m= line is rejected this can still be the bundle port.

We could say that any port in the bundle could be used but I don't see this gains us anything.

Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Emil Ivov
> Sent: 20 May 2013 13:13
> To: Christer Holmberg
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Bundle offer with different ports - where to
> expect media?
> 
> Hey Christer,
>

---

From: Emil Ivov <[email-masked]>
Date: Mon, 20 May 2013 16:18:21 +0300

On 20.05.13, 16:14, Hutton, Andrew wrote:
> Agree with Emil but think maybe the question was meant to be on which
> port(s) it needs to be able to receive bundled media.
> 
> This is covered by the last para in section 6.3 which states that the
> answerer MUST use the port and everything else relating to the 1st m=
> line. So far I thought this to be reasonable and even if the 1st m=
> line is rejected this can still be the bundle port.

+1

> see this gains us anything.

Agreed.

Emil
> 
> Andy
> 
> 
> 
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Emil Ivov Sent: 20
>> May 2013 13:13 To: Christer Holmberg Cc: [email-masked] Subject:
>> Re: [MMUSIC] Bundle offer with different ports - where to expect
>> media?
>> 
>> Hey Christer,
>> 
>>> Currently BUNDLE defines that the first offer is sent with
>>> separate
>> port
>>> numbers (later, if the answerer has indicated support of BUNDLE,
>>> the offerer will send a second offer, with identical port
>>> numbers).
>>> 
>>> Some people have indicated that the offerer shall be able to
>>> receive data already when the first offer has been sent. The
>>> question is on which port(s) it needs to be able to receive
>>> media.
>> 
>> Do we really have a choice here? We send the offer with different
>> port numbers so that it would work with endpoints that have no
>> knowledge of bundle. Such endpoints can start streaming media to
>> any port. Bundled devices can, on the other hand, start streaming
>> media on the bundle port.
>> 
>> So in other words, the offerer need to expect media arriving on
>> any port just as it needs to expect any stream arriving on the
>> bundle port.
>> 
>>> in the answer may reject it (put the port to zero), or remove it
>>> from the bundle group (which people seem to want to allow). In
>>> both cases
>> it
>>> Now, in case e.g. ICE is used, the offerer will be able to send
>>> the second offer before any media is received to begin with. But,
>>> the offerer could still receive STUN connectivity checks on any
>>> of the ports, until the second offer has been sent.
>>> 
>>> 
>>> 
>>> _______________________________________________ mmusic mailing
>>> list [email-masked] 
>> -- https://jitsi.org 
>> _______________________________________________ mmusic mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 May 2013 13:27:35 +0000

Hi,

>> line is rejected this can still be the bundle port.

I agree that is what the spec currently says. 

But, again, the following can happen:

1) The answerer rejects the 1st m- line; or

2) The answerer accepts the 1st m- line, but removes it from the bundle group. Yes, in this case the answerer WILL send media on that port, but ONLY media associated with that m- line (as it is no long part of the bundle group). The media associated with the remaining m- lines in the bundle group has to be sent somewhere else.

Again, once the second offer has been sent, the "bundle port" is explicitly signaled (as each m- line in the bundle group uses the same port number).

Regards,

Christer

>> [mailto:[email-masked]] On Behalf Of Emil Ivov Sent: 20 May 
>> 2013 13:13 To: Christer Holmberg Cc: [email-masked] Subject:
>> knowledge of bundle. Such endpoints can start streaming media to any 
>> port. Bundled devices can, on the other hand, start streaming media 
>> on the bundle port.
>> 
>> So in other words, the offerer need to expect media arriving on any 
>> port just as it needs to expect any stream arriving on the bundle 
>> port.
>> 
>>> from the bundle group (which people seem to want to allow). In both 
>>> cases
>> it
>>> _______________________________________________ mmusic mailing list 
>>> [email-masked] https://www.ietf.org/mailman/listinfo/mmusic
>>> 
>> 
>> -- https://jitsi.org 

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 May 2013 09:38:48 -0400

I agree with Christer's analysis here. The bundle port must be one 
associated with an m-line that is accepted, and included in the bundle, 
in the answer. That means the bundle port may not be the one from the 
first bundled m-line in the offer.

A corollary of that is that the offerer needs to be prepared to receive 
bundled media on any of the ports listed in the offer.

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Mon, 20 May 2013 16:46:37 +0300

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?

If so, I don't see why it should be different in the case where the offerer
could not make the assumption about the bundle support.

--sent from my mobile
On May 20, 2013 4:39 PM, "Paul Kyzivat" <[email-masked]> wrote:

> associated with an m-line that is accepted, and included in the bundle, in
> the answer. That means the bundle port may not be the one from the first
> bundled m-line in the offer.
>
>> 2) The answerer accepts the 1st m- line, but removes it from the bundle
>> group. Yes, in this case the answerer WILL send media on that port, but
>> ONLY media associated with that m- line (as it is no long part of the
>> bundle group). The media associated with the remaining m- lines in the
>> bundle group has to be sent somewhere else.
>>
>> Again, once the second offer has been sent, the "bundle port" is
>> explicitly signaled (as each m- line in the bundle group uses the same port
>> number).
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>>>> [mailto:mmusic-bounces@ietf.**org <[email-masked]>] On Behalf
>>>> Of Emil Ivov Sent: 20 May
>>>>> Currently BUNDLE defines that the first offer is sent with separate
>>>>>
>>>> port
>>>>
>>>>> The issue with assuming the first non-zero m- line is that the
>>>>>
>>>> answerer
>>>>
>>>>> ______________________________**_________________ mmusic mailing list
>>>>> [email-masked] https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>>>>>
>>>>>
>>>> -- https://jitsi.org
>>>> ______________________________**_________________ mmusic mailing
>>>> list [email-masked] https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>>>>
>>>
>>>
>>
> ______________________________**_________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 May 2013 13:50:23 +0000

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

Regards,

Christer

If so, I don't see why it should be different in the case where the offerer could not make the assumption about the bundle support.
--sent from my mobile
On May 20, 2013 4:39 PM, "Paul Kyzivat" <[email-masked]> wrote:
I agree with Christer's analysis here. The bundle port must be one associated with an m-line that is accepted, and included in the bundle, in the answer. That means the bundle port may not be the one from the first bundled m-line in the offer.

A corollary of that is that the offerer needs to be prepared to receive bundled media on any of the ports listed in the offer.

        Thanks,
        Paul

+1

Regards,

Christer

Hey Christer,

Emil

-          Some have suggested the port of the first non-zero m-
line within the offered bundle group.

We need text in BUNDLE about this, so comments/inputs are welcome
:)

Regards,

Christer

-- https://jitsi.org

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 20 May 2013 14:00:23 +0000

> bundled media on any of the ports listed in the offer.

Also the offerer therefore needs to be prepared to send the bundled media from this port or immediately initiate a new offer indicating a different port for the bundle.

Andy

---

From: Emil Ivov <[email-masked]>
Date: Mon, 20 May 2013 17:12:35 +0300

On May 20, 2013 4:50 PM, "Christer Holmberg" <[email-masked]>
wrote:
>
> Hi,
>
> > What happens when the offerer knows the answerer has bundle support,
sends all m-lines with the same port, then the answerer
> 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?

Emil

--sent from my mobile

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 20 May 2013 14:16:59 +0000

Hi,

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

HOWEVER, it would still not help in the case where the 1st m- line is rejected.

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Mon, 20 May 2013 17:51:47 +0300

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

> HOWEVER, it would still not help in the case where the 1st m- line is

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.

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.

Subsequent offers and answers would all use that same m=line for the
bundle port.

Does this make sense?

Emil

-- 
https://jitsi.org

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 May 2013 11:09:03 -0400

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

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

> 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? What do you 
think you can avoid doing my making this assumption?

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Tue, 21 May 2013 11:45:46 +0300

Hey Paul,

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

Note that I am not defending such an approach. I'd much prefer that
splitting is only allowed when re-offering.

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

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

Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 21 May 2013 11:53:09 +0000

Hi,

>>>>>>> support, sends all m-lines with the same port, then the answerer 
>>> 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?
>
> Note that I am not defending such an approach. I'd much prefer that splitting is only allowed when re-offering.

Well, it could maybe work - but that means that the endpoint using the same port would have to include the m- line in the bundle group in subsequent offers/answers - otherwise you break the rule of not being allowed to use the same port number in an m- line :)

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

It could. The reason we're talking about the first m= line is because it has been suggested that should represent the "bundle port".

Regards,

Christer

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

Emil

--
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Tue, 21 May 2013 15:15:23 +0300

Hey Christer,

> Well, it could maybe work - but that means that the endpoint using the same port would have to include the m- line in the bundle group in subsequent offers/answers - otherwise you break the rule of…

Right. Or now that it at that point it could choose a different port
(but again I am not defending this approach).

> It could. The reason we're talking about the first m= line is because it has been suggested that should represent the "bundle port".

What I meant was the following:

Paul expressed a concern that if we were to insist on using the first
port from the rejected m= line, this could cause problems in cases where
that line was rejected exactly because of that port (or the entire c=
address for that line) did not please the answerer.

I suppose this was an argument for using the remaining topmost
address/port as a bundle address (rather than the one that was rejected).

I guess what I don't understand is: what would be the case where an
offerer created an offer such that the address in the topmost m=line was
problematic for the answerer but the one in the second m= line was
different enough so that it wouldn't be and so that it could
successfully become the new bundle address.

How likely would such a case be?

Emil

-- 
https://jitsi.org

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 21 May 2013 14:38:20 +0000

Let say Alice make an initial offer with there M lines with port 1 for video 1 and port 2 for video 2, and port 3 for video 3 and they are all in bundle. 

The semantics of O/A are that you must be prepared to receive anything you offered as soon as you offer it.  So for this to work, Alice has to be receiving on any combination of ports that would be valid in any possible answer. ( I think everyone else on this thread came to same conclusion so just agreeing and summarizing) 

So the interesting cases is an if the answer rejected the video 1 and accepted the video 2 and 3 with theses two bundled. I think that results in saying that you have to be able to receive on any port. 

This has impact for when the PT overlap and you don't know the SSRC yet. For that case, given Alice is the one that created the PT used for each m-line, I think that is just OK. That goes to the demux conversation. 

I don't know what people mean by splitting a bundle but I think one should be able to reject m lines inside a bundle, including the first m line, but I don't think there is a need to take offer lines 1,2,3, 4,5,6 in a bundle and have the answer put 1,2,3, in one bundle and 4,5,6 in a second bundle. So if that is what we mean by splitting bundle, I don't think we need it. But we do need to be able to reject m lines inside a bundle.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 May 2013 13:26:16 -0400

> I don't know what people mean by splitting a bundle but I think one should be able to reject m lines inside a bundle, including the first m line, but I don't think there is a need to take offer lin…

I agree that it is unrealistic to expect that we can get to separate 
bundles via just the answer to the offer.

But there is a need for a way to get to that condition *somehow*.

What I proposed was that the first answer could accept 1,2,3 in a bundle 
and reject (port zero) 4,5,6. Then in a subsequent offer, set a nonzero 
port in 4,5,6 and put them in a new bundle.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 May 2013 13:57:44 -0400

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

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

> 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

---

From: Emil Ivov <[email-masked]>
Date: Wed, 22 May 2013 01:34:30 +0300

Hey Paul,

> device or process that will be supporting that one, that must be reached 

Yes, sure. My point was that the party that unbundled the one m= line
can receive it separately. The party that sent the offer can keep
getting it on the same port.

> investigated that approach early in the bundle discussions, and gave it up.

No I don't and I suspect you misunderstood me.

Also in all my comments I kept noting that we shouldn't be allowing the
answer to unbundle a single m= line. In your response to Cullen you
seemed to agree with this so I guess we are in agreement.

> m-line one might also end up with different addresses.

This makes me wonder: should we even allow for different c= addresses
within a bundle? The reason to use different ports was a compromise, not
a choice based on the necessity to give that option to applications.
While falling back to different port numbers is defendable, I don't see
how we would justify the possibility to fallback to different c= lines.

> that the first offered m-line?

The bundle suggestion started out by saying that all ports would be the
same. We then moved to a version where we would use different ports, in
order to prevent some non-bundle endpoints from fainting at the sight of
port reuse. We still agreed that the first one is the bundle port and
the others are there just for fall back. So far so good.

Now we are discussing the possibility of saying: your bundle port will
be the first one you offer, unless the answerer rejects that m= line, in
which case it could be the port of the second m= line, or the third one ...

I agree it wouldn't be the end of the world, but to me this doesn't
sound particularly consistent.

Emil

-- 
https://jitsi.org

---

From: Justin Uberti <[email-masked]>
Date: Tue, 21 May 2013 15:37:58 -0700

On Tue, May 21, 2013 at 3:34 PM, Emil Ivov <[email-masked]> wrote:

> the
> the
> the

Perhaps not the most elegant thing in the world, but it doesn't seem
inconsistent to me. I think this is the most practical choice.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 21 May 2013 15:38:50 -0700

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
3) All m= lines offered in a BUNDLE must be present in the answer, unless
they are rejected
3a) no selective unbundling/BUNDLE splitting is permitted

On Tue, May 21, 2013 at 10:57 AM, Paul Kyzivat <[email-masked]>wrote:

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 21 May 2013 15:46:03 -0700

That sounds good to me.

On Tue, May 21, 2013 at 3:38 PM, Justin Uberti <[email-masked]> wrote:

>  2) Once the answer is received, bundling is activated, and BUNDLEs use
> the port of the first non-rejected m= line in the offer
>> first *accepted* m-line defines the bundle addr/port as it is to say that
>> the first offered m-line?
>>
>>         Thanks,
>>         Paul
>>
>>

---

From: Emil Ivov <[email-masked]>
Date: Wed, 22 May 2013 01:53:50 +0300

> BUNDLE-compatible answer)

Apparently we are going for: BUNDLE offerers must be able to receive
*bundled* data on any port except for that on the last m= line. They
must also be prepared to received unbundled data on any port.

> 2) Once the answer is received, bundling is activated,

I suppose bundling should be active before the answer is received and it
can be deactivated when that happens.

Emil

> and BUNDLEs use
> 3) All m= lines offered in a BUNDLE must be present in the answer,
> unless they are rejected
> On Tue, May 21, 2013 at 10:57 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>                         OK, so shouldn't the same thing happen in the
>                         case with different
>                         ports?
> 
> 
>     device or process that will be supporting that one, that must be
>     reached at its own addr/port.
> 
>                     HOWEVER, it would still not help in the case where
>                     the 1st m- line is
>                     rejected.
> 
> 
>     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.
> 
> 
>     _________________________________________________
>     mmusic mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>
> 
> 

-- 
https://jitsi.org

---

From: Martin Thomson <[email-masked]>
Date: Tue, 21 May 2013 16:29:26 -0700

> Lots of discussion here; is this an accurate summary of the discussed

Yeah, this discussion was too much for me to track properly.

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

Only one qualm with that last item.  Agree with the splitting, but I
believe that the restriction on unbundling only applies if you create
an offer that assumes bundle support (i.e., same transport parameters
on every m-line).  This is the optimized option that I expect we'll
need a constraint for in WebRTC.  In that case, you don't have a port
to use for the unbundled m-line.

It should be possible to have a new m-line negotiated out of a bundle
(but not into another bundle).  It's just a refinement of the
answerer-does-not-support-BUNDLE case.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 21 May 2013 22:00:56 -0700

> answerer-does-not-support-BUNDLE case.

I agree. This carries over into subsequent offers - if you add a m= line
that assumes BUNDLEing (i.e. uses the same transport parameters as an
existing m= line), the recipient cannot choose to unBUNDLE it.

Taking into account Emil's suggestion as well, this leads to this
restatement of the rules:

1.1) An offerer must be prepared to receive unbundled traffic on the
offered ports, as if talking to a legacy endpoint.
1.2) An offerer must be prepared to receive bundled traffic on any port,
except the port associated with the last m= line.
2) Once the answer is received, the decision on bundled/unbundled and which
ports to use is finalized.
2.1) BUNDLEd m= lines use the port of the m= line that appears first in the
bundle.
2.2) Unused ports can be discarded at this point.
3.1) m= lines offered with distinct ports may be omitted from the bundle
answer, in line with RFC 5888.
3.2) m= lines offered with the same port may not be omitted from the bundle
answer, since there is no unbundled port from them to fall back to.
3.3) m= lines that are rejected are omitted from the bundle answer, per RFC
5888.

Quick check on 2.1: are we using the m= line that appears first in the SDP,
or the m= line that appears first in the a=group:BUNDLE?

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 May 2013 10:35:20 +0000

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

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 <[email-masked]> wrote:
On 5/21/13 4:45 AM, Emil Ivov wrote:
Hey Paul,

We discussed this week,

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

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.

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.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 May 2013 09:55:36 -0400

On 5/22/13 1:00 AM, Justin Uberti wrote:

> 2) Once the answer is received, the decision on bundled/unbundled and
> which ports to use is finalized.
> 2.1) BUNDLEd m= lines use the port of the m= line that appears first in
> the bundle.
> 3.2) m= lines offered with the same port may not be omitted from the
> bundle answer, since there is no unbundled port from them to fall back to.
> 3.3) m= lines that are rejected are omitted from the bundle answer, per
> RFC 5888.
>
> Quick check on 2.1: are we using the m= line that appears first in the
> SDP, or the m= line that appears first in the a=group:BUNDLE?

IMO it would be best to use the lexically first m-line that has a 
non-zero port and that appears in the bundle group of the answer.

Alternately, it *could* be the m-line with non-zero port that appears 
first in the bundle group of the answer. But if so, the exception in 1.2 
would also need to be correspondingly adjusted.

AFAICT the only reason to mention that exception in 1.2 is that might 
provide an opportunity for optimization, by setting up the port with 
simpler code that doesn't support bundling. I don't see a requirement in 
5888 that the bundle group in the answer be ordered the same way as in 
the offer. So the one m-line guaranteed not to receive bundled traffic 
would then not be predictable at the time of the offer, so could not be 
exploited. This problem doesn't exist if the lexical ordering of m-lines 
is used.

	Thanks,
	Paul

---

From: Kevin Dempsey <[email-masked]>
Date: Wed, 22 May 2013 15:11:12 +0100

Would it make it simpler if the offer included an attribute in bundled m=
lines that said where to send the media if bundle is supported by the
answerer; and for the answer to include an attribute that said where it was
going to send the media (ie. to the bundled destination or the unbundled
destination)

On 22 May 2013 14:55, Paul Kyzivat <[email-masked]> wrote:

> IMO it would be best to use the lexically first m-line that has a non-zero
> port and that appears in the bundle group of the answer.
>
> 5888 that the bundle group in the answer be ordered the same way as in the
> offer. So the one m-line guaranteed not to receive bundled traffic would
> then not be predictable at the time of the offer, so could not be
> exploited. This problem doesn't exist if the lexical ordering of m-lines is
> used.
>
>         Thanks,
>         Paul
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 May 2013 10:15:52 -0400

On 5/21/13 6:34 PM, Emil Ivov wrote:

>> offering side and different addr/ports on the answering side.

Your statement above seems to be exactly what my following statement says.

>> But we

I must be misunderstanding you. Your "no I don't" comment seems to be in 
direct conflict with what you said above.

But maybe we don't need to keep discussing this. It seems the discussion 
has moved beyond it.

> seemed to agree with this so I guess we are in agreement.

Its getting hard to sort out what these statements mean out of context. 
So I don't know.

> how we would justify the possibility to fallback to different c= lines.

When faced with a choice of leaving something general or narrowing it, I 
opt for leaving it general unless there is some compelling reason to do 
otherwise.

IMO in the entire discussion, when we talk about "different ports" that 
is really shorthand for "different address/port pairs". (And this 
includes cases where the addresses are different and the ports are the 
same.)

If the offerer needs a bunch of address/port pairs to assign to the 
different m-lines of the bundle, it will presumably allocate them out of 
some pool available to it. That pool may include multiple addresses as 
well as ports. Restricting to a set that all share the same address may 
cause it difficulty. An example of where this might occur is if it is 
using STUN/TURN to get the address/ports.

> sound particularly consistent.

I agree it is a complication. If the alternative is saying that the 
answer can't unbundle or reject the first m-line, or that if it 
unbundles it then it will be bundled on one end and unbundled on the 
other end, then that is also a complication. So its a value judgment 
which complication is most acceptable.

	Thanks,
	Paul

---

From: Justin Uberti <[email-masked]>
Date: Wed, 22 May 2013 15:53:19 -0700

> exploited. This problem doesn't exist if the lexical ordering of m-lines is

To me, this seems like an optimization that only adds complexity. I don't
think there's likely to be a significant savings by setting up 1 out of N
ports differently.

The one advantage of using the a=group:BUNDLE ordering is that it makes it
explicit where the answerer is planning to send the media, which might be
useful at some point. So I would prefer to use that ordering, and NOT
include rejected m= lines in the answer a=group attribute.

---

From: Justin Uberti <[email-masked]>
Date: Wed, 22 May 2013 15:55:34 -0700

I think we could do this using the existing syntax, e.g.

an offer of a=group:BUNDLE A B C would indicate that the offerer would
prefer A, B, and C to be muxed onto A, and
an answer of a=group:BUNDLE C A would indicate that the answerer is going
to mux C and A onto C, and send B unbundled.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 May 2013 19:22:49 -0400

On 5/22/13 6:55 PM, Justin Uberti wrote:
> an answer of a=group:BUNDLE C A would indicate that the answerer is
> going to mux C and A onto C, and send B unbundled.

That would work. I don't have an objection to it.
But I'm also ok with choosing based on static ordering of m-lines.

Whether to allow m-lines with zero ports in the bundle is a separate 
question. This approach could still work with that, as long as the zero 
ones aren't listed first, or the rules are adjusted to use the first in 
the answer bundle that is non-zero.

IIRC the desire to allow zero port m-lines in a bundle was so that an 
offer could indicate what it wants to bundle even though it doesn't want 
to assign ports yet. If that is still of interest then we shouldn't take 
it away.

	Thanks,
	Paul

>
> On Wed, May 22, 2013 at 7:11 AM, Kevin Dempsey <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Would it make it simpler if the offer included an attribute in
>     bundled m= lines that said where to send the media if bundle is
>     supported by the answerer; and for the answer to include an
>     attribute that said where it was going to send the media (ie. to the
>     bundled destination or the unbundled destination)
>
>
>     On 22 May 2013 14:55, Paul Kyzivat <[email-masked]
>         IMO it would be best to use the lexically first m-line that has
>         a non-zero port and that appears in the bundle group of the answer.
>
>         Alternately, it *could* be the m-line with non-zero port that
>         appears first in the bundle group of the answer. But if so, the
>         exception in 1.2 would also need to be correspondingly adjusted.
>
>         AFAICT the only reason to mention that exception in 1.2 is that
>         might provide an opportunity for optimization, by setting up the
>         port with simpler code that doesn't support bundling. I don't
>         see a requirement in 5888 that the bundle group in the answer be
>         ordered the same way as in the offer. So the one m-line
>         guaranteed not to receive bundled traffic would then not be
>         predictable at the time of the offer, so could not be exploited.
>         This problem doesn't exist if the lexical ordering of m-lines is
>         used.
>
>                  Thanks,
>                  Paul
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 22 May 2013 22:02:06 -0400 (EDT)

> From: Emil Ivov <[email-masked]>
> 
> *bundled* data on any port except for that on the last m= line. 

You can also receive bundled data on the last m= line, though it would
be a bundle of one.  (Depending on how we demultiplex, the media
packets for a bundle of one might be different from the media packets
for the one constituent media flow.)

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 May 2013 06:13:59 +0000

Hi,

>> prefer A, B, and C to be muxed onto A, and an answer of a=group:BUNDLE 
>> C A would indicate that the answerer is going to mux C and A onto C, 
>> and send B unbundled.
>

There are different ways an offerer can tell the remote bundle endpoint on which port it prefers to receive media.

But, again, if there is an intermediary that doesn't understand bundle, it will send according to the ports indicated in the m= lines.

The way we solve that is by sending the second offer, with identical port numbers. So, the sooner we send that second offer, the sooner we get rid of the problem about where to send the media :)

Regards,

Christer

> <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 23 May 2013 01:43:29 -0700

On Wed, May 22, 2013 at 3:55 PM, Justin Uberti <[email-masked]> wrote:

> Agree with this. This also fits with the way to categorization for Attr
Muxing as TRANSPORT.

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 May 2013 10:13:16 +0000

Hi,

>>> an offer of a=group:BUNDLE A B C would indicate that the offerer 
>>> would prefer A, B, and C to be muxed onto A, and an answer of 
>>> a=group:BUNDLE C A would indicate that the answerer is going to mux C 
>>> and A onto C, and send B unbundled.
>>

Actually, correcting myself.

The intermediary will of course forward media only towards the bundle port (however it is indicated), as the answerer is only sending towards that port.

The problem is that the intermediary may trigger error events when it detects media types etc not negotiated for that port. So, for THAT reason the second offer needs to be sent asap :)

Regards,

Christer

---

From: Emil Ivov <[email-masked]>
Date: Thu, 23 May 2013 13:35:36 +0300

Hey all, Paul,

One more thought on the use of the port in the first accepted line
rather than the first offered.

As is often the case, the discussion on the list is delightfully
confusing so apologies if this was already mentioned and I missed it:

> that the first offered m-line?

In case a bundle offer gets forked and various answers accept the bundle
but reject different m= lines, then we could end up with receiving
bundled traffic on any port. In this case consistently using the first
offered port as the one for the bundle would give us use of a single port.

I agree this is not necessarily a big deal but I thought I'd mention it
just the same.

Cheers,
Emil

-- 
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 May 2013 13:15:43 +0000

Hi,

>an offer of a=group:BUNDLE A B C would indicate that the offerer would prefer A, B, and C to be muxed onto A, and 
>an answer of a=group:BUNDLE C A would indicate that the answerer is going to mux C and A onto C, and send B unbundled.

In general, is there are reason why we would want to allow the answerer to use a separate port than the one indicated by the offerer? There may be reasons why the offerer has chosen that specific port.

Also, I think it is semantically wrong to do as you suggest, as you would use the group attribute to indicate a SENDING capability.

Regards,

Christer

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 23 May 2013 13:41:55 +0000

On May 21, 2013, at 11:00 PM, Justin Uberti <[email-masked]> wrote:

> 
> 1.1) An offerer must be prepared to receive unbundled traffic on the offered ports, as if talking to a legacy endpoint.
> 1.2) An offerer must be prepared to receive bundled traffic on any port, except the port associated with the last m= line.

I'm fine with this but would be just as happy without the "except last one"

> 2) Once the answer is received, the decision on bundled/unbundled and which ports to use is finalized.

Yes, as long as we keen final answer. For provisional answer you need to not free the resources. Yes, I expect to get emails from folks telling me that provisioning and final aren't defined but you know what I mean and this is the clearest way to say it for this email. 

> 2.1) BUNDLEd m= lines use the port of the m= line that appears first in the bundle.

Again, we could go this way or the using the group syntax to do 

> 3.1) m= lines offered with distinct ports may be omitted from the bundle answer, in line with RFC 5888.

yes, I would change "bundle answer" to "bundle group in the answer" 
 
> 3.2) m= lines offered with the same port may not be omitted from the bundle answer, since there is no unbundled port from them to fall back to.

uh, no, not on aboard with this part. As we have discussed many times, having multiple m line in the original offer with the same port won't work. I think EKR's proposal of allowing m-lines with 0 port in offer will work well. 

> 3.3) m= lines that are rejected are omitted from the bundle answer, per RFC 5888.
>

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 23 May 2013 13:41:56 +0000

> an answer of a=group:BUNDLE C A would indicate that the answerer is going to mux C and A onto C, and send B unbundled.

I suspect several people are on the fence about using this approach or the first non rejected m-line in the bundle. 

Can anyone think of reasons why to pick one of the other of these two approaches ?

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 May 2013 13:34:04 -0400

On 5/23/13 6:35 AM, Emil Ivov wrote:

> In case a bundle offer gets forked and various answers ...

I trimmed everything else out of Emil's reply, and changed to subject, 
because this is a whole different can of worms!

I think we must acknowledge that this *can* happen, though it is a low 
probability event. It raises all sorts of ugly issues. A few:

* if the bundle is accepted by multiple forks, does this form
   one RTP session or several? If so,

   - if so, then if each fork accepts a different set of m-lines from
     the bundle, how can that work with a single RTP session?

* How does ICE work in this case? (Is that already covered by ICE,
   since it mostly isn't specific to bundle?

* If one fork adds/removes an m-line from the bundle, should that
   be mirrored to the other forks?

* ...

ISTM that the simplest thing we could do about this is put a statement 
in the draft that this draft does not specify behavior in the case of 
forking - that conforming devices are constrained to a single fork, and 
that behavior in forking cases could be a subject of future standardization.

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 23 May 2013 23:47:15 +0530

Paul,

I agree with you that it takes more energy to solve bundle with forking.
Forking is not low probability event as of now in SIP deployments. I wish to
see the forking within the scope of this work.

Thanks
Partha 

> Behalf Of Paul Kyzivat
> Sent: Thursday, May 23, 2013 11:04 PM
> To: Emil Ivov
> Cc: mmusic; Christer Holmberg
> Subject: [MMUSIC] When a bundle offer is forked
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 May 2013 14:44:06 -0400

Partha,

> see the forking within the scope of this work.

If so, can you take a stab at enumerating the issues that can arise, and 
how they should be handled?

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 May 2013 13:55:18 -0700

> Can anyone think of reasons why to pick one of the other of these two approaches ?

I was originally strongly in favor of basing transport parameter
choice solely on the order of m-lines in the SDP document.

However, after our discussion this morning, if we allow a previously
rejected m-line to be revived and added to a BUNDLE group, then the
rule stating that any existing transport is used would take precedence
over this.

But that sucks.  I have a better solution for this case. We should
require that previously negotiated m-lines cannot change their BUNDLE
affiliation.  That would prevent the old m-line from being re-added to
an existing BUNGLE.  A new m-line would be required.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 May 2013 14:09:53 -0700

The more I think about forking, the more I don't want to think about
it any more.

On 23 May 2013 10:34, Paul Kyzivat <[email-masked]> wrote:
>   one RTP session or several?

If the subjective view of the RTP session that the offerer holds is
bound to a 5-tuple (as opposed to just local addressing), then this
forms multiple sessions.

However...

Prior to getting answer(s), the offerer might be unable to tell that
there are multiple RTP sessions, or if it is just media arriving from
multiple source addresses.  This would only be a problem in the
absence of ICE and with multiple m-lines.

>   since it mostly isn't specific to bundle?

I believe that ICE works in this case.  Each RTP session should have a
different set of ufrag/pwd for the peer.

I know that others have talked about the implications for the ICE
state machine for bundle, but that depends on ufrag/pwd.

>   be mirrored to the other forks?

I don't see how that has a significant impact.  Each fork could choose
different bundling configurations.  This is not significantly
different to other forking cases.  The offerer has to be prepared to
demux at the session layer first.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 May 2013 17:39:50 -0400

> an existing BUNGLE.  A new m-line would be required.

I am pretty strongly opposed to restricting how one can recycle m-lines.
IMO this is a pretty basic and fundamental mechanism.

Your concern is only important if you we use the "first m-line in the 
SDP that is non-zero and part of the bundle" rather than "first mid in 
the bundle that identifies a non-zero m-line". I thought we settled that.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 May 2013 17:45:42 -0400

> The more I think about forking, the more I don't want to think about

You and everybody else. :-)

That's why I'm happy to leave it out of scope here unless somebody 
volunteers to do the hard work.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 23 May 2013 18:06:47 -0400 (EDT)

> From: Paul Kyzivat <[email-masked]>
> 

Is this actually complicated?  That is, worse than is already the case
in SIP...

My understanding is that in SIP (and this must be a SIP situation),
each fork proceeds with completely independent state from all other
forks.  The forks happen to share sending/receiving ports, but the
received packets can be demultiplexed to the correct fork based on
their sending addresses.  Of course, there are a range of obnoxious
situations where you receive packets before you receive a SIP response
(SDP answer) that describes them, but that is true in non-bundled SIP
as well.

Dale

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 May 2013 17:14:39 -0700

> IMO this is a pretty basic and fundamental mechanism.

What I'm suggesting would permit recycling(*).  However, if you are
amending a session (as opposed to throwing it out entirely and
starting over), then I would rather that you cannot (I suggest MUST
NOT) change the BUNDLE affiliation of an m-line.  This is - of course
- only possible if you permit rejected m-lines to remain in a group.

This really goes back to the whole BUNDLE negotiation model.  If a
line is tentatively part of a BUNDLE group in the first exchange,
confirmed in the second, do we permit splitting, reassignment, etc...
in subsequent exchanges?

Or, do we permit the movement in and out of BUNGLE groups for any
m-line?  If I want to migrate off one BUNDLE and to another, do I
first reject the line and remove it from the BUNDLE group (exchange 1)
and then re-animate it with a new BUNDLE group (exchange 2)?

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 May 2013 08:24:50 +0000

Hi,

I agree with Dale. Each early dialog is handled separately.

>From a standards perspective, I don't think we need to say much about forking in BUNDLE, other than maybe some general words that it may happen.

Then, whether it becomes tricky to implement, e.g. if one early leg uses BUNDLE and another doesn't, is another issue. But, as SIP has mechanisms to terminate early dialogs you don't like etc, I see this as a pure implementation issue.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: 24. toukokuuta 2013 1:07
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [MMUSIC] When a bundle offer is forked

> probability event. It raises all sorts of ugly issues. A few:

Is this actually complicated?  That is, worse than is already the case in SIP...

My understanding is that in SIP (and this must be a SIP situation), each fork proceeds with completely independent state from all other forks.  The forks happen to share sending/receiving ports, but the received packets can be demultiplexed to the correct fork based on their sending addresses.  Of course, there are a range of obnoxious situations where you receive packets before you receive a SIP response (SDP answer) that describes them, but that is true in non-bundled SIP as well.

Dale

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 26 May 2013 17:30:30 +0530

Dale/Christer,

Forking has to be seen with the RTP role (endpoint, translator, mixer) as
the offer/answer exchange varies drastically for each RTP role. SIP forking
with RTP endpoint issues are explained as part of Sec 3.1 of RFC 3960. One
of the complexity introduced as part of BUNDLE is to have two offer/answer
before consolidating. The offer/answer interaction between SIP forking with
RTP endpoint and BUNDLE has to be mentioned. I'll explain with the SIP
serial forking with RTP endpoint scenario for more clarity

1) INVITE with SDP having BUNDLE offer and different port in each m-line is
send out from UAC
2) 183 with SDP and BUNDLE support is received from UAS1
3) UPDATE with SDP having BUNDLE offer and single port in each m-line is
send towards UAS1 after completing PRACK & 200
4) 183 with SDP and BUNDLE support is received from UAS2

Here at Step 4, it is not possible for UAC to "mute" UAS1 as one another
OFFER is initiated already at Step 3 and BUNDLE forces to "mute" the answer
UAS2. This limitation has to be mentioned as part of BUNDLE. Please let me
know your opinion on this.

Thanks
Partha

> Behalf Of Christer Holmberg
> Sent: Friday, May 24, 2013 1:55 PM
> To: Dale R. Worley; Paul Kyzivat
> Cc: [email-masked]
> From a standards perspective, I don't think we need to say much about
> forking in BUNDLE, other than maybe some general words that it may
> happen.
> 
> Then, whether it becomes tricky to implement, e.g. if one early leg
> uses BUNDLE and another doesn't, is another issue. But, as SIP has
> mechanisms to terminate early dialogs you don't like etc, I see this as
> a pure implementation issue.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> Behalf Of Dale R. Worley

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 May 2013 08:14:00 +0000

Hi,

>Forking has to be seen with the RTP role (endpoint, translator, mixer) as the offer/answer exchange varies drastically for each RTP role. SIP 
>forking with RTP endpoint issues are explained as part of Sec 3.1 of RFC 3960. One of the complexity introduced as part of BUNDLE is to have 
>two offer/answer before consolidating. The offer/answer interaction between SIP forking with RTP endpoint and BUNDLE has to be mentioned. I'll explain with the SIP serial forking with RTP endpoint scenario for more clarity
>
>1) INVITE with SDP having BUNDLE offer and different port in each m-line is send out from UAC
>3) UPDATE with SDP having BUNDLE offer and single port in each m-line is send towards UAS1 after completing PRACK & 200
>Here at Step 4, it is not possible for UAC to "mute" UAS1 as one another OFFER is initiated already at Step 3 and BUNDLE forces to "mute" the answer 
>UAS2. This limitation has to be mentioned as part of BUNDLE. Please let me know your opinion on this.

I don't understand. The UAC can:

1) wait for the UPDATE answer from UAS1, and then send a new "mute" UPDATE; or
2) send a BYE to UAS1, and terminate the whole early dialog.

Also, BUNDLE is not the only SIP/SDP mechanism which uses multiple Offer/Answer transactions.

Regards,

Christer

> mechanisms to terminate early dialogs you don't like etc, I see this 
> as a pure implementation issue.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 May 2013 11:47:54 -0400

On 5/23/13 8:14 PM, Martin Thomson wrote:
> NOT) change the BUNDLE affiliation of an m-line.

I disagree with this.

> This is - of course

Yes, I think we do. IMO the following are some basic principles that 
ought to hold:

1) we can't allow an accepted m-line to be removed from a bundle while 
it shares an address/port with the bundle. We've settled that.

2) it should be possible to remove non-zero-port m-lines from a bundle 
offer, because the recipient needs to put them on separate addresses 
from the bundle.

3) There needs to be a way to handle the case where an answerer can't 
handle all the m-lines in a bundle offer as a single bundle, but could 
handle them as multiple bundles. I've proposed that this could be 
handled by refusing some of the m-lines in the bundle, and also removing 
them from the bundle. Then making a new offer that includes those 
m-lines in a new bundle. Removing the refused m-lines from the bundle 
could be handled at the time of rejection (the answer), or at the time 
of the new offer. I see no particular reason to prefer or legislate one 
way or the other.

4) In (3) I was thinking of a starting point where splitting occurred at 
the time of the initial offer for the bundle. The situation is a little 
different if the goal is to split an operational bundle, where the 
m-lines being split out already share an address/port with the bundle. 
(This is a less compelling case, but there are probably some reasons for 
it.) I see several approaches to this:

4a) new O/A that removes the m-lines from the old bundle and gives them 
unique address/ports. Later, another O/A that puts those m-lines into a 
new bundle.

4b) new O/A that rejects the m-lines and removes them from the old 
bundle. Later, another O/A that puts those m-lines into a new bundle.

4c) new O/A that rejects the m-lines, leaving them in the bundle. Later, 
another O/A that removes the rejected m-lines from the bundle. Later 
yet, another O/A that offers addresses for those m-lines and puts them 
into a new bundle.

4d) consolidate two steps in 4c: new O/A that rejects the m-lines, 
leaving them in the bundle. Later, another O/A that offers addresses for 
those m-lines and puts them into a new bundle.

4e) further consolidation: new O/A that removes previously active 
m-lines that had been previously bundled from their old bundle, gives 
them unique address/port values, and puts them into a new bundle.

There are basic primitives that show up above, that IMO ought to be ok:

A) reject an m-line (port zero) in an answer and remove from bundle.
    (This is basic behavior of 5888. Even if we relax it and allow
   rejected m-lines in groups we should still permit this.)

B) in a subsequent offer, reject (port zero) an m-line that was
    previously active and bundled, and remove it from the bundle.
    (This also seems to be basic behavior from 5888.)

C) in a subsequent offer, reject (port zero) an m-line that was
    previously active and bundled, but leave the m-line in the bundle.
    (Only if 5888 is extended to allow rejected m-lines in bundles.)

D) in a subsequent offer, remove a previously rejected m-line from a
    previously signaled bundle. (Only if 5888 is extended to allow
    rejected m-lines in bundles.)

E) in an answer, remove a zero port m-line in the offered bundle from
    the bundle in the answer.

F) in a subsequent offer, reuse an m-line that was rejected in the prior
    offer or answer, and was previously not in any bundle. Use this
    m-line for any purpose where a totally new m-line may be used.
    (This includes adding to an existing bundle, or proposing a new
    bundle.)

G) in a subsequent offer, reuse an m-line that was rejected in a prior
    offer or answer, and was previously in a bundle, as a new active
    m-line within the bundle. (According to the same rules as for
    adding an entirely new m-line to the bundle.)

H) Any change that can be done with two O/A exchanges using above
    rules, should be able to be done in one O/A exchange if the outcome
    of the first is deterministic. (Some examples:

    B = C+D

    Replace C+G with an offer that replaces a previously active m-line
    within a bundle with a proposal for a new m-line, also in the bundle,
    but otherwise entirely new.

    Replace an active m-line within a bundle with an unbundled m-line
    with a different address/port. (Skipping B.)

If we are going to revise 5888 so that we can keep rejected m-lines in 
bundle groups, then we must clearly define the distinction between a 
rejected m-line that is bundled from one that is not.

IMO the distinction is that an unbundled one has *no* significance other 
than as a placeholder required by the O/A requirement to preserve the 
ordering and numbering of m-lines. Including one in an offer means that 
this m-line is desired if and only if the bundle is accepted in the answer.

In that case, a rejected m-line in the bundle in an answer agrees that. 
Then a cleanup O/A will put the bundle port into that m-line, so that 
rejected m-lines would only be in bundles in a transient way.

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 27 May 2013 21:58:06 +0530

Christer,

My intention of the below mail is to say that the offer/answer interaction
issues created by BUNDLE for forking and it has to be documented. Also, it
is not implementation issue but more of protocol design issue. Please read
inline for more comments.

Thanks
Partha

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Monday, May 27, 2013 1:44 PM
> To: Parthasarathi R; 'Dale R. Worley'; 'Paul Kyzivat'
> Cc: [email-masked]
> Subject: RE: [MMUSIC] When a bundle offer is forked
> 
> Hi,
> 
> >Forking has to be seen with the RTP role (endpoint, translator, mixer)
> as the offer/answer exchange varies drastically for each RTP role. SIP
> >forking with RTP endpoint issues are explained as part of Sec 3.1 of
> RFC 3960. One of the complexity introduced as part of BUNDLE is to have
> >two offer/answer before consolidating. The offer/answer interaction
> between SIP forking with RTP endpoint and BUNDLE has to be mentioned.
> I'll explain with the SIP serial forking with RTP endpoint scenario for
> more clarity
> >
> >3) UPDATE with SDP having BUNDLE offer and single port in each m-line
> is send towards UAS1 after completing PRACK & 200
> >Here at Step 4, it is not possible for UAC to "mute" UAS1 as one
> another OFFER is initiated already at Step 3 and BUNDLE forces to
> "mute" the answer
<Partha> UAC choice is restricted to the above choice because of BUNDLE.
This has to be mentioned in the document </Partha>

> Offer/Answer transactions.
<Partha> I agree with you that multiple offer/answer transaction is not just
by BUNDLE. Please indicate whether any document mention the issues related
forking with  multiple offer/answer. </Partha>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 27 May 2013 17:22:06 +0000

Hi,

>inline for more comments.

Ok.

><Partha> UAC choice is restricted to the above choice because of BUNDLE.

I don't see how the UAC is more restricted than in other cases where it would send an UPDATE to UAS1, and then receive an answer on UAS2.

>> forking with  multiple offer/answer. </Partha>

Not any IETF document that I am aware of.

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 May 2013 09:16:26 -0700

On 27 May 2013 08:47, Paul Kyzivat <[email-masked]> wrote:
> no

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 May 2013 09:34:50 -0700

> On 27 May 2013 08:47, Paul Kyzivat <[email-masked]> wrote:

FWIW, I can live with that.  (Sorry about the earlier empty email.)  I
was simply trying to be aggressively minimalist.

This model requires that each m-line has two independently negotiable
properties:
 - accepted/rejected (signaled using zero port)
 - bundle membership (signaled using a=group)

(and yes, this requires an update to 5888)

Then we need, as you describe, rules for transitioning between states.

Transition between accepted and rejected is always possible in both
offers and answers.

It seems like we are saying that bundle membership can transition in
the following ways:

Any group to no group:
 - In an offer, under all circumstances.
 - In an answer, if the m-line is rejected.
 - In an answer, if unique transport parameters are provided in the offer.

No group to any group:
 - In an offer, under all circumstances.
 - In an answer, never.

Any group to any other group:
 - In an offer, if the m-line was previously rejected.
 - In an answer, if the lines were offered as a bundle and there are
sufficient transport parameters on offer.

Is that the rules you would like to see?  I think that the last option
(splitting) is the only one that I haven't seen anyone else slavering
for.  The model permits it, but I'd rather prohibit features fix it up
later than start with something that ends up too permissive.

For example, it would be possible to split a bundle that had multiple
m-lines and only two sets of transport parameters like the following:

offer:
BUNDLE 1 2 3 4
mid:1  transport A
mid:2  transport A
mid:3  transport A
mid:4  transport B

answer:
BUNDLE 1 2
BUNDLE 4 3

Despite a (possible) preference from the offerer for bundling 1-3
together, 3 has been split off.

I'm sure that we can get the rules right, but I like avoiding these
sorts of little complications.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 May 2013 10:41:54 -0400

Martin,

Agreed.

Agreed.

Agreed.

Agreed.

> sufficient transport parameters on offer.

I don't understand what you mean here.
What are "sufficient transport parameters on offer"?
Do you mean when the addr/port in the offered m-line is unique?

I hadn't considered that case. I'm thinking its a bad idea to allow 
this, because it creates a bundling situation that the offerer hasn't 
consented to and has no way of refusing.

> Is that the rules you would like to see?

Yes, aside from my comment about the last one.
You describe it more clearly than I did.

> I think that the last option

Without the last rule splitting is still possible, but it requires two 
O/A cycles. In the splitting case I have in mind, the initial offer puts 
a bunch of m-lines in one bundle. The answerer is decomposed so that it 
can't handle them all in one bundle. But perhaps it can handle them in 
two bundles. (The 2nd bundle has never been mentioned yet.)

So in its answer it refuses the m-lines that it wants in a separate 
bundle. Then it sends another offer, reviving the previously refused 
m-lines and putting them into a new bundle.

This can be accomplished with the rules you give above, dropping the 
last one. While it would be nice to accomplish this in a single O/A, I 
can see no way to accomplish that while giving both sides an opportunity 
to refuse what it can't do.

	Thanks,
	Paul

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 May 2013 11:35:36 -0700

On 29 May 2013 07:41, Paul Kyzivat <[email-masked]> wrote:
> This can be accomplished with the rules you give above, dropping the last
> one.

Oh good.  I was worried that you might want to split on answer.  The
revised last rule set is: