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

[Roman Shpount <[e-mail]>]

Hi Christer,

I have reviewed the changes and there are a couple of nits:

In 7.4.1:
"answeris" should be  "answer is"

In 7.6
"In this situation the endpoint" should be "In this situation, the
endpoint" (missing comma).

"Therefore, the 3PCC controller SHOULD take actions to mitigate this
problem, e.g., by rewriting the subsequent BUNDLE offer into a valid
initial BUNDLE offer (Section 7.2), before it forwards the BUNDLE offer to
a UA."

should be

"Therefore, the 3PCC controller SHOULD take actions to mitigate this
problem, e.g., rewrite the subsequent BUNDLE offer into a valid initial
BUNDLE offer (Section 7.2), before it forwards the BUNDLE offer to a UA."

Best Regards,
_____________
Roman Shpount


On Thu, Dec 2, 2021 at 3:54 AM Christer Holmberg <christer.holmberg=
[e-mail]> wrote:

> Hi,
>
>
>
> I just submitted a new version (-07), which implements the changes based
> on Paul’s comments.
>
>
>
> Thank You to everyone who provided comments and input! :)
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Flemming Andreasen <[e-mail]>
> *Sent:* maanantai 29. marraskuuta 2021 20.13
> *To:* Christer Holmberg <[e-mail]>;
> [e-mail]
> *Cc:* mmusic <[e-mail]>
> *Subject:* Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations)
> in draft-ietf-mmusic-rfc8843bis-06
>
>
>
>
>
> 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]>
> <[e-mail]>
> *Sent:* Monday, November 29, 2021 1:46 AM
> *To:* Roman Shpount <[e-mail]> <[e-mail]>
> *Cc:* Christer Holmberg <[e-mail]>
> <[e-mail]>; Flemming Andreasen <[e-mail]>
> <[e-mail]>; mmusic <[e-mail]> <[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]> 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 1st paragraph remains independent from SIP.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Roman Shpount <[e-mail]>
> *Sent:* tiistai 23. marraskuuta 2021 20.54
> *To:* Justin Uberti <[e-mail]>
> *Cc:* Christer Holmberg <[e-mail]>; 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
>
>
>
> 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]> wrote:
>
>
>
>
>
> On Tue, Nov 23, 2021 at 2:00 AM Christer Holmberg <
> [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] 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] 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]> 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]
> 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
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>