[MMUSIC] Using SDP Media Capabilities for AAC Signalling

[Fred Melville <[e-mail]>]

Hello all,

My query is a similar to the question posed here by Jochen Issing, Nov 30 2011, in that it relates to session setup with the negotiation of AAC codecs, and addressing the following two main issues encountered with AAC signalling using standard SDP (e.g. RFC3264 / 3640):


[ISSUE_1] What I like to call "asymmetric format parameters". For example, Alice offers a certain mpeg4-generic codec as follows:

  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=AAA111; sizeLength=13; indexLength=3; indexDeltaLength=3; constantDuration=1024

Bob checks that he can decode with this configuration and would like to accept, but Bob's encoder will be using a different AudioSpecificConfig of AAA222, so he would like to inform Alice of this different parameter in his answer (this may also apply to other format parameters such as profile-level-id). To do so, according to RFC3264 Section 6.1, he can simply keep the same PayloadTypeID (i.e. 96) and edit the fmtp parameters to his own preferences. The problem with doing this is that after returning his Answer the session should be able to begin immediately, but Bob has no idea if Alice actually agrees to (i.e. will be able to decode) the edited configuration he has made, and so Bob cannot safely send using this codec.

[ISSUE_2] The limited number of available dynamic Payload ID's (32 - could easily be exceeded with a few different codecs each with several configurations). If the Offerer produced a list of configurations that exceeded 32 then this would have to be filtered down rather crudely, because the Offerer cannot filter intelligently without any information on their partner's capabilities and therefore what the partner is likely to accept.


I intend to use a preliminary round of SDP Media Capabilities Negotiation (draft 14 at time of writing). My objective for this first round is to communicate all the possible configurations that each partner offers, along with their preferred format parameters for those configurations. Without mapping to PayloadTypeID's in the first round this will allow for lists much larger than 32 configurations.

Alice                                         Bob

| (S1) sdpMedCapNeg Offer      |
|--------------------------------------->|
|                                                       |
| (S2) sdpMedCapNeg Answer |
|<---------------------------------------|
|                                                      |
| (S3) Standard SDP Offer         |
|--------------------------------------->|
|                                                      |
| (S4) Standard SDP Answer    |
|<---------------------------------------|
|                                                      |

This is my proposed logic for the sdpMedCapNeg Answer formation at (S2) and I am asking that if I negotiate using the method described here am I doing so as the authors intended?

  (a1) When the codec configuration AND format parameters proposed by Alice are identical to the preferred parameters Bob would like to use, then the preferred config remains unchanged.

  (a2) When Alice's codec configuration and format parameters are accepted by Bob BUT he would like to specify his own preferred parameters, then using the same 'pcfg' handle he changes the parameters as desired. Then, when both parties store the parameters from the first round, Alice can chose to accept or refuse Bob's preferences in the final Offer (S3), by listing Bob's parameters if she accepts his proposal, or by repeating her own parameters if she refuses.
  
  (a3) When the codec configuration is accepted, but the format parameters cannot be accepted, then we remove the 'pcfg' and add a new 'pcfg' handle with the codec configuration and our format parameters.
  
  (a4)  When the codec configuration cannot be accepted, remove the related 'rmcap', 'mfcap(s)' and 'pcfg(s)'.


If Bob does change the any parameters, or adds configurations to the Answer, he sets the Port number set to zero to indicate that the session will not be ready to start after this round (because he is unsure if Alice accepts his additions). After the first round (S1 & S2) round both parties will be aware of their partner's capabilities, and all 32 PayloadTypeID's can be used to list configurations that the offerer knows for certain that the answerer will accept, which should be an ample selection to switch between during a call. Hence ISSUE_1 would be fully solved since both parties have exchanged and checked their asymmetric parameter preferences, and ISSUE_2 is partially solved because the limit of 32 becomes much more palatable when the options can be filtered intelligently down to 32 that make sense for the given capabilities, and are guaranteed to be accepted by the Answerer.

My main concern is (a2), and if this is the best way for Alice to signal that she accepts Bob's alternative parameters? I.e. in her final offer S3, if Alice accepts Bob's alternative parameters, then she would signal this by sending his parameters in the Offer even though in reality she will be sending using her own parameters (assuming Bob also accepted her preferences in the first round). Is this safe to do so (e.g. what about when intermediaries / middleboxes are present?).

I can reply with a example Offers and Answers, but I thought I'd remove them for now as the email was becoming excessive!

Best regards,

Fred Melville
--
Multimedia Transport
Fraunhofer IIS