Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-rfc8843bis-00

From: Flemming Andreasen <[email-masked]>
Date: Wed, 2 Jun 2021 16:30:28 -0400

The WGLC has now completed.

We only saw 2 reviews, both of which were in favor of the current document.

If you reviewed the document but did not have any comments on it, please 
send a note to that effect to the mailing list.

Thanks

-- Flemming

On 5/18/21 2:09 PM, Flemming Andreasen wrote:
> Greetings MMUSIC
>
> This is to announce a 2 week WGLC on the draft:
>
> https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-00.txt
>
> as Proposed Standard. Please note that changes in the document are 
> limited to what was agreed to at IET110 for JSEP alignment plus any 
> verified erratas. Please review and provide any comments you may have 
> on the document by Tuesday, June 1, 2021. Comments should be sent to 
> the document authors and the MMUSIC WG list. If you review the 
> document 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]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 3 Jun 2021 13:54:14 -0400

Flemming asked me to review this doc...

Its unfortunate that the misalignment between RFC8843 and RFC8829 
occurred, requiring a bis so soon. And I'm not particularly happy with 
the choice to prefer the mechanism in RFC8829 over that in RFC8843, 
since I think the mechanism chosen in RFC8843 was well reasoned. 
However, I did follow the discussions and understand the pragmatics that 
drove this choice. So I am going to take that as a given.

Now to other comments:

First, I have a general question about the overall goals of this bis. 
Superficially it is to eliminate the inconsistencies with RFC8829. But 
why? ISTM that the ultimate goal is to maximize the possibility of 
interoperation between webrtc and other SDP-based sessions such as SIP. 
If that is the true goal, maybe other things ought to be included in 
this bis. Notably, RFC8829 has a multitude of constraints on things that 
are included in bundled "m=" sections. For instance, section 5.2.1 of 
rfc8829 says:

    Bundle-only "m=" sections MUST NOT contain any ICE
    credentials and MUST NOT gather any candidates.

Should that constraint be included in the bis? It would be harmless to 
do so since it only affects syntax, not semantics. There are many 
similar constraints.

OTOH, RFC8829 also contains a lot of restrictions forbidding usage that 
is valid in RFC8843. Those constraints might make sense in the webrtc 
context but not so much for general use of bundle non-webrtc 
environments. Implementations should be free to use features that can't 
interoperate with webrtc. So importing those into this bis would IMO be 
an overreach.

It isn't my place to decide what is right here. But ISTM this ought to 
be discussed by the WG.

Other things:

* Section 1.4 says:

    In addition, this document implements the following erratas: 6431,
    6437

AFAICT errata 6437 was already corrected in RFC8843, which is odd since 
it was reported against it. The fix was a change in section reference 
from 4.2.2 to 4.2.6. But RFC8843 does reference 4.2.6, not 4.2.2, and 
the bis is unchanged in this regard. So perhaps mention of this errata 
should be dropped.

* Notes at the end of sections 7.3 and 7.4 discuss interoperation if 
implementions of the bis with those of RFC8843. It would be good to 
include an example of this. (For the benefit of those who implement from 
the examples!)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Jun 2021 21:11:29 +0000

Hi Paul,

Thanks for the review! Please see inline.

>Its unfortunate that the misalignment between RFC8843 and RFC8829 occurred, requiring a bis so soon. And I'm not particularly happy with the choice to prefer the
>mechanism in RFC8829 over that in RFC8843, since I think the mechanism chosen in RFC8843 was well reasoned. 
>However, I did follow the discussions and understand the pragmatics that drove this choice. So I am going to take that as a given.
>
>Now to other comments:
>
>Superficially it is to eliminate the inconsistencies with RFC8829. But why? ISTM that the ultimate goal is to maximize the possibility of interoperation between webrtc and other SDP-based sessions such as SIP. 
>If that is the true goal, maybe other things ought to be included in this bis. Notably, RFC8829 has a multitude of constraints on things that are included in bundled "m=" sections. For instance, section 5.2.1 of
>rfc8829 says:
>
>Should that constraint be included in the bis? It would be harmless to do so since it only affects syntax, not semantics. There are many similar constraints.

It is covered in Section 10:

     "the offerer includes ICE-related media-level attributes in each bundled "m=" section (excluding any bundle-only "m=" sections)"

>OTOH, RFC8829 also contains a lot of restrictions forbidding usage that is valid in RFC8843. Those constraints might make sense in the webrtc context but not so much for general use of
>bundle non-webrtc environments. Implementations should be free to use features that can't interoperate with webrtc. So importing those into this bis would IMO be an overreach.

I am not sure I understand. What has been imported?

As you said, eventhough something may be optionally allowed by BUNDLE, webrtc can define constraints. 

We DID have a look whether there were other misalignments, but we could not find any, so if there is something one has to point to it.

----

> AFAICT errata 6437 was already corrected in RFC8843, which is odd since it was reported against it. The fix was a change in section reference from 4.2.2 to 4.2.6. But RFC8843
>does reference 4.2.6, not 4.2.2, and the bis is unchanged in this regard. So perhaps mention of this errata should be dropped.

Both 8843 and 8843bis does reference 4.2.2, i.e., there has been no change. I think you are looking at the wrong bullet in Section 9.2 :)

But, I guess this means that the change shall be implemented in 8843bis.

---

>* Notes at the end of sections 7.3 and 7.4 discuss interoperation if implementions of the bis with those of RFC8843. It would be good to include an example of this. (For the benefit of those who implement from the examples!)

You want to include examples of the examples from RFC8843?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 17 Jun 2021 16:40:50 -0400

Hi Christer,

I have reviewed the document and document changes look good in removing the
inconsistencies with JSEP.

One question that I do have is related to third-party call control and
generating offers in response to INVITE with no SDP body. This is not
covered anywhere in this document. In order to work correctly thes offers
should be constructed the same ways as initial offers with separate
addresses and ports allocated for all m= lines which are not bundle-only
and port zero and bundle-only attribute set on all the bundle-only m= lines.

Best Regards,
_____________
Roman Shpount

On Tue, May 18, 2021 at 2:09 PM Flemming Andreasen <fandreas=
[email-masked]> wrote:

> as Proposed Standard. Please note that changes in the document are limited
> to what was agreed to at IET110 for JSEP alignment plus any verified
> erratas. Please review and provide any comments you may have on the
> document by Tuesday, June 1, 2021. Comments should be sent to the document
> authors and the MMUSIC WG list. If you review the document but do not have
> any comments, please send a note to that effect as well.
>
> Thanks
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Jun 2021 06:52:13 +0000

Hi Roman,

Regarding offers for 3PPC, I think sending an initial offer needs to be a generic O/A rule. I don’t think we can have SDP extension-specific rules.

Regards,

Christer

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: Roman Shpount <[email-masked]>
Sent: Thursday, June 17, 2021 11:40:50 PM
To: Flemming Andreasen <fandreas=[email-masked]>; Christer Holmberg <[email-masked]>
Cc: mmusic <[email-masked]>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-rfc8843bis-00

Hi Christer,

I have reviewed the document and document changes look good in removing the inconsistencies with JSEP.

One question that I do have is related to third-party call control and generating offers in response to INVITE with no SDP body. This is not covered anywhere in this document. In order to work correctly thes offers should be constructed the same ways as initial offers with separate addresses and ports allocated for all m= lines which are not bundle-only and port zero and bundle-only attribute set on all the bundle-only m= lines.

Best Regards,
_____________
Roman Shpount

On Tue, May 18, 2021 at 2:09 PM Flemming Andreasen <fandreas=[email-masked]<mailto:[email-masked]>> wrote:
Greetings MMUSIC

as Proposed Standard. Please note that changes in the document are limited to what was agreed to at IET110 for JSEP alignment plus any verified erratas. Please review and provide any comments you may have on the document by Tuesday, June 1, 2021. Comments should be sent to the document authors and the MMUSIC WG list. If you review the document 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: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jun 2021 12:17:16 -0400

On 6/18/21 2:52 AM, Christer Holmberg wrote:
> Hi Roman,
> 
> Regarding offers for 3PPC, I think sending an initial offer needs to be 
> a generic O/A rule. I don’t think we can have SDP extension-specific rules.

I agree this *ought* to be a generic recommendation. But I don't think 
it is. So I think it would be helpful to say it in this document.

