Subject: [MMUSIC] Need input on SDP "multiple ptime" parameter proposal

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 23 Jul 2002 10:49:31 -0400

Mmusic experts,

I am hoping you can provide opinions on a proposed SDP alteration that is
being considered by PacketCable, but I think is of use to both SIP and
MEGACO.

MEGACO and SIP (as well as MGCP/NCS which is used by PacketCable) use the
offer/answer model with SDP for achieving negotiation while we all wait for
SDPng.  PacketCable has discovered that while multiple codecs are often
specified in one m= line, only one ptime can be specified across all those
codecs.  The offshoot of this is that individual packetization rates for
each codec cannot be specified (without going through some gyrations which
will make the SDP grow significantly, and which draws a question about
alternatives versus simultaneous transmission that isn't easily answered).
This limitation then removes the possibility of a media gateway controller
controlling bandwidth allocations during the negotiation process between two
media gateways.  This control has turned out to be very important for QoS
reservations.

A solution that has been proposed is a new SDP "multiple ptime" parameter
(a=mptime) that will take a list of packetization rates seperated by
semicolons; one entry for each encoding algorithm in the associated m= line.
Those algorithms to which packetization rate doesn't apply (like 96 -
telephone event) will have a dash for the appropriate entry.

I have read in the charter that most items of this nature will be deferred
to SDPng.  However, we have a real opportunity here to prevent the protocols
that use SDP for negotiation from diverging with each other and becoming
non-interoperable by defining their own proprietary extensions to SDP.  I
believe that this addition would fall within the spirit of the charter, as
this extension is within the framework of SDP.

What are your opinions of this proposal?  My plan is to issue an I-D for
eventual promotion to Informational RFC status, and then to push in the
negotiating protocols for utilization of the new parameter.  However, if the
working group is dead-set against such an addition, then I will not bother,
and I'll seek other methods of keeping the negotiating protocols from
deviating from each other.

Thanks for your consideration.

Kevin
--
Kevin J. Boyle II
Nortel Networks
+1 919 991 2690

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 24 Jul 2002 17:22:43 -0400

>alternatives versus simultaneous transmission that isn't easily answered).

Could you elaborate on what you mean here? 

>this extension is within the framework of SDP.

We're getting strong input from our Area Directors to keep QoS extensions
out of SDP, and to leave such work for SDPng where it can be done properly.

>deviating from each other.

I'd like to see discussion of alternative mechanisms, for example FID, too.
Your proposal is one solution to the problem, I'm not yet convinced that
there are not other solutions using existing mechanisms.

Colin