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

Christer,

I think as far as specification goes, "needs to" still means some action is
required, but using SHOULD makes it more apparent.

I also like keeping the proposed text as an example of what needs to be
done, especially since this is exactly what is required in all the current
use cases.
_____________
Roman Shpount

On Mon, Nov 29, 2021 at 2:00 PM Christer Holmberg <christer.holmberg=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi Paul,
>
> Since the issue is introduced by BUNDLE, I think we should say more than
> simply "the 3PCC has to do something".
>
> I am fine to change the current procedure from a SHOULD to an example, but
> I do think we should include some guidance.
>
> For example:
>
> "Therefore, the 3PCC controller needs to 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."
>
> (I have no strong opinion on whether we use "3GPP controller needs to" or
> "3GPP controller SHOULD".)
>
> Regards,
>
> Christer
>
>
>
> ------------------------------
> *From:* mmusic <mmusic-bounces@ietf.org> on behalf of Paul Kyzivat <
> pkyzivat@alum.mit.edu>
> *Sent:* Monday, November 29, 2021 8:07 PM
> *To:* mmusic@ietf.org <mmusic@ietf.org>
> *Subject:* Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations)
> in draft-ietf-mmusic-rfc8843bis-06
>
> Roman,
>
> On 11/29/21 12:14 PM, Roman Shpount wrote:
> > Paul,
> >
> > There is already the following language there:
> >
> > When the BUNDLE mechanism is used, an initial BUNDLE Offer is
> > constructed using different rules than subsequent BUNDLE Offers, and it
> > cannot be assumed that a UA is able to correctly process a subsequent
> > BUNDLE Offer as an initial BUNDLE offer.  Therefore, the  3PCC
> > controller SHOULD rewrite the subsequent BUNDLE Offer into a valid
> > initial BUNDLE Offer, following the procedures in Section 7.2, before it
> > forwards the BUNDLE Offer to a UA.  In the rewritten BUNDLE Offer the
> > 3PCC controller will set the port value to zero (and include an SDP
> > 'bundle-only' attribute) for each "m=" section within the BUNDLE group,
> > excluding the offerer-tagged "m=" section.
>
> OK. Shame on me for responding to Christer's proposed new text without
> reviewing it in the context it falls within.
>
> You are right that the paragraph you mention here, which immediately
> follows the revised text for #2, does address the need to mitigate the
> problem. But that then goes back to my earlier comment:
>
> > This approach has a limitation:
> >
> > If the new UA is unable/unwilling to bundle the media then the updated
> call will be limited to a single media stream, even if the old UA is
> willing to operate with unbundled media.
> >
> > An alternative way to do this is for the 3pcc controller start the
> transfer by sending the old UA an offerless INVITE/Replaces. That will
> result in getting an initial bundle offer that should give maximum
> flexibility to the new UA.
> >
> > Its possible that the old UA doesn't support INVITE/Replaces. If so, the
> 3pcc controller could then fall back to the method currently in 7.6.
>
> Subsequent discussion of that comment led me to conclude that getting
> into the weeds of *how* to mitigate the problem may be unwise.
>
> So perhaps my more recent can replace part of this last paragraph.
> Specifically, replace:
>
> OLD
>
>     ... Therefore, the
>     3PCC controller SHOULD rewrite the subsequent BUNDLE Offer into a
>     valid initial BUNDLE Offer, following the procedures in Section 7.2,
>     before it forwards the BUNDLE Offer to a UA.  In the rewritten BUNDLE
>     Offer the 3PCC controller will set the port value to zero (and
>     include an SDP 'bundle-only' attribute) for each "m=" section within
>     the BUNDLE group, excluding the offerer-tagged "m=" section.
>
> NEW
>
>     The 3PCC controller SHOULD take actions to mitigate this problem.
>
>         Thanks,
>         Paul
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>