Subject: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt

From: Ted Hardie <[email-masked]>
Date: Tue, 26 Oct 2021 11:54:41 +0100

This email serves as the start of a working group last call for
draft-uberti-rtcweb-rfc8829bis-01.txt.  Because of the upcoming IETF
meeting, it will be slightly longer than normal, ending on November 16,
2021.

Please send comments to the list.

thanks,

Ted and Sean

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Oct 2021 11:15:00 +0000

Hi,

I already earlier commented that the draft still references RFC 8843, eventhough it should be updated to draft-8843bis.

But, as draft-8843bis is now in the RFC editors queue, I guess that update can be done once the RFC number for 8843bis has been assigned.

Regards,

Christer

From: rtcweb <[email-masked]> On Behalf Of Ted Hardie
Sent: tiistai 26. lokakuuta 2021 13.55
To: RTCWeb IETF <[email-masked]>; Justin Uberti <[email-masked]>; Cullen Jennings <[email-masked]>; Eric Rescorla <[email-masked]>; Sean Turner <[email-masked]>
Subject: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt

This email serves as the start of a working group last call for draft-uberti-rtcweb-rfc8829bis-01.txt.  Because of the upcoming IETF meeting, it will be slightly longer than normal, ending on November 16, 2021.

thanks,

Ted and Sean

---

From: Ted Hardie <[email-masked]>
Date: Tue, 26 Oct 2021 13:39:31 +0100

Thanks, Christer.  I've added an issue to the tracker for this.  When you
get the RFC number, can you please let the author team know, so that they
can update?

thanks,

Ted

On Tue, Oct 26, 2021 at 12:15 PM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> I already earlier commented that the draft still references RFC 8843,
> eventhough it should be updated to draft-8843bis.
>
>
>
> But, as draft-8843bis is now in the RFC editors queue, I guess that update
> can be done once the RFC number for 8843bis has been assigned.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* rtcweb <[email-masked]> *On Behalf Of *Ted Hardie
> *Sent:* tiistai 26. lokakuuta 2021 13.55
> *To:* RTCWeb IETF <[email-masked]>; Justin Uberti <[email-masked]>;
> Cullen Jennings <[email-masked]>; Eric Rescorla <[email-masked]>; Sean
> Turner <[email-masked]>
> *Subject:* [rtcweb] Working Group Last Call for
> draft-uberti-rtcweb-rfc8829bis-01.txt
>
>
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 26 Oct 2021 13:00:57 -0400

Hi Ted,

I have mentioned on git that:
1. The reference to RFC 8843bis is missing

2. The following language is factually incorrect:

This is by design, but could cause issues in the rare case of sending a
subsequent offer as an initial offer to a non-bundle-aware endpoint via
Third Party Call Control (3PCC).

Primarily, this will cause issues if a subsequent offer is used as an
initial even with bundle-aware end points. An offer with no bundle-only
attributes for bundled m= lines might not get processed correctly. Second,
I would not comment on how frequent this call scenario is going to be
unless we have to.

My suggested language was:

This is by design, but could cause issues in case of sending a subsequent
offer as an initial offer due to Third Party Call Control (3PCC). In such
cases, the signaling application is responsible for adding bundle-only
attributes to the offer so that it can be used as an initial offer.

Best Regards,
_____________
Roman Shpount

On Tue, Oct 26, 2021 at 6:55 AM Ted Hardie <[email-masked]> wrote:

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

---

From: Justin Uberti <[email-masked]>
Date: Tue, 26 Oct 2021 10:15:02 -0700

Agree we should add a reference to 8843-bis. I assume we can do that in the
endgame as (I believe) no text in 8829bis needs to change.

Regarding 3PCC:
- bundle clients should be able to accept initial offers without
bundle-only. If not, we should fix that in 8843bis, as this seems like an
unnecessary limitation - current implementations seem to be managing this
OK.
- the stats on BUNDLE show that it has been widely adopted (99.999% usage
when there is more than 1 a/v stream), and these numbers are only
increasing. If "rare" seems overly opinionated, we could use "uncommon"
instead.

