Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0494F11E80DF for ; Fri, 17 Aug 2012 10:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3IekBRRaQTE for ; Fri, 17 Aug 2012 10:40:01 -0700 (PDT) Received: from mx-relay02-haj2.antispameurope.com (mx-relay02-haj2.antispameurope.com [83.246.65.202]) by ietfa.amsl.com (Postfix) with ESMTP id 38DDE11E809B for ; Fri, 17 Aug 2012 10:39:59 -0700 (PDT) Received: from smtp02.iis.fraunhofer.de (mailserv02.iis.fraunhofer.de [153.96.171.52]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mailgw1.iis.fraunhofer.de (Postfix) with ESMTPS id 0D67D2400081 for ; Fri, 17 Aug 2012 19:39:56 +0200 (CEST) Received: from mbp188.iis.fhg.de (unknown [10.54.95.92]) by smtp02.iis.fraunhofer.de (Postfix) with ESMTPS id 0415094002 for ; Fri, 17 Aug 2012 19:39:56 +0200 (CEST) From: Fred Melville Content-Type: multipart/alternative; boundary="Apple-Mail=_181BAAFC-D408-4B83-82ED-39CE0F133AFC" Date: Fri, 17 Aug 2012 19:39:55 +0200 Message-Id: To: mmusic@ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-cloud-security-sender: frederick.melville@iis.fraunhofer.de X-cloud-security-recipient: mmusic@ietf.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mx-gate02-haj2 with 19C686EC009 X-cloud-security: scantime:.8523 X-Mailman-Approved-At: Fri, 17 Aug 2012 14:32:18 -0700 Subject: [MMUSIC] Using SDP Media Capabilities for AAC Signalling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 17:43:07 -0000 --Apple-Mail=_181BAAFC-D408-4B83-82ED-39CE0F133AFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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=3Daudio 49170 RTP/AVP 96 a=3Drtpmap:96 mpeg4-generic/48000/2 a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D15; mode=3DAAC-hbr; = config=3DAAA111; sizeLength=3D13; indexLength=3D3; indexDeltaLength=3D3; = constantDuration=3D1024 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. =20 (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. =20 (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 --Apple-Mail=_181BAAFC-D408-4B83-82ED-39CE0F133AFC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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=3Daudio 49170 RTP/AVP = 96
  a=3Drtpmap:96 mpeg4-generic/48000/2
  = a=3Dfmtp:96 streamtype=3D5; profile-level-id=3D15; mode=3DAAC-hbr; = config=3DAAA111; sizeLength=3D13; indexLength=3D3; indexDeltaLength=3D3; = constantDuration=3D1024

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

= --Apple-Mail=_181BAAFC-D408-4B83-82ED-39CE0F133AFC--