Miguel A. Garcia | 1 Jun 13:46 2012
Picon

Liaison Statement from 3GPP SA4 on RTCP Bandwidth Negotiation

3GPP SA4 has sent us an LS on RTCP Bandwidth Negotiation. I copy below 
the text.

We should be able to provide them an answer in a reasonable time frame, 
so please, review it and provide with comments to the list. The chairs 
will compile a reply text.

The original document can be found at the 3GPP web site:
http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_69/Docs/S4-120810.zip

/Miguel and Flemming
-------

3GPP SA4 uses the RTCP bandwidth modifiers (b=RS and b=RR) to control the 
amount of RTCP bandwidth used in point-to-point VoIP and video telephony 
sessions.  As these parameters were primarily designed for multicast 
sessions, the calculations in section 2 of RFC 3556 apply to the total 
RTCP bandwidth for the session, i.e., total bandwidth for all clients 
sending/receiving RTCP traffic. However, there are no SDP Offer/Answer 
models defined that use these parameters for the negotiation of the total 
RTCP bandwidth for point-to-point sessions.

To clarify this, SA4 is planning to make the following recommendations in 
our specifications:

1.	The RS and RR values included in the SDP offer should be treated as 
proposed values for the session and may be modified by the answerer 
during session negotiation.

2.	When generating the SDP answer, the answerer should include the RR and 
(Continue reading)

Roni Even | 1 Jun 18:03 2012
Picon

Re: Liaison Statement from 3GPP SA4 on RTCP Bandwidth Negotiation

Hi,
In general it is good to add some text about this case since it is not
addressed in RFC3556 or RFC3264. I do not see any text that claims that
RFC3556 should be used for multicast or broadcast only and not to negotiate
for point to point calls.

I am not sure about the proposed recommendations. My understanding is that
since RTCP unlike RTP is bidirectional channel than the RS and RR values
specify the bw required for all endpoints. If the offer had a value for RS
and RR, I believe that in a point to point call when we have two sender and
two receivers each will get half of the RS and RR bandwidth. 
The offerer in this case will offer what he believes is needed for him to
send RTCP RRs and SRs reports multiply by two so if the answerer thinks he
need less bandwidth he should allow for the offerer to have enough RTCP
bandwidth at least for his sender reports. So I think that answerer should
respond with the same value or possibly higher. otherwise we may need to
define that the RR and RS values in the offer represent the bw that offerer
wants to use and the values in the answer would be the value the answerer
like to use, the total RTCP bw will be the sum of the two values.

Roni Even

> -----Original Message-----
> From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On
> Behalf Of Miguel A. Garcia
> Sent: Friday, June 01, 2012 2:46 PM
> To: mmusic
> Cc: Flemming Andreasen; nleung <at> qualcomm.com
> Subject: [MMUSIC] Liaison Statement from 3GPP SA4 on RTCP Bandwidth
> Negotiation
(Continue reading)

Stephan Wenger | 1 Jun 18:29 2012

Incoming liaison statement from MPEG

Hi all,
MPEG is working towards codec independent code points, and has sent to MMUSIC a liaison statement asking for our input.  Especially the audio stuff may also be relevant to CLUE, so I copy CLUE here as well.  No deadline is provided, but I note that MPEG meets two weeks before the Vancouver IETF meeting and the text they sent us is already a CD, so our time to influence their decisions (if we choose to do so) is limited.
MPEG has observed that many code points relevant for audio and video are generic in the sense that they can be applicable to many video or audio codecs.  Recent MPEG (and joint MPEG/ITU) video coding standards have occasionally copy-pasted whole sections of code points concerning things like color primaries.  They want to avoid this in the future.  So they farm out stuff that is historically located in video/audio codec specs, but are likely to be common between different codecs.
My hunch is that the code point in their draft standard could be translated to SDP-ish syntax.  At this point, it is XML-ish.
Stephan
_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Roni Even | 1 Jun 19:00 2012
Picon

Re: [clue] Incoming liaison statement from MPEG

Stephan,

I did not see the liaison statement yet in MMUSIC, so I hope it will be available in time for us to review.

From the example of color primaries I am not sure why we need to have this in SDP. if this is something that is sent as part of the payload do we need to send it also in SDP?

 

Roni

 

From: clue-bounces <at> ietf.org [mailto:clue-bounces <at> ietf.org] On Behalf Of Stephan Wenger
Sent: Friday, June 01, 2012 7:29 PM
To: mmusic <at> ietf.org; clue <at> ietf.org
Subject: [clue] Incoming liaison statement from MPEG

 