Regarding the suggested workaround:
- adding a=bundle-only is insufficient, the application would also need to
insert zero ports for the bundled m= lines. It's also not clear that this
would lead to a good outcome, as the non-bundle endpoint would only be able
to accept the first bundled m= line. So I would suggest that if 3PCC with
non-bundle-aware endpoints is likely, the application should just eat the
a=group attribute for bundle to prevent bundling in the first place.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 26 Oct 2021 18:06:31 -0400

Regarding 3PCC, bundle clients should be able to accept the initial offer
without bundle-only. Unfortunately there is nothing there that prevents
them from moving an m= line out of the bundle unless it is marked with
bundle-only.

I was not thinking about the frequency of use of 3PCC with non-bundle
endpoints (extremely rare) but about the use of 3PCC in general (more
common and hard to identify).

I agree that a=bundle-only is insufficient. We do need to add port zero.
This will ensure that a bundle-aware endpoint will not take the m= line out
of the bundle. If 3PCC with a non-bundle-aware endpoint is likely, the
application should create a new PeerConnection instead with an appropriate
bundle policy.
_____________
Roman Shpount

On Tue, Oct 26, 2021 at 1:15 PM Justin Uberti <[email-masked]> wrote:

> Agree we should add a reference to 8843-bis. I assume we can do that in
> the endgame as (I believe) no text in 8829bis needs to change.
>
> Regarding 3PCC:

---

From: Ted Hardie <[email-masked]>
Date: Wed, 27 Oct 2021 08:47:20 +0100

On Tue, Oct 26, 2021 at 6:15 PM Justin Uberti <[email-masked]> wrote:

> Yes, it can be done later; if the RFC number is available before IETF last
call, in the version that goes to IETF last call.

regards,

Ted

---

From: Justin Uberti <[email-masked]>
Date: Fri, 29 Oct 2021 10:35:17 -0700

> them from moving an m= line out of the bundle unless it is marked with

If it's already bundled, I don't think it can be unbundled, since there is
no other transport to move it to. This is the same situation as in
subsequent o/a exchanges.

> application should create a new PeerConnection instead with an appropriate

As noted above I don't think taking an m= line out of the bundle is allowed
when a shared port is already in use.

>> - adding a=bundle-only is insufficient, the application would also need
>> to insert zero ports for the bundled m= lines. It's also not clear that
>> this would lead to a good outcome, as the non-bundle endpoint would only be
>> able to accept the first bundled m= line. So I would suggest that if 3PCC
>> with non-bundle-aware endpoints is likely, the application should just eat
>> the a=group attribute for bundle to prevent bundling in the first place.
>>
>>
>>> This is by design, but could cause issues in case of sending a
>>> subsequent offer as an initial offer due to Third Party Call Control
>>> (3PCC). In such cases, the signaling application is responsible for adding
>>> bundle-only attributes to the offer so that it can be used as an initial
>>> offer.
>>>
>>> Best Regards,
>>> _____________
>>> Roman Shpount
>>>
>>>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 29 Oct 2021 14:08:15 -0400

> subsequent o/a exchanges.

It is correct that m= line cannot be unbundled once it is bundled. If this
offer is received as a result of 3PCC, there is nothing in the offer that
indicates that the m= line cannot be unbundled.
Per draft-ietf-mmusic-rfc8843bis section 7.3.2 (
https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-moving-a-media-description-
):

   - In the corresponding offer, the "m=" section is within a previously
      negotiated BUNDLE group, and
      - In the corresponding offer, the "m=" section contains an SDP
      'bundle-only' attribute.

If either criterion above is fulfilled, the answerer cannot move the "m="
section out of the BUNDLE group in the answer.

