I am starting work on a messy part of the media policy dataset
definition: Specifying the logic when a policy is applied to a
session-info, and also specifying how two policies are combined to
apply jointly to session-infos. The goal is to implement one's
intuitive expectations while introducing as few special cases as
possible.
My current analysis is:
- The primary operation is applying a session-policy to a session-info
to produce a possibly more restricted session-info. This is done by
applying the session-policy to each stream in turn, which may
"restrict" the stream (in regard to bandwidth, codecs, etc.).
- A stream may be restricted to the point that it permits no media
whatsoever. Such "null" streams are all logically equivalent,
although a null stream can be represented in many different ways.
When translated back into SDP, a null stream becomes a rejected
m= line.
- The different <stream> elements in a session-policy are effectively
ORed together, in that the policy intends to permit any stream that
conforms to *any one* of the <stream> elements. This is necessary
because e.g. a session-policy can contain one <stream> that specifies
audio media and restricts the codecs permitted for audio, and
another <stream> that specifies video media and restricts the codecs
permitted for video.
- Thus, applying a session-policy to a stream involves applying each
session-policy <stream> to the stream, and then choosing the "best"
result. In practice, we expect that the streams admitted by the
session-policy <stream> elements to be disjoint (e.g., one is for
audio, one is for video), so the result of applying any but one
<stream> will be a null stream, and the "best" result will be the
only non-null result.
- The alternative strategy of "unioning" the results of applying each
<stream> element cannot be used because it can allow the resulting
session to exceed all of the <stream> element policies. Consider
the policy
<streams>
<stream> codecs: audio/foo, bandwidth: 10 </stream>
<stream> codecs: audio/foo,audio/bar, bandwidth: 1 </stream>
</streams>
applied to the requested stream "codecs: audio/foo,audio/bar,
bandwidth: 10". The result of restricting with the first <stream>
is "codecs: audio/foo, bandwidth: 10" and the result of restricting
with the second <stream> is "codecs: audio/foo,audio/bar, bandwidth:
1". The union of the two (the "smallest" stream that contains them
both) is "codecs: audio/foo,audio/bar, bandwidth: 10", which is not
allowed by either <stream>.
- Within this context, combining two policies to form a joint policy
that enforces both their restrictions simultaneously is simple: The
resulting policy is made by "intersecting" all possible pairs of
<stream>s, one from the first policy and one from the second policy.
(Intersections that result in null policies can be dropped from the
result.)
- I haven't studied the role of the directional attributes yet, but
currently I believe that a bidirectional session-info <stream> can
be treated as an abbreviation for two session-info <stream>s, one in
each direction, and a bidirectional session-policy <stream> can be
treated similarly. Or, directionality can be treated as an
attribute with two possible values, *with identical results*.
Comments?
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@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
