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

[Flemming Andreasen <[e-mail]>]

On 11/29/21 11:58, Christer Holmberg wrote:
> Chairs,
>
> Can I submit a new version of the document, with the changes suggested 
> below?

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

Thanks

-- Flemming
>
> Regards,
>
> Christer
> ------------------------------------------------------------------------
> *From:* Justin Uberti <[e-mail]>
> *Sent:* Monday, November 29, 2021 1:46 AM
> *To:* Roman Shpount <[e-mail]>
> *Cc:* Christer Holmberg <[e-mail]>; Flemming 
> Andreasen <[e-mail]>; mmusic <[e-mail]>
> *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 <[e-mail]> wrote:
>
>     This still works for me.
>     _____________
>     Roman Shpount
>
>
>     On Sat, Nov 27, 2021 at 4:33 PM Christer Holmberg
>     <christer.holmberg=[e-mail]> wrote:
>
>         Hi,
>
>         Is everyone else ok with the changes?
>
>         Change #1:
>
>         Change ‘Offer’ and ‘Answer’ to ‘offer’ and ‘answer’ throughout
>         the document.
>
>         Change #2:
>
>         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,
>
>            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
>
>            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.
>
>         Regards,
>
>         Christer
>
>         *From:*mmusic <[e-mail]> *On Behalf Of *Justin
>         Uberti
>         *Sent:* torstai 25. marraskuuta 2021 1.16
>         *To:* Christer Holmberg <[e-mail]>
>         *Cc:* Flemming Andreasen
>         <fandreas=[e-mail]>; mmusic <[e-mail]>
>         *Subject:* Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC
>         Considerations) in draft-ietf-mmusic-rfc8843bis-06
>
>         Good suggestion, that works for me.
>
>         On Wed, Nov 24, 2021 at 3:17 AM Christer Holmberg
>         <[e-mail]
>         <mailto:[e-mail]>> 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 <[e-mail]
>             <mailto:[e-mail]>>
>             *Sent:* tiistai 23. marraskuuta 2021 20.54
>             *To:* Justin Uberti <[e-mail]
>             <mailto:[e-mail]>>
>             *Cc:* Christer Holmberg <[e-mail]
>             <mailto:[e-mail]>>; Flemming
>             Andreasen <fandreas=[e-mail]
>             <mailto:[e-mail]>>; mmusic
>             <[e-mail] <mailto:[e-mail]>>
>             *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
>             <[e-mail]
>             <mailto:[e-mail]>> wrote:
>
>                 On Tue, Nov 23, 2021 at 2:00 AM Christer Holmberg
>                 <[e-mail]
>                 <mailto:[e-mail]>> 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.
>
>                     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.
>
>                 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:
>                     >>
>                     >> 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.
>
>                     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."
>
>                 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.
>
>                     Regards,
>
>                     Christer
>
>
>
>
>
>                     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)
>                     [https://datatracker.ietf.org/doc/html/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)
>                     [https://datatracker.ietf.org/doc/html/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.
>
>                     On Wed, Nov 17, 2021 at 3:16 PM Flemming Andreasen
>                     <fandreas=mailto:[e-mail]
>                     <mailto:[e-mail]>> 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
>                     mailto:[e-mail] <mailto:[e-mail]>
>                     https://www.ietf.org/mailman/listinfo/mmusic
>                     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>                 _______________________________________________
>                 mmusic mailing list
>                 [e-mail] <mailto:[e-mail]>
>                 https://www.ietf.org/mailman/listinfo/mmusic
>                 <https://www.ietf.org/mailman/listinfo/mmusic>
>
>         _______________________________________________
>         mmusic mailing list
>         [e-mail]
>         https://www.ietf.org/mailman/listinfo/mmusic
>