For subsequent offers processed as initial offers neither of those criteria
are true. There are no previously negotiated BUNDLE groups (it is an
initial offer). There is no 'bundle-only' attribute. Because of this, even
a bundle aware endpoint can move the m= line out. There is no requirement
to check that bundled m= lines are using the same address/port.

> As noted above I don't think taking an m= line out of the bundle is
> allowed when a shared port is already in use.
>

As I am trying to explain, there is nothing in the offer that would
prevent the compliant implementation from moving the m= line out. This is
not obvious but can cause grief.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Fri, 29 Oct 2021 11:16:41 -0700

On Fri, Oct 29, 2021 at 11:08 AM Roman Shpount <[email-masked]> wrote:

>>> Regarding 3PCC, bundle clients should be able to accept the initial
>>> offer without bundle-only. Unfortunately there is nothing there that
>>> prevents them from moving an m= line out of the bundle unless it is marked
>>> with bundle-only.
>>>
>>
>> If it's already bundled, I don't think it can be unbundled, since there
>> is no other transport to move it to. This is the same situation as in
> For subsequent offers processed as initial offers neither of those
> criteria are true. There are no previously negotiated BUNDLE groups (it is
> an initial offer). There is no 'bundle-only' attribute. Because of this,
> even a bundle aware endpoint can move the m= line out. There is no
> requirement to check that bundled m= lines are using the same address/port.
>
>

The problem is that it is not possible, as there is no other transport to
move the unbundled line to. As noted in the section you cite:

 "NOTE: One consequence of the rules above is that, once a BUNDLE group has
been negotiated, a bundled "m=" section cannot be moved out of the BUNDLE
group in an answer. Instead, an offer is needed.:"

Generally, I think that if there is a shared address, that signifies that a
BUNDLE group has already been negotiated, even if that decision was made
elsewhere. Perhaps a note should be added to bundle-bis to explicitly state
this.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 29 Oct 2021 18:29:41 -0400

On Fri, Oct 29, 2021 at 2:16 PM Justin Uberti <
[email-masked]> wrote:

>  "NOTE: One consequence of the rules above is that, once a BUNDLE group
> has been negotiated, a bundled "m=" section cannot be moved out of the
> BUNDLE group in an answer. Instead, an offer is needed.:"
>
> Generally, I think that if there is a shared address, that signifies that
> a BUNDLE group has already been negotiated, even if that decision was made

When discussing bundle-bis the understanding was that it is generally known
when an offer is generated for 3pcc. Because of this, it was decided that
when the offer is generated for 3pcc it should be generated using the same
rules as the initial offer (i.e. with port zero and bundle-only). This was
considered to be both backwards compatible with RBF 8843 and safe to use as
an initial offer for non-bundle aware, bundle, and bundle-bis endpoints.
For whatever reason, inspecting transport addresses was not considered a
valid mechanism to detect that m= lines are already bundled and cannot be
unbundled in the future. If we want to switch to inspecting transport
addresses when deciding which m= lines can be unbundled, this deserves a
lot more than a note in bundle-bis.

I would still argue that a safe way to generate an offer for 3PCC is to do
SDP manipulation and set ports to 0 with attribute bundle-only. Everything
else would not be compatible with either bundle-bis or RFC 8843.
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Fri, 29 Oct 2021 15:48:49 -0700

On Fri, Oct 29, 2021 at 3:29 PM Roman Shpount <[email-masked]> wrote:

> When discussing bundle-bis the understanding was that it is generally
> known when an offer is generated for 3pcc. Because of this, it was decided
> that when the offer is generated for 3pcc it should be generated using the
> same rules as the initial offer (i.e. with port zero and bundle-only). This
> was considered to be both backwards compatible with RBF 8843 and safe to
> use as an initial offer for non-bundle aware, bundle, and bundle-bis
> endpoints. For whatever reason, inspecting transport addresses was not
> considered a valid mechanism to detect that m= lines are already bundled
> and cannot be unbundled in the future. If we want to switch to inspecting
> transport addresses when deciding which m= lines can be unbundled, this
> deserves a lot more than a note in bundle-bis.
>

