Subject: [MMUSIC] Draft new version: 8843bis-02

From: Christer Holmberg <[email-masked]>
Date: Mon, 7 Jun 2021 20:17:18 +0000

Hi,

I have submitted a new version (-02) of 8843bis.

Based on Paul's comment, the latest version contains two new sub-sections, 7.3.5 and 7.4.1, that in addition to describing the differences from 8843 also include examples showing the differences.

Unless I have missed something, all WGLC comments should now have been addressed.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 10 Jun 2021 09:51:01 +0000

Paul, are you happy with the way your comments have been addressed?

Regards,

Christer

From: mmusic <[email-masked]> On Behalf Of Christer Holmberg
Sent: maanantai 7. kesäkuuta 2021 23.17
To: [email-masked]
Cc: [email-masked]
Subject: [MMUSIC] Draft new version: 8843bis-02

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jun 2021 10:09:52 -0400

Christer,

> Paul, are you happy with the way your comments have been addressed?

I have one remaining question:

The new section 7.3.5 is addressing the case where the offerer only 
support RFC8843 while the answerer supports 8842bis. In this case, what 
sort of answer should the answerer generate? Should it emulate RFC8843 
behavior? Do we understand what the impact will be if not?

	Thanks,
	Paul

> Regards,
> 
> Christer
> 
> *From:*mmusic <[email-masked]> *On Behalf Of *Christer Holmberg
> *Sent:* maanantai 7. kesäkuuta 2021 23.17
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [MMUSIC] Draft new version: 8843bis-02
> 
> Hi,
> 
> Based on Paul’s comment, the latest version contains two new 
> sub-sections, 7.3.5 and 7.4.1, that in addition to describing the 
> differences from 8843 also include examples showing the differences.
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 10 Jun 2021 14:29:31 +0000

Hi,

>The new section 7.3.5 is addressing the case where the offerer only support RFC8843 while the answerer supports 8842bis. In this case, what sort of answer should the answerer generate?
>Should it emulate RFC8843 behavior? Do we understand what the impact will be if not?

That is a good question.

Because, if we say that the endpoint shall generate an answer according to 8843, what about when the same endpoint later wants to generate a new offer itself? Should it then generate the offer according to 8843? I think we could easily go down a slippery slope, and eventually 8843bis endpoints would also have to fully implement 8843. I don't think we want that.

Having said that, we probably do need to say something about what "accept such offer" really means when it comes to generating the answer. My suggestion would be to say that the answer SHOULD be generated according to 8843bis. 

Nothing prevents 8843bis endpoints to fully implement 8843 if they want to, but I don't think we should specify such behavior.

Regards,

Christer

> Based on Paul's comment, the latest version contains two new

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jun 2021 11:02:59 -0400

Christer,

> Having said that, we probably do need to say something about what "accept such offer" really means when it comes to generating the answer. My suggestion would be to say that the answer SHOULD be ge…

I don't have an answer here. But it would be helpful for those impacted 
one way or the other to comment.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 10 Jun 2021 15:45:55 +0000

Hi,

>> Because, if we say that the endpoint shall generate an answer according to 8843, what about when the same endpoint later wants to generate a new offer itself? Should it then generate
>> the offer according to 8843? I think we could easily go down a slippery slope, and eventually 8843bis endpoints would also have to fully implement 8843. I don't think we want that.
>> 
> I don't have an answer here. But it would be helpful for those impacted one way or the other to comment.

The ones impacted DID comment when we discussed what way to go, and the draft reflects the outcome.  There was never an agreement (or even suggested, AFAIR) that an 8843bis endpoint would also have to implement 8843 functionality, in order to backward compatible. The only requirement was to be backward compatible with non-BUNDLE endpoints (e.g., not include identical port numbers in the initial offer). This was also the reason we wanted to get the alignment published as far as possible, in order to minimize the backward compatibility issues.

So, if people think this causes confusion, perhaps we should just remove the "8843 Consideration" sections and leave it up to implementers to fix things, if needed.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Jun 2021 15:39:42 -0400

> So, if people think this causes confusion, perhaps we should just remove the "8843 Consideration" sections and leave it up to implementers to fix things, if needed.

I agree that these changes don't seem to have improved clarity.

Maybe it would be worth mentioning that the changes in this bis may 
break interoperation with RFC8843 implementations. And that actions to 
ease interoperation in such cases is out of scope for this document.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Jun 2021 07:35:07 +0000

Hi,

>>>> Because, if we say that the endpoint shall generate an answer 
>>>> according to 8843, what about when the same endpoint later wants to generate a new offer itself? Should it then generate the offer according to 8843? I think we could easily
>>>> go down a slippery slope, and eventually 8843bis endpoints would also have to fully implement 8843. I don't think we want that.
>>>>
>>>> Having said that, we probably do need to say something about what "accept such offer" really means when it comes to generating the answer.
>>>> My suggestion would be to say that the answer SHOULD be generated according to 8843bis.
>>>
>> The ones impacted DID comment when we discussed what way to go, and the draft reflects the outcome.  There was never an agreement (or even suggested, AFAIR) that an 8843bis endpoint
>> would also have to implement 8843 functionality, in order to backward compatible. The only requirement was to be backward compatible with non-BUNDLE endpoints (e.g., not include identical
>> port numbers in the initial offer). This was also the reason we wanted to get the alignment published as far as possible, in order to minimize the backward compatibility issues.
>> 
> Maybe it would be worth mentioning that the changes in this bis may break interoperation with RFC8843 implementations. And that actions to

We could e.g., keep the text, because I do think that showing the examples is useful, but instead of saying that endpoints should support them we simply say that the processing is outside the scope of the document.

Something like:

---

7.3.5.  RFC 8843 Considerations

   In RFC 8843, instead of assigning the offerer BUNDLE address:port to
   each "m=" section within the BUNDLE group when modifying the session
   (Section 7.5), the offerer only assigned the offerer BUNDLE
   address:port to the offerer-tagged "m=" section.  For every other
   "m=" section within the BUNDLE group, the offerer included an SDP
   'bundle-only' attribute in, and assigned a zero port value to, the
   "m=" section. The way an answerer compliant to this specification
    processes such offer is considered an implementation issue (e.g., based
    on whether the answerer needs to be backward compatible with RFC 8843
    compliant offerers), and is outside the scope of this specification.

   SDP Offer

     v=0
     o=alice 2890844526 2890844526 IN IP6 2001:db8::3
     s=
     c=IN IP6 2001:db8::3
     t=0 0
     a=group:BUNDLE foo bar

     m=audio 10000 RTP/AVP 0 8 97
     b=AS:200
     a=mid:foo
     a=rtcp-mux
     a=rtpmap:0 PCMU/8000
     a=rtpmap:8 PCMA/8000
     a=rtpmap:97 iLBC/8000
     a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

     m=video 0 RTP/AVP 31 32
     b=AS:1000
     a=mid:bar
     a=bundle-only
     a=rtpmap:31 H261/90000
     a=rtpmap:32 MPV/90000
     a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid

---

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jun 2021 10:39:04 -0400

Christer,

This sounds good to me.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 12 Jun 2021 09:43:26 +0000

Are others ok with the suggestion below?

Regards,

Christer

-----Original Message-----
From: mmusic <[email-masked]> On Behalf Of Paul Kyzivat
Sent: perjantai 11. kesäkuuta 2021 17.39
To: [email-masked]
Subject: Re: [MMUSIC] Draft new version: 8843bis-02

Christer,

This sounds good to me.

	Thanks,
	Paul