Hi all,

MPEG is working towards codec independent code points, and has sent to MMUSIC a liaison statement asking for our input.  Especially the audio stuff may also be relevant to CLUE, so I copy CLUE here as well.  No deadline is provided, but I note that MPEG meets two weeks before the Vancouver IETF meeting and the text they sent us is already a CD, so our time to influence their decisions (if we choose to do so) is limited.

MPEG has observed that many code points relevant for audio and video are generic in the sense that they can be applicable to many video or audio codecs.  Recent MPEG (and joint MPEG/ITU) video coding standards have occasionally copy-pasted whole sections of code points concerning things like color primaries.  They want to avoid this in the future.  So they farm out stuff that is historically located in video/audio codec specs, but are likely to be common between different codecs.

My hunch is that the code point in their draft standard could be translated to SDP-ish syntax.  At this point, it is XML-ish.

Stephan

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Stephan Wenger | 1 Jun 19:17 2012

Re: [clue] Incoming liaison statement from MPEG

Hi Roni,
The statement was sitting in my inbox for a few days, and I have forwarded it to the secretariat for posting only this morning.  Therefore, it is not yet on the tracker, but should be on the tracker sometime soon.
Color primaries, as one example, can actually being sent in SDP today, as part of the VUI in the sequence parameter set of H.264.  And, color primaries are an interoperability point, at least for high quality applications (such as video contribution).  If your receiving box does not understand, or cannot meaningfully process color primaries as sent, then you may get a picture but it will look odd…  There is also other stuff in the MPEG doc that is even more needed for interoperability; for example, association of audio channels inside the codec bitstream with a speaker location.
The key point of the MPEG doc is that they are out farming generic codec things from the audio/video specs into this MPEG-A format, and we (as we are not using MPEG-A) will probably have to find a way to either encapsulate MPEG-A XML for cap exchange, or translate the code points to SDP-ish things.
Stephan




From: Roni Even <ron.even.tlv <at> gmail.com>
Date: Friday, 1 June, 2012 10:00
To: Stephan Wenger <stewe <at> stewe.org>, "mmusic <at> ietf.org" <mmusic <at> ietf.org>, "clue <at> ietf.org" <clue <at> ietf.org>
Subject: RE: [clue] Incoming liaison statement from MPEG

<!-- /* Font Definitions */ <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} <at> font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} <at> font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} <at> page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.WordSection1 {page:WordSection1;} -->

Stephan,

I did not see the liaison statement yet in MMUSIC, so I hope it will be available in time for us to review.

From the example of color primaries I am not sure why we need to have this in SDP. if this is something that is sent as part of the payload do we need to send it also in SDP?

 

Roni

 

From: clue-bounces <at> ietf.org [mailto:clue-bounces <at> ietf.org] On Behalf Of Stephan Wenger
Sent: Friday, June 01, 2012 7:29 PM
To: mmusic <at> ietf.org; clue <at> ietf.org
Subject: [clue] Incoming liaison statement from MPEG

 

Hi all,

MPEG is working towards codec independent code points, and has sent to MMUSIC a liaison statement asking for our input.  Especially the audio stuff may also be relevant to CLUE, so I copy CLUE here as well.  No deadline is provided, but I note that MPEG meets two weeks before the Vancouver IETF meeting and the text they sent us is already a CD, so our time to influence their decisions (if we choose to do so) is limited.

MPEG has observed that many code points relevant for audio and video are generic in the sense that they can be applicable to many video or audio codecs.  Recent MPEG (and joint MPEG/ITU) video coding standards have occasionally copy-pasted whole sections of code points concerning things like color primaries.  They want to avoid this in the future.  So they farm out stuff that is historically located in video/audio codec specs, but are likely to be common between different codecs.

My hunch is that the code point in their draft standard could be translated to SDP-ish syntax.  At this point, it is XML-ish.

Stephan

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Thomas Stockhammer | 1 Jun 21:12 2012
Picon

Re: [clue] Incoming liaison statement from MPEG

Stephan, all,

a bit more background.

MPEG is NOT defining the mapping of the code points to any specific syntax, such as XML or SDP or a bitstream format. However, it provides common code points (generally unsigned integers) and common definitions of the code points.