This logic needs to be applied on subsequent offers already though, so I
don't understand why asking endpoints to also consider it on initial offers
is an issue. Perhaps Christer could weigh in here.

> else would not be compatible with either bundle-bis or RFC 8843.

I am fine to include this as a consideration for non-BUNDLE endpoints but
it seems error-prone and unnecessary to do this for BUNDLE-aware endpoints.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 29 Oct 2021 22:27:09 -0400

On Fri, Oct 29, 2021 at 6:49 PM Justin Uberti <
[email-masked]> wrote:

>>> The problem is that it is not possible, as there is no other transport
>>> to move the unbundled line to. As noted in the section you cite:
>>>
>>> Generally, I think that if there is a shared address, that signifies
>>> that a BUNDLE group has already been negotiated, even if that decision was
>>> made elsewhere. Perhaps a note should be added to bundle-bis to explicitly
>>> state this.
>>>
>>

During the initial offer end point does not have already negotiated bundle
groups. Once the endpoint has already negotiated bundle groups, m= lines
cannot be removed from them.

> it seems error-prone and unnecessary to do this for BUNDLE-aware endpoints.

Your logic only works if bundle-aware endpoints were not allowed to remove
m= lines from a bundle group. Looking at the addresses to determine what is
already grouped is insufficient, since an offer can also be an offer with
ice restart and trickle. No addresses will be present, so the endpoint will
have to look at ice parameters as well. This gets complicated and no one
wanted to describe this when 8843bis was written.  This is why rfc
8843bis specifies that subsequent offers for 3PCC should be valid initial
offers.

There are, potentially, two solutions to this:

1. Change bundle so that endpoints are required to inspect initial offers
for transport addresses and ice parameters. Do not allow m= lines to be
removed from the bundle group if they share the transport address. This
would require pulling RFC 8843bis and writing the appropriate language.

2. Change JSEP note to specify that the application needs to make sure that
in case of 3PCC and remote endpoints either potentially removing m= lines
from the bundle or not being bundle-aware, bundled m= lines need to be
modified to have port 0 and bundle-only attribute. Considering that most
bundle-aware endpoints do not remove m= lines from the bundle, this option
would cause the least amount of specification work.

3. If we want to completely avoid applications messing with SDP, change
JSEP to specify that when ice-restart is specified and a new offer is
generated, already bundled m= lines should be marked with port 0 and
bundle-only. This would also result in the least number of surprises for
developers.

Best Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 30 Oct 2021 22:44:32 +0000

Hi,

First, it would have been nice to see a call-flow that shows exactly where the issue arises, as there are different ways of doing 3PCC.

Already at the early days of BUNDLE, we agreed that an initial offer will NOT contain a shared address, because it is not backward compatible with non-bundle aware endpoints. Some people (including e.g., myself and Cullen) were very keen on that. Instead we will use port zero + bundle-only for m- lines that are only be accepted if part of a BUNDLE group. I do not agree to adding text to 8843bis saying there are cases where the specified procedures for initial offers don’t apply, or don’t have to be followed.

Yes, we did add some 3PCC clarification text  (which anyone could have commented on) in 8843bis, but we did not change the procedures for initial offers.

Also keep in mind that the difference between an initial offer and a subsequent offer is not related only the BUNDLE-related information. For example, an initial offer must also contain unique ICE candidates in each non-bundle-only m- line.

My understanding of the text in 8829bis is that JSEP does NOT support (or, if we want to word it differently, is not able to detect) the 3PCC cases referenced by Roman (again, call flows would have been nice), so a JSEP endpoint will always send a subsequent offer according to the rules for sending a subsequent offer.

