Subject: [MMUSIC] Telephone-event and multiple clock rates

From: Adam Roach <[email-masked]>
Date: Thu, 23 Jan 2014 14:17:58 -0600

I've had an interesting issue brought to my attention regarding RFC4473 
"telephone-event" handling.

Section 2.1 requires that "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".

On its face, this would imply that offering voice codecs with varying 
clock rates would result in the need to offer several PTs with 
telephone-event, varying only in frequency.

So, for example, if we were setting up a media session that looked like this

    m=audio 12346 RTP/AVP 0 97 98 99
    a=rtpmap:0 PCMU/8000
    a=rtpmap:97 opus/4800 0/2
    a=rtpmap:98 AMR-WB/16000
    a=rtpmap:99 speex/32000

But want to add telephone-event to it, we would need to do this:

    m=audio 12346 RTP/AVP 0 97 98 99 100 101 102 103
    a=rtpmap:0 PCMU/8000
    a=rtpmap:97 opus/48000/2
    a=rtpmap:98 AMR-WB/16000
    a=rtpmap:99 speex/32000
    a=rtpmap:100 telephone-event/8000
    a=fmtp:100 0-15
    a=rtpmap:101 telephone-event/48000
    a=fmtp:101 0-15
    a=rtpmap:102 telephone-event/16000
    a=fmtp:102 0-15
    a=rtpmap:103 telephone-event/32000
    a=fmtp:103 0-15

Rather than this:

    m=audio 12346 RTP/AVP 0 97 98 99 100
    a=rtpmap:0 PCMU/8000
    a=rtpmap:0 PCMA/8000
    a=rtpmap:97 opus/48000/2
    a=rtpmap:98 AMR-WB/16000
    a=rtpmap:99 speex/32000
    a=rtpmap:100 telephone-event/8000
    a=fmtp:100 0-15

And then it would be incumbent on the remote end to ensure that they use 
the *correct* DTMF PT to match the codec that they're using for speech.

This all seems like patent nonsense, and it burns an additional PT for 
each clock rate. Is that really what was intended by this language in 
RFC 4733?

/a

---

From: "Stach, Thomas" <[email-masked]>
Date: Fri, 24 Jan 2014 07:19:40 +0000

Adam,

there is an errata that covers the issue.
http://www.rfc-editor.org/errata_search.php?rfc=4733 (close to bottom)
It points to some discussion at
http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html (close to bottom)

From that I understand that the negotiated audio codec determines the clock rate for DTMF.
It still remains interesting what his means if two codecs with different clock rates were negotiated and codec-switching-on-the-fly happens.

Kind Regards/mit freundlichen Grüßen
Thomas Stach

From: mmusic [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Donnerstag, 23. Januar 2014 21:18
To: [email-masked]
Subject: [MMUSIC] Telephone-event and multiple clock rates

I've had an interesting issue brought to my attention regarding RFC4473 "telephone-event" handling.

Section 2.1 requires that "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".

On its face, this would imply that offering voice codecs with varying clock rates would result in the need to offer several PTs with telephone-event, varying only in frequency.

Rather than this:

And then it would be incumbent on the remote end to ensure that they use the *correct* DTMF PT to match the codec that they're using for speech.

This all seems like patent nonsense, and it burns an additional PT for each clock rate. Is that really what was intended by this language in RFC 4733?

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 24 Jan 2014 11:29:36 +0100

Hi,

My understanding for the reasoning behind this definition in the RFC is
due to that the events is supposed to be connected to the same time-line
as the audio. Thus it ended up using the same SSRC. To avoid timestamp
rate switching which we know has issues
(https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-rates/)
it was mandated to provide one PT for each rate negotiated for the audio
payload types.

On 2014-01-24 08:19, Stach, Thomas wrote:
> 
> It still remains interesting what his means if two codecs with different
> clock rates were negotiated and codec-switching-on-the-fly happens.
> 

So there is a difference in negotiating possible to use, another to
actively switch between them within a RTP session for a particular media
source. If you actually switch then you have to take the considerations
in draft-ietf-avtext-multiple-clock-rates into account.

If you are not switching, then these are only ensuring that you can use
the events for what ever audio payload format you select to use out of
the set offered and accepted.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Adam Roach <[email-masked]>
Date: Fri, 24 Jan 2014 09:59:39 -0600

> it was mandated to provide one PT for each rate negotiated for the audio

To make sure I understand what you're saying correctly: you are 
asserting that having four different clock rates for voice codecs 
requires us to use four different PTs for telephone-event if we're going 
to have them on the same SSRC. Is that correct?

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 27 Jan 2014 09:47:18 +0100

> to have them on the same SSRC. Is that correct?

Yes!

All to avoid the issue that with rate switching within an SSRC. This is
both potential loss of time synchronization as well as degrading RTP
timestamp based RTCP measurements. And the above draft (soon RFC) does
require new implementations to change their SSRC when doing
rate-switching. That clearly have signaling implications in the context
of WebRTC.

Cheers

Magnus Westerlund

---

From: Randell Jesup <[email-masked]>
Date: Mon, 27 Jan 2014 03:48:00 -0500

On 1/24/2014 10:59 AM, Adam Roach wrote:
> requires us to use four different PTs for telephone-event if we're 
> going to have them on the same SSRC. Is that correct?

If those four PT's (not codecs) are accepted (and thus can be switched 
between on-the-fly), yes.  Multiple clock rates plays hell with RTP 
timestamps.

