Re: [Sipping] draft-ietf-sipping-media-policy-dataset: Bandwidth directionality

"Worley, Dale R (Dale)" <dworley@avaya.com> Mon, 09 May 2011 19:01 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: sipping@ietfa.amsl.com
Delivered-To: sipping@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22B3E080E for <sipping@ietfa.amsl.com>; Mon, 9 May 2011 12:01:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.404
X-Spam-Level:
X-Spam-Status: No, score=-102.404 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 FTxeK+JBBA6b for <sipping@ietfa.amsl.com>; Mon, 9 May 2011 12:01:44 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8B98DE0787 for <sipping@ietf.org>; Mon, 9 May 2011 12:01:02 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAOY3yE2HCzI1/2dsb2JhbACmAneIcaJXAptdhgwElCqKNA
X-IronPort-AV: E=Sophos;i="4.64,341,1301889600"; d="scan'208";a="278976028"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 09 May 2011 14:57:48 -0400
X-IronPort-AV: E=Sophos;i="4.64,341,1301889600"; d="scan'208";a="649370437"
Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 09 May 2011 14:57:48 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.201]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Mon, 9 May 2011 14:57:47 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "Worley, Dale R (Dale)" <dworley@avaya.com>, "sipping@ietf.org" <sipping@ietf.org>
Date: Mon, 09 May 2011 14:57:47 -0400
Thread-Topic: [Sipping] draft-ietf-sipping-media-policy-dataset: Bandwidth directionality
Thread-Index: AQHL3RUNafBx19X2g0mVkymy0YZjuZSFOQPd
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22246BD46E@DC-US1MBEX4.global.avaya.com>
References: <CD5674C3CD99574EBA7432465FC13C1B220B5C1555@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B220B5C1555@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [Sipping] draft-ietf-sipping-media-policy-dataset: Bandwidth directionality
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2011 19:01:48 -0000

> From: Worley, Dale R (Dale) [dworley@avaya.com]
> 
> One problem I'm noticing is that the session-policy XML allows
> specifying the bandwidth in each direction, but SDP does not (as far
> as I can tell).  How should we resolve this?  Should we define
> directional bandwidth modifiers in SDP?  Or should we restrict
> bandwidth in a stream based on the directionality attributes of the
> stream?
> 
> That is, if the sending bandwidth is limited to 10,000 and the
> receiving bandwidth is limited to 100,000, then an a=sendrecv stream
> would be have b=10000 but an a=recv stream would have b=100000.

That was a misunderstanding on my part.  The solution to bandwidth
directionality is that there are two SDPs, an offer and an answer, and
each has a separate b= line.  The session-policy's bandwidth limit is
applied to the offer and answer as they are generated (or received).

Detail to remember:  An SDP offer or answer describes what the sender
of the SDP wishes to *receive*.  (Despite that a standalone SDP
describes what the sender will be sending.)

Detail to remember:  The format of the b= line in this case is:
        b=AS:<bandwidth in kbits/sec>

Thus, in the case of 10 kbits/sec sending and 100 kbits/sec receiving,
the SDP sent would have "b=AS:10" and the SDP received would have (or
would be modified to have) "b=AS:100" (as session-level attributes).
The session-policy XML would be:

        <session-policy>
          <max-bw direction="sendonly">10</max-bw>
          <max-bw direction="recvonly">100</max-bw>
          ...
        </session-policy>

Dale