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

[Roman Shpount <[e-mail]>]

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 <
[e-mail]> 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 <[e-mail]> *On Behalf Of *Roman Shpount
> *Sent:* lauantai 30. lokakuuta 2021 5.27
> *To:* Justin Uberti <[e-mail]>
> *Cc:* Justin Uberti <[e-mail]>; RTCWeb IETF <[e-mail]>
> *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 <
> [e-mail]> wrote:
>
>
>
>
>
> On Fri, Oct 29, 2021 at 3:29 PM Roman Shpount <[e-mail]> wrote:
>
> On Fri, Oct 29, 2021 at 2:16 PM Justin Uberti <
> [e-mail]> 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.
>
>
>
> 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
>
>
>