headers
Worley, Dale R (Dale | 9 May 2011 20:57
Favicon

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

> From: Worley, Dale R (Dale) [dworley <at> 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:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Worley, Dale R (Dale | 9 May 2011 21:26
Favicon

draft-ietf-sipping-media-policy-dataset: Bandwidth limitations

The media-policy-dataset provides 3 different bandwidth limitations:

max-bw
max-session-bw
max-stream-bw

Comparing the description of these (section 7.3 et seq.) with the description of
the b= line in SDP (RFC 4566 section 5.8) turns up a lot of ambiguity in the
definitions.

It seems to me to be clear that the max-stream-bw number corresponds to the "b=AS:..." line
in an SDP media description -- the bandwidth used by one direction of one media
stream.

The max-session-bw seems to correspond to the "b=AS:..." line in the *session* description,
the total bandwidth used (in one direction) by the whole session.

The max-bw number is less clear.  It seems to be intended to limit the total bandwidth used
by an agent (across all of the sessions it participates in).  As such, it can't be translated to
an SDP attribute.

Conversely, the "b=CT:..." line in an SDP session description seems to be intended to
describe the total bandwidth used by a "conference" (whatever that is).  It's not clear
what the significance of that is exactly, since the agent in question may not be the conference
focus, and indeed, the session may not be part of a "conference".

Thoughts?

Dale
_______________________________________________
(Continue reading)

Permalink | Reply | 2 comments |
headers
Worley, Dale R (Dale | 10 May 2011 21:54
Favicon

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

I see commented-out text about these bandwidth descriptions:

    The <max-bw-ti> Element

      The <max-bw-ti> element defined as the <max-bw>
      element with the following exceptions.

      The given bandwidth limit is transport independent and
      therefore does not include include the bandwidth needed for
      lower-layer transport and network protocols (e.g., UDP and
      IP).

      The bandwidth limit is given in bits per second (i.e., not in 
      kilobits per second).

      The <max-bw-ti> element MAY have the following
      attribute (see <xref target="sec_attributes" />): pprate.  

   The maxprate attribute

      The <max-bw-ti> element has an optional attribute
      'maxprate'. The "maxprate" value is the maximum packet rate
      calculated over all the declared media streams.  If this can't
      be measured (stored media) or estimated (live), the sum of all
      media level values provides a ceiling value.

      All other attributes and merging rules are defined as for the 
      <max-bw> element.

Do people think these data are significant, or can they be safely omitted from
(Continue reading)

Permalink | Reply | 1 comment |
headers
Worley, Dale R (Dale | 12 May 2011 00:10
Favicon

draft-ietf-sipping-media-policy-dataset: Bandwidth limitations

I have updated the definition of the <max-stream-bw> element to remove
the "label" and "media-type" attributes, which in the previous version
were used to limit the effect of the bandwidth limitation to
particular media types or one particular stream.

Doing this makes <max-stream-bw> work the same way as other elements.

Limiting the bandwidth for streams of a particular media type can be
done by the usual method of a <stream> that has both <media-type> and
<max-stream-bw> children:

    <session-policy>
      <stream>
	<media-type>video</media-type>
	<max-stream-bw>1000</max-stream-bw>
      </stream>
    </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 sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |
headers
Worley, Dale R (Dale | 18 May 2011 18:33
Favicon

session-info <token> value

There is a "token" value which is passed from a policy server to a UA.  The token value is the content of a
<token> element in the session-info document, so in general it is a sequence of Unicode characters.  The UA
uses it when it makes certain requests by adding a Policy-Info header of the form:

Policy-Info: sip:foo <at> example.com;token=xyzzy

where the value of the "token" parameter is the content of the <token> element in the session-info that it
was given.

The question is what characters are permitted in the token value?

The only limitation on the session-info document is that it consist of Unicode characters.  But in order to
put it in a parameter value, it must be representable there.  Parameter values use %-escaping, so
characters from U+0020 (space) to U+007E (~) can easily be accommodated.  If we use %80 to %FF to represent
the characters from U+0080 to U+00FF, we can add the Latin-1 set.  Or we could assume that %-escaping is used
to encode *bytes* used in the *UTF-8* representation of characters, in which case the entire Unicode set
is representable.  (Since the semantics of %-escaping is not described anywhere in RFC 3261, either of
these is possible.)

It seems to me that limiting the characters to U+0020 through U+007E, the ordinary ASCII set, is enough
flexibility and avoids all sorts of complications.

Dale
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gonzalo Camarillo | 20 May 2011 14:21
Picon
Favicon

Re: session-info <token> value

Hi,

yes, I think limiting the valid characters to something simpler (UTF8 or
ASCII) makes sense.

Cheers,

Gonzalo

On 18/05/2011 7:33 PM, Worley, Dale R (Dale) wrote:
> There is a "token" value which is passed from a policy server to a UA.  The token value is the content of a
<token> element in the session-info document, so in general it is a sequence of Unicode characters.  The UA
uses it when it makes certain requests by adding a Policy-Info header of the form:
> 
> Policy-Info: sip:foo <at> example.com;token=xyzzy
> 
> where the value of the "token" parameter is the content of the <token> element in the session-info that it
was given.
> 
> The question is what characters are permitted in the token value?
> 
> The only limitation on the session-info document is that it consist of Unicode characters.  But in order to
put it in a parameter value, it must be representable there.  Parameter values use %-escaping, so
characters from U+0020 (space) to U+007E (~) can easily be accommodated.  If we use %80 to %FF to represent
the characters from U+0080 to U+00FF, we can add the Latin-1 set.  Or we could assume that %-escaping is used
to encode *bytes* used in the *UTF-8* representation of characters, in which case the entire Unicode set
is representable.  (Since the semantics of %-escaping is not described anywhere in RFC 3261, either of
these is possible.)
> 
> It seems to me that limiting the characters to U+0020 through U+007E, the ordinary ASCII set, is enough
(Continue reading)

Permalink | Reply | 0 comments |
headers
Worley, Dale R (Dale | 20 May 2011 22:25
Favicon

draft-ietf-sipping-media-policy-dataset: media-intermediaries

The media policy dataset defines an XML element <media-intermediaries> for specifying intermediary
relays that should be used for sending media.  The current draft has some odd features with regard
to this element:

- It can be specified for a session-info but not a session-policy.  Whereas it seems to me that it should
be possible to put a media intermediary specification into a policy.

- <media-intermediaries> is specified as a child of <session-info>, with various complexities to allow
particular intermediaries to be specified for particular streams.  But it seems simpler to me to demote
<media-intermediaries> to a child of <stream>, so that the intermediaries for each stream can be
specified directly.

- The handling of media streams that use multiple ports is not specified clearly.  My impression is that the
only such protocol is RTP, which uses one port for the media (RTP proper) and one port for control information
(RTCP).  Are there any other protocols that use multiple ports?

Dale
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |
headers
Worley, Dale R (Dale | 23 May 2011 20:49
Favicon

media-policy-dataset: <local-ports>

draft-ietf-sipping-media-policy-dataset defines a <local-ports> restriction which a policy server
can use to inform a UA what ports it may use for sending/receiving media.  I'd like to make two changes to the
current definition:

1) Allow specifications in which the "start" port is greater than the "end" port.  These specifications
permit *no* ports to be used, and hence no sessions are in conformance with the policy.  This is not a useful
facility for configured policies, but it makes it possible to to construct the logical AND of two policies
that make incompatible restrictions on the local port numbers.

2) Change the merging rule from "the local policy controls" to "the intersection of the two specified
ranges".  In practice, we expect only the most local policy to restrict what ports can be used.  But it would
help to make the merging process more consistent if it was specified as a "logical AND" of all the specified restrictions.

Dale
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |
headers
Worley, Dale R (Dale | 31 May 2011 21:33
Favicon

FW: Progressing draft-ietf-sipping-media-policy-dataset

From: Worley, Dale R (Dale)
Sent: Thursday, May 12, 2011 5:56 PM
To: Gonzalo Camarillo
Subject: RE: Progressing draft-ietf-sipping-media-policy-dataset

I just ran into something I had overlooked.  I've been taking the Abstract seriously when it says "It can be
used to describe the properties of a specific SIP session or to define policies that are then applied to
different SIP sessions."  That is, I've assumed that a session-policy is sort of a generic session-info
whose <stream>s show what sorts of <stream>s are permitted in a conforming session-info.  This is what
lead to the "implicit Boolean logic" message.

But when I look at the examples, I see that session-policy and session-info documents have completely
different structure.  The session-policy is a collection of elements, each of which specifies a
particular restriction on conforming session-info's.  And in particular, a session-policy does not
contain stream elements.

A certain amount of my editing has been driven by this misconception, although I don't think it would take
much work to reverse those edits.

The high-level question is whether we want to stay with the original scheme, where session-policy's have a
distinctly different structure, or whether we want to go with my misconception, where session-policy
are template session-info documents.

The original scheme would be easier for people to understand and thus to implement, but it has the
limitation that one has to specifically define an element to represent every restriction that anyone
will want to use.  The "new" scheme requires more abstract thought, but it automatically provides ways to
make restrictions in every feature that can be expressed in a session-info, and so extensions of the data
set require less design, and the processing code can be written in a more generic way.

What do you think?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane