Re: [MMUSIC] 3GPP liaison statement to IETF MMUSIC

Thank you for the review Colin!

I think this is sufficient information for a liaison response.

MMUSIC, I would like to provide 3GPP TSG SA WG4 with a response liaison well in time for their next meeting in June, so please provide any further comments in two weeks, before COB UTC May 31.

Bo
MMUSIC co-chair

> -----Original Message-----
> From: Colin Perkins [mailto:csp@csperkins.org]
> Sent: den 12 maj 2016 19:02
> To: Ben Campbell
> Cc: Bo Burman; mmusic; Gonzalo Camarillo
> Subject: Re: [MMUSIC] 3GPP liaison statement to IETF MMUSIC
> 
> Bo, Ben,
> 
> I’ve revised this liaison statement, and the attached 3GPP TR 26.924 V13.0.0, at the chair’s request. I do not follow the
> work in 3GPP closely, but I understand that SDP attribute-based approaches, such as solutions D and F in the TR, are
> being considered for further development.
> 
> Of the alternatives proposed, I believe that use of an SDP attribute (i.e., an “a=” line) is to be preferred over use of
> further extensions to SDP “b=“ lines. Attributes are the natural extension point for SDP, and offer flexibility that is not
> present in “b=“ lines. This is compatible with the solutions proposed by 3GPP.
> 
> Whether any new attribute is signalled per RTP payload type, as in solution D, or per m= line, as in solution F, is a more
> complex issue. Neither seems unreasonable on the surface, and a QoS attribute per “m=“ line is natural if each “m=“ line
> represents a single media sent on a single port, with the offer/answer exchange being used only to select what encoding
> is used for that media.
> 
> However, with the definition and widespread adoption of the SDP BUNDLE extension, the assumption that a single “m=“
> line represents a single type of media being sent on a single UDP port is becoming less tenable. I would urge 3GPP to
> consider the impact of the BUNDLE extension on their choice, and to further coordinate with IETF to ensure that
> whatever is developed is compatible with SDP sessions where multiple “m=“ lines, representing several different types
> of media, are sent on a single UDP port.
> 
> Colin
> 
> 
> 
> > On 1 Dec 2015, at 21:25, Ben Campbell <ben@nostrum.com> wrote:
> >
> > Does anyone have thoughts on this?
> >
> > Thanks!
> >
> > Ben.
> >
> > On 16 Nov 2015, at 4:26, Bo Burman wrote:
> >
> >> MMUSIC members,
> >>
> >> We have received a liaison statement from the 3GPP TSG SA WG4 group.
> >>
> >> Briefly summarizing the attached document, they have been studying resource allocation at session setup and have
> found lack of bandwidth information elements and lack of end-to-end alignment that can result in inconsistent setting of
> QoS parameters in 3GPP networks. They have also documented the problem analysis and potential solutions in a
> (publicly accessible) technical report.
> >>
> >> They would like MMUSIC to consider their work and want us to provide feedback on whether we would like to be
> involved in the coordination of future work on this topic.
> >>
> >> For details, please see the attached liaison document.
> >>
> >> Cheers,
> >> /Bo
> >>
> >> ________________________________
> >>
> >> Title:                      LS on Improved end-to-end QoS Enhancements for MTSI
> >>
> >> Release:               Release 13
> >>
> >> Work Item:         QOSE2EMTSI
> >>
> >> Source:                 3GPP TSG SA WG4
> >>
> >> To:                          IETF MMUSIC
> >>
> >> Cc:                          3GPP TSG CT WG1, 3GPP TSG CT WG3, 3GPP TSG CT WG4
> >>
> >>
> >>
> >> -------------------------------------------------------------
> >>
> >> Susanna Kooistra, ETSI MCC
> >>
> >> 3GPP liaison co-ordinator
> >>
> >> E-mail: 3GPPLiaison@etsi.org<mailto:3GPPLiaison@etsi.org> <mailto:3GPPLiaison@etsi.org>
> >>
> >> Please consider the environmental impact before printing this e-mail
> >>
> >> _______________________________________________
> >> mmusic mailing list
> >> mmusic@ietf.org
> >> https://www.ietf.org/mailman/listinfo/mmusic