You could use a separate SSRC (or m=audio line) for each clock rate 
instead.  This would likely mean glitching at transitions however, so 
not a great solution, but works.  You might be able to avoid glitches by 
making sure you send RTCP for the alternate SSRCs so synchronization 
info is available, though this may require the receiver to know somehow 
that the SSRC's need to be "lip-synced" (in this case audio to audio 
though).  Overall - here be (baby) dragons in the glitch-avoidance 
variation...

In theory you could allow one telephone-event PT and do a renegotiate 
after an effective codec/PT change.  You might need to be careful about 
asynchronicity due to the renegotiation and not re-use the same PT for a 
different rate of telephone-event (ping-pong between two).  There would 
exist a window when there was a switch where it would be problematic to 
send telephone-event (and you'd need to require that both sides switch 
when one does). Overall - here be (big) dragons.

-- 
Randell Jesup -- rjesup a t mozilla d o t com

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Jan 2014 13:02:50 +0000

Hi,

I guess it would be good to add some text to BUNDLE, to indicate that you must include the telephone-event PTs for every m- line which may use them. I.e. you cannot indicate telephone-event for one m- line, and then use them on every m- line within the bundle group.

But, I guess there will be no need for people to support telephone-events on more than one m- line to begin with, so...

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Randell Jesup
Sent: 27. tammikuuta 2014 10:48
To: [email-masked]
Subject: Re: [MMUSIC] Telephone-event and multiple clock rates

On 1/24/2014 10:59 AM, Adam Roach wrote:
>> My understanding for the reasoning behind this definition in the RFC 
>> is due to that the events is supposed to be connected to the same 
>> time-line as the audio. Thus it ended up using the same SSRC. To 
>> avoid timestamp rate switching which we know has issues
>> it was mandated to provide one PT for each rate negotiated for the 
>> audio payload types.
>

If those four PT's (not codecs) are accepted (and thus can be switched between on-the-fly), yes.  Multiple clock rates plays hell with RTP timestamps.

You could use a separate SSRC (or m=audio line) for each clock rate instead.  This would likely mean glitching at transitions however, so not a great solution, but works.  You might be able to avoid glitches by making sure you send RTCP for the alternate SSRCs so synchronization info is available, though this may require the receiver to know somehow that the SSRC's need to be "lip-synced" (in this case audio to audio though).  Overall - here be (baby) dragons in the glitch-avoidance variation...

