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

[Christer Holmberg <[e-mail]>]

Hi,

>I have reviewed the changes between -05 and -06 and have the following comments:
>
>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.

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

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) [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) [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=[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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mmusic