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

I think think that your Problem Statement has short-changed the
"maxmptime" SDP attribute of V.152,

	One of these mechanisms is the 'maxmptime' attribute, defined
	in the ITU-T Recommendation V.152 [ITU.V152], which "indicates
the
	supported packetization period for all codec payload types".  

The complete definition of the 'maxmptime' SDP attribute follows,

	In addition to negotiating support of V.152 and the
corresponding RTP payload type, a V.152 implementation should include
the 'maxmptime' attribute (maximum multiple ptime) to indicate the
supported packetisation period for all codec payload types. 

	a=maxmptime:<list of packet times separated by space>
	This attribute is a media-level attribute. The maxmptime
attribute defines a list of maximum packetisation time values, expressed
in milliseconds, the endpoint is capable of using (sending and
receiving) for this connection. There shall be precisely one entry in
the list for each <format> entry provided in the "m=" line. Each entry
is separated by a space. Entry number j in this list defines the maximum
packetisation time for entry number j in the "m=" line. The first entry
in the list shall be a decimal number whereas subsequent entries in the
list shall be either a decimal number or a hyphen. For those media
formats where a single maximum packetisation rate does not apply (e.g.
non- voice codecs such as telephone-event or comfort noise), a hyphen
("-") shall be included at the corresponding location in the list of
packetisation periods.
	When receiving an SDP session description the maxmptime
attribute conveys the list of maximum packetisation periods that the
remote endpoint is capable of using for this connection; one for each
media format in the "m=" line. For media formats whose packetization
period is specified as a hyphen ("-"), the VBD gateway shall use one of
the maximum packetization periods that was actually specified in the
list. 
	The "a=ptime" attribute  defined in RFC 2327 shall be ignored if
the SDP session description contains the "maxmptime" attribute. 
	If the "maxmptime" attribute is absent, then the value of the
"ptime" attribute, if present, shall be taken as indicating the
packetization period for all codecs present in the "m=" line.
	If neither the 'ptime' nor 'maxmptime' attribute are present in
the SDP session description, then a V.152 implementation shall assume
the default packetisation period defined in RFC3550 (which is 20 ms for
G.711 and G.726-32k). A V.152 implementation shall not transmit V.152
packets with a packetisaton time greater other than the one offered by
the remote end.

With the 'maxmptime' SDP attribute, there is one maximum packetization
period value (possibly "-") for each media format (payload type) in the
media description.

You've misrepresented the PacketCable 'mptime' SDP attribute,

   Another
   one is the 'mptime' attribute, defined in the PacketCable Network-
   Based Call Signaling Protocol Specification [PKT.PKT-SP-EC-MGCP],
   which indicates "a list of packetization period values the endpoint
   is capable of using (sending and receiving) for this connection".
   While all have similar semantics, there is obviously no
   interoperability between them, creating a nightmare for the
   implementor who happens to be defining a common SDP stack for
   different applications.

defined in the PacketCable Network-Based Call Signaling Protocol
Specification,

http://www.packetcable.com/downloads/specs/PKT-SP-NCS1.5-I03-040712.pdf

and the PacketCable PSTN Gateway Call Signaling Protocol Specification,

http://www.packetcable.com/downloads/specs/PKT-SP-TGCP1.5-I03-040712.pdf

The 'mptime' SDP attribute is more than "a list of packetization period
values the endpoint is capable of using (sending and receiving) for this
connection". The complete definition of the 'mptime' SDP attribute
follows,

	mptime:

	This attribute is a media-level attribute defined by
PacketCable. The mptime attribute defines a list of packetization
	period values the endpoint is capable of using (sending and
receiving) for this connection.

		Send: The mptime attribute MUST be present. There MUST
be precisely one entry in the list for
		each <format> entry provided in the "m=" line. Entry
number j in this list defines the
		packetization period for entry number j in the "m="
line. The first entry in the list MUST be a
		decimal number whereas subsequent entries in the list
MUST be either a decimal number or a
		hyphen. For those media formats where a single
packetization rate does not apply (e.g., nonvoice
		codecs such as telephone-event or comfort noise), a
hyphen ("-") MUST be encoded at
		the corresponding location in the list of packetization
periods.

		Receive: Conveys the list of packetization periods that
the remote endpoint is capable of using for this
		connection; one for each media format in the "m=" line.
For media formats whose
		packetization period is specified as a hyphen ("-"), the
endpoint MUST use one of the
		packetization periods that was actually specified in the
list. If the "mptime" attribute is
		absent, then the value of the "ptime" attribute, if
present, MUST be taken as indicating the
		packetization period for all codecs present in the "m="
line.

and note the PacketCable semantics related to the 'ptime' SDP attribute,

	ptime:

		Send: The ptime SHOULD be sent if it was received in a
Remote Connection Descriptor or if the
		CMS used the packetization period ('p:')
LocalConnectionOption.

		Receive: The field MUST be ignored if the SDP contains
the "mptime" attribute (as required in
		PacketCable compliant devices). If the "mptime"
attribute is not present, then this field is
		used to define the packetization interval for all codecs
present in the SDP description and the
		MTA MUST use the ptime in the calculation of QoS
reservations.

With the 'mptime' SDP attribute, there is one packetization period value
(possibly "-") for each media format (payload type) in the media
description.

There's no "interoperability nightmare" within the context in which the
'mptime' SDP attribute is defined. The above semantics state that the
'mptime' SDP attribute takes precedence over the 'ptime' SDP attribute,
if present. An implementation which does not recognize the 'mptime' SDP
attribute must ignore it. Note that similar precedence rules *could* be
defined between the 'maxptime' and 'maxmptime' SDP attributes. 

Your Problem Statement should address the issue of backward
compatibility. Regardless of your final solution, the proposed syntax
and semantics must be backward compatible with existing implementations.
PacketCable addresses backward compatibility through the precedence
rule, the fundamental SDP principle of ignoring unrecognized attributes,
"offers" which include both old and new syntax and "answers" which are
consistent (in terms of syntax) with "offers".

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 problem (the lack of "strict" negotiation) isn't unique to
packetization period. I think that there's a general solution that we
can discuss at a later date.

I appreciate the fact that you're attempting to finally bring closure to
this long-standing issue.

Joe