Subject: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

From: Flemming Andreasen <[email-masked]>
Date: Wed, 17 Nov 2021 18:16:44 -0500

Greetings MMUSIC

We previously submitted draft-ietf-mmusic-rfc8843bis for publication, 
however subsequently, the issue of 3rd Party Call Control came up and as 
a result of that, Section 7.6 has been updated accordingly.

We are hereby starting a 1-week WGLC on Section 7.6 only in 
draft-ietf-mmusic-rfc8843bis-06.

If you have any comments on Section 7.6, please send those to the 
document authors and the MMUSIC mailing list by Wednesday November 24, 
2021. If you review it but do not have any comments, please send a note 
to that effect as well.

Thanks

-- Flemming (MMUSIC co-chair)

---

From: Roman Shpount <[email-masked]>
Date: Wed, 17 Nov 2021 21:47:20 -0500

I have reviewed this and I the changes look good.
_____________
Roman Shpount

On Wed, Nov 17, 2021 at 6:17 PM Flemming Andreasen <fandreas=
[email-masked]> wrote:

> however subsequently, the issue of 3rd Party Call Control came up and as a
> result of that, Section 7.6 has been updated accordingly.
>
> If you have any comments on Section 7.6, please send those to the document
> authors and the MMUSIC mailing list by Wednesday November 24, 2021. If you
> review it but do not have any comments, please send a note to that effect
> as well.
>
> Thanks
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 20 Nov 2021 11:37:07 -0500

Hi,

This is interesting ...

> 2021. If you review it but do not have any comments, please send a note 

This approach has a limitation:

If the new UA is unable/unwilling to bundle the media then the updated 
call will be limited to a single media stream, even if the old UA is 
willing to operate with unbundled media.

An alternative way to do this is for the 3pcc controller start the 
transfer by sending the old UA an offerless INVITE/Replaces. That will 
result in getting an initial bundle offer that should give maximum 
flexibility to the new UA.

Its possible that the old UA doesn't support INVITE/Replaces. If so, the 
3pcc controller could then fall back to the method currently in 7.6.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 20 Nov 2021 17:06:35 +0000

Hi,

The purpose of the text is not to mandate 3PCC to be implemented in a specific way. The purpose is to point out that if 3PCC is implemented in a way that the 3PCC controller receives a subsequent BUNDLE offer from an endpoint currently in a session, it needs to convert it into an initial BUNDLE offer before forwarding it to an endpoint that is currently not in a session.

Regards,

Christer

-----Original Message-----
From: mmusic <[email-masked]> On Behalf Of Paul Kyzivat
Sent: lauantai 20. marraskuuta 2021 18.37
To: [email-masked]
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Hi,

This is interesting ...

On 11/17/21 6:16 PM, Flemming Andreasen wrote:
> however subsequently, the issue of 3rd Party Call Control came up and 
> as a result of that, Section 7.6 has been updated accordingly.
> 
> 2021. If you review it but do not have any comments, please send a 
> note to that effect as well.

If the new UA is unable/unwilling to bundle the media then the updated call will be limited to a single media stream, even if the old UA is willing to operate with unbundled media.

An alternative way to do this is for the 3pcc controller start the transfer by sending the old UA an offerless INVITE/Replaces. That will result in getting an initial bundle offer that should give maximum flexibility to the new UA.

Its possible that the old UA doesn't support INVITE/Replaces. If so, the 3pcc controller could then fall back to the method currently in 7.6.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 20 Nov 2021 12:54:23 -0500

> The purpose of the text is not to mandate 3PCC to be implemented in a specific way. The purpose is to point out that if 3PCC is implemented in a way that the 3PCC controller receives a subsequent B…

OK. It would be helpful to point out that doing so may degrade the call 
- specifically it may result in no longer having a multimedia call, and 
that if this is a concern then special consideration may need to be taken.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Sun, 21 Nov 2021 00:15:00 -0500

Paul,

As a matter of background, what was observed for the current
implementations, which are mostly WebRTC based, is that endpoints either
use multiple media streams and implement bundle or use single media stream
(audio) and do not implement bundle. This skewed the bundle draft design to
optimize for these specific use cases. Furthermore, once media streams are
bundled, unbundling them will require additional resources (ports and ICE
TURN candidates), which is undesirable unless needed. This provides a
strong incentive not to unbundle media streams in most 3PCC scenarios.