Regarding Roman’s suggested solutions #2 and #3, sending ALL bundled m- lines with port zero and bundle-only would be something completely new, as there would be no offerer-tagged m- section. I don’t think that is a good idea. We wither send an initial offer, using the procedures for initial offers, or we send a subsequent offer, using the procedures for subsequent offers.

Regards,

Christer

From: rtcweb <[email-masked]> On Behalf Of Roman Shpount
Sent: lauantai 30. lokakuuta 2021 5.27
To: Justin Uberti <[email-masked]>
Cc: Justin Uberti <[email-masked]>; RTCWeb IETF <[email-masked]>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt

On Fri, Oct 29, 2021 at 6:49 PM Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Oct 29, 2021 at 3:29 PM Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Oct 29, 2021 at 2:16 PM Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

As I am trying to explain, there is nothing in the offer that would prevent the compliant implementation from moving the m= line out. This is not obvious but can cause grief.

The problem is that it is not possible, as there is no other transport to move the unbundled line to. As noted in the section you cite:

 "NOTE: One consequence of the rules above is that, once a BUNDLE group has been negotiated, a bundled "m=" section cannot be moved out of the BUNDLE group in an answer. Instead, an offer is needed.:"

Generally, I think that if there is a shared address, that signifies that a BUNDLE group has already been negotiated, even if that decision was made elsewhere. Perhaps a note should be added to bundle-bis to explicitly state this.

When discussing bundle-bis the understanding was that it is generally known when an offer is generated for 3pcc. Because of this, it was decided that when the offer is generated for 3pcc it should be generated using the same rules as the initial offer (i.e. with port zero and bundle-only). This was considered to be both backwards compatible with RBF 8843 and safe to use as an initial offer for non-bundle aware, bundle, and bundle-bis endpoints. For whatever reason, inspecting transport addresses was not considered a valid mechanism to detect that m= lines are already bundled and cannot be unbundled in the future. If we want to switch to inspecting transport addresses when deciding which m= lines can be unbundled, this deserves a lot more than a note in bundle-bis.

This logic needs to be applied on subsequent offers already though, so I don't understand why asking endpoints to also consider it on initial offers is an issue. Perhaps Christer could weigh in here.

During the initial offer end point does not have already negotiated bundle groups. Once the endpoint has already negotiated bundle groups, m= lines cannot be removed from them.

I would still argue that a safe way to generate an offer for 3PCC is to do SDP manipulation and set ports to 0 with attribute bundle-only. Everything else would not be compatible with either bundle-bis or RFC 8843.

I am fine to include this as a consideration for non-BUNDLE endpoints but it seems error-prone and unnecessary to do this for BUNDLE-aware endpoints.

Your logic only works if bundle-aware endpoints were not allowed to remove m= lines from a bundle group. Looking at the addresses to determine what is already grouped is insufficient, since an offer can also be an offer with ice restart and trickle. No addresses will be present, so the endpoint will have to look at ice parameters as well. This gets complicated and no one wanted to describe this when 8843bis was written.  This is why rfc 8843bis specifies that subsequent offers for 3PCC should be valid initial offers.

1. Change bundle so that endpoints are required to inspect initial offers for transport addresses and ice parameters. Do not allow m= lines to be removed from the bundle group if they share the transport address. This would require pulling RFC 8843bis and writing the appropriate language.

2. Change JSEP note to specify that the application needs to make sure that in case of 3PCC and remote endpoints either potentially removing m= lines from the bundle or not being bundle-aware, bundled m= lines need to be modified to have port 0 and bundle-only attribute. Considering that most bundle-aware endpoints do not remove m= lines from the bundle, this option would cause the least amount of specification work.

3. If we want to completely avoid applications messing with SDP, change JSEP to specify that when ice-restart is specified and a new offer is generated, already bundled m= lines should be marked with port 0 and bundle-only. This would also result in the least number of surprises for developers.

Best Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Sun, 31 Oct 2021 00:01:37 -0400

Hi Christer,

I can try to explain the issue. If you need I can provide a more detailed
call flow with SDP examples but here is the basic scenario for nonw:

