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

From: Colin Perkins <[email-masked]>
Date: Thu, 12 May 2016 19:01:38 +0200

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 <[email-masked]> 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: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
>> 
>> Please consider the environmental impact before printing this e-mail
>> 
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bo Burman <[email-masked]>
Date: Tue, 17 May 2016 15:24:15 +0000

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:[email-masked]]
> 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
> 
> 
> 
> >> 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.
> >>