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

From: Miguel Garcia <[email-masked]>
Date: Fri, 01 Jun 2007 09:05:06 +0300

Hi Joe:

Thanks for your valuable comments. Some more inline discussion.

Joe Stone (joestone) wrote:
> Hi Miguel,
> 
> [js] Comments in line...
> 
> More seriously now... I didn't want to have a discussion on the exact
> semantics on those attributes, I understand that I a summary of a few
> words may offer the wrong impression.
> 
> [js] Yes, I'm simply suggesting that we could more accurately paraphrase
> rather than take a single sentence out of context.

Fine, point taken.

> 
> The idea with that text is to highlight that the same problem has been
> discussed in the past elsewhere with different type of solutions. If the
> text is offensive, I can remove the references in a future version of
> the draft.
> 
> [js] I certainly wouldn't remove the references. These references
> contain viable solutions.
> 
> [js] I'd also like to point out the PacketCable Call Management Server
> Signaling Specification,
> 
> 	
> http://www.packetcable.com/downloads/specs/PKT-SP-CMSS1.5-I04-070412.pdf
> 
> [js] Section 8.4.10 of this specification deals with SIP-NCS/TGCP SDP
> interworking. We could consider this in the (slightly) more general
> context of SIP-xGCP SDP interworking where xGCP refers to MGCP and its
> variants (including NCS, TGCP, ...). For example, section 8.4.10.1
> deals with the fact that preferred SIP call hold SDP syntax
> ("a=sendonly" SDP attribute, IP address "0.0.0.0", ...) is commonly
> ignored or rejected by xGCP implementations. I wanted to highlight
> section 8.4.10.2 which deals with ptime and mptime SDP interworking.
> This section addresses the relationship between the packetization period
> *value* of the "a=ptime" SDP attribute and the possible packetization
> period *values* of the per media format "a=mptime" SDP attribute
> assuming the two co-exist as part of the same media description for
> backward compatibility. This issue would need to be addressed with any
> per media format packetization period approach.

Thanks for the pointer, I think this is good input when we start 
discussing solutions.

> 
>> I think that you've understated the problem of existing packetization 
>> period semantics being nothing more than a preference or 
>> recommendation (as it relates to actually sending based on the
> "negotiated"
>> packetization period). If we can agree on per media format 
>> packetization period syntax and semantics, have we really solved the 
>> problem if the "negotiated" packetization period is nothing more than
> a recommendation?
> 
> This is a point for discussion. The text about ptime in RFC 4566 says: 
> "It should not be necessary to know ptime to decode RTP or vat audio,
> and it is intended as a recommendation for the encoding/packetisation of
> audio. "
> 
> If you agree with the text, then there is nothing to negotiate. It is
> only that the SDP creator should have the means to express: "hey, I
> would understand any packetization time you send me for this media
> format, but if you happen to be able to use xx ms. packetization time, I
> will get better performance, so please, please, please, use that
> packetization time.". But at the end of the day, it is up to the RTP
> sender to decide the packetization time for that particular media type.
> 
> [js] There's the world of I-Ds and RFCs and then there's reality. Dan
> Wing's E-mail points out the reality that some implementations can't
> change between codecs on-the-fly. There's a similar reality in that some
> implementations can only send and receive using a finite set of
> packetization periods (in some cases a single packetization period). I'm
> sure that we've all seen cases of one-way audio (or no audio) in which
> the two parties failed to agree on a common, bi-directional
> packetization period. RFC 3551 suggests, "A receiver SHOULD accept
> packets representing between 0 and 200 ms of audio data". The reality is
> that not all implementations can accept packets over that entire range.
> We can dismiss these implementations as non-compliant or we can
> recognize these as real problems in need of a solution. In addition,
> intermediary devices which shape or police may depend on a negotiated
> packetization period which is more than simply a recommendation. 

I agree with you: sometimes there are statements in RFCs that are not 
easy to implement. You just pointed out one. So, I think this is the 
most important issue we should be discussing. If the packetization time 
is a plea the solution is much simpler than if it is a negotiation. I 
acknowledge the implementation report, which we can't just simple 
obviate. This gives background to further discuss the problem and try to 
derive requirements.

/Miguel

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

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

---

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

Hi Stephen:

Thanks for your post. Some inline comments.

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.

Great

> 
> Joe Stone has focussed on the interoperability of end points in his 
> 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.

> 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.

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.

> 
> 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.

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.

> 
> 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).

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.

> 
> 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).

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.

> 
> 
> 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.

Great

> 
> 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.

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.

> 
> 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.

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

/Miguel

> Regards,
> Steve

---

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

Hello List,

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

Regards,

Steve