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

[Paul Kyzivat <[e-mail]>]

Christer,

On 11/29/21 11:59 AM, Christer Holmberg wrote:
> Hi Paul,
> 
> For #2, exactly where would you like to put that sentence?

My thought was that it could go right at the end of the new text for #2. 
But I defer to you as editor to perfect the text.

	Thanks,
	Paul

> 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 
> <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 
> <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] 
> <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] <mailto:[e-mail]>>>
>>     *Sent:* tiistai 23. marraskuuta 2021 20.54
>>     *To:* Justin Uberti <[e-mail]
>>     <mailto:[e-mail] 
> <mailto:[e-mail]>>>
>>     *Cc:* Christer Holmberg <[e-mail]
>>     <mailto:[e-mail] 
> <mailto:[e-mail]>>>; Flemming Andreasen
>>     <fandreas=[e-mail]
>>     <mailto:[e-mail] <mailto:[e-mail]>>>; 
> mmusic <[e-mail]
>>     <mailto:[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] 
> <mailto:[e-mail]>>> wrote:
>> 
>>         On Tue, Nov 23, 2021 at 2:00 AM Christer Holmberg
>>         <[e-mail]
>>         <mailto:[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 
> <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 
> <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] <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]> <mailto:[e-mail] 
> <mailto:[e-mail]>>
>>             https://www.ietf.org/mailman/listinfo/mmusic 
> <https://www.ietf.org/mailman/listinfo/mmusic>
>>             <https://www.ietf.org/mailman/listinfo/mmusic 
> <https://www.ietf.org/mailman/listinfo/mmusic>>
>> 
>>         _______________________________________________
>>         mmusic mailing list
>>         [e-mail] <mailto:[e-mail] <mailto:[e-mail]>>
>>         https://www.ietf.org/mailman/listinfo/mmusic 
> <https://www.ietf.org/mailman/listinfo/mmusic>
>>         <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 
> <https://www.ietf.org/mailman/listinfo/mmusic>
>> 
> 
> _______________________________________________
> mmusic mailing list
> [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
>