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

[Christer Holmberg <[e-mail]>]

Hi Paul,

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

Regards,

Christer

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

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:
> 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
>

_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic