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

[Roman Shpount <[e-mail]>]

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

> 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 <[e-mail]>
> *Sent:* Tuesday, November 2, 2021 6:33 PM
> *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
>
> 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
>
>
>
>