One of the relevant code points for IETF SDP are the frame-compatible video formats such as SbS or TaB. Others may relate to audio properties such as the number and configuration of audio channels.

One of the main motivations is to avoid copying such code points from one specification to the next as it happens today for example in video coding standards. 

The IETF is encouraged to support the unification of such code points and by providing input to MPEG and by using references to the MPEG specification in IETF documents.

Thomas

On Jun 1, 2012, at 7:17 PM, Stephan Wenger wrote:

Hi Roni,
The statement was sitting in my inbox for a few days, and I have forwarded it to the secretariat for posting only this morning.  Therefore, it is not yet on the tracker, but should be on the tracker sometime soon.
Color primaries, as one example, can actually being sent in SDP today, as part of the VUI in the sequence parameter set of H.264.  And, color primaries are an interoperability point, at least for high quality applications (such as video contribution).  If your receiving box does not understand, or cannot meaningfully process color primaries as sent, then you may get a picture but it will look odd…  There is also other stuff in the MPEG doc that is even more needed for interoperability; for example, association of audio channels inside the codec bitstream with a speaker location.
The key point of the MPEG doc is that they are out farming generic codec things from the audio/video specs into this MPEG-A format, and we (as we are not using MPEG-A) will probably have to find a way to either encapsulate MPEG-A XML for cap exchange, or translate the code points to SDP-ish things.
Stephan




From: Roni Even <ron.even.tlv <at> gmail.com>
Date: Friday, 1 June, 2012 10:00
To: Stephan Wenger <stewe <at> stewe.org>, "mmusic <at> ietf.org" <mmusic <at> ietf.org>, "clue <at> ietf.org" <clue <at> ietf.org>
Subject: RE: [clue] Incoming liaison statement from MPEG

<!-- /* Font Definitions */ <at> font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} <at> font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} <at> font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman","serif";} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {mso-style-priority:99; color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-reply; font-family:"Calibri","sans-serif"; color:#1F497D;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} <at> page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.WordSection1 {page:WordSection1;} -->

Stephan,

I did not see the liaison statement yet in MMUSIC, so I hope it will be available in time for us to review.

From the example of color primaries I am not sure why we need to have this in SDP. if this is something that is sent as part of the payload do we need to send it also in SDP?

 

Roni

 

From: clue-bounces <at> ietf.org [mailto:clue-bounces <at> ietf.org] On Behalf Of Stephan Wenger
Sent: Friday, June 01, 2012 7:29 PM
To: mmusic <at> ietf.org; clue <at> ietf.org
Subject: [clue] Incoming liaison statement from MPEG

 

Hi all,

MPEG is working towards codec independent code points, and has sent to MMUSIC a liaison statement asking for our input.  Especially the audio stuff may also be relevant to CLUE, so I copy CLUE here as well.  No deadline is provided, but I note that MPEG meets two weeks before the Vancouver IETF meeting and the text they sent us is already a CD, so our time to influence their decisions (if we choose to do so) is limited.

MPEG has observed that many code points relevant for audio and video are generic in the sense that they can be applicable to many video or audio codecs.  Recent MPEG (and joint MPEG/ITU) video coding standards have occasionally copy-pasted whole sections of code points concerning things like color primaries.  They want to avoid this in the future.  So they farm out stuff that is historically located in video/audio codec specs, but are likely to be common between different codecs.

My hunch is that the code point in their draft standard could be translated to SDP-ish syntax.  At this point, it is XML-ish.

Stephan

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

---
Dr. Thomas Stockhammer (CEO) || stockhammer <at> nomor.de || phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com
Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.