In theory you could allow one telephone-event PT and do a renegotiate after an effective codec/PT change.  You might need to be careful about asynchronicity due to the renegotiation and not re-use the same PT for a different rate of telephone-event (ping-pong between two).  There would exist a window when there was a switch where it would be problematic to send telephone-event (and you'd need to require that both sides switch when one does). Overall - here be (big) dragons.

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Jan 2014 11:32:02 -0500

> But, I guess there will be no need for people to support telephone-events on more than one m- line to begin with, so...

Why would you say that?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 28 Jan 2014 18:25:17 +0000

Hi Paul,

I can't think of a use-case with multiple audio m- lines, where each would need to support telephone-events.

Perhaps such use-cases do exist, but I don't they are very common.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Paul Kyzivat <[email-masked]> wrote:

Why would you say that?

        Thanks,
        Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 28 Jan 2014 19:01:46 +0100

> But, I guess there will be no need for people to support telephone-events on more than one m- line to begin with, so...

Telephone-events are a hack for gateways into contexts where DTMF
signalling makes sense - which is primarily the telephone network and
telephone-related systems.

In practice, I don't expect gateways into those contexts to support very
many clock rates - they should support G.711's 8000 and Opus' 48K, and
hopefully that's the end of it.

I don't want to worry very much about two extra lines of SDP; let's just
declare (probably in -rtcweb-audio-) that if multiple audio codec
bitrates are offered, and one wishes to use DTMF no matter what codec is
selected, one must offer DTMF at each clock rate offered - each offer
consuming one PT.

-- 
Surveillance is pervasive. Go Dark.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 28 Jan 2014 20:19:44 +0000

Well I could postulate a webrtc endpoint forming the collection endpoint for a telephone voting system.

Keith 

> From: mmusic [mailto:[email-masked]] On Behalf Of 
> Christer Holmberg
> Sent: 28 January 2014 13:03
> To: Randell Jesup; [email-masked]
> I guess it would be good to add some text to BUNDLE, to 
> indicate that you must include the telephone-event PTs for 
> every m- line which may use them. I.e. you cannot indicate 
> telephone-event for one m- line, and then use them on every 
> m- line within the bundle group.
> 
> But, I guess there will be no need for people to support 
> telephone-events on more than one m- line to begin with, so...
> 
> Regards,
> 
> Christer
> 
> 
> If those four PT's (not codecs) are accepted (and thus can be 
> switched between on-the-fly), yes.  Multiple clock rates 
> plays hell with RTP timestamps.
> 
> You could use a separate SSRC (or m=audio line) for each 
> clock rate instead.  This would likely mean glitching at 
> transitions however, so not a great solution, but works.  You 
> might be able to avoid glitches by making sure you send RTCP 
> for the alternate SSRCs so synchronization info is available, 
> though this may require the receiver to know somehow that the 
> SSRC's need to be "lip-synced" (in this case audio to audio 
> though).  Overall - here be (baby) dragons in the 
> glitch-avoidance variation...
> 
> In theory you could allow one telephone-event PT and do a 
> renegotiate after an effective codec/PT change.  You might 
> need to be careful about asynchronicity due to the 
> renegotiation and not re-use the same PT for a different rate 
> of telephone-event (ping-pong between two).  There would 
> exist a window when there was a switch where it would be 
> problematic to send telephone-event (and you'd need to 
> require that both sides switch when one does). Overall - here 
> be (big) dragons.
> 
> --

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Jan 2014 06:53:48 +0000

> Well I could postulate a webrtc endpoint forming the collection endpoint for a telephone voting system.

Sure, if you are going to represent every new incoming "vote call" by adding an audio m- line to a single ongoing session.

Regards,

Christer

> From: mmusic [mailto:[email-masked]] On Behalf Of Christer 
> Holmberg
> I guess it would be good to add some text to BUNDLE, to indicate that 
> you must include the telephone-event PTs for every m- line which may 
> use them. I.e. you cannot indicate telephone-event for one m- line, 
> and then use them on every
> not a great solution, but works.  You might be able to avoid glitches 
> by making sure you send RTCP for the alternate SSRCs so 
> synchronization info is available, though this may require the 
> receiver to know somehow that the SSRC's need to be "lip-synced" (in 
> this case audio to audio though).  Overall - here be (baby) dragons in 
> the glitch-avoidance variation...
> 
> after an effective codec/PT change.  You might need to be careful 
> about asynchronicity due to the renegotiation and not re-use the same 
> PT for a different rate of telephone-event (ping-pong between two).  
> There would exist a window when there was a switch where it would be 
> problematic to send telephone-event (and you'd need to require that 
> both sides switch when one does). Overall - here be (big) dragons.
> 
> --