Note that this would be a recommendation (MAY). It can't really be 
mandatory, since for an initial offer the offerer has almost complete 
discretion.

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> Get Outlook for iOS <https://aka.ms/o0ukef>
> ------------------------------------------------------------------------
> *From:* Roman Shpount <[email-masked]>
> *Sent:* Thursday, June 17, 2021 11:40:50 PM
> *To:* Flemming Andreasen <fandreas=[email-masked]>; Christer 
> Holmberg <[email-masked]>
> *Cc:* mmusic <[email-masked]>
> *Subject:* Re: [MMUSIC] WGLC on draft-ietf-mmusic-rfc8843bis-00
> Hi Christer,
> 
> covered anywhere in this document. In order to work correctly thes 
> offers should be constructed the same ways as initial offers with 
> separate addresses and ports allocated for all m= lines which are not 
> bundle-only and port zero and bundle-only attribute set on all the 
> bundle-only m= lines.
> 
> Best Regards,
> _____________
> Roman Shpount
> 
> 
> On Tue, May 18, 2021 at 2:09 PM Flemming Andreasen 
> <fandreas=[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Greetings MMUSIC
> 
>     <https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-00.txt>
> 
>     verified erratas. Please review and provide any comments you may
>     have on the document by Tuesday, June 1, 2021. Comments should be
>     sent to the document authors and the MMUSIC WG list. If you review
>     the document but do not have any comments, please send a note to
>     that effect as well.
> 
>     Thanks
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/mmusic>
> 
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 18 Jun 2021 12:28:00 -0400

I was looking for some sort of language or note similar to
https://datatracker.ietf.org/doc/html/rfc8839#section-7.5. This note should
say that when the endpoint receives a mid-dialog re-INVITE that contains no
offer, it MUST use the rules for generating the initial SDP offers (
https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-02.html#section-7.2).
In some sense, we are preserving RFC8843 behavior for subsequent offers if
these offers are generated due to a mid-dialog re-INVITE that contains no
offer.

Best Regards,
_____________
Roman Shpount

On Fri, Jun 18, 2021 at 12:17 PM Paul Kyzivat <[email-masked]>
wrote:

> >     <https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-00.txt
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jun 2021 13:07:01 -0400

On 6/18/21 12:28 PM, Roman Shpount wrote:
> https://datatracker.ietf.org/doc/html/rfc8839#section-7.5 
> <https://datatracker.ietf.org/doc/html/rfc8839#section-7.5>. This note 
> should say that when the endpoint receives a mid-dialog re-INVITE that 
> contains no offer, it MUST use the rules for generating the initial SDP 
> offers 

It isn't quite that simple. There are additional rules for mid-dialog 
offers. In particular payload types may not be recycled for use with a 
different codec configuration than it was previously used for. I think 
there are other limitations along the same vein.

There could be something with a similar spirit.

	Thanks,
	Paul

> (https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-02.html#section-7.2 
> <https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-02.html#section-7.2>). 
> In some sense, we are preserving RFC8843 behavior for subsequent offers 
> if these offers are generated due to a mid-dialog re-INVITE that 
> contains no offer.
> 
> Best Regards,
> _____________
> Roman Shpount
> 
> 
> On Fri, Jun 18, 2021 at 12:17 PM Paul Kyzivat <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      > Get Outlook for iOS <https://aka.ms/o0ukef <https://aka.ms/o0ukef>>
>      >
>      > *From:* Roman Shpount <[email-masked] <mailto:[email-masked]>>
>      > *To:* Flemming Andreasen <fandreas=[email-masked]
>     <mailto:[email-masked]>>; Christer
>      > Holmberg <[email-masked]
>     <mailto:[email-masked]>>
>      > *Cc:* mmusic <[email-masked] <mailto:[email-masked]>>
>      > I have reviewed the document and document changes look good in
>     removing
>      > the inconsistencies with JSEP.
>      >
>     <mailto:[email-masked]>
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >     Greetings MMUSIC
>      >
>       <https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-00.txt <https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-00.txt>>
>      >
>      > [email-masked] <mailto:[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: Fri, 18 Jun 2021 13:06:46 -0400

Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Fri, 18 Jun 2021 13:14:50 -0400

Let me be more specific -- I meant rules defined for initial SDP offer in
https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-02.html#section-7.2,
not all rules for initial SDP offers. Specifically, all m= lines should
either have a different address:port for each bundled m= line and be
prepared to receive media on these addresses or should have port 0 and
a=bundle-only
_____________
Roman Shpount

On Fri, Jun 18, 2021 at 1:07 PM Paul Kyzivat <[email-masked]>
wrote:

> > (
> https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-02.html#section-7.2
> > <
> https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-02.html#section-7.2>).
>
> >      > Get Outlook for iOS <https://aka.ms/o0ukef <https://aka.ms/o0ukef
> >>
> >      >
> >
> >       <
> https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-00.txt <
> https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-00.txt>>
> >      >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Jun 2021 13:49:18 -0400

On 6/18/21 1:14 PM, Roman Shpount wrote:
> <https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-02.html#section-7.2>, 

Ahh. OK.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Jun 2021 17:12:51 +0000

Hi,

I think it is important to keep in mind that the scope of 8843bis was only to fix the BUNDLE/JSEP alignment, and to implement some of the erratas.

Having said that, unless someone objects I am fine adding something like:

---

7.6. SIP Considerations

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 as an Initial SDP Offer [Section7.2].

---

Regards,

Christer

-----Original Message-----
From: mmusic <[email-masked]> On Behalf Of Paul Kyzivat
Sent: perjantai 18. kesäkuuta 2021 20.49
To: Roman Shpount <[email-masked]>
Cc: mmusic WG <[email-masked]>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-rfc8843bis-00

On 6/18/21 1:14 PM, Roman Shpount wrote:
> <https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-02.html#
> section-7.2>, not all rules for initial SDP offers. Specifically, all 
> m= lines should either have a different address:port for each bundled 
> m= line and be prepared to receive media on these addresses or should 
> have port 0 and a=bundle-only

Ahh. OK.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 22 Jun 2021 13:47:41 -0400

Hi Christer,

I think this change is in scope since the problem with 3PCC was introduced
by the changes you just made. Before the JSEP alignment fix, subsequent
offers would have port 0 in the m= line and a=bundle-only on all the
bundled m= lines. This would make it a valid initial offer for 3PCC. With
the new changes,  bundled m= lines will have the address and port reused,
which is not a valid initial offer.

I am generally ok with the text but based on the confusion that the term
"Initial SDP Offer" caused Paul, I would suggest omitting it and changing
the text to:

7.6. SIP Considerations

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 procedures defined in
[Section7.2].

Best Regards,
_____________
Roman Shpount

On Tue, Jun 22, 2021 at 1:12 PM Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> I think it is important to keep in mind that the scope of 8843bis was only
> to fix the BUNDLE/JSEP alignment, and to implement some of the erratas.
>
> 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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Jun 2021 20:38:55 +0000

Hi,

>I think this change is in scope since the problem with 3PCC was introduced by the changes you just made. Before the JSEP alignment fix, subsequent offers would have port 0 in the
>m= line and a=bundle-only on all the bundled m= lines. This would make it a valid initial offer for 3PCC. With the new changes,  bundled m= lines will have the address and port reused, which is not a valid initial offer.

Fair enough.

>I am generally ok with the text but based on the confusion that the term "Initial SDP Offer" caused Paul, I would suggest omitting it and changing the text to:
>
>7.6. SIP Considerations
>
>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 procedures defined in [Section7.2].

I’d be fine with that.

Regards,

Christer

On Tue, Jun 22, 2021 at 1:12 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

---

7.6. SIP Considerations

---

Regards,

Christer

-----Original Message-----
From: mmusic <[email-masked]<mailto:[email-masked]>> On Behalf Of Paul Kyzivat
Sent: perjantai 18. kesäkuuta 2021 20.49
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: mmusic WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] WGLC on draft-ietf-mmusic-rfc8843bis-00

On 6/18/21 1:14 PM, Roman Shpount wrote:
> <https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-02.html#<https://www.ietf.org/archive/id/draft-ietf-mmusic-rfc8843bis-02.html>

Ahh. OK.

        Thanks,
        Paul