_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Mo Zanaty (mzanaty | 1 Jun 22:32 2012
Picon

Re: [clue] Incoming liaison statement from MPEG

IETF documents typically refer to IANA registries for code points that are used in protocols. Code points that are part of codec payloads that are opaque to protocols are typically not referenced.

 

The MPEG spec for common code points across codecs would be similar to an IANA registry across all media formats. Should there be such a registry kept in sync with MPEG, or should IETF codec payload specs directly refer to the MPEG spec?

 

Mo

 

From: mmusic-bounces <at> ietf.org [mailto:mmusic-bounces <at> ietf.org] On Behalf Of Thomas Stockhammer
Sent: Friday, June 01, 2012 3:12 PM
To: Stephan Wenger
Cc: clue <at> ietf.org; mmusic <at> ietf.org
Subject: Re: [MMUSIC] [clue] Incoming liaison statement from MPEG

 

Stephan, all,

 

a bit more background.

 

MPEG is NOT defining the mapping of the code points to any specific syntax, such as XML or SDP or a bitstream format. However, it provides common code points (generally unsigned integers) and common definitions of the code points.

 

One of the relevant code points for IETF SDP are the frame-compatible video formats such as SbS or TaB. Others may relate to audio properties such as the number and configuration of audio channels.

 

One of the main motivations is to avoid copying such code points from one specification to the next as it happens today for example in video coding standards. 

 

The IETF is encouraged to support the unification of such code points and by providing input to MPEG and by using references to the MPEG specification in IETF documents.

 

Thomas

 

On Jun 1, 2012, at 7:17 PM, Stephan Wenger wrote:



Hi Roni,

The statement was sitting in my inbox for a few days, and I have forwarded it to the secretariat for posting only this morning.  Therefore, it is not yet on the tracker, but should be on the tracker sometime soon.

Color primaries, as one example, can actually being sent in SDP today, as part of the VUI in the sequence parameter set of H.264.  And, color primaries are an interoperability point, at least for high quality applications (such as video contribution).  If your receiving box does not understand, or cannot meaningfully process color primaries as sent, then you may get a picture but it will look odd…  There is also other stuff in the MPEG doc that is even more needed for interoperability; for example, association of audio channels inside the codec bitstream with a speaker location.

The key point of the MPEG doc is that they are out farming generic codec things from the audio/video specs into this MPEG-A format, and we (as we are not using MPEG-A) will probably have to find a way to either encapsulate MPEG-A XML for cap exchange, or translate the code points to SDP-ish things.

Stephan

 

 

 

 

From: Roni Even <ron.even.tlv <at> gmail.com>
Date: Friday, 1 June, 2012 10:00
To: Stephan Wenger <stewe <at> stewe.org>, "mmusic <at> ietf.org" <mmusic <at> ietf.org>, "clue <at> ietf.org" <clue <at> ietf.org>
Subject: RE: [clue] Incoming liaison statement from MPEG

 

Stephan,

I did not see the liaison statement yet in MMUSIC, so I hope it will be available in time for us to review.

From the example of color primaries I am not sure why we need to have this in SDP. if this is something that is sent as part of the payload do we need to send it also in SDP?

 

Roni

 

From: clue-bounces <at> ietf.org [mailto:clue-bounces <at> ietf.org] On Behalf Of Stephan Wenger
Sent: Friday, June 01, 2012 7:29 PM
To: mmusic <at> ietf.org; clue <at> ietf.org
Subject: [clue] Incoming liaison statement from MPEG

 

Hi all,

MPEG is working towards codec independent code points, and has sent to MMUSIC a liaison statement asking for our input.  Especially the audio stuff may also be relevant to CLUE, so I copy CLUE here as well.  No deadline is provided, but I note that MPEG meets two weeks before the Vancouver IETF meeting and the text they sent us is already a CD, so our time to influence their decisions (if we choose to do so) is limited.

MPEG has observed that many code points relevant for audio and video are generic in the sense that they can be applicable to many video or audio codecs.  Recent MPEG (and joint MPEG/ITU) video coding standards have occasionally copy-pasted whole sections of code points concerning things like color primaries.  They want to avoid this in the future.  So they farm out stuff that is historically located in video/audio codec specs, but are likely to be common between different codecs.

My hunch is that the code point in their draft standard could be translated to SDP-ish syntax.  At this point, it is XML-ish.

Stephan

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic

 

---

Dr. Thomas Stockhammer (CEO) || stockhammer <at> nomor.de || phone +49 89 978980 02 || cell +491725702667 || http://www.nomor-research.com

Nomor Research GmbH  -  Sitz der Gesellschaft: München - Registergericht: München, HRB 165856 – Umsatzsteuer-ID: DE238047637 - Geschäftsführer: Dr. Thomas Stockhammer, Dr. Ingo Viering.

 

 

 

 



 

_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Mary Barnes | 1 Jun 22:55 2012
Picon

Fwd: [clue] Incoming liaison statement from MPEG


I would appreciate it if folks could reply only to the MMUSIC WG mailing list.  We are getting messages in the CLUE moderator queue from folks that are not subscribed to CLUE (and likely don't want to be).  CLUE folks can follow the discussion on the MMUSIC mailing list. 

Thanks,
Mary. 

---------- Forwarded message ----------
From: Stephan Wenger <stewe <at> stewe.org>
Date: Fri, Jun 1, 2012 at 11:29 AM
Subject: [clue] Incoming liaison statement from MPEG
To: "mmusic <at> ietf.org" <mmusic <at> ietf.org>, "clue <at> ietf.org" <clue <at> ietf.org>


Hi all,
MPEG is working towards codec independent code points, and has sent to MMUSIC a liaison statement asking for our input.  Especially the audio stuff may also be relevant to CLUE, so I copy CLUE here as well.  No deadline is provided, but I note that MPEG meets two weeks before the Vancouver IETF meeting and the text they sent us is already a CD, so our time to influence their decisions (if we choose to do so) is limited.
MPEG has observed that many code points relevant for audio and video are generic in the sense that they can be applicable to many video or audio codecs.  Recent MPEG (and joint MPEG/ITU) video coding standards have occasionally copy-pasted whole sections of code points concerning things like color primaries.  They want to avoid this in the future.  So they farm out stuff that is historically located in video/audio codec specs, but are likely to be common between different codecs.
My hunch is that the code point in their draft standard could be translated to SDP-ish syntax.  At this point, it is XML-ish.
Stephan

_______________________________________________
clue mailing list
clue <at> ietf.org
https://www.ietf.org/mailman/listinfo/clue



_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Stephan Wenger | 2 Jun 18:26 2012

Incoming liaison statement from MPEG

Hi,
The liaison statement has been posted as https://datatracker.ietf.org/liaison/1158/
Replies to mmusic list only, please.
Stephan

P.s.: if someone could off-list tell me how to set an reply-to header field in outlook for Mac 2011, I would appreciate that.



_______________________________________________
mmusic mailing list
mmusic <at> ietf.org
https://www.ietf.org/mailman/listinfo/mmusic
Gonzalo Camarillo | 4 Jun 10:03 2012
Picon

Fwd: New Liaison Statement, "Liaison Statement from SC 29/WG 11 on Coding Independent Media Code Points"

FYI.

Gonzalo

-------- Original Message --------
Subject: New Liaison Statement,	"Liaison Statement from SC 29/WG 11 on
Coding Independent Media Code	Points"
Date: Fri, 1 Jun 2012 23:12:45 +0200
From: Liaison Statement Management Tool <lsmt <at> ietf.org>
To: Flemming Andreasen <fandreas <at> cisco.com>, Miguel Garcia A
<miguel.a.garcia <at> ericsson.com>
CC: Gonzalo Camarillo <gonzalo.camarillo <at> ericsson.com>, Robert Sparks
<rjsparks <at> nostrum.com>, Multiparty Multimedia Session Control Discussion
List <mmusic-request <at> ietf.org>, Stephan Wenger <stewe <at> stewe.org>,
Stephan Wenger <stewe <at> stewe.org>

Title: Liaison Statement from SC 29/WG 11 on Coding Independent Media
Code Points
Submission Date: 2012-06-01
URL of the IETF Web page: http://datatracker.ietf.org/liaison/1158/

From: ISO/IEC JTC 1/SC 29/WG 11  (Stephan Wenger <stewe <at> stewe.org>)
To: Multiparty Multimedia Session Control (Flemming Andreasen
<fandreas <at> cisco.com>, Miguel Garcia <miguel.a.garcia <at> ericsson.com>)
Cc: Gonzalo Camarillo <gonzalo.camarillo <at> ericsson.com>,Robert Sparks
<rjsparks <at> nostrum.com>,Multiparty Multimedia Session Control Discussion
List <mmusic-request <at> ietf.org>,Stephan Wenger <stewe <at> stewe.org>
Reponse Contact: Stephan Wenger <stewe <at> stewe.org>
Technical Contact:
Purpose: For information

Body:
Attachments:

    Liaison Statement from SC 29/WG 11 on Coding Independent Media Code
Points

https://datatracker.ietf.org/documents/LIAISON/liaison-2012-06-01-isoiec-jtc-1sc-29wg-11-mmusic-liaison-statement-from-sc-29wg-11-on-coding-independent-media-code-points-attachment-1.zip

    SC 29 N 12729 (WG 11 N 12659)

https://datatracker.ietf.org/documents/LIAISON/liaison-2012-06-01-isoiec-jtc-1sc-29wg-11-mmusic-liaison-statement-from-sc-29wg-11-on-coding-independent-media-code-points-attachment-2.zip

Gmane