1. 3PCC application requests an offer from client A.
2. Client A generates an offer with audio, video, and data m= lines which
are part of a single bundle group. It does not matter for this case if they
are bundle-only or can be unbundled
3. Signaling application sends the offer received from client A to client B.
4. Client B supports bundle so it generates an answer where all m= lines
are bundled
5. 3PCC sends the answer to Client A. At this point all m= lines are
bundled and cannot be unbundled.
6. 3PCC application requests another offer from client A within the same
session. This offer is a subsequent offer so it would have all 3 m= lines
bundled.
7. 3PCC sends the generated offer to client C.
8. Client C is generating an answer to the offer it received. Client C is
bundle aware but decides that it wants to unbundle data m= line. As far as
Client C is concerned, there are no pre-negotiated bundle groups. If there
are no bundle-only attributes on m= lines, there is nothing stopping client
C from unbundling.

Per draft 8843 bis, SIP consideration section (
https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-considerations),
ofer in step 6 should be generated as an initial offer, i.e. with port 0
and bundle-only in bundled m= lines. This is done specifically to avoid
problems in step 8.

What I am suggesting is not to always generate subsequent offers with port
zero and bundle-only. I am suggesting only do this, when this offer is
intended for 3PCC. There is already a similar feature for ICE which
triggers ice restart for the offer which can be used for 3PCC. It can also
trigger generation of an offer with bundle-only for all bundled m= lines. I
would even be fine with webrtc endpoint not doing anything and adding a
note to JSEP telling the 3PCC application to "fix" the offer and add m=
port zero and bundle-only attributes when it is sending subsequent offers
as initial offers to a new end point.

In any case, the subsequent offer generated in step 6 is not a valid
initial offer according to the bundle specification. We have two choices:

1. Make subsequent offers valid initial offers. This means adding some
language explaining how the endpoint processing initial offer can detect
that m= lines cannot be unbundled. Even if we add this language it will
have backwards compatibility issues with anything that has not implemented
it.

2. Make endpoints generate subsequent offers that are valid initial offers
in 3PCC scenarios. This is what draft 8843 bis does.

Please let me know if you need more details.
_____________
Roman Shpount

On Sat, Oct 30, 2021 at 6:44 PM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> First, it would have been nice to see a call-flow that shows exactly where
> the issue arises, as there are different ways of doing 3PCC.
>
>
>
> Already at the early days of BUNDLE, we agreed that an initial offer will
> NOT contain a shared address, because it is not backward compatible with
> non-bundle aware endpoints. Some people (including e.g., myself and Cullen)
> were very keen on that. Instead we will use port zero + bundle-only for m-
> lines that are only be accepted if part of a BUNDLE group. I do not agree
> to adding text to 8843bis saying there are cases where the specified
> procedures for initial offers don’t apply, or don’t have to be followed.
>
>
>
> Yes, we did add some 3PCC clarification text  (which anyone could have
> commented on) in 8843bis, but we did not change the procedures for initial
> offers.
>
>
>
> Also keep in mind that the difference between an initial offer and a
> subsequent offer is not related only the BUNDLE-related information. For
> example, an initial offer must also contain unique ICE candidates in each
> non-bundle-only m- line.
>
>
>
> My understanding of the text in 8829bis is that JSEP does NOT support (or,
> if we want to word it differently, is not able to detect) the 3PCC cases
> referenced by Roman (again, call flows would have been nice), so a JSEP
> endpoint will always send a subsequent offer according to the rules for
> sending a subsequent offer.
>
>
>
> Regarding Roman’s suggested solutions #2 and #3, sending ALL bundled m-
> lines with port zero and bundle-only would be something completely new, as
> there would be no offerer-tagged m- section. I don’t think that is a good
> idea. We wither send an initial offer, using the procedures for initial
> offers, or we send a subsequent offer, using the procedures for subsequent
> offers.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
> *From:* rtcweb <[email-masked]> *On Behalf Of *Roman Shpount
> *Sent:* lauantai 30. lokakuuta 2021 5.27
> *To:* Justin Uberti <[email-masked]>
> *Cc:* Justin Uberti <[email-masked]>; RTCWeb IETF <[email-masked]>
> *Subject:* Re: [rtcweb] Working Group Last Call for
> 2. Change JSEP note to specify that the application needs to make sure
> that in case of 3PCC and remote endpoints either potentially removing m=
> lines from the bundle or not being bundle-aware, bundled m= lines need to
> be modified to have port 0 and bundle-only attribute. Considering that most

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 31 Oct 2021 11:46:31 +0000

