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

[Christer Holmberg <[e-mail]>]

Hi,

>>>>>> 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?
>>>>
>>>> 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.
>>>
>>> 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.
>
> 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.

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