sipwise / rtpengine

The Sipwise media proxy for Kamailio
GNU General Public License v3.0
784 stars 368 forks source link

How to correctly set fmtp options for Opus #962

Open elbow opened 4 years ago

elbow commented 4 years ago

Hi,

I'm trying to do this on my calls where I'm trancoding from Opus to G722/ALAW:

const voipProviderFacingProxyCharacteristics = {
  'transport protocol': 'RTP/AVP',
  'DTLS': 'off',
  'SDES': 'off',
  'ICE': 'remove',
  'flags': ['port-latching'],
  'codec': {
    'strip': ['telephone-event', 'G722', 'PCMA', 'PCMU'],
    'mask': ['opus'],
    'set': ['opus/48000/2/32000//maxplaybackrate=48000;stereo=0;useinbandfec=1;maxaveragebitrate=32000'],
    'transcode': ['G722', 'PCMA', 'PCMU'],
    'offer': ['telephone-event'],
  },
  'rtcp-mux': ['demux']
};

And going the other way:

const webrtcFacingProxyCharacteristics = {
  'ICE': 'force',
  'SDES': 'off',
  'DTLS': 'passive',
  'flags': ['SDES-no', 'port-latching'],
  'codec': {
    // about stripping opus: may seem weird to remove it and then transcode it.
    // but Telviva offers opus and if we pass it through that Telviva likely ends up transcoding it, which we want to avoid
    'strip': ['telephone-event', 'opus'],
    'mask': ['G722', 'PCMA', 'PCMU', 'G729', 'G729a'],
    'transcode': ['opus/48000/2/32000//maxplaybackrate=48000;stereo=0;useinbandfec=1;maxaveragebitrate=32000'],
    'offer': ['telephone-event']
  },
  'rtcp-mux': ['require']
};

Using "transcode opus/48000/2/32000" seems to be effective in getting rtpengine to use the 32Kb bit rate.

But Chrome keeps sending at a higher rate.

So I used that extra option to try to adjust the fmtp line to try to tell the sending side what I want. But I don't see these options in the fmtp line in the SDP.

Can you help me get on the right track?

Thanks, Steve

rfuchs commented 4 years ago

Seems to work for me, at least in the forward direction. Using --codec-strip=opus --codec-transcode='opus/48000/2/32000//maxplaybackrate=48000;stereo=0;useinbandfec=1;maxaveragebitrate=32000' produces:

v=0
o=- 1822058533 1822058533 IN IP4 1.2.3.4
s=Asterisk
c=IN IP4 192.168.1.90
t=0 0
m=audio 30238 RTP/AVP 96
a=rtcp-fb:111 transport-cc
a=rtpmap:96 opus/48000/2
a=fmtp:96 maxplaybackrate=48000;stereo=0;useinbandfec=1;maxaveragebitrate=32000
a=sendrecv
a=rtcp:30239

The reverse direction (mask plus set) doesn't work as the fmtp is taken from the original offer and then mirrored back in the answer. I'd have to look at the Opus specs to see how fmtp is supposed to be handled for Opus.

elbow commented 4 years ago

Hi Richard,

Let me try do it like that and double check my result.

As for the other direction, I guess I get to try to persuade webrtc to set it up how I want it.

Steve

On Fri, 03 Apr 2020, 18:22 Richard Fuchs, notifications@github.com wrote:

Seems to work for me, at least in the forward direction. Using --codec-strip=opus --codec-transcode='opus/48000/2/32000//maxplaybackrate=48000;stereo=0;useinbandfec=1;maxaveragebitrate=32000' produces:

v=0 o=- 1822058533 1822058533 IN IP4 1.2.3.4 s=Asterisk c=IN IP4 192.168.1.90 t=0 0 m=audio 30238 RTP/AVP 96 a=rtcp-fb:111 transport-cc a=rtpmap:96 opus/48000/2 a=fmtp:96 maxplaybackrate=48000;stereo=0;useinbandfec=1;maxaveragebitrate=32000 a=sendrecv a=rtcp:30239

The reverse direction (mask plus set) doesn't work as the fmtp is taken from the original offer and then mirrored back in the answer. I'd have to look at the Opus specs to see how fmtp is supposed to be handled for Opus.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sipwise/rtpengine/issues/962#issuecomment-608534148, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAA2IVQJ5KTRMQ4Z7W5LDMTRKYEM7ANCNFSM4L4F3YCA .

elbow commented 4 years ago

Yeah, sorry, must have made a stupid mistake.

For an "inbound" call (where we want to transcode to Opus) I'm getting what I want:

m=audio 21828 UDP/TLS/RTP/SAVPF 101 96
...
a=fmtp:96 maxplaybackrate=48000;stereo=0;useinbandfec=1;maxaveragebitrate=32000

Chrome webrtc gave me back:

m=audio 61441 UDP/TLS/RTP/SAVPF 101 96
a=fmtp:96 minptime=10;useinbandfec=1

So that's what I had in mind.

Not sure what to do for calls going the other way - but one thing at a time.