1. Yes, I was thinking slow start, but the generic capability
applies to Fast Connect too.  In Setup you typically propose
many OLCs for the receiver to choose from, eg. G729AB
and G729A.  Similary G711+CN and G711.  For G711+CN
you encode a MultiplePayloadStreamCapability in the OLC.
 
2.  I disagree with your view that it won't make any difference to
the performance of the system.  There are reasons to send CN.
The ITU is taking the trouble to standardize it for older codecs.
Not sending packets can cause noticeably lower voice quality,
depending on the receiver.  Sending CN and having it ignored
is like not sending packets.  It may be better to send audio
continuously without silence detection.  That's why the
transmitter wants to know the receiver's capability.

- tlyons@sonusnet.com +1 732 625-3003 x212

-----Original Message-----
From: Francois Audet [mailto:audet@nortelnetworks.com]
Sent: Friday, October 31, 2003 3:27 PM
To: 'Lyons, Terry'; 'itu-sg16@external.cisco.com'
Subject: RE: SIP beats H323?


> There is a more fundamental problem: the silenceSuppression
> flag in H225LogicalChannelParameters is an option set by the
> transmitter. What we need -- what H.323 normally provides,
> what SIP now provides by its declaration of CN in SDP -- is a
> receiver CAPABILITY.
>
> The decision taken in Paris 9/2003 will do just fine: add a
> new generic capability to H.245 as soon as possible.  A
> receiver can then say it supports CN; a transmitter can take
> advantage of it.

Ah... You are talking slowStart, and was was thinking fastStart.

Regardless, I think this is the core of the disagreement. What Paul
and I are saying is that it doesn't matter. Any receiver will
ignore the silence packet if it doesn't understand it
and will process it properly if it does. So we can already
take advantage of it today. And the silenceSuppression flag
will tell the far end that it will send CN, in case it needs to
know.

I'm just very sceptical people will bother using the new
generic capability since it won't make any difference to
the performance of the system.

> BTW there is a related misuse of H225LogicalChannelParameters
> for dynamicRTPPayloadType.  SIP gets it right, having a
> receiver declare its capability to receive specified dynamic
> payload types in the SDP it sends.  H323 mistakenly lets the
> transmitter choose the dynamic payload type it will send. 
> The two don't interwork.

Correct.

I remember stumbling into this when I wrote the RFC2833
additions for H.323 (which also uses dynamic payload types).
For that particular case, we just simply only allowed in the
procedures to negotiate the dynamic payload type for receiving.
So dynamic payload types for RFC2833 should interwork.

Not sure how to fix it for dynamic payload types for voice codecs
however.