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

[Christer Holmberg <[e-mail]>]

Hi,

As an individual, keeping the proposed text is my preference too.

As we know this is how 3PCC controllers will have to act, I see no reason why we should spend time arguing about it. The SHOULD does give the 3PCC controller the possibility to also do something else, in case it has a good reason for doing so.

Regards,

Christer
________________________________
From: Roman Shpount <[e-mail]>
Sent: Tuesday, November 30, 2021 7:03 AM
To: Christer Holmberg <[e-mail]>
Cc: Paul Kyzivat <[e-mail]>; [e-mail] <[e-mail]>
Subject: 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=[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> on behalf of Paul Kyzivat <[e-mail]<mailto:[e-mail]>>
Sent: Monday, November 29, 2021 8:07 PM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
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
[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