SIP beats H323?

Lyons, Terry TLyons at SONUSNET.COM
Fri Oct 31 16:06:07 EST 2003

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 at +1 732 625-3003 x212 

-----Original Message-----
From: Francois Audet [mailto:audet at]
Sent: Friday, October 31, 2003 3:27 PM
To: 'Lyons, Terry'; 'itu-sg16 at'
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 

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. 


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 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the sg16-avd mailing list