From nobody Thu Nov 4 22:12:22 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 C051E3A0C90 for ; Thu, 4 Nov 2021 22:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 xTRnIcBJ7zJe for ; Thu, 4 Nov 2021 22:12:14 -0700 (PDT) Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (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 9C23B3A0C81 for ; Thu, 4 Nov 2021 22:12:14 -0700 (PDT) Received: by mail-pl1-f175.google.com with SMTP id t21so10415421plr.6 for ; Thu, 04 Nov 2021 22:12:14 -0700 (PDT) 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=YgPJBsNY1T4wLavxPWQbBsuh4m7q9jYepNjA69Qr3hI=; b=6XSssg18jV1UEGy85K6sQIlSoPjkuywT7jd4mRfsMSnRz8O0TFPTsxbJ/3KN0a8fsw bQQV17HYrzrtVPBk03mcMCIS8LMhCO3/yqDjGxG0nBGzuSUhNI57Xtf6iyXPgiPs2zef SbuT51/sBPSPpLHXKplyvegV1FZJSIB99w6xKosDjHzXD9e5QPOQUPsppC2LpOCWARP2 iTCOvJsKi5YNb+Cqhfi0Np3T4FiRCTUF25ns7ZduLMT+xkTGiKakHv0YlSM9truWg8r6 yp9Ga4X7S6U1yQnz53TrxSp4TnVNmoBIxvz2HGy79RN0lrIl2/P22bPRSE2rtijvGS7B auRQ== X-Gm-Message-State: AOAM530zdzTNfwcKxZX+AlH5+4UVF7B7lvs7Hmd6kA9z1wdKaRMqubFj dHEpUA5wilOrSehcTHdUhEGLItNg1tljydCcuoUpZuNz X-Google-Smtp-Source: ABdhPJw2PJ2zWHQP/GIisGSKOanI5RXHg5ry8c8E9TUbmx4V3KVfBg6NCVNQf7ZA3+T95bwPDrd8IFwxWYshfQsq+Dc= X-Received: by 2002:a17:902:d652:b0:13f:c302:b945 with SMTP id y18-20020a170902d65200b0013fc302b945mr48936133plh.69.1636089133679; Thu, 04 Nov 2021 22:12:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Justin Uberti Date: Thu, 4 Nov 2021 22:12:02 -0700 Message-ID: To: Christer Holmberg Cc: Cullen Jennings , RTCWeb IETF , Roman Shpount Content-Type: multipart/alternative; boundary="000000000000a2489505d003af99" 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: Fri, 05 Nov 2021 05:12:20 -0000 --000000000000a2489505d003af99 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 < christer.holmberg@ericsson.com> wrote: > Hi, > > > > The question was whether an endpoint would be assumed to be able to accep= t > a subsequent offer (same address:port in each m- line) as an initial offe= r. > I did not agree to that. > > > > However, the suggestion a couple of days ago, which people seemed to agre= e > to, does NOT make that assumption anymore. Nothing out of the normal woul= d > 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 > *Sent:* perjantai 5. marraskuuta 2021 5.34 > *To:* Christer Holmberg ; Roman Shpount < > roman@telurix.com>; Justin Uberti > *Cc:* RTCWeb IETF > *Subject:* Re: [rtcweb] Working Group Last Call for > draft-uberti-rtcweb-rfc8829bis-01.txt > > > > > > 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 sen= se > to me. I=E2=80=99m a bit lost on what the varios proposed resolutions are= . > > > > > > On Nov 3, 2021, at 12:38 PM, Christer Holmberg < > christer.holmberg=3D40ericsson.com@dmarc.ietf.org> wrote: > > > > Justin, are you ok with the suggested text? I would probably be a good > idea to refer it in 8829bis. > > > > Regards, > > > > Christer > ------------------------------ > > *From:* rtcweb on behalf of Christer Holmberg < > christer.holmberg=3D40ericsson.com@dmarc.ietf.org> > *Sent:* Tuesday, November 2, 2021 11:13 PM > *To:* Roman Shpount > *Cc:* Justin Uberti ; RTCWeb IETF > *Subject:* Re: [rtcweb] Working Group Last Call for > draft-uberti-rtcweb-rfc8829bis-01.txt > > > > 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 a= s > well, not just SIP. > > > > Sure, that=E2=80=99s fine. > > > > Regards, > > > > Christer > > > > > > > > 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 > > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > > > --000000000000a2489505d003af99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I still feel the cleanest solution would be to allow the = answerer to accept a subsequent offer as an initial offer (since then thing= s will work in 3PCC with no SDP rewriting), and AFAIK no technical reason h= as been put forth to explain why this cannot work.
<= br>
However, I can live with the alternate solution = put forth by Christer, and the proposed text seems reasonable to me.
<= div dir=3D"auto">
Justin

On Thu, Nov 4, 2021= at 9:14 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

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

=C2=A0

However, the suggestion a coupl= e of days ago, which people seemed to agree to, does NOT make that assumpti= on anymore. Nothing out of the normal would be assumed by endpoints, and in= stead the 3GPP controller will act as a B2BUA and modify the SDP if needed.

=C2=A0

Regards,

=

=C2=A0

Christer

=C2=A0

From: Cullen Jennings <fluffy@iii.ca>
Sent: perjantai 5. marraskuuta 2021 5.34
To: Christer Holmberg <christer.holmberg@ericsson.com>; Roman Shp= ount <roman@telur= ix.com>; Justin Uberti <justin@uberti.name>
Cc: RTCWeb IETF <rtcweb@ietf.org>
Subject: Re: [rtcweb] Working Group Last Call for draft-uberti-rtcwe= b-rfc8829bis-01.txt

=C2=A0

=C2=A0

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 doe= s not make much sense to me. I=E2=80=99m a bit lost on what the varios prop= osed resolutions are.=C2=A0

=C2=A0



On Nov 3, 2021, at 12:38 PM, Christer Holmberg <<= a href=3D"mailto:christer.holmberg=3D40ericsson.com@dmarc.ietf.org" target= =3D"_blank">christer.holmberg=3D40ericsson.com@dmarc.ietf.org> wrote= :

=C2=A0

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

=C2=A0

Regards,<= /u>

=C2=A0

Christer<= /u>

From:=C2=A0rtcweb <rtcweb-bounces@ietf.org> on behalf of = Christer Holmberg <christer.holmberg=3D40ericsson.com@dmarc.= ietf.org>
Sent:=C2= =A0Tuesday, November 2, 2021 11:13 PM
To:=C2= =A0Roman Shpount <roman@telurix.com>
Cc:=C2= =A0Justin Uberti <justin@uberti.name>; RTCWeb IETF <rtcweb@ietf.org>
Subject:= =C2=A0Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-r= fc8829bis-01.txt

=C2=A0

Hi,

=C2=A0

>This makes it much better.<= span class=3D"m_-3506113441870466143apple-converted-space">=C2=A0I think it is missing a couple of commas ("In some 3PCC scenarios,= " and "In the rewritten offer,") but works for me.=

=C2=A0

I can add them when I add the t= ext to the draft, but I think the RFC editor will most likely notice such t= hing.

=C2=A0

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

=C2=A0

Sure, that=E2=80=99s fine.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

=C2=A0

On Tue, Nov 2, 2021 at 1:24 PM Christer Holmberg <= ;christ= er.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

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

=C2=A0

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

=C2=A0

(The first paragrap= h is generic, the second SIP specific, and the third BUNDLE specific.)

=C2=A0

---

=C2=A0

3PCC Considerations

=C2=A0

In some 3PCC scenarios a new session will be establis= hed 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 co= ntroller. The endpoint that is not part of a session will process the offer= as an initial offer.=C2=A0

=C2=A0

The Session Initiation Protocol (SIP) [RFC3261] allow= s 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 th= e associated 200 OK response. If the UAS is a part of an ongoing session, i= t 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 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.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From:=C2=A0Roman Shpount <roman@telurix.com>
Sent:=C2= =A0Tuesday, November 2, 2021 6:33 PM
To:=C2= =A0Christer Holmberg <christer.holmberg@ericsson.com>
Cc:=C2= =A0Justin Uberti <juberti@alphaexplorationco.com>; Justin Uberti = <justin@uberti.n= ame>; RTCWeb IETF <rtcwe= b@ietf.org>
Subject:= =C2=A0Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-r= fc8829bis-01.txt

=C2=A0

How about we replace the SIP Considerations with:=C2=A0

=C2=A0

3PCC Considerations

=C2=A0

In some 3PCC scenarios, an offer generated during an= ongoing session, i.e., a subsequent offer, will be used by a 3PCC controll= er 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 (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

=C2=A0

=C2=A0

On Tue, Nov 2, 2021 at 6:00 AM Christer Holmberg <= ;christ= er.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

What about something like this:

=C2=A0

---=

=C2=A0

OLD:

=C2=A0

=E2=80=9CThe Session Initiation Pr= otocol (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 Serv= er (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 SD= P Offer SHOULD be generated using the procedures defined in Section 7.2.=E2= =80=9D

=C2=A0

NEW:

=C2=A0

=E2=80=9CThe Session Initiation Pr= otocol (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 Serv= er (UAS) will include 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 wil= l be part of an ongoing session, and will therefore include a subsequent of= fer 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.

=C2=A0

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

=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:=C2=A0Roman Shpount <roman@t= elurix.com>=C2=A0
Sent:=C2= =A0tiistai 2. marraskuuta 2021 10.41
To:=C2= =A0Justin Uberti <juberti@alphaexplorationco.com>
Cc:=C2= =A0Christer Holmberg <christer.holmberg@ericsson.com>; Justin Ube= rti <justin@uber= ti.name>; RTCWeb IETF <rtcwe= b@ietf.org>
Subject:= =C2=A0Re: [rtcweb] Working Group Last Call for draft-uberti-rtcweb-r= fc8829bis-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. W= hat 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 t= ext from 8843bis, and simply add a note somewhere (in 8843bis and/or 8829bi= s) which describes the issue and says that the 3GPP controller needs to modify the offer accordingly.

=C2=A0

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

=C2=A0

I am not opposed to=C2=A0this idea. 3PCC typicall= y knows that the subsequent offer is going to be used as initial, and shoul= d be able to rewrite the offer to make it valid. We can change=C2=A0SIP Considerations section in 8843bis (https://www.ietf.org/archive/id/draft-ietf-mmus= ic-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

_______________________________________________ rtcweb mailing list
rtcweb@ietf.= org
https://www.ietf.org/mailman/listinfo/rtcweb=

=C2=A0

--000000000000a2489505d003af99--