Wrong telephone-event rate in SDP.

[Anthony Roach]

We are working on implementing telephone-events in a mixed WebRTC and SIP environment and we noticed that the telephone-event rate in the SDP from Chrome is only 8000. For example:

a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000

Since the telephone-event packets must use the same timestamp as the audio packets this seems to mean that telephone-events (according to the RFCs, see below) will only be used for the 8000 Hz codecs (i.e. PCMU and PCMA) and not the other high bandwidth codecs (Opus and ISAC) since the other codecs are not using 8000 Hz as their clock rate. Is this a correct interpretation or is Chrome going to send telephone events with a different clock when Opus is selected as the Codec? 

For comparison this is the SDP we would have expected if telephone-events are being offered for all the codecs:

a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000

a=rtpmap:127 telephone-event/16000

a=rtpmap:128 telephone-event/32000

a=rtpmap:129 telephone-event/48000

Here are some relevant RFC quotes that support this:

From http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-requirements-02 :

 

From 7.1:

      ----------------------------------------------------------------

      A3-7            WebRTC MUST generate [RFC4733] events using

                      the same SSRC as the audio codec(s) for a

                      stream.

      ----------------------------------------------------------------

      A3-8            WebRTC MUST generate [RFC4733] events in the

                      same RTP sequence number space as the audio RTP

                      packets.

      ----------------------------------------------------------------

      A3-9            WebRTC MUST generate [RFC4733] events with the

                      same clock frequency and timestamp space as

                      the audio.

      ----------------------------------------------------------------

and from https://tools.ietf.org/html/rfc4733#section-2.1 :

 

   Named telephone events are carried as part of the audio stream and

   MUST use the same sequence number and timestamp base as the regular

   audio channel to simplify the generation of audio waveforms at a

   gateway.  The named telephone-event payload type can be considered to

   be a very highly-compressed audio codec and is treated the same as

   other codecs.

 

[Vikas]

Thanks for the feedback, we are looking into it. Also, there was some discussion regarding this in issue 225948 as well. 

/Vikas

[Alfred E. Heggestad]

inline

On 10/2/13 10:44 PM, Vikas wrote:
> Thanks for the feedback, we are looking into it. Also, there was some discussion regarding this in issue 225948 <https://code.google.com/p/chromium/issues/detail?id=225948#c28> as well.

>
> /Vikas
>
> On Wednesday, October 2, 2013 5:23:21 AM UTC-7, Anthony Roach wrote:
>

<snip>

>
> a=rtpmap:111 opus/48000/2
> a=fmtp:111 minptime=10
> a=rtpmap:103 ISAC/16000
> a=rtpmap:104 ISAC/32000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:107 CN/48000
> a=rtpmap:106 CN/32000
> a=rtpmap:105 CN/16000
> a=rtpmap:13 CN/8000

> *a=rtpmap:126 telephone-event/8000
> *
> *a=rtpmap:127 telephone-event/16000
> *
> *a=rtpmap:128 telephone-event/32000
> *
> *a=rtpmap:129 telephone-event/48000*
>

is it really necessary to duplicate the telephone-event for all supported
sampling rates ? that does not make sense to me.


/alfred

[feli...@gmail.com]

Yes, it is required.  Please see https://tools.ietf.org/html/rfc4733#section-2.1.  Note how there is a comfort noise (CN) offered for each timestamp rate.  The same is needed for telephone-event.  IMHO not using the same timestamp rate makes no sense.