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

[Roman Shpount <[e-mail]>]

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 <
[e-mail]> wrote:

> 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 <[e-mail]>
> *Sent:* tiistai 2. marraskuuta 2021 10.41
> *To:* Justin Uberti <[e-mail]>
> *Cc:* Christer Holmberg <[e-mail]>; Justin Uberti <
> [e-mail]>; RTCWeb IETF <[e-mail]>
> *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 <
> [e-mail]> 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.
>
>
>
> 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.
>
>
>
> 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
>
>
>