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

[Christer Holmberg <[e-mail]>]

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 1st 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] 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]<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
_______________________________________________
mmusic mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mmusic