That means the issue mentioned by Terry about the sending payload type instead of receive payload type will have to be solved too...

-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Friday, October 31, 2003 14:55 To: Audet, Francois [SC100:4K02:EXCH]; 'Paul Long'; itu-sg16@external.cisco.com Subject: Re: SIP beats H323?

Guys,

The comfort noise document does allow for the use of a static payload type, but it also allows for the use of a dynamic payload type. Thus, in order to ensure interoperability with devices that use a dynamic payload type, we need such a capability within H.323.

With that said, I agree that using a static payload type should be permissible, as some SIP devices do the same today.

Paul

----- Original Message ----- From: Francois Audet mailto:audet@nortelnetworks.com To: 'Paul Long' mailto:plong@PACKETIZER.COM ; 'itu-sg16@external.cisco.com' mailto:'itu-sg16@external.cisco.com' ; 'Paul mailto:paulej@packetizer.com)' JONES (paulej@packetizer.com)' Sent: Friday, October 31, 2003 1:40 PM 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@PACKETIZER.COM mailto:plong@PACKETIZER.COM

]

Sent: Friday, October 31, 2003 10:08 To: itu-sg16@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

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 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@SONUSNET.COM mailto:TLyons@SONUSNET.COM ] Sent: Friday, October 31, 2003 10:16 AM To: itu-sg16@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@sonusnet.com +1 732 625-3003 x212