Subject: Re: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 5 Dec 2011 11:02:32 -0800

Hi Jochen,

I am not that familiar with the details of the variation modes. If you
want to specify different fmtp parameters for AAC-LC vs. HE-AAC vs. and
HE-AACv2, it seems you could include multiple payload types in the
m-line, and then specify the corresponding fmtp parameters for each. Is
there a need to support, for example, AAC-LC, HE-AACC, and HE-AACv2
within a single payload type?

Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jochen Issing
> Sent: Wednesday, November 30, 2011 7:18 AM
> To: [email-masked]; [email-masked]
> Subject: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues
> 
> Dear experts,
> 
> I need to double-apologize before posting our findings:
> 1) for cross-posting, as I do not know, where this issue has its exact
home, which is hopefully not a
> response killer.
> 2) for the long mail, even though I tried to keep it short.
> 
> Now, here's the actual request:
> 
> We are referring to RFC3640 SDP fields only, as this is most often the
stumbling block. Let's use the
> following example:
> 
>    m=audio 49170 RTP/AVP 96
>    a=rtpmap:96 mpeg4-generic/48000/2
>    a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-hbr;
config=1190; sizeLength=13;
> indexLength=3; indexDeltaLength=3; constantDuration=1024
> 
> The fields of interest are in the fmtp line: 'profile-level-id' and
'config'.
> In contrast to other codecs, e.g. G.XXX, AAC integrates many different
types of sub codecs, which are
> identified using the Audio Object Type (AOT). The AOT and some
additional (codec internal) information
> is stored in the Audio Specific Config (ASC), which is conveyed in the
'config' field.
> The 'profile-level-id' points to a profile with a certain level. The
profile comprises a set of one or
> more AOTs and the level restricts the stream to a maximum sample rate
and/or number channels. The
> profile-level-ids, as specified in ISO 14496-3, are partly
hierarchical and most often ambiguous.
> 
> Suppose the classic SIP use case that two clients want to exchange
their codec capabilities.
> The first client specifies some payload types in the SDP part of SIP
INVITE which can differ in their
> profile-level-id and/or config.
> For instance, client bob supports AAC-LC, HE-AAC and HE-AACv2. To
signal these codecs/AOTs he could
> either indicate all formats with the same profile-level-id (e.g., 48),
which includes all these AOTs
> or he could specify profile-level-ids, that are most 'narrow' to the
actual specified AOT or he could
> even mix this principle.
> On the other hand, the ASC might use implicit signaling, explicit
backwards-compatible, or explicit
> non-backwards-compatible.
> Bobs main problem would be to determine, whether the profile-level-id
was chosen to really identify
> the necessary (and applied) AAC AOTs or if he could rely on the ASC or
if the profile-level-id was
> just brawling about the encoders feature.
> 
> To clean up this mess of opportunities, we would like to specify a
non-ambiguous way to utilize the
> profile-level-id and config fields appropriately and provide a guide
on how to accomplish clean and
> easier signalization and thus improve interoperability.
> 
> 
> But first of all we would like to make sure, that you agree to this
problem statement or do we miss
> something here?
> Comments are as always highly appreciated.
> 
> Best Regards,
> --
> jochen
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Jochen Issing <[email-masked]>
Date: Mon, 5 Dec 2011 23:50:25 +0100

Hi Charles,

thanks for your response! However, the issue we identified is somewhat different:

The problem already takes place with a single fmtp line:
For example, one client indicates that it can (decode and) encode an AAC stream using
the config field in fmtp. The other side, receiving this information, then must
check its decoder, if it can decode the ASC and needs to setup its encoder,
so that it uses the very same ASC.

The problem occurs at the encoder of the caller (the receiver of the first SDP):
It might not be possible with reasonable effort to get an encoder creating the
same ASC as given in SDP (encoders are in general not initialized using an ASC).

I hope, this explained our problem much clearer.
Best,

jochen

-- 
jochen

---

From: "Severa, Michael J (Mike)" <[email-masked]>
Date: Mon, 5 Dec 2011 17:28:12 -0600

My personal feeling is that the ASC need not be identical in syntax, just in semantics (one of the unfortunate aspects of AAC-related signaling is that there are a number of ways to signal the same bitstream). Another unfortunate aspect is that one of the options is to signal implicitly, which essentially means dont signal at all, rather 'detect' at decode time. That is obviously not useful for a capabilities exchange step. 

I think there might also be other open questions surrounding ambiguities in signaling AAC-LC/HE-AAC that should be worked through to generate a best or acceptable practices approach. 

Two of the ones that jump out at me are:
- the question of what timescale from the rtpmap line means when you intend to be using HE-AAC in a 3640 environment (3GPP has explicitly indicated this should be sampling frequency of the underlying, 'core' AAC-LC portion of an HE-AAC stream. I assume this is the same semantic in 3640 (though I didnt notice it specified explicitly)). This question is probably only relevant in cases where the goal is to assume HE-AAC (something the multiple fmtp line suggestion might be implying). 
- how HE-AAC can be detected in implicit mode during negotiation (again, 3GPP added an SBR-Enabled flag to the SDP to allow HE-AAC to be detected ahead of time even with implicit signaling, im not sure there is an analogous solution for 3640). 

Both of these questions are probably irrelevant if implicit signaling is disallowed for HE-AAC (though in the first case that would require parsing the ASC during negotiation). Using multiple fmtp lines might be one way to 'disable' the implicit signaling requirement (since the backwards compatibility concern associated with implicit signaling can be dealt with by an explicit AAC-LC-only ftmp (and rtpmap)line). 

Sorry if that's a tangent. 

thanks, 

Mike

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Jochen Issing [[email-masked]]
Sent: Monday, December 05, 2011 2:50 PM
To: Charles Eckel (eckelcu)
Cc: [email-masked]; [email-masked]
Subject: Re: [MMUSIC] RFC3640 (AAC) and SIP offer/answer issues

Hi Charles,

jochen

--
jochen

---

From: Jochen Issing <[email-masked]>
Date: Tue, 06 Dec 2011 00:49:40 +0100

Hi Mike,

as far as I understand the AAC codecs, ASCs of the same AOT (and 
channels and sample rate) are not necessarily 'compatible' to each 
other, especially when it comes to more recent codecs, like AAC-ELD, 
where critical information might be included in the ASC. Thus, for a 
uniform usage of ASCs, it should be bit-exact. I'm afraid the caller 
needs to add a payload type if he does not manage to reproduce the ASC 
indicated by the callee, which would be then used in one direction only.

Regarding the signalization of SBR and PS (HE-AAC/HE-AACv2) you are 
right, that's another issue. However, with presence of SIP/SDP and 
offer/answer functionality, implicit and backwards-compatible 
signalization do not make sense at all IMHO. The legacy receiver can 
simply disregard the unsupported codecs. Anyhow, this is neither stated 
anywhere.

Best,
jochen

-- 
jochen