G.722 codec is not defined for any other clock rates except 16KHz. This means that no matter what the SDP says, G.722 connection is used to pass 16KHz audio.
On the other hand, there is a little complication caused by RFC 3551: RTP clock operates at 8Khz. This means timestamps should be incremented at the rate of 8000 units per second. In other words if you have 20 ms packets, the two consecutive packets will have their timestamps different by 160, not by 320 that would have been the case with 16KHz RTP clock. It looks like phone implementers get somewhat confused about this. Snom and Policom seem to get this right. CounterPath declares 8KHz timing in RTP but uses 16KHz RTP clock (10 ms packets with RTP timestamp incremented by 160). Grandstream declares RTP clock to be 16Khz and increments RTP timestamp accordingly. __________________________ Roman Shpount On 8/8/07, Murat Artun <[EMAIL PROTECTED]> wrote: > > On 8/7/07, Roman Shpount <[EMAIL PROTECTED]> wrote: > > Hi All, > > > > >>m=audio 9292 RTP/AVP 9 > > >>a=rtpmap:9 G722/48000 > > >>a=rtpmap:9 G722/56000 > > >>a=rtpmap:9 G722/64000 > > > > This is definitely incorrect. The only clock rate supported by G.722 is > > 16KHz, which should be specified as 8KHz for compatibility reasons (see > RFC > > 3551 4.5.2). This means the offer should be: > > > > m=audio 9292 RTP/AVP 9 > > a=rtpmap:9 G722/8000 > > So, should we interpret RFC 3551 section 4.5.2 that although RTP clock > rate is announced to be 8000Hz in SDP, we should consider it to be > 16KHz? Or what else, does G722 considered to be with clock rate 8000Hz > in RTP although it is 16 KHz? > > > > > Everything else is not standard and is not supported (except specifying > the > > number of channels, such as a=rtpmap:9 G722/8000/1). > > > > Also, there is almost no reason to use any other G.722 bit rate except > 64KB. > > All of those bit rates actually occupy 64KB of bandwidth. Lower bite > rates > > simply leave space for a side channel inside the audio stream, which, > > IMHO, is not extremely useful in an IP environments. Furthermore, you > can > > decode all of these bit rates as 64KB with minimal affect on the audio > > quality. > > > > ___________________________________________ > > Roman Shpount > > _______________________________________________ > > Sip-implementors mailing list > > Sip-implementors@lists.cs.columbia.edu > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > -- > M u r at A r t u n, MSc. > Design Engineer > > "be conservative in what you do, be liberal in what you accept from > others" > > > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
