- sg16-avd - lists.packetizer.com

FW: [AVT] RFC 3611 on RTP Control Protocol Extended Reports (RTCP
by simao.campos＠ITU.INT 06 Nov '03

06 Nov '03

For your information. Best regards, Simao -----Original Message----- From: rfc-editor(a)rfc-editor.org [mailto:rfc-editor@rfc-editor.org] Sent: 05 November 2003 20:05 Cc: rfc-editor(a)rfc-editor.org; avt(a)ietf.org Subject: [AVT] RFC 3611 on RTP Control Protocol Extended Reports (RTCP XR) A new Request for Comments is now available in online RFC libraries. RFC 3611 Title: RTP Control Protocol Extended Reports (RTCP XR) Author(s): T. Friedman, R. Caceres, A. Clark, Eds. Status: Standards Track Date: November 2003 Mailbox: timur.friedman(a)lip6.fr, caceres(a)watson.ibm.com, alan(a)telchemy.com Pages: 55 Characters: 126736 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtcp-report-extns-06.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3611.txt This document defines the Extended Report (XR) packet type for the RTP Control Protocol (RTCP), and defines how the use of XR packets can be signaled by an application if it employs the Session Description Protocol (SDP). XR packets are composed of report blocks, and seven block types are defined here. The purpose of the extended reporting format is to convey information that supplements the six statistics that are contained in the report blocks used by RTCP's Sender Report (SR) and Receiver Report (RR) packets. Some applications, such as multicast inference of network characteristics (MINC) or voice over IP (VoIP) monitoring, require other and more detailed statistics. In addition to the block types defined here, additional block types may be defined in the future by adhering to the framework that this document provides. This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST(a)IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST(a)RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info(a)RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info(a)RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager(a)RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR(a)RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs.

1 0

RE: SIP beats H323?
by Francois Audet 31 Oct '03

31 Oct '03

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(a)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(a)external.cisco.com' <mailto:'itu-sg16(a)external.cisco.com'> ; 'Paul <mailto:paulej@packetizer.com)'> JONES (paulej(a)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(a)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(a)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(a)sonusnet.com +1 732 625-3003 x212

1 0

RE: SIP beats H323?
by Lyons, Terry 31 Oct '03

31 Oct '03

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(a)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(a)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.

1 0

RE: SIP beats H323?
by Paul Long 31 Oct '03

31 Oct '03

Terry, Oh, yeah, you're right--silenceSuppression is not a capability. Why do you say that "SIP gets it right?" How is it better to advertise dynamic payload types in one's receive caps rather than in an OLC? Just seems different to me. Or are you just making the oservation that SIP and H.323 are different in this regard? Paul -----Original Message----- From: Lyons, Terry [mailto:TLyons@SONUSNET.COM] Sent: Friday, October 31, 2003 2:04 PM To: itu-sg16(a)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. 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(a)sonusnet.com +1 732 625-3003 x212 -----Original Message----- From: Paul Long [mailto:plong@PACKETIZER.COM] Sent: Friday, October 31, 2003 2:16 PM To: itu-sg16(a)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@nortelnetworks.com] Sent: Friday, October 31, 2003 12:41 PM To: 'Paul Long'; 'itu-sg16(a)external.cisco.com'; 'Paul JONES (paulej(a)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@PACKETIZER.COM] > Sent: Friday, October 31, 2003 10:08 > To: itu-sg16(a)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@SONUSNET.COM] Sent: Friday, October 31, 2003 10:16 AM To: itu-sg16(a)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(a)sonusnet.com +1 732 625-3003 x212

1 0

RE: SIP beats H323?
by Lyons, Terry 31 Oct '03

31 Oct '03

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(a)sonusnet.com +1 732 625-3003 x212 -----Original Message----- From: Paul Long [mailto:plong@PACKETIZER.COM] Sent: Friday, October 31, 2003 2:16 PM To: itu-sg16(a)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@nortelnetworks.com] Sent: Friday, October 31, 2003 12:41 PM To: 'Paul Long'; 'itu-sg16(a)external.cisco.com'; 'Paul JONES (paulej(a)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@PACKETIZER.COM] > Sent: Friday, October 31, 2003 10:08 > To: itu-sg16(a)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@SONUSNET.COM] Sent: Friday, October 31, 2003 10:16 AM To: itu-sg16(a)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(a)sonusnet.com +1 732 625-3003 x212

1 0

RE: SIP beats H323?
by Paul Long 31 Oct '03

31 Oct '03

Terry, Good point. I suppose that a robust receiver would generate local CN in the absence of audio packets, but I admit that your scheme would be more reliable. Paul -----Original Message----- From: Lyons, Terry [mailto:TLyons@SONUSNET.COM] Sent: Friday, October 31, 2003 1:05 PM To: 'Paul Long'; itu-sg16(a)external.cisco.com Subject: RE: SIP beats H323? Paul, Thanks for the pointers. I shall look for a new generic capability in the next edition of H.245. H.323 devices negotiate to optimize voice quality. If it is likely that the receiver will discard CN packets, a transmitter may achieve better results by sending G.711 without interruption. - tlyons(a)sonusnet.com +1 732 625-3003 x212 -----Original Message----- From: Paul Long [mailto:plong@PACKETIZER.COM] Sent: Friday, October 31, 2003 1:08 PM To: itu-sg16(a)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-2410.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@SONUSNET.COM] Sent: Friday, October 31, 2003 10:16 AM To: itu-sg16(a)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(a)sonusnet.com +1 732 625-3003 x212

1 0

RE: SIP beats H323?
by Paul Long 31 Oct '03

31 Oct '03

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@nortelnetworks.com] Sent: Friday, October 31, 2003 12:41 PM To: 'Paul Long'; 'itu-sg16(a)external.cisco.com'; 'Paul JONES (paulej(a)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@PACKETIZER.COM] > Sent: Friday, October 31, 2003 10:08 > To: itu-sg16(a)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@SONUSNET.COM] Sent: Friday, October 31, 2003 10:16 AM To: itu-sg16(a)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(a)sonusnet.com +1 732 625-3003 x212

1 0

RE: SIP beats H323?
by Lyons, Terry 31 Oct '03

31 Oct '03

Paul, Thanks for the pointers. I shall look for a new generic capability in the next edition of H.245. H.323 devices negotiate to optimize voice quality. If it is likely that the receiver will discard CN packets, a transmitter may achieve better results by sending G.711 without interruption. - tlyons(a)sonusnet.com +1 732 625-3003 x212 -----Original Message----- From: Paul Long [mailto:plong@PACKETIZER.COM] Sent: Friday, October 31, 2003 1:08 PM To: itu-sg16(a)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-2410.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@SONUSNET.COM] Sent: Friday, October 31, 2003 10:16 AM To: itu-sg16(a)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(a)sonusnet.com +1 732 625-3003 x212

1 0

RE: SIP beats H323?
by Francois Audet 31 Oct '03

31 Oct '03

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

1 0

RE: SIP beats H323?
by Paul Long 31 Oct '03

31 Oct '03

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

1 0