Hi Roman,

Thank you for the clarifications!

I think the “generating a subsequent offer as an initial offer” wording could be confusing to people. I would say something like “generating a new initial offer within a session”, or something… However, as far as the issues itself is concerned, that is not relevant – as long as we know what we are talking about :)

>1. Make subsequent offers valid initial offers. This means adding some language explaining how the endpoint processing initial offer can detect that m= lines cannot be unbundled. Even if we add this language it will have backwards compatibility issues with anything that has not implemented it.

I don’t agree with that suggestion. Because, in that case we could have done it from the beginning, as a general rule, without using port zero. But there were reason we chose not to allow shared addresses (with non-zero port values) in initial offers.

>2. Make endpoints generate subsequent offers that are valid initial offers in 3PCC scenarios. This is what draft 8843 bis does.

Correct.

However, keep in mind that it is not only about how to encode the port numbers and bundle-only attributes. Sending an initial offer also comes with a set of procedures. Some of those (e.g., ICE)  I assume you will have to do anyway, as the remote endpoint changes.

>I would even be fine with webrtc endpoint not doing anything and adding a note to JSEP telling the 3PCC application to "fix" the offer and add m= port zero and bundle-only attributes when it is sending subsequent offers as initial offers to a new end point.

I would be fine adding such text to JSEP. It could be an additional sentence to the existing text.

(However, I still would not say “sending subsequent offers as initial offers”. I would say “create and send an initial offer based on a received subsequent offer”, or something like that.)

Regards,

Christer

From: Roman Shpount <[email-masked]>
Sent: sunnuntai 31. lokakuuta 2021 6.02
To: Christer Holmberg <[email-masked]>
Cc: Justin Uberti <[email-masked]>; Justin Uberti <[email-masked]>; RTCWeb IETF <[email-masked]>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt

Hi Christer,

I can try to explain the issue. If you need I can provide a more detailed call flow with SDP examples but here is the basic scenario for nonw:

1. 3PCC application requests an offer from client A.
2. Client A generates an offer with audio, video, and data m= lines which are part of a single bundle group. It does not matter for this case if they are bundle-only or can be unbundled
3. Signaling application sends the offer received from client A to client B.
4. Client B supports bundle so it generates an answer where all m= lines are bundled
5. 3PCC sends the answer to Client A. At this point all m= lines are bundled and cannot be unbundled.
6. 3PCC application requests another offer from client A within the same session. This offer is a subsequent offer so it would have all 3 m= lines bundled.
7. 3PCC sends the generated offer to client C.
8. Client C is generating an answer to the offer it received. Client C is bundle aware but decides that it wants to unbundle data m= line. As far as Client C is concerned, there are no pre-negotiated bundle groups. If there are no bundle-only attributes on m= lines, there is nothing stopping client C from unbundling.

Per draft 8843 bis, SIP consideration section (https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-considerations), ofer in step 6 should be generated as an initial offer, i.e. with port 0 and bundle-only in bundled m= lines. This is done specifically to avoid problems in step 8.

