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.