Re: draft-ietf-sipping-media-policy-dataset: Bandwidth directionality

"Worley, Dale R (Dale)" <[email protected]> Mon, 9 May 2011 14:57:47 -0400
Newsgroups gmane.ietf.sipping
Message-ID <CD5674C3CD99574EBA7432465FC13C1B22246BD46E@DC-US1MBEX4.global.avaya.com>
> From: Worley, Dale R (Dale) [[email protected]]
> 
> 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
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP