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

[Christer Holmberg <[e-mail]>]

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 <[e-mail]>
Sent: sunnuntai 31. lokakuuta 2021 6.02
To: Christer Holmberg <[e-mail]>
Cc: Justin Uberti <[e-mail]>; Justin Uberti <[e-mail]>; RTCWeb IETF <[e-mail]>
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.

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


On Sat, Oct 30, 2021 at 6:44 PM Christer Holmberg <[e-mail]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Roman Shpount
Sent: lauantai 30. lokakuuta 2021 5.27
To: Justin Uberti <[e-mail]<mailto:[e-mail]>>
Cc: Justin Uberti <[e-mail]<mailto:[e-mail]>>; RTCWeb IETF <[e-mail]<mailto:[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]<mailto:[e-mail]>> wrote:


On Fri, Oct 29, 2021 at 3:29 PM Roman Shpount <[e-mail]<mailto:[e-mail]>> wrote:
On Fri, Oct 29, 2021 at 2:16 PM Justin Uberti <[e-mail]<mailto:[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