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

[Paul Kyzivat <[e-mail]>]

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
>