SIP beats H323?

[Lyons, Terry]

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.

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.

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


-----Original Message-----
From: Paul Long [mailto:plong at PACKETIZER.COM]
Sent: Friday, October 31, 2003 2:16 PM
To: itu-sg16 at external.cisco.com
Subject: RE: SIP beats H323?


Francois,

I'm not too sure about the silenceSuppression flag in
H225LogicalChannelParameters:

B.3.1/H.225.0v4: "The silenceSuppression is used to indicate whether the
transmitter stops sending packets during times of silence."

Strictly speaking, it can be argued that a SID, or CN packet, is actually
transmitted "during times of silence" because it marks the start of the
silence period. In that sense, this flag should only be set if the
transmitter suppresses _all_ packets during silence the way that NetMeeting
does even for G.723.1--no audio, no data. (I think we've had this discussion
before.) If we loosen up a little to allow SIDs at the beginning of silence,
we still have a problem because multiple SIDs can be sent _during_ silence
to, for example, update the CN sample if the background noise changes. I
think yours is the general understanding of this field, but I think it would
be clearer if the above passage were changed to something like this:

"silenceSuppression indicates whether the transmitter stops sending
>>>>normal, voiced<<<< packets during times of silence."

Paul
-----Original Message-----
From: Francois Audet [mailto:audet at nortelnetworks.com]
Sent: Friday, October 31, 2003 12:41 PM
To: 'Paul Long'; 'itu-sg16 at external.cisco.com'; 'Paul JONES
(paulej at packetizer.com)'
Subject: RE: SIP beats H323?


Hi Terry, Paul, & Paul,
I am in complete agreement with Paul Long on this.
Annex F.4/H.225.0 was written before the comfort noise
mechanism of RFC3389 (which used to be in the revision to RFC1890) was
finalized. The intent has always been that the generic mechanism of
draft-new-RFC1890 would be used and is what the "for further study" is
refering to.
Therefore, my assumption is that using the silenceSuppression flag
in the H225LogicalChannelParameters (in H.245) really means that
you are using the standard comfort noise as per RFC3389 on payload
type 13.
Some early implemenations might have chosen just not to sent packets
instead of comfort noise.
In any case, defining a new mechanism is likely in my opininon to DELAY
parity of H.323 with SIP with regards to silence suppression as
implementation
will have to upgrade their H.323 protocol stack.
I'd much go with Paul Long's approach. In fact, I really was under the
impression that it was the case anyways. I am convinced that if you start
using the CN packets as described above (with the silenceSuppression flag),
it will be backward compatible with existing implemenations.
To confirm what Paul is saying regarding the fact that "receivers MUST
ignore packets with payload type that it does not understand", I will point
out that I have observed implementations that send "bogus" UDP packets that
are NOT comfort noise to maintain NAT binding, and I've never seen any
interoperability problems.
To summarize: I think we should just update section Annex F.4/H.225.0 to
point to RFC 3389, add some material about ignoring non-recognized payload
type, and forget about the procedures of AVD-1366. I really think it will
result in better interoperability, and much faster.
----
François AUDET, Nortel Networks
Tel: +1 408 495 3756


> -----Original Message-----
> From: Paul Long [mailto:plong at PACKETIZER.COM]
> Sent: Friday, October 31, 2003 10:08
> To: itu-sg16 at external.cisco.com
> Subject: RE: SIP beats H323?
>
>
> Terry,
>
> First of all, RFC 3389 specifies its use with SDP, not SIP,
> per se. SDP is used by several protocols, one of which is
> SIP. Maybe your subject hedaer should have been "SDP beats H245?" :-)
>
> While it is currently not possible to explicitly signal RFC
> 3389 in H.323, at the last SG16 meeting in Paris it was agreed
> (http://avguest@ftp3.itu.int/av-arch/avc-site/0309_Par/AVD-241
0.zip) to add a generic capability specifically for RFC 3389
(http://ftp3.itu.int/av-arch/avc-site/0309_Par/AVD-2366.zip). However, IMO,
this is unfortunate because it is unnecessary. The way I've seen CN used is
that the transmitter includes CN packets (with static payload type of 13)
and assumes that the receiver will process them if it supports RFC 3389 and
ignore them otherwise. To wit, RTP (RFC 3550, which obsoletes RFC 1889): "A
receiver MUST ignore packets with payload types that it does not
understand." Admittedly, though, this presents problems for less robust
(non-compliant) receivers that ignore payload type.
Paul
-----Original Message-----
From: Lyons, Terry [mailto:TLyons at SONUSNET.COM]
Sent: Friday, October 31, 2003 10:16 AM
To: itu-sg16 at external.cisco.com
Subject: SIP beats H323?


Is there a standard way in H323 to signal the capability to accept the
comfort noise payload (Appendix II/G.711) with G.711 or G.726?
Appendix VIII of H.245 lists no relevant generic capability. RFC 3389 only
explains how CN is to be signaled with SIP.
- tlyons at sonusnet.com +1 732 625-3003 x212