What I am suggesting is not to always generate subsequent offers with port zero and bundle-only. I am suggesting only do this, when this offer is intended for 3PCC. There is already a similar feature for ICE which triggers ice restart for the offer which can be used for 3PCC. It can also trigger generation of an offer with bundle-only for all bundled m= lines. I would even be fine with webrtc endpoint not doing anything and adding a note to JSEP telling the 3PCC application to "fix" the offer and add m= port zero and bundle-only attributes when it is sending subsequent offers as initial offers to a new end point.

In any case, the subsequent offer generated in step 6 is not a valid initial offer according to the bundle specification. We have two choices:

1. Make subsequent offers valid initial offers. This means adding some language explaining how the endpoint processing initial offer can detect that m= lines cannot be unbundled. Even if we add this language it will have backwards compatibility issues with anything that has not implemented it.

2. Make endpoints generate subsequent offers that are valid initial offers in 3PCC scenarios. This is what draft 8843 bis does.

On Sat, Oct 30, 2021 at 6:44 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: rtcweb <[email-masked]<mailto:[email-masked]>> On Behalf Of Roman Shpount
Sent: lauantai 30. lokakuuta 2021 5.27
To: Justin Uberti <[email-masked]<mailto:[email-masked]>>
Cc: Justin Uberti <[email-masked]<mailto:[email-masked]>>; RTCWeb IETF <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt

Best Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Sun, 31 Oct 2021 22:41:02 -0700

> I don’t agree with that suggestion. Because, in that case we could have
> done it from the beginning, as a general rule, without using port zero. But
> there were reason we chose not to allow shared addresses (with non-zero
> port values) in initial offers.
>

We did come up with a=bundle-only mechanism to ensure backwards
compatibility, and none of us want to revisit that decision. However, I do
think that it would be consistent with Postel's Principle for the answerer
to properly handle the case where a 3PCC offer ends up with a shared
address, rather than failing simply because the offer does not appear to be
an initial offer.

>
>
> >2. Make endpoints generate subsequent offers that are valid initial
> offers in 3PCC scenarios. This is what draft 8843 bis does.
>
>
>
> Correct.
>
>
>
> However, keep in mind that it is not only about how to encode the port
> numbers and bundle-only attributes. Sending an initial offer also comes
> with a set of procedures. Some of those (e.g., ICE)  I assume you will have
> to do anyway, as the remote endpoint changes.
>
>
>
> >I would even be fine with webrtc endpoint not doing anything and adding a
> (However, I still would not say “sending subsequent offers as initial
> offers”. I would say “create and send an initial offer based on a received
> subsequent offer”, or something like that.)
>

This might turn out to be the simplest option, but as noted before, it will
require several SDP changes and will be somewhat error-prone as a result
(assuming anyone implements this at all). Accordingly I think #1 above is
the least bad choice.

---

From: Roman Shpount <[email-masked]>
Date: Mon, 1 Nov 2021 01:59:25 -0400

> to do anyway, as the remote endpoint changes.
There is already PeerConnection.restartIce() which will cause the next
offer created after restartIce call to initiate ICE restart, set new
ufrag/pwd, and collect new candidates. This is the method an end point
would call before generating an offer for 3PCC (or to recover a connection
which failed due to bad connectivity). It would not be illogical to set
port zero and bundle-only for all bundled m= lines in this case, when
max-bundle policy is used.

Best Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 1 Nov 2021 02:02:16 -0400

> address, rather than failing simply because the offer does not appear to be
In case of trickle ICE, would shared address be detected by the absence of
ICE ufrag and pwd in the bundled m= line definition?

Best Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Sun, 31 Oct 2021 23:05:42 -0700

> max-bundle policy is used.

Right, but that could happen for normal ICE restarts, in which case it
would be an invalid subsequent offer.

---

From: Justin Uberti <[email-masked]>
Date: Sun, 31 Oct 2021 23:06:15 -0700

On Sun, Oct 31, 2021 at 11:02 PM Roman Shpount <[email-masked]> wrote:

> On Mon, Nov 1, 2021 at 1:41 AM Justin Uberti <

yes, exactly.