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

From: Christer Holmberg <[email-masked]>
Date: Mon, 1 Nov 2021 13:29:17 +0000

Hi,

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

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

I don't agree with that. Again, that is why we did not define it to begin with. When this was discussed, people indicated that even in cases where an answerer would accept the offer, it is not possible to predict how the answer would look like.

Also, keep in mind that the answerer may not know that the offer is for 3PCC. It may just see 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 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.)

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

I don't agree with suddenly allowing (read: specify in the standard that it is ok) something that we agreed that we are not going to do more or less from day one, and that has never considered later during the process either.

---

The PROBLEM is that we have two endpoints, where one sends a subsequent offer, and the other one expects an initial offer. What do you normally do when you have that kind of problem? You use an SBC/B2BUA. In this case that SBC/B2BUA would be the 3PCC controller.

So, my suggestion would be to remove the SHOULD text from 8843bis, and simply add a note somewhere (in 8843bis and/or 8829bis) which describes the issue and says that the 3GPP controller needs to modify the offer accordingly.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Mon, 1 Nov 2021 11:52:36 -0700

On Mon, Nov 1, 2021 at 6:29 AM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
> >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.
>
>
> >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.
>
> I don't agree with that. Again, that is why we did not define it to begin
> with. When this was discussed, people indicated that even in cases where an
> answerer would accept the offer, it is not possible to predict how the
> answer would look like.
>

I think we are talking about a much narrower situation than what was
considered years ago. The concern Roman raises is regarding a bundle-aware
endpoint that receives an initial offer that is a valid bundle subsequent
offer.

Can you suggest a specific technical reason why it would be ambiguous for
the answerer to handle this 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
> 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.
>
>
>
> (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.
>
> I don't agree with suddenly allowing (read: specify in the standard that
> it is ok) something that we agreed that we are not going to do more or less
> from day one, and that has never considered later during the process either.
>
> ---
>
> The PROBLEM is that we have two endpoints, where one sends a subsequent
> offer, and the other one expects an initial offer. What do you normally do
> when you have that kind of problem? You use an SBC/B2BUA. In this case that
> SBC/B2BUA would be the 3PCC controller.
>
> So, my suggestion would be to remove the SHOULD text from 8843bis, and
> simply add a note somewhere (in 8843bis and/or 8829bis) which describes the
> issue and says that the 3GPP controller needs to modify the offer
> accordingly.
>
>
Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP
anyway then maybe adding a=bundle-only isn't the end of the world.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 2 Nov 2021 04:40:56 -0400

> anyway then maybe adding a=bundle-only isn't the end of the world.

I am not opposed to this idea. 3PCC typically knows that the subsequent
offer is going to be used as initial, and should be able to rewrite the
offer to make it valid. We can change SIP Considerations section in 8843bis
(
https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-consideration),
remove the SHOULD, and specify that 3PCC controller should fix the offer.
We can then reference this note from 8829bis or restate the same guidance.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Nov 2021 10:00:32 +0000

Hi,

What about something like this:

---

OLD:

“The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE).
In such cases, the User Agent Server (UAS) will include an SDP Offer in the associated 200 OK response. This is typically used for 3rd Party Call Control (3PCC) scenarios.
From a BUNDLE perspective, such SDP Offer SHOULD be generated using the procedures defined in Section 7.2.”

NEW:

“The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE).
In such cases, the User Agent Server (UAS) will include an SDP offer in the associated 200 OK response. This is typically used for 3rd Party Call Control (3PCC) scenarios.

In some 3PCC scenarios the UAS will be part of an ongoing session, and will therefore include a subsequent offer in the 200 OK responses. The offer will be
received by a 3PCC controller (UAC) and then forwarded as an initial offer to another User Agent (UA) that is currently not part of a session.

When the BUNDLE mechanism is used, as an initial BUNDLE offer look different than a subsequent BUNDLE offer, it cannot be assumed that a UA that expects an initial offer
will be able to properly process a subsequent offer. Therefore, the 3PCC controller needs to act as a Back-To-Back User Agent (B2BUA), and when it receives the subsequent
offer it needs to rewrite it into an initial offer before it is forwarded to such UA.”

----

Regards,

Christer

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

On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
The PROBLEM is that we have two endpoints, where one sends a subsequent offer, and the other one expects an initial offer. What do you normally do when you have that kind of problem? You use an SBC/B2BUA. In this case that SBC/B2BUA would be the 3PCC controller.

Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP anyway then maybe adding a=bundle-only isn't the end of the world.

