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

From: Christian Groves <[email-masked]>
Date: Mon, 18 Jun 2007 17:55:30 +1000

Hello Stephen,

I didn't see what H.248 command/flow that you want to be able to 
support? Did you want to the MGC to CHOOSE a media type (single group) 
based on a list of ptimes it provides? Or CHOOSE a media type (single 
group) and then get the list of ptimes? or CHOOSE on a single group and 
get back multiple groups? or? An example of the flow you want would be 
good. There are other mechanisms e.g. ReserveValue, Overspecification, 
choose on ptime etc I'm not sure if these may be suitable.

Is it correct that you are advocating not to use the ReserveGroup 
concept in general as your arguments seem to be general in nature?

Regards, Christian

Stephen Mell (CV/ETL) wrote:
>
> 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
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
>   

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

---

From: "Stephen Mell (CV/ETL)" <[email-masked]>
Date: Mon, 18 Jun 2007 11:54:10 +0200

Christian,

I wanted to make an initial proposition that within H.248 framework it
might be possible to solve the problem of matching packet times
unambigously with media types, in cases where more than one media type
is offered, by using:

Multiple groups, each with fully specified media type and a ptime
attribute which unambiguously relates to that media type

rather than,

Single group with overspecified or underspecified media type, in which
the ptime attribute must apply to all media types

So a change in protocol style employed by the MGC, rather than a change
in protocol.

Then I wanted to show a couple of reasons why this is not generally an
adequate solution to the "multiple ptimes" problem.

If you follow this line in an implementation, then you ALWAYS having to
use using multiple groups, then you are limited from use
over/underspecified values in a single group.

So my arguments are really only stating that it is important to retain
the freedom to use both mechanisms (single group with over/under/full
specification AND multiple group).

To use Multiple Groups purely for the purposes of unambiguously matching
packet-time to media type is in itself OK, but the danger is that an MGC
implemenatation is restricted by this and can no longer employ the
Single Group Construct with under/overspecification, which is useful in
itself.

I have no general issue with using Multiple Groups (with or without
reserveGroup). I just think that implementations should not be compelled
to use Multiple Groups just for the purposes of solving this particular
problem, when they would have otherwise used a single group with
over/under specified values.  

My conclusion is that the "multiple ptimes" problem actually requires a
solution in SDP iteslf, and its not a good strategy to try and work
around the problem by changing the style of H.248 employed to carry it.

Hope this is clearer.

Steve 

-----Original Message-----
From: Christian Groves [mailto:[email-masked]] 
Sent: 18 June 2007 08:56
To: Stephen Mell (CV/ETL)
Cc: [email-masked]; megaco ietf
Subject: Re: [MMUSIC] RE: New draft: multiple times problem
description:draft-garcia-mmusic-multiple-ptimes-problem-00.txt

Hello Stephen,

Regards, Christian