The goal of the current language in the 3PCC considerations was to make
sure that the bundle-aware endpoint, which gets a new session established
via 3PCC, gets a valid initial bundle offer. This bundle would have a
bundle-only attribute set on most of the bundled m= lines, but this is
generally ok since non-bundle aware endpoints which will get it would
typically only support audio. Bundle-aware endpoints should be able to
handle such offers correctly.

As far as recovery is concerned, the 3PCC controller can detect that one
endpoint did not support bundle during the 3PCC call setup of a multimedia
session and initiate another offerless INVITE to that endpoint. The
non-bundle endpoint will generate an offer with unbundled m= lines for each
supported media type. If a bundle-aware endpoint supports such an offer, it
will re-establish the multimedia session. This being said, such scenarios
have not been seen in the wild.
_____________
Roman Shpount

On Sat, Nov 20, 2021 at 12:54 PM Paul Kyzivat <[email-masked]> wrote:

> > The purpose of the text is not to mandate 3PCC to be implemented in a
> specific way. The purpose is to point out that if 3PCC is implemented in a
> way that the 3PCC controller receives a subsequent BUNDLE offer from an
> endpoint currently in a session, it needs to convert it into an initial
> BUNDLE offer before forwarding it to an endpoint that is currently not in a
> session.
>

---

From: Justin Uberti <[email-masked]>
Date: Mon, 22 Nov 2021 11:19:00 -0800

I have reviewed the changes between -05 and -06 and have the following
comments:

1) for some reason, "offer" has been replaced with "Offer" throughout the
document. This is a minor nit, but seems incorrect to me.

2) The first two paragraphs of 7.6 say similar things and it's not clear to
me why they both exist. Here is my suggested revision:

OLD:

   In some 3rd Party Call Control (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 SDP 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 SDP Offer.

   The Session Initiation Protocol (SIP) [RFC3261
<https://datatracker.ietf.org/doc/html/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 SIP 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 SIP
   session, it will process the offer as an initial SDP Offer.

NEW:

   In some 3rd Party Call Control (3PCC) scenarios a new session will be

   established between an endpoint that is currently part of an ongoing
   session and an endpoint that is not currently part of an ongoing
   session.  In this situation the endpoint that is not part of a session

   can receive SDP with subsequent offer semantics in an initial

   SDP Offer, as described below.

The Session Initiation Protocol (SIP) [RFC3261
<https://datatracker.ietf.org/doc/html/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, and when the UAS
is a part of an ongoing SIP session, this offer will be a subsequent offer.
This offer will be received

   by the 3PCC controller (UAC) and then forwarded to another User Agent (UA).
   When that UA is not part of an ongoing SIP session, as noted above,

   it will process the offer as an initial SDP Offer.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Nov 2021 19:22:52 +0000

Hi,

>I have reviewed the changes between -05 and -06 and have the following comments:
>
>1) for some reason, "offer" has been replaced with "Offer" throughout the document. This is a minor nit, but seems incorrect to me.

I did that, because in the previous version we already used "BUNDLE Offer", so I thought I'd do it to be consistent.

>2) The first two paragraphs of 7.6 say similar things and it's not clear to me why they both exist. Here is my suggested revision:

The first paragraph is more general, while the second paragraph describes how it is realized in SIP.

Regards,

Christer

OLD:

   The Session Initiation Protocol (SIP) [RFC3261<https://datatracker.ietf.org/doc/html/rfc3261>] allows a User Agent

NEW:

The Session Initiation Protocol (SIP) [RFC3261<https://datatracker.ietf.org/doc/html/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, and when the UAS is a part of an ongoing SIP session, this offer will be a subsequent offer. This offer will be received

On Wed, Nov 17, 2021 at 3:16 PM Flemming Andreasen <fandreas=[email-masked]<mailto:[email-masked]>> wrote:
Greetings MMUSIC

We previously submitted draft-ietf-mmusic-rfc8843bis for publication, however subsequently, the issue of 3rd Party Call Control came up and as a result of that, Section 7.6 has been updated accordingly.

We are hereby starting a 1-week WGLC on Section 7.6 only in draft-ietf-mmusic-rfc8843bis-06.

If you have any comments on Section 7.6, please send those to the document authors and the MMUSIC mailing list by Wednesday November 24, 2021. If you review it but do not have any comments, please send a note to that effect as well.

Thanks

-- Flemming (MMUSIC co-chair)
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Justin Uberti <[email-masked]>
Date: Mon, 22 Nov 2021 16:37:14 -0800

On Mon, Nov 22, 2021 at 11:22 AM Christer Holmberg <
[email-masked]> wrote:

> I did that, because in the previous version we already used "BUNDLE
> Offer", so I thought I'd do it to be consistent.
>

The problem though is that "answer" still is in lowercase so that
introduces its own inconsistency. Generally I think we should avoid
capitalization of common words to avoid confusion.

>
> >2) The first two paragraphs of 7.6 say similar things and it's not clear
> to me why they both exist. Here is my suggested revision:
>
Understood, but I feel like that intent was not totally clear in the
current text.

>    The Session Initiation Protocol (SIP) [RFC3261 <https://datatracker.ietf.org/doc/html/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, and
> when the UAS is a part of an ongoing SIP session, this offer will be a
> subsequent offer. This offer will be received
>

---

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

Hi,
 
> The problem though is that "answer" still is in lowercase so that introduces its own inconsistency.

Good catch. I was actually going to change that too, but now realized I forgot to.

I have no strong opinion regarding whether we use upper- or lowercase, as long as we are consistent.

> Generally I think we should avoid capitalization of common words to avoid confusion. 

I can change everything to lowercase.

---

> Understood, but I feel like that intent was not totally clear in the current text.

I am mostly fine with your suggested modification.

However, as we don't really talk about "offer semantics" elsewhere in the document, perhaps:

"In this situation the endpoint that is not part of a session can receive an SDP offer, created as a
subsequent offer, while expecting an initial offer, as described below."

Regards,

Christer

OLD:

   The Session Initiation Protocol (SIP) [https://datatracker.ietf.org/doc/html/rfc3261] allows a User Agent

NEW:

   The Session Initiation Protocol (SIP) [https://datatracker.ietf.org/doc/html/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, and when the UAS is a part of an ongoing SIP session,
   this offer will be a subsequent offer. This offer will be received
   by the 3PCC controller (UAC) and then forwarded to another User Agent (UA).
   When that UA is not part of an ongoing SIP session, as noted above,
   it will process the offer as an initial SDP Offer.

On Wed, Nov 17, 2021 at 3:16 PM Flemming Andreasen <fandreas=mailto:[email-masked]> wrote:
Greetings MMUSIC

Thanks 

mailto:[email-masked]

---

From: Keith Drage <[email-masked]>
Date: Tue, 23 Nov 2021 14:19:35 +0000

RFC 3264 uses "offer" in lower case. Because it only talks about SDP, 
the SDP prefix is not used.

Keith

---

From: Justin Uberti <[email-masked]>
Date: Tue, 23 Nov 2021 10:29:19 -0800

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

> Hi,
>
> >>>1) for some reason, "offer" has been replaced with "Offer" throughout
> the document. This is a minor nit, but seems incorrect to me.
> >>
> introduces its own inconsistency.
>

Sounds good.

>
> ---
>
> >>>2) The first two paragraphs of 7.6 say similar things and it's not
> clear to me why they both exist. Here is my suggested revision:
> >>
That works. It might be easier to understand with the "while expecting an
initial offer" clause first:

"In this situation the endpoint that is not part of a session, while
expecting an initial offer, can receive an SDP offer created as a
subsequent offer, as described below."

But I am fine either way.

>    The Session Initiation Protocol (SIP) [
> https://datatracker.ietf.org/doc/html/rfc3261] allows a User Agent
>    The Session Initiation Protocol (SIP) [
> https://datatracker.ietf.org/doc/html/rfc3261] allows a User Agent

---

From: Roman Shpount <[email-masked]>
Date: Tue, 23 Nov 2021 13:54:26 -0500

Justin,

Part of the reason for the non-SIP language and renaming the section was to
make it clearer that it can apply to WebRTC, not just SIP. I think the goal
here is to come up with the language that can be referenced from the JSEP
draft, which should reduce your work.
_____________
Roman Shpount

On Tue, Nov 23, 2021 at 1:29 PM Justin Uberti <
[email-masked]> wrote:

>> 2021. If you review it but do not have any comments, please send a note to
>> that effect as well.
>>
>> Thanks
>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Nov 2021 11:17:25 +0000

Hi,

Maybe we instead of saying “as described below” could say ”The text below describes how this can occur with SIP”.

That way the 1st paragraph remains independent from SIP.

Regards,

Christer

From: Roman Shpount <[email-masked]>
Sent: tiistai 23. marraskuuta 2021 20.54
To: Justin Uberti <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; Flemming Andreasen <fandreas=[email-masked]>; mmusic <[email-masked]>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Justin,

Part of the reason for the non-SIP language and renaming the section was to make it clearer that it can apply to WebRTC, not just SIP. I think the goal here is to come up with the language that can be referenced from the JSEP draft, which should reduce your work.
_____________
Roman Shpount

On Tue, Nov 23, 2021 at 1:29 PM Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:

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

Sounds good.

---

That works. It might be easier to understand with the "while expecting an initial offer" clause first:

"In this situation the endpoint that is not part of a session, while expecting an initial offer, can receive an SDP offer created as a
subsequent offer, as described below."

Regards,

Christer

OLD:

NEW:

On Wed, Nov 17, 2021 at 3:16 PM Flemming Andreasen <fandreas=mailto:[email-masked]<mailto:[email-masked]>> wrote:
Greetings MMUSIC

Thanks

mailto:[email-masked]<mailto:[email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Wed, 24 Nov 2021 15:15:57 -0800

Good suggestion, that works for me.

On Wed, Nov 24, 2021 at 3:17 AM Christer Holmberg <
[email-masked]> wrote:

> *From:* Roman Shpount <[email-masked]>
> *Sent:* tiistai 23. marraskuuta 2021 20.54
> *To:* Justin Uberti <[email-masked]>
> *Cc:* Christer Holmberg <[email-masked]>; Flemming
> Andreasen <fandreas=[email-masked]>; mmusic <[email-masked]>
> *Subject:* Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations)
> in draft-ietf-mmusic-rfc8843bis-06
>
>
>
> Justin,
>
>
>
> Part of the reason for the non-SIP language and renaming the section was
> to make it clearer that it can apply to WebRTC, not just SIP. I think the
> goal here is to come up with the language that can be referenced from the
> JSEP draft, which should reduce your work.
>
> _____________
> Roman Shpount
>
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 27 Nov 2021 21:33:12 +0000

Hi,

Is everyone else ok with the changes?

Change #1:

Change ‘Offer’ and ‘Answer’ to ‘offer’ and ‘answer’ throughout the document.

Change #2:

OLD:

NEW:

   session. In this situation the endpoint that is not part of a session,

   while expecting an initial offer, can receive an SDP offer created as

   a subsequent offer. The text below describes how this can occur with

   the Session Initiation Protocol (SIP)[RFC3261<https://datatracker.ietf.org/doc/html/rfc3261>].

   SIP 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

Regards,

Christer

From: mmusic <[email-masked]> On Behalf Of Justin Uberti
Sent: torstai 25. marraskuuta 2021 1.16
To: Christer Holmberg <[email-masked]>
Cc: Flemming Andreasen <fandreas=[email-masked]>; mmusic <[email-masked]>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

On Wed, Nov 24, 2021 at 3:17 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Sent: tiistai 23. marraskuuta 2021 20.54
To: Justin Uberti <[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Flemming Andreasen <fandreas=[email-masked]<mailto:[email-masked]>>; mmusic <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Justin,

Sounds good.

---

Regards,

Christer

OLD:

NEW:

Thanks

---

From: Roman Shpount <[email-masked]>
Date: Sun, 28 Nov 2021 02:13:17 -0500

This still works for me.
_____________
Roman Shpount

On Sat, Nov 27, 2021 at 4:33 PM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

>    the Session Initiation Protocol (SIP)[RFC3261 <https://datatracker.ietf.org/doc/html/rfc3261>].
>
>
>
> *From:* mmusic <[email-masked]> *On Behalf Of *Justin Uberti
> *Sent:* torstai 25. marraskuuta 2021 1.16
> *To:* Christer Holmberg <[email-masked]>
> *Cc:* Flemming Andreasen <fandreas=[email-masked]>; mmusic <
> [email-masked]>

---

From: Justin Uberti <[email-masked]>
Date: Sun, 28 Nov 2021 18:46:45 -0500

Looks good to me too.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Nov 2021 11:57:42 -0500

Christer,

#1 seems fine to me.

For #2 I think it would be helpful to expand the new text. E.g., add:

"The 3PCC controller may want to take actions to mitigate this problem."

That at least puts it on warning while not getting into the details of 
*how* to work around the problem.

	Thanks,
	Paul

On 11/27/21 4:33 PM, Christer Holmberg wrote:
>     the Session Initiation Protocol (SIP)[RFC3261 
> <https://datatracker.ietf.org/doc/html/rfc3261>].
> 
> *From:*mmusic <[email-masked]> *On Behalf Of *Justin Uberti
> *Cc:* Flemming Andreasen <fandreas=[email-masked]>; mmusic 
> <[email-masked]>
> On Wed, Nov 24, 2021 at 3:17 AM Christer Holmberg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     Hi,
> 
>     Maybe we instead of saying “as described below” could say ”The text
>     below describes how this can occur with SIP”.
> 
>     That way the 1^st paragraph remains independent from SIP.
> 
>     Regards,
> 
>     Christer
> 
>     *From:*Roman Shpount <[email-masked] <mailto:[email-masked]>>
>     *To:* Justin Uberti <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Christer Holmberg <[email-masked]
>     <mailto:[email-masked]>>; Flemming Andreasen
>     <fandreas=[email-masked]
>     <mailto:[email-masked]>>; mmusic <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject:* Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC
>     Considerations) in draft-ietf-mmusic-rfc8843bis-06
> 
>     Justin,
> 
>     Part of the reason for the non-SIP language and renaming the
>     section was to make it clearer that it can apply to WebRTC, not just
>     SIP. I think the goal here is to come up with the language that can
>     be referenced from the JSEP draft, which should reduce your work.
> 
>     _____________
>     Roman Shpount
> 
>     On Tue, Nov 23, 2021 at 1:29 PM Justin Uberti
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         On Tue, Nov 23, 2021 at 2:00 AM Christer Holmberg
>         <[email-masked]
>         <mailto:[email-masked]>> wrote:
> 
>             Hi,
> 
>             "In this situation the endpoint that is not part of a
>             session can receive an SDP offer, created as a
>         That works. It might be easier to understand with the "while
>         expecting an initial offer" clause first:
> 
>         "In this situation the endpoint that is not part of a session,
>         while expecting an initial offer, can receive an SDP offer
>         created as a
> 
>                 The Session Initiation Protocol (SIP)
>             [https://datatracker.ietf.org/doc/html/rfc3261
>                 The Session Initiation Protocol (SIP)
>             [https://datatracker.ietf.org/doc/html/rfc3261
>             On Wed, Nov 17, 2021 at 3:16 PM Flemming Andreasen
>             <fandreas=mailto:[email-masked]
>             <mailto:[email-masked]>> wrote:
>             Greetings MMUSIC
> 
>             We previously submitted draft-ietf-mmusic-rfc8843bis for
>             publication, however subsequently, the issue of 3rd Party
>             Call Control came up and as a result of that, Section 7.6
>             has been updated accordingly.
> 
>             If you have any comments on Section 7.6, please send those
>             to the document authors and the MMUSIC mailing list by
>             Wednesday November 24, 2021. If you review it but do not
>             have any comments, please send a note to that effect as well.
> 
>             Thanks
> 
>             mailto:[email-masked] <mailto:[email-masked]>
>             <https://www.ietf.org/mailman/listinfo/mmusic>
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/mmusic>
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Nov 2021 16:58:16 +0000

Chairs,

Can I submit a new version of the document, with the changes suggested below?

Regards,

Christer
________________________________
From: Justin Uberti <[email-masked]>
Sent: Monday, November 29, 2021 1:46 AM
To: Roman Shpount <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; Flemming Andreasen <[email-masked]>; mmusic <[email-masked]>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Looks good to me too.

On Sun, Nov 28, 2021 at 2:13 AM Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
This still works for me.
_____________
Roman Shpount

On Sat, Nov 27, 2021 at 4:33 PM Christer Holmberg <christer.holmberg=[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Change #1:

Change #2:

OLD:

NEW:

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> On Behalf Of Justin Uberti
Sent: torstai 25. marraskuuta 2021 1.16
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: Flemming Andreasen <fandreas=[email-masked]<mailto:[email-masked]>>; mmusic <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Hi,

Regards,

Christer

Justin,

_____________
Roman Shpount

Hi,

Sounds good.

---

Regards,

Christer

OLD:

NEW:

Thanks

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Nov 2021 16:59:18 +0000

Hi Paul,

For #2, exactly where would you like to put that sentence?

Regards,

Christer

________________________________
From: mmusic <[email-masked]> on behalf of Paul Kyzivat <[email-masked]>
Sent: Monday, November 29, 2021 6:57 PM
To: [email-masked] <[email-masked]>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Christer,

#1 seems fine to me.

        Thanks,
        Paul

---

From: Roman Shpount <[email-masked]>
Date: Mon, 29 Nov 2021 12:14:09 -0500

Paul,

There is already the following language there:

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 BUNDLE Offer as
an initial BUNDLE offer.  Therefore, the  3PCC controller SHOULD rewrite
the subsequent BUNDLE Offer into a valid initial BUNDLE Offer, following
the procedures in Section 7.2, before it forwards the BUNDLE Offer to a
UA.  In the rewritten BUNDLE 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.
_____________
Roman Shpount

On Mon, Nov 29, 2021 at 11:59 AM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> ------------------------------
> *From:* mmusic <[email-masked]> on behalf of Paul Kyzivat <
> [email-masked]>
> *Sent:* Monday, November 29, 2021 6:57 PM
> *To:* [email-masked] <[email-masked]>
> > <[email-masked] <mailto:[email-masked]
> <[email-masked]>>>
> > wrote:
> >
> >     Hi,
> >
> >     *From:*Roman Shpount <[email-masked] <mailto:[email-masked]
> <[email-masked]>>>
> >     <mailto:[email-masked]
> <[email-masked]>>>
> >     <mailto:[email-masked]
> <[email-masked]>>>; Flemming Andreasen
> >     <mailto:[email-masked] <[email-masked]>>>;
> mmusic <[email-masked]
> >     <mailto:[email-masked] <[email-masked]>>>
> >     <mailto:[email-masked]
> <[email-masked]>>> wrote:
> >
> >         <mailto:[email-masked]
> <[email-masked]>>> wrote:
> >
> >             Hi,
> >
> >             >>>1) for some reason, "offer" has been replaced with
> "Offer" throughout the document. This is a minor nit, but seems incorrect
> to me.
> >             >>
> >             >> I did that, because in the previous version we already
> used "BUNDLE Offer", so I thought I'd do it to be consistent.
> >             >
> >             > The problem though is that "answer" still is in lowercase
> so that introduces its own inconsistency.
> >
> >             >>>2) The first two paragraphs of 7.6 say similar things and
> it's not clear to me why they both exist. Here is my suggested revision:
> >             >>
> >             >> The first paragraph is more general, while the second
> paragraph describes how it is realized in SIP.
> >             >
> >             <mailto:[email-masked]
> <[email-masked]>>> wrote:
> >             Greetings MMUSIC
> >
> >             mailto:[email-masked] <[email-masked]> <
> mailto:[email-masked] <[email-masked]>>
> >         [email-masked] <mailto:[email-masked] <[email-masked]>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Nov 2021 12:47:22 -0500

Christer,

> For #2, exactly where would you like to put that sentence?

My thought was that it could go right at the end of the new text for #2. 
But I defer to you as editor to perfect the text.

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> ------------------------------------------------------------------------
> *From:* mmusic <[email-masked]> on behalf of Paul Kyzivat 
> <[email-masked]>
>> <https://datatracker.ietf.org/doc/html/rfc3261 
> <https://datatracker.ietf.org/doc/html/rfc3261>>] allows a User Agent
>> 
>> <https://datatracker.ietf.org/doc/html/rfc3261 
> <https://datatracker.ietf.org/doc/html/rfc3261>>].
>> 
> <mailto:[email-masked]>>>
>> wrote:
>> 
>>     Hi,
>> 
>>     *From:*Roman Shpount <[email-masked] <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked]>>>
> <mailto:[email-masked]>>>; Flemming Andreasen
>>     <mailto:[email-masked] <mailto:[email-masked]>>>; 
> mmusic <[email-masked]
>>     <mailto:[email-masked] <mailto:[email-masked]>>>
> <mailto:[email-masked]>>> wrote:
>> 
> <mailto:[email-masked]>>> wrote:
>> 
>>             Hi,
>> 
>>             >>>1) for some reason, "offer" has been replaced with "Offer" throughout the document. This is a minor nit, but seems incorrect to me.
>>             >>
>>             >> I did that, because in the previous version we already used "BUNDLE Offer", so I thought I'd do it to be consistent.
>>             >
>>             > The problem though is that "answer" still is in lowercase so that introduces its own inconsistency.
>> 
>>             > Generally I think we should avoid capitalization of common words to avoid confusion.
>> 
>>             >>>2) The first two paragraphs of 7.6 say similar things and it's not clear to me why they both exist. Here is my suggested revision:
>>             >>
>>             >> The first paragraph is more general, while the second paragraph describes how it is realized in SIP.
>>             >
>>             > Understood, but I feel like that intent was not totally clear in the current text.
>> 
>>             <https://datatracker.ietf.org/doc/html/rfc3261 
> <https://datatracker.ietf.org/doc/html/rfc3261>>] allows a
>>             User Agent
>>             <https://datatracker.ietf.org/doc/html/rfc3261 
> <https://datatracker.ietf.org/doc/html/rfc3261>>] allows a
>>             User Agent
>>             <mailto:[email-masked] <mailto:[email-masked]>>> 
> wrote:
>>             Greetings MMUSIC
>> 
>>             mailto:[email-masked] <mailto:[email-masked]> <mailto:[email-masked] 
>>             <https://www.ietf.org/mailman/listinfo/mmusic 
> <https://www.ietf.org/mailman/listinfo/mmusic>>
>> 
>>         [email-masked] <mailto:[email-masked] <mailto:[email-masked]>>
>>         <https://www.ietf.org/mailman/listinfo/mmusic 
> <https://www.ietf.org/mailman/listinfo/mmusic>>
>> 
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Nov 2021 13:07:16 -0500

Roman,

On 11/29/21 12:14 PM, Roman Shpount wrote:
> 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 
> BUNDLE Offer as an initial BUNDLE offer.  Therefore, the  3PCC 
> controller SHOULD rewrite the subsequent BUNDLE Offer into a valid 
> initial BUNDLE Offer, following the procedures in Section 7.2, before it 
> forwards the BUNDLE Offer to a UA.  In the rewritten BUNDLE 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.

OK. Shame on me for responding to Christer's proposed new text without 
reviewing it in the context it falls within.

You are right that the paragraph you mention here, which immediately 
follows the revised text for #2, does address the need to mitigate the 

> Its possible that the old UA doesn't support INVITE/Replaces. If so, the 3pcc controller could then fall back to the method currently in 7.6.

Subsequent discussion of that comment led me to conclude that getting 
into the weeds of *how* to mitigate the problem may be unwise.

So perhaps my more recent can replace part of this last paragraph. 
Specifically, replace:

OLD

    ... Therefore, the
    3PCC controller SHOULD rewrite the subsequent BUNDLE Offer into a
    valid initial BUNDLE Offer, following the procedures in Section 7.2,
    before it forwards the BUNDLE Offer to a UA.  In the rewritten BUNDLE
    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.

NEW

    The 3PCC controller SHOULD take actions to mitigate this problem.

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 29 Nov 2021 13:13:00 -0500

> Can I submit a new version of the document, with the changes suggested 

Please do. Also, did Paul Kyzivat's comments get resolved / updated ?

Thanks

-- Flemming
> *From:* Justin Uberti <[email-masked]>
> *Sent:* Monday, November 29, 2021 1:46 AM
> *To:* Roman Shpount <[email-masked]>
> Andreasen <[email-masked]>; mmusic <[email-masked]>
>     On Sat, Nov 27, 2021 at 4:33 PM Christer Holmberg
>     <christer.holmberg=[email-masked]> wrote:
>
>         Hi,
>
>         created as
>         *Cc:* Flemming Andreasen
>         <fandreas=[email-masked]>; mmusic <[email-masked]>
>             Maybe we instead of saying “as described below” could say
>             ”The text below describes how this can occur with SIP”.
>
>             <mailto:[email-masked]>>; Flemming
>             Andreasen <fandreas=[email-masked]
>             <mailto:[email-masked]>>; mmusic
>             <[email-masked] <mailto:[email-masked]>>
>             Part of the reason for the non-SIP language and renaming
>             the section was to make it clearer that it can apply to
>             WebRTC, not just SIP. I think the goal here is to come up
>             with the language that can be referenced from the JSEP
>                     >>>1) for some reason, "offer" has been replaced
>                     with "Offer" throughout the document. This is a
>                     minor nit, but seems incorrect to me.
>                     >>
>                     >> I did that, because in the previous version we
>                     already used "BUNDLE Offer", so I thought I'd do
>                     it to be consistent.
>                     >
>                     > The problem though is that "answer" still is in
>                     lowercase so that introduces its own inconsistency.
>
>                     I have no strong opinion regarding whether we use
>                     upper- or lowercase, as long as we are consistent.
>
>                     >>>2) The first two paragraphs of 7.6 say similar
>                     things and it's not clear to me why they both
>                     exist. Here is my suggested revision:
>                     >>
>                     >> The first paragraph is more general, while the
>                     second paragraph describes how it is realized in SIP.
>                     >
>                     However, as we don't really talk about "offer
>                     semantics" elsewhere in the document, perhaps:
>
>                     "In this situation the endpoint that is not part
>                     of a session can receive an SDP offer, created as a
>                 That works. It might be easier to understand with the
>                 "while expecting an initial offer" clause first:
>
>                 session, while expecting an initial offer, can receive
>                 an SDP offer created as a
>
>                     We previously submitted
>                     draft-ietf-mmusic-rfc8843bis for publication,
>                     however subsequently, the issue of 3rd Party Call
>                     Control came up and as a result of that, Section
>                     7.6 has been updated accordingly.
>
>                     We are hereby starting a 1-week WGLC on Section
>                     7.6 only in draft-ietf-mmusic-rfc8843bis-06.
>
>                     If you have any comments on Section 7.6, please
>                     send those to the document authors and the MMUSIC
>                     mailing list by Wednesday November 24, 2021. If
>                     you review it but do not have any comments, please
>                     send a note to that effect as well.
>
>                     Thanks
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Nov 2021 19:00:05 +0000

Hi Paul,

Since the issue is introduced by BUNDLE, I think we should say more than simply "the 3PCC has to do something".

I am fine to change the current procedure from a SHOULD to an example, but I do think we should include some guidance.

For example:

"Therefore, the 3PCC controller needs to take actions to mitigate this problem, e.g., by rewriting the subsequent BUNDLE offer
into a valid initial BUNDLE offer (Section 7.2), before it forwards the BUNDLE offer to a UA."

(I have no strong opinion on whether we use "3GPP controller needs to" or "3GPP controller SHOULD".)

Regards,

Christer

Sent: Monday, November 29, 2021 8:07 PM

Roman,

OLD

    ... Therefore, the

NEW

        Thanks,
        Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 30 Nov 2021 00:03:20 -0500

Christer,

I think as far as specification goes, "needs to" still means some action is
required, but using SHOULD makes it more apparent.

I also like keeping the proposed text as an example of what needs to be
done, especially since this is exactly what is required in all the current
use cases.
_____________
Roman Shpount

On Mon, Nov 29, 2021 at 2:00 PM Christer Holmberg <christer.holmberg=
[email-masked]> wrote:

> I am fine to change the current procedure from a SHOULD to an example, but
> I do think we should include some guidance.
>
> For example:
>
> "Therefore, the 3PCC controller needs to take actions to mitigate this
> problem, e.g., by rewriting the subsequent BUNDLE offer
> *Sent:* Monday, November 29, 2021 8:07 PM

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 30 Nov 2021 08:43:16 +0000

Hi,

As an individual, keeping the proposed text is my preference too.

As we know this is how 3PCC controllers will have to act, I see no reason why we should spend time arguing about it. The SHOULD does give the 3PCC controller the possibility to also do something else, in case it has a good reason for doing so.

Regards,

Christer
________________________________
From: Roman Shpount <[email-masked]>
Sent: Tuesday, November 30, 2021 7:03 AM
To: Christer Holmberg <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Christer,

I think as far as specification goes, "needs to" still means some action is required, but using SHOULD makes it more apparent.

I also like keeping the proposed text as an example of what needs to be done, especially since this is exactly what is required in all the current use cases.
_____________
Roman Shpount

On Mon, Nov 29, 2021 at 2:00 PM Christer Holmberg <christer.holmberg=[email-masked]<mailto:[email-masked]>> wrote:
Hi Paul,

For example:

Regards,

Christer

________________________________
From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Paul Kyzivat <[email-masked]<mailto:[email-masked]>>
Sent: Monday, November 29, 2021 8:07 PM
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations) in draft-ietf-mmusic-rfc8843bis-06

Roman,

OLD

    ... Therefore, the

NEW

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Nov 2021 11:24:18 -0500

Christer,

On 11/29/21 2:00 PM, Christer Holmberg wrote:
> I am fine to change the current procedure from a SHOULD to an example, 
> but I do think we should include some guidance.
> 
> For example:
> 

That works for me. My problem with the earlier text was that it 
described *a* solution as if it was *the* solution that would solve the 
problem, when there are potential problems it doesn't solve.

Changing it to be one example improves it.

There could be a longer discussion about what kinds of things could go 
wrong and how to mitigate each. But that may be overkill.

	Thanks,
	Paul