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

From: "Joe Stone \(joestone\)" <[email-masked]>
Date: Wed, 30 May 2007 20:55:15 -0700

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
 
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Miguel Garcia <[email-masked]>
Date: Thu, 31 May 2007 11:12:33 +0300

Hi Joe:

Thanks for your comments.

You probably have noticed that the quoted text in the draft has been 
copied from the corresponding specification, so if you think the quoted 
text is wrong, don't shoot the messenger :-)

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.

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.

Some more discussion below.

> defined between the 'maxptime' and 'maxmptime' SDP attributes.

Right, this is correct. However, by "interoperability nightmare" I meant 
the possibility of two independent SDP implementations to interoperate, 
if one has been customized for, say, V.152, and the other had 
implemented a proprietary mechanism. They won't interoperate for the 
packetization time per media type. Or, in other words, they interoperate 
(for the packetization time per media type) as long as both SDP 
implementations are in the same context, I mean, both follow what V.152 say.

> and semantics must be backward compatible with existing implementations. 

Agreed, it is assumed that whatever solution the IETF develops should be 
backwards compatible. I don't mind mentioning it explicitly in a future 
version of draft.

> consistent (in terms of syntax) with "offers".

Yes, I've noticed it.

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

> can discuss at a later date.

We should first agree on whether there is a need for a negotiation or it 
is just a plea for using a packetization time for a given media type.
> this long-standing issue.

Thanks.

/Miguel

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

---

From: "Joe Stone \(joestone\)" <[email-masked]>
Date: Thu, 31 May 2007 10:05:48 -0700

Hi Miguel,

[js] Comments in line...

[js] Yes, I'm simply suggesting that we could more accurately paraphrase
rather than take a single sentence out of context.

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

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

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