From nobody Tue Nov 2 10:53:47 2021 Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8803A3A0965 for ; Tue, 2 Nov 2021 10:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telurix.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnw31yEF6Ity for ; Tue, 2 Nov 2021 10:53:41 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053523A0962 for ; Tue, 2 Nov 2021 10:53:40 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id v22so1967154qtk.9 for ; Tue, 02 Nov 2021 10:53:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J3lwzxOhA0V8QQa21ckj7Ah9AKIhIc+Mom2Fpa/x/i8=; b=HzCGMnpMOcUyKbII6E+TxS55j3gL7FyFotrTjglj4ZK/JzmlPIT5liv7WXp8eERH2T 4G1ksHXdQqa6Y1cOP0BhrezinRmN03ZoxoUwUPg6F90d89vGxLXZQkYHL3p5FX4e3rRY lEQbaRYQwBHhx7DyX7kqkxB2fl4d0EWwMi6v4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J3lwzxOhA0V8QQa21ckj7Ah9AKIhIc+Mom2Fpa/x/i8=; b=uNwVGpbPw+PjJcBNLAqn33s+brSeVIdQmvM4ir6r5QinVkxZldrkRuhEdYNYChb/on UDla8Y2qcxt5pTm2z/rq8lqs6wvqurnT4uTmeMi51aOgzoRMg/AjNH7sdy4v9+1ljIj/ XYcQ2b9k8lMFmWF/vduPgHoP7QVfAxg9WQNDZtEGYHlmay1ttrhfCJGc/EzoGT4wTxFm al1XNhH6xcgdug+wGWYaEec4slrHLxcAvXKZjJJG6hjZrA+auyK/Me5E4J66d/AKK12l APbMc4uEpLV+V383VrnQu3foULppnis81SRflk5F0b4i3r72H8kVorZKRaKf28b2VdQy Ik3Q== X-Gm-Message-State: AOAM532wkjV8qTNj14wKhzaDz32JjNEp24cDdBizFydZBYEgF3sfnlQA 3kdB/WEEjqopUo1kcd0WC4j7X3/bEMH1hg== X-Google-Smtp-Source: ABdhPJyowG5+c7Q8cuecEHv5PEPOte2AuRcG8VPiAosM+zJ/O3xMQ1qDyrBGzhKZV+eLMmb4ZinnJA== X-Received: by 2002:ac8:615c:: with SMTP id d28mr38070813qtm.103.1635875618586; Tue, 02 Nov 2021 10:53:38 -0700 (PDT) Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com. [209.85.219.179]) by smtp.gmail.com with ESMTPSA id v18sm3120598qkp.129.2021.11.02.10.53.37 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Nov 2021 10:53:37 -0700 (PDT) Received: by mail-yb1-f179.google.com with SMTP id v138so282807ybb.8 for ; Tue, 02 Nov 2021 10:53:37 -0700 (PDT) X-Received: by 2002:a25:ca58:: with SMTP id a85mr44556140ybg.155.1635875617499; Tue, 02 Nov 2021 10:53:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Tue, 2 Nov 2021 13:53:26 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Justin Uberti , Justin Uberti , RTCWeb IETF Content-Type: multipart/alternative; boundary="00000000000013f05905cfd1f955" Archived-At: Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-rfc8829bis-01.txt X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Nov 2021 17:53:47 -0000 --00000000000013f05905cfd1f955 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 < christer.holmberg@ericsson.com> wrote: > Hi, > > Eventhough I would not like to make more changes than necessary, I am fin= e > 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 tha= t > 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 Clien= t > (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) wil= l > 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 th= en > 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 subseque= nt > 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 3P= CC > controller will set the port value to zero (and include an SDP > 'bundle-only' attribute) for each "m=3D" section within the BUNDLE group, > excluding the offerer-tagged "m=3D" section. > > > > > > > ------------------------------ > *From:* Roman Shpount > *Sent:* Tuesday, November 2, 2021 6:33 PM > *To:* Christer Holmberg > *Cc:* Justin Uberti ; Justin Uberti < > justin@uberti.name>; RTCWeb IETF > *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 Use= r > 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 th= at > 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=3D lines to include the bundle-only attribute and set th= e m=3D > line port to zero. > _____________ > Roman Shpount > > > On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > Hi, > > > > What about something like this: > > > > --- > > > > OLD: > > > > =E2=80=9CThe Session Initiation Protocol (SIP) [RFC3261] allows a User Ag= ent > 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.=E2=80=9D > > > > NEW: > > > > =E2=80=9CThe Session Initiation Protocol (SIP) [RFC3261] allows a User Ag= ent > 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 offe= r > 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.=E2=80=9D > > > > ---- > > > > Regards, > > > > Christer > > > > > > > > > > > > > > > > > > *From:* Roman Shpount > *Sent:* tiistai 2. marraskuuta 2021 10.41 > *To:* Justin Uberti > *Cc:* Christer Holmberg ; Justin Uberti < > justin@uberti.name>; RTCWeb IETF > *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 < > juberti@alphaexplorationco.com> 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 d= o > when you have that kind of problem? You use an SBC/B2BUA. In this case th= at > 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 t= he > 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=3Dbundle-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 8843b= is > ( > 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 > > > > --00000000000013f05905cfd1f955 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christer,

This makes it much better.= I think it is missing a couple of commas ("In some 3PCC scenarios,&qu= ot; 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 <christer.holmberg@ericsson.com> 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 BUN= DLE specific.)

---

3PCC Considerations

In some 3PCC scenarios a new session will be established between an endpoin= t that is currently part of an ongoing session and an endpoint that is curr= ently not part of an ongoing session. The endpoint that is part of a sessio= n will generate a subsequent offer that will be forwarded to the other endpoint by a 3PCC controller. The end= point that is not part of a session will process the offer as an initial of= fer.=C2=A0

The Session Initiation Protocol (SIP) [RFC3261] allows a User Agent Client = (UAC) to send a re-INVITE request without an SDP body (sometimes referred t= o as an empty re-INVITE). In such cases, the User Agent Server (UAS) will i= nclude an SDP offer in the associated 200 OK response. If the UAS is a part of an ongoing session, it will inclu= de 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 u= sing different rules than subsequent BUNDLE offers, and it cannot be assume= d that a UA is able to correctly process a subsequent offer as an initial o= ffer. 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 t= he rewritten offer the 3PCC controller will set the port value to zero (and= include an SDP 'bundle-only' attribute) for each "m=3D" section within the BUNDLE group, excluding the o= fferer-tagged "m=3D" section.






From= : Roman Shpount <roman@telurix.com>
Sent: Tuesday, November 2, 2021 6:33 PM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Justin Uberti <juberti@alphaexplorationco.com>; Justin Uberti= <justin@uberti.= name>; RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt
=C2=A0
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 c= urrently 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 (sometim= es 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 A= gent (UA) as an initial offer.

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


On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg <christer.hol= mberg@ericsson.com> wrote:

Hi,

=C2=A0

What about something like this:

=C2=A0

---

=C2=A0

OLD:

=C2=A0

=E2=80=9CThe Session Initiation Protocol (SIP) [RFC= 3261] 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 inc= lude 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.=E2=80=9D<= /u>

=C2=A0

NEW:

=C2=A0

=E2=80=9CThe Session Initiation Protocol (SIP) [RFC= 3261] 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 inc= lude an SDP offer in the associated 200 OK response. This is typically used= for 3rd Party Call Control (3PCC) scenarios.

=C2=A0

In some 3PCC scenarios the UAS will be part of an o= ngoing 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 forwar= ded as an initial offer to another User Agent (UA) that is currently not pa= rt of a session.

=C2=A0

When the BUNDLE mechanism is used, as an initial BU= NDLE offer look different than a subsequent BUNDLE offer, it cannot be assu= med 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.=E2=80=9D

=C2=A0

----

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Roman Shpo= unt <roman@teluri= x.com>
Sent: tiistai 2. marraskuuta 2021 10.41
To: Justin Uberti <juberti@alphaexplorationco.com>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>; Justin Ub= erti <justin@ube= rti.name>; RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt

=C2=A0

On Mon, Nov 1, 2021 at 2:52 PM Justin Uberti <juberti@alphaexplorationco.com= > 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.

=C2=A0

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

=C2=A0

Roman, thoughts on this? If the 3PCC is going to rewrite the offer SDP a= nyway then maybe adding a=3Dbundle-only isn't the end of the world.<= /u>

=C2=A0

I am not opposed to=C2=A0this idea. 3PCC typically knows that the subseq= uent offer is going to be used as initial, and should be able to rewrite th= e offer to make it valid. We can change=C2=A0SIP Considerations section in = 8843bis (https://www.ietf.or= g/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.<= u>

_____________
Roman Shpount

=C2=A0

--00000000000013f05905cfd1f955--