I am not opposed to this idea. 3PCC typically knows that the subsequent offer is going to be used as initial, and should be able to rewrite the offer to make it valid. We can change SIP Considerations section in 8843bis (https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-consideration), remove the SHOULD, and specify that 3PCC controller should fix the offer. We can then reference this note from 8829bis or restate the same guidance.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 2 Nov 2021 12:33:47 -0400

How about we replace the SIP Considerations with:

3PCC Considerations

In some 3PCC scenarios, an offer generated during an ongoing session, i.e.,
a subsequent offer, will be used by a 3PCC controller to establish a new
session and forwarded as an initial offer to another endpoint that is
currently not part of a session.

For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User
Agent Client (UAC) to send a re-INVITE request without an SDP body
(sometimes referred to as an empty re-INVITE). In such cases, the User
Agent Server (UAS) will include an SDP offer in the associated 200 OK
response. If UAS is a part of an ongoing session, it will include a
subsequent offer in the 200 OK response. The offer will be received by a
3PCC controller (UAC) and then forwarded to another User Agent (UA) as an
initial offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed
using different rules than subsequent BUNDLE offers. It cannot be assumed
that a subsequent offer is a valid initial offer and that the endpoint that
expects an initial offer will properly process such a subsequent offer.
Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a
valid initial offer before it is used to establish a new session. To make
the subsequent offer a valid initial offer, 3PCC will need to modify all
the non-tagged m= lines to include the bundle-only attribute and set the m=
line port to zero.
_____________
Roman Shpount

On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg <
[email-masked]> wrote:

> “The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent
> Client (UAC) to send a re-INVITE request without an SDP body (sometimes
> referred to as an empty re-INVITE).
>
> In such cases, the User Agent Server (UAS) will include an SDP Offer in
> the associated 200 OK response. This is typically used for 3rd Party Call
> Control (3PCC) scenarios.
>
> “The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent
> Client (UAC) to send a re-INVITE request without an SDP body (sometimes
> referred to as an empty re-INVITE).
>
> In such cases, the User Agent Server (UAS) will include an SDP offer in
> the associated 200 OK response. This is typically used for 3rd Party Call
> Control (3PCC) scenarios.
>
>
>
> In some 3PCC scenarios the UAS will be part of an ongoing session, and
> will therefore include a subsequent offer in the 200 OK responses. The
> offer will be
>
> received by a 3PCC controller (UAC) and then forwarded as an initial offer
> to another User Agent (UA) that is currently not part of a session.
>
>
>
> When the BUNDLE mechanism is used, as an initial BUNDLE offer look
> different than a subsequent BUNDLE offer, it cannot be assumed that a UA
> that expects an initial offer
>
> will be able to properly process a subsequent offer. Therefore, the 3PCC
> controller needs to act as a Back-To-Back User Agent (B2BUA), and when it
> receives the subsequent
>
> *From:* Roman Shpount <[email-masked]>
> *Sent:* tiistai 2. marraskuuta 2021 10.41
> *To:* Justin Uberti <[email-masked]>
> *Cc:* Christer Holmberg <[email-masked]>; Justin Uberti <
> [email-masked]>; RTCWeb IETF <[email-masked]>
> *Subject:* Re: [rtcweb] Working Group Last Call for
> draft-uberti-rtcweb-rfc8829bis-01.txt
>
>
>
> On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti <
> [email-masked]> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Nov 2021 17:24:26 +0000

Hi,

Eventhough I would not like to make more changes than necessary, I am fine with "3PCC Considerations".

However, your suggested text is very difficult to understand in some places, so let me give it a try.

(The first paragraph is generic, the second SIP specific, and the third BUNDLE specific.)

---

3PCC Considerations

In some 3PCC scenarios a new session will be established between an endpoint that is currently part of an ongoing session and an endpoint that is currently not part of an ongoing session. The endpoint that is part of a session will generate a subsequent offer that will be forwarded to the other endpoint by a 3PCC controller. The endpoint that is not part of a session will process the offer as an initial offer.

