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

[Roman Shpount <[e-mail]>]

Paul,

As a matter of background, what was observed for the current
implementations, which are mostly WebRTC based, is that endpoints either
use multiple media streams and implement bundle or use single media stream
(audio) and do not implement bundle. This skewed the bundle draft design to
optimize for these specific use cases. Furthermore, once media streams are
bundled, unbundling them will require additional resources (ports and ICE
TURN candidates), which is undesirable unless needed. This provides a
strong incentive not to unbundle media streams in most 3PCC scenarios.

The goal of the current language in the 3PCC considerations was to make
sure that the bundle-aware endpoint, which gets a new session established
via 3PCC, gets a valid initial bundle offer. This bundle would have a
bundle-only attribute set on most of the bundled m= lines, but this is
generally ok since non-bundle aware endpoints which will get it would
typically only support audio. Bundle-aware endpoints should be able to
handle such offers correctly.

As far as recovery is concerned, the 3PCC controller can detect that one
endpoint did not support bundle during the 3PCC call setup of a multimedia
session and initiate another offerless INVITE to that endpoint. The
non-bundle endpoint will generate an offer with unbundled m= lines for each
supported media type. If a bundle-aware endpoint supports such an offer, it
will re-establish the multimedia session. This being said, such scenarios
have not been seen in the wild.
_____________
Roman Shpount


On Sat, Nov 20, 2021 at 12:54 PM Paul Kyzivat <[e-mail]> wrote:

> On 11/20/21 12:06 PM, Christer Holmberg wrote:
> > Hi,
> >
> > The purpose of the text is not to mandate 3PCC to be implemented in a
> specific way. The purpose is to point out that if 3PCC is implemented in a
> way that the 3PCC controller receives a subsequent BUNDLE offer from an
> endpoint currently in a session, it needs to convert it into an initial
> BUNDLE offer before forwarding it to an endpoint that is currently not in a
> session.
>
> OK. It would be helpful to point out that doing so may degrade the call
> - specifically it may result in no longer having a multimedia call, and
> that if this is a concern then special consideration may need to be taken.
>
>         Thanks,
>         Paul
>
> > Regards,
> >
> > Christer
> >
> > -----Original Message-----
> > From: mmusic <[e-mail]> On Behalf Of Paul Kyzivat
> > Sent: lauantai 20. marraskuuta 2021 18.37
> > To: [e-mail]
> > Subject: Re: [MMUSIC] 1-week WGLC on Section 7.6 (3PCC Considerations)
> in draft-ietf-mmusic-rfc8843bis-06
> >
> > Hi,
> >
> > This is interesting ...
> >
> > On 11/17/21 6:16 PM, Flemming Andreasen 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.
> >
> > 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.
> >
> >       Thanks,
> >       Paul
> >
> > _______________________________________________
> > 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
>