Packetizer Logo
 

Capability Descriptors (Q56)

The information in this article applies to:

There is some confusion over how to use capability descriptors. While some of the following capability sets from real endpoints may have been constructed this way intentionally, we thought it would be useful to point out some corrections and possible areas of improvement.

1. Simultaneous capabilities are inherently optional. For example, descriptor #1, below, is not necessary, because descriptor #0 already implies #1. In the same way, descriptor #0 also implies the descriptor, ( 3 or 4 ).

entry 1: rcv & xmit audio G.711 U LAW 64K

entry 2: rcv & xmit audio G.723.1 maxFrames: 8 silenceSuppression: 0

entry 3: rcv & xmit video H.261

entry 4: rcv & xmit video H.263 QCIF: 4 maxBitRate: 1999

descriptors:

#0: simultaneous caps: ( 1 or 2 ) and ( 3 or 4 )

#1: simultaneous caps: ( 1 or 2 )

2. Just as low descriptor numbers indicate preferred descriptors, alternative capabilities that appear earlier in an alternative-capability sequence also indicate preference. For example, the five descriptors, below, #6 through #10, could be replaced with the following, single descriptor while retaining the same semantics: ( 8 or 7 or 5 or 1 or 6 or 2 or 3 or 4 ) and ( 11 or 13 or 10 or 12 or 14 )

entry 32768: nonStd H.221

entry 1: rcv audio nonStd

entry 2: rcv audio G.711 A LAW 64K

entry 3: rcv audio G.711 U LAW 64K

entry 4: rcv audio nonStd H.221

entry 5: rcv audio nonStd H.221

entry 6: rcv audio nonStd H.221

entry 7: rcv audio nonStd H.221

entry 8: rcv audio G.723.1 maxFrames: 12 silenceSuppression: 0

entry 10: rcv video H.263 SQCIF: 1 maxBitRate: 6216 tempSpat

entry 11: rcv video H.263 QCIF: 1 maxBitRate: 6216 tempSpat

entry 12: rcv video H.263 CIF: 1 maxBitRate: 6216 tempSpat

entry 13: rcv video H.261

entry 14: rcv video H.261

descriptors:

#6: simultaneous caps:

( 8 or 7 or 5 or 1 or 6 or 2 or 3 or 4 ) and ( 11 )

#7: simultaneous caps:

( 8 or 7 or 5 or 1 or 6 or 2 or 3 or 4 ) and ( 13 )

#8: simultaneous caps:

( 8 or 7 or 5 or 1 or 6 or 2 or 3 or 4 ) and ( 10 )

#9: simultaneous caps:

( 8 or 7 or 5 or 1 or 6 or 2 or 3 or 4 ) and ( 12 )

#10: simultaneous caps:

( 8 or 7 or 5 or 1 or 6 or 2 or 3 or 4 ) and ( 14 )

3. Besides having a superfluous descriptor (#1), we believe the capability set, below, contains a mistake. Just looking at descriptor #0, the unusual combination of receive and transmit capabilities defines an interesting set of simultaneous capabilities. Descriptor #0 says, "I can transmit G.723.1 and receive H.263 at the same time, or I can receive and transmit G.711 and receive H.263 at the same time"; however, it conspicuously precludes receiving G.723.1 and H.263 at the same time. This may have been intended, but we don't think so.

entry 1: xmit audio G.723.1 maxFrames: 8 silenceSuppression: 0

entry 2: rcv video H.263 SQCIF: 4 QCIF: 4 CIF: 4 maxBitRate: 18349

entry 3: rcv & xmit audio G.711 U LAW 64K

descriptors:

#0: simultaneous caps: ( 1 or 3 ) and ( 2 )

#1: simultaneous caps: ( 1 or 3 )

4. The above capability set also contains an H.263 receive capability with suspiciously high minimum picture intervals of 4 (in units of 1/29.97 Hz). This notifies the remote terminal that this terminal is not capable of receiving a video stream with a frame rate greater than 7.5fps. I'm guessing that it should probably be set to 1 or 2, which translates to 30fps and 15fps, respectively. Interestingly, when the terminal that sent this subsequently opened its outgoing video logical channel as QCIF-only, it specified a minimum picture interval of 16, which translates to something just under 2fps. I'm sure that this was not intended.