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

From: Jochen Issing <[email-masked]>
Date: Wed, 30 Nov 2011 16:18:26 +0100

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