The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the associated 200 OK response. If the UAS is a part of an ongoing session, it will include a subsequent offer in the 200 OK response. The offer will be received by a 3PCC controller (UAC) and then forwarded to another User Agent (UA). If the UA is not part of an ongoing session, it will process the offer as an initial offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed using different rules than subsequent BUNDLE offers, and it cannot be assumed that a UA is able to correctly process a subsequent offer as an initial offer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer, following the procedures in (Section 7.2), before it forwards the offer to a UA. In the rewritten offer the 3PCC controller will set the port value to zero (and include an SDP 'bundle-only' attribute) for each "m=" section within the BUNDLE group, excluding the offerer-tagged "m=" section.

________________________________
From: Roman Shpount <[email-masked]>
Sent: Tuesday, November 2, 2021 6:33 PM
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

3PCC Considerations

In some 3PCC scenarios, an offer generated during an ongoing session, i.e., a subsequent offer, will be used by a 3PCC controller to establish a new session and forwarded as an initial offer to another endpoint that is currently not part of a session.

For example, the Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client (UAC) to send a re-INVITE request without an SDP body (sometimes referred to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will include an SDP offer in the associated 200 OK response. If UAS is a part of an ongoing session, it will include a subsequent offer in the 200 OK response. The offer will be received by a 3PCC controller (UAC) and then forwarded to another User Agent (UA) as an initial offer.

When the BUNDLE mechanism is used, an initial BUNDLE offer is constructed using different rules than subsequent BUNDLE offers. It cannot be assumed that a subsequent offer is a valid initial offer and that the endpoint that expects an initial offer will properly process such a subsequent offer. Therefore, the 3PCC controller SHOULD rewrite the subsequent offer into a valid initial offer before it is used to establish a new session. To make the subsequent offer a valid initial offer, 3PCC will need to modify all the non-tagged m= lines to include the bundle-only attribute and set the m= line port to zero.
_____________
Roman Shpount

On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

---

OLD:

NEW:

----

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Sent: tiistai 2. marraskuuta 2021 10.41
To: Justin Uberti <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; 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

_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 2 Nov 2021 13:53:26 -0400

Hi Christer,

This makes it much better. I think it is missing a couple of commas ("In
some 3PCC scenarios," and "In the rewritten offer,") but works for me.

I have changed the section name so it is clear that it applies to JSEP as
well, not just SIP.

Best Regards,
_____________
Roman Shpount

On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg <
[email-masked]> wrote:

> In some 3PCC scenarios a new session will be established between an
> endpoint that is currently part of an ongoing session and an endpoint that
> is currently not part of an ongoing session. The endpoint that is part of a
> session will generate a subsequent offer that will be forwarded to the
> other endpoint by a 3PCC controller. The endpoint that is not part of a
> session will process the offer as an initial offer.
>
> The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client
> (UAC) to send a re-INVITE request without an SDP body (sometimes referred
> to as an empty re-INVITE). In such cases, the User Agent Server (UAS) will
> include an SDP offer in the associated 200 OK response. If the UAS is a
> part of an ongoing session, it will include a subsequent offer in the 200
> OK response. The offer will be received by a 3PCC controller (UAC) and then
> forwarded to another User Agent (UA). If the UA is not part of an ongoing
> session, it will process the offer as an initial offer.
>
> using different rules than subsequent BUNDLE offers, and it cannot be
> assumed that a UA is able to correctly process a subsequent offer as an
> initial offer. Therefore, the 3PCC controller SHOULD rewrite the subsequent
> offer into a valid initial offer, following the procedures in (Section
> 7.2), before it forwards the offer to a UA. In the rewritten offer the 3PCC
> controller will set the port value to zero (and include an SDP
> 'bundle-only' attribute) for each "m=" section within the BUNDLE group,
> excluding the offerer-tagged "m=" section.
>
>
>
>
>
>
> ------------------------------
> *Sent:* Tuesday, November 2, 2021 6:33 PM
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* Justin Uberti <[email-masked]>; Justin Uberti <
> In some 3PCC scenarios, an offer generated during an ongoing session,
> i.e., a subsequent offer, will be used by a 3PCC controller to establish a
> new session and forwarded as an initial offer to another endpoint that is

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Nov 2021 21:13:11 +0000

Hi,

>This makes it much better. I think it is missing a couple of commas ("In some 3PCC scenarios," and "In the rewritten offer,") but works for me.

I can add them when I add the text to the draft, but I think the RFC editor will most likely notice such thing.

>I have changed the section name so it is clear that it applies to JSEP as well, not just SIP.

Sure, that’s fine.

Regards,

Christer

On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

---

3PCC Considerations

________________________________
From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, November 2, 2021 6:33 PM
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Justin Uberti <[email-masked]<mailto:[email-masked]>>; 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

3PCC Considerations

Hi,

---

OLD:

NEW:

----

Regards,

Christer

_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Nov 2021 18:38:23 +0000

Justin, are you ok with the suggested text? I would probably be a good idea to refer it in 8829bis.

Regards,

Christer
________________________________
From: rtcweb <[email-masked]> on behalf of Christer Holmberg <christer.holmberg=[email-masked]>
Sent: Tuesday, November 2, 2021 11:13 PM
To: Roman Shpount <[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

Hi,

Sure, that’s fine.

Regards,

Christer

Hi,

---

3PCC Considerations

3PCC Considerations

_____________
Roman Shpount

Hi,

---

OLD:

NEW:

----

Regards,

Christer

_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 4 Nov 2021 21:33:52 -0600

Could we have a quick call on this next week during one of the breaks. I have tried to follow this whole thread and some it does not make much sense to me. I’m a bit lost on what the varios proposed resolutions are. 

> On Nov 3, 2021, at 12:38 PM, Christer Holmberg <christer.holmberg=[email-masked]> wrote:
> 
> From: rtcweb <[email-masked] <mailto:[email-masked]>> on behalf of Christer Holmberg <christer.holmberg=[email-masked] <mailto:christer.holmberg=[email-masked]>>
> To: Roman Shpount <[email-masked] <mailto:[email-masked]>>
> Cc: Justin Uberti <[email-masked] <mailto:[email-masked]>>; RTCWeb IETF <[email-masked] <mailto:[email-masked]>>
> On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
>  
> From: Roman Shpount <[email-masked] <mailto:[email-masked]>>
> To: Christer Holmberg <[email-masked] <mailto:[email-masked]>>
> Cc: Justin Uberti <[email-masked] <mailto:[email-masked]>>; Justin Uberti <[email-masked] <mailto:[email-masked]>>; RTCWeb IETF <[email-masked] <mailto:[email-masked]>>
> On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
>  
> From: Roman Shpount <[email-masked] <mailto:[email-masked]>> 
> To: Justin Uberti <[email-masked] <mailto:[email-masked]>>
> Cc: Christer Holmberg <[email-masked] <mailto:[email-masked]>>; Justin Uberti <[email-masked] <mailto:[email-masked]>>; RTCWeb IETF <[email-masked] <mailto:[email-masked]>>
> On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti <[email-masked] <mailto:[email-masked]>> wrote:
> I am not opposed to this idea. 3PCC typically knows that the subsequent offer is going to be used as initial, and should be able to rewrite the offer to make it valid. We can change SIP Considerations section in 8843bis (https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-consideration <https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-05.html#name-sip-consideration>), remove the SHOULD, and specify that 3PCC controller should fix the offer. We can then reference this note from 8829bis or restate the same guidance.
> _____________
> Roman Shpount
>  
> _______________________________________________
> rtcweb mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 4 Nov 2021 23:52:50 -0400

I am available during US Eastern hours.

I will try to summarize this discussion:

With the latest bundle update, subsequent offers with the bundle (offers
where bundled m= lines which can no longer be unbundled are not marked in
any way except that they share the same communication address) are not
valid initial offers for the bundle (where bundled m= lines which can no
longer be unbundled have the port set to zero and bundle-only attribute).
It was not the case with RFC8843 (all offers and answers had bundle-only m=
line attributes). If, as a result of 3PCC, a subsequent offer becomes an
initial offer, it either needs to be fixed by something (originating
endpoint or 3PCC controller), or RFC8843 should be modified to make
subsequent offers valid initial offers (detect that bundled m= lines share
the same address and cannot be unbundled). The solution that Christer and I
are proposing is that the 3PCC controller should fix the offer if it were
the subsequent offer for one session and was used as the initial offer for
another. Christer came up with the text for RFC8843bis to specify this.
_____________
Roman Shpount

On Thu, Nov 4, 2021 at 11:33 PM Cullen Jennings <[email-masked]> wrote:

>
> Could we have a quick call on this next week during one of the breaks. I
> have tried to follow this whole thread and some it does not make much sense
> to me. I’m a bit lost on what the varios proposed resolutions are.
>
>
> On Nov 3, 2021, at 12:38 PM, Christer Holmberg <
> christer.holmberg=[email-masked]> wrote:
>
> *From:* rtcweb <[email-masked]> on behalf of Christer Holmberg <
> christer.holmberg=[email-masked]>
> *Sent:* Tuesday, November 2, 2021 11:13 PM
> *To:* Roman Shpount <[email-masked]>
> *Cc:* Justin Uberti <[email-masked]>; RTCWeb IETF <[email-masked]>
> I can add them when I add the text to the draft, but I think the RFC
> editor will most likely notice such thing.
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Nov 2021 04:14:49 +0000

Hi,

The question was whether an endpoint would be assumed to be able to accept a subsequent offer (same address:port in each m- line) as an initial offer. I did not agree to that.

However, the suggestion a couple of days ago, which people seemed to agree to, does NOT make that assumption anymore. Nothing out of the normal would be assumed by endpoints, and instead the 3GPP controller will act as a B2BUA and modify the SDP if needed.

Regards,

Christer

From: Cullen Jennings <[email-masked]>
Sent: perjantai 5. marraskuuta 2021 5.34
To: Christer Holmberg <[email-masked]>; Roman Shpount <[email-masked]>; Justin Uberti <[email-masked]>
Cc: RTCWeb IETF <[email-masked]>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt

On Nov 3, 2021, at 12:38 PM, Christer Holmberg <christer.holmberg=[email-masked]<mailto:christer.holmberg=[email-masked]>> wrote:

Regards,

Christer
________________________________
From: rtcweb <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <christer.holmberg=[email-masked]<mailto:christer.holmberg=[email-masked]>>
Sent: Tuesday, November 2, 2021 11:13 PM
To: Roman Shpount <[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

Hi,

Sure, that’s fine.

Regards,

Christer

---

3PCC Considerations

3PCC Considerations

---

OLD:

NEW:

----

Regards,

Christer

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

---

From: Justin Uberti <[email-masked]>
Date: Thu, 4 Nov 2021 22:12:02 -0700

I still feel the cleanest solution would be to allow the answerer to accept
a subsequent offer as an initial offer (since then things will work in 3PCC
with no SDP rewriting), and AFAIK no technical reason has been put forth to
explain why this cannot work.

However, I can live with the alternate solution put forth by Christer, and
the proposed text seems reasonable to me.

Justin

On Thu, Nov 4, 2021 at 9:14 PM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> The question was whether an endpoint would be assumed to be able to accept
> a subsequent offer (same address:port in each m- line) as an initial offer.
> I did not agree to that.
>
>
>
> However, the suggestion a couple of days ago, which people seemed to agree
> to, does NOT make that assumption anymore. Nothing out of the normal would
> be assumed by endpoints, and instead the 3GPP controller will act as a
> B2BUA and modify the SDP if needed.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Cullen Jennings <[email-masked]>
> *Sent:* perjantai 5. marraskuuta 2021 5.34
> *To:* Christer Holmberg <[email-masked]>; Roman Shpount <
> [email-masked]>; Justin Uberti <[email-masked]>
> *Cc:* RTCWeb IETF <[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 5 Nov 2021 11:40:15 +0000

Hi,

If the text is something that everyone can agree on, then I suggest we go with that. It does not require any changes or assumptions regarding the endpoint behaviour.

Regards,

Christer

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Justin Uberti <[email-masked]>
Sent: Friday, November 5, 2021 7:12:02 AM
To: Christer Holmberg <[email-masked]>
Cc: Cullen Jennings <[email-masked]>; RTCWeb IETF <[email-masked]>; Roman Shpount <[email-masked]>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt

I still feel the cleanest solution would be to allow the answerer to accept a subsequent offer as an initial offer (since then things will work in 3PCC with no SDP rewriting), and AFAIK no technical reason has been put forth to explain why this cannot work.

However, I can live with the alternate solution put forth by Christer, and the proposed text seems reasonable to me.

Justin

On Thu, Nov 4, 2021 at 9:14 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

From: Cullen Jennings <[email-masked]<mailto:[email-masked]>>
Sent: perjantai 5. marraskuuta 2021 5.34
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Roman Shpount <[email-masked]<mailto:[email-masked]>>; Justin Uberti <[email-masked]<mailto:[email-masked]>>
Cc: RTCWeb IETF <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt

Regards,

Christer

Hi,

Sure, that’s fine.

Regards,

Christer

Hi,

---

3PCC Considerations

3PCC Considerations

_____________
Roman Shpount

Hi,

---

OLD:

NEW:

----

Regards,

Christer

_____________
Roman Shpount