Subject: [Megaco] RE: [MMUSIC] New draft: multiple times problem description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt

From: "Stephen Mell (CV/ETL)" <[email-masked]>
Date: Sun, 17 Jun 2007 20:29:27 +0200

Hi Miguel,

I would strongly agree that there is a need to explicitly specify an
exact packetisation time per media type within SDP.

Joe Stone has focussed on the interoperability of end points in his
postings; I think that the network itself also deserves some
consideration.

The maxmptime attribute given in V.152 (and I guess also the packetcable
"mptime" attribute) also helps prevent the endpoints from generating a
packet *SIZE* which is too large for the network, but I don't know of a
mechanism that allows the endpoints some flexibility in negotiating and
choosing packet times whilst still preventing them from from generating
a packet *RATE* which is considered too large for network.

Given that network restrictions can often be expressed in terms of these
limits of sizes and rates, then a "minptime" (single valued) attribute
could perhaps be considered, so that endpoints can be given an offer
which allows them to choose (or negotiate, via an intermeddiary) a media
flow with charectersitics which falls within these twin constraints of
Maximum Payload size and Maximum Packet Rate.

Having said that, we should also consider that in general, network
policing policy may need to be defined more rigorously, such that only
flows which exactly match specific traffic criteria are admitted and/or
transitted on policed parts of a network. Also real-world endpoint
implementations may impose additional restrictions on what combinations
of media types and packetisation times can be supported (or at least
viable without excessive use of available resources).

For these reasons I think that it is more important to address the issue
of providing an exact packetisation time for each media type (allowing
the media flow to be exactly specified) than it is to provide a flexible
framework (allowing the media flow to be bounded within certain
constraints).

My particular interest is in H.248. I've considered the problem with
respect to H.248, and come to the conclusion that a solution to the
"multiple ptimes" problem would be beneficial to interoperability, and
that H.248 does not in itself provide any solution to the problem.

The arguments relating to H.248 follow:

Within H.248 there are facilities which exist which allow multiple SDPs
(each containing exactly one media section, m line) to be passed from
Controller to Gateway, with flags (ReserveGroup) which instruct the
Gateway to reserve either one (ReserveGroup=Off) or all
(ReserveGroup=On) of the SDPs (referred to as Groups).

At first sight, this might seem to provide H.248 with an escape from the
"multiple ptime" problem. By using multiple SDP groups, each with its
own "ptime" attribute and a single fully specified media type, the
specification of per-media type packetisation time can be achieved.

However this is problematic, as it restricts the Controller from using a
single Group, with ReserveValue=On, and CHOOSE  ( "$" ) as the media
type, thus allowing the Gateway to choose a number of different media
types to reserve, according to the support for codecs, availablitity of
codecs, and importantly, the Gateways own preference policy with regard
to codecs.

To solve the "multiple ptimes" problem by using multiple groups, the
Controller must always fully specify the media type in each SDP group,
These use of underspecified or overspecified media types in the
controllers offer could mean (when ReserveValue=On) that the combination
of media type and packet time in the Gateway's Answer is no longer
unambiguous. The CHOOSE facility allows the Controller to know nothing
about the media types that are supported on the network and delegate
responsibility for the media selection entirely the Gateways. This
CHOOSE facility cannot therefore be used, if the "multiple ptimes"
problem were tackled this way, using multiple groups, as the use of
mutiple groups defines a convention that then limits the use of other
constructs within the protocol.

Also each of the SDPs (Groups) has its own Session details eg: When
using multiple groups it is harder for the Controller to prevent the
Gateway from allocating separate session details to each of the groups.
Commonly, the controller will ask the Gateway to choose its own session
settings for each group and the Gateway then is at liberty to assign
different session details (inc. addressing details) to each SDP Group.
Where switching between reserved media types is subsequently
co-ordinated by the Controller this is not a problem. When autonomous
switching between the reserved media types occurs, as in the case of the
V.152 fallback mechanism, the consequences are disasterous; the switch
to a reserved non-compression codec must *NOT* be accompanied by a
change in source address as the the far end would then interpret this as
barge-in and ignore the packets.

To avoid the above problem and ensure that reservation of multiple
groups is made with the same session details in each Group, the Gateway
would require two reservation requests rather than one. The first
reservation would ask for single group asking the Gateway to add its
address details, and the second reservation would ask the Gateway to
reserve both groups with the identical address details explicitly,
learned from the first reservation response,  supplied by the controller
in each group. This makes the "multiple groups" solution to the
"multiple ptimes" problem start to make the H.248 a little unwieldy.

In conclusion, I believe, due to these two arguments, that H.248 doesn't
provides any viable workaround for the "multiple ptimes" problem, when
SDP is carried over H.248.

Regards,

Steve 
_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Miguel Garcia <[email-masked]>
Date: Mon, 18 Jun 2007 10:04:45 +0300

Hi Stephen:

Thanks for your post. Some inline comments.

> exact packetisation time per media type within SDP.

Great

> postings; I think that the network itself also deserves some consideration.
> 
I agree, there are different scenarios we should consider. I always
thought this was related to network constraints, but Joe indicated that
implementations in endpoints have restrictions, so we need to take both
into account.

> a packet *RATE* which is considered too large for network.

I guess packet rate is a a complex issue, which depends primarily on the
selected codec. I would say that this is a separate topic.

> Maximum Payload size and Maximum Packet Rate.

I think, based on the discussions, we are heading to a direction where
we are going to need some sort of threshold for the packetization time,
which is negotiated between the endpoints. In other cases, where
negotiation is not really needed, a hint might be enough.

> viable without excessive use of available resources).

I agree, the network policy in many cases influence these decisions.
There are quite a few options for transferring the policy to the
endpoints, all of them are outside the scope of the problem. So, I think
we need to consider that there might be a mechanism for the endpoint to
discover a policy that affects the packetization time. And we should
take this into account.

> framework (allowing the media flow to be bounded within certain 

I think we are going to need to both. In fact, an interval of
packetization times can be set to a fixed limit, if both limits are equal.

> that H.248 does not in itself provide any solution to the problem.

Great

> specification of per-media type packetisation time can be achieved.

Something similar has been suggested as a solution, not only for H.248.
I don't like grouping, or in this case, ungrouping codecs, just because
of a simple limitation in the protocol.

> SDP is carried over H.248.

The conclusion is as expected, thanks for making it 100% clear.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland