[asterisk-dev] Opus and VP8
Andrea Suisani
sickpig at opinioni.net
Wed Jun 5 08:07:09 CDT 2013
On 06/05/2013 12:45 PM, Lorenzo Miniero wrote:
> 2013/6/5 Andrea Suisani <sickpig at opinioni.net <mailto:sickpig at opinioni.net>>
[cut]
> as I already said this fix solve the issue we had.
>
> the tests we made are related to this configuration:
>
> (sip+opus) (iax/sip+g729)
> WebRTC -----------> Asterisk -----------------> pstn/mobile
> (A) (B)
>
> I know that there is no ad-hoc Opus configuration yet,
> but I'm trying to measure the bandwidth of the call opus leg (A).
>
> I've used iftop to get a rough measure, catching only udp
> packets. the iftop instance was executed on the same host
> where asterisk is running catching packets only on the net
> interface to which asterisk is bind to.
>
> While using opus the A leg bandwidth is something like 50/55 kb/s,
> from the webrtc client to the asterisk, while something along
> 100kb/s from asterisk to client. is it normal?
>
>
> Opus is conceived to be able to transparently switch rate during a call. In the code I made sure that
> the encoding would take note of the peer sampling rate, in order to cap it in Opus as well. This means that,
> if you're talking to a GSM/ulaw/g729 peer, Opus itself should be "capped" at 8kHz as
> there would be no need for a higher sampling rate to transport the audio.
I've enabled the opus debug (normal) and I can confirm you're right.
Your code does create a 8kHz encoder, but then due to the way we place
the call everything fall back to a 48kHz encoder/decoder.
This is going to be long but I've to explain how our env is set up, I'm sorry :)
If you want just skip to the bottom where I've pasted the console log for a session.
The main thing is that webrtc client does not place call directly.
Instead it use an AMI Originate command to place the call,
that way asterisk call the pstn/mobile number and bridge
the call to webrtc client.
so actually the webrtc never perform an outgoing call, it simply
answer to an incoming call.
to make a long story short
since the actual call is performed by a Dial() in asterisk dialplan,
the webrtc endpoint has no way to know when pstn party pick up the phone
through proper sip protocol signaling.
and since we need to notify webrtc client about thestatus of the 2nd call leg
(asterisk -> pstn) due to soma application constraints that we had
we've set up a quite bizarre mechanism to work around this problem.
using the G Dial option in such a way that if the call is answered,
the calling party will be transfer to the specified priority and
the called party to the specified priority plus one.
so once pstn pickup we move to mix_me context that
then bridge the two legs again after notifying the
webrtc client.
this a stripped down version of our dialplan
[mycontext]
exten => _X.,n,Set(CHANNEL(userfield)=${session})
exten => _X.,n,Dial(IAX2/myprovider/${EXTEN},22,areG(mix_me^s^1))
...
...
[mix_me]
exten => s,1,Goto(bridge_me,s,1)
exten => s,2,Wait(1)
[bridge_me]
exten => s,1,SendText(ANSWERED)
exten => s,n,Bridge(${DIALEDPEERNAME},x)
exten => s,n,Goto(bridge-unlink,s,1)
exten => h,1,Goto(bridge-unlink,s,1)
[bridge-unlink]
exten => s,1,Set(...)
...
exten => s,n,HangUp()
and this is the result....
[Opus] Created encoder #7 (8000->opus)
-- Call accepted by XXX.XXX.XXX.XXX (format g729)
-- Format for call is (g729)
-- IAX2/myprovider-14409 is making progress passing it to SIP/webrtc_form_cloud2_10_326_1370433026-00000003
-- IAX2/myprovider-14409 is making progress passing it to SIP/webrtc_form_cloud2_10_326_1370433026-00000003
-- IAX2/myprovider-14409 answered SIP/webrtc_form_cloud2_10_326_1370433026-00000003
-- Executing [s at mix_me:1] Goto("SIP/webrtc_form_cloud2_10_326_1370433026-00000003", "bridge_me,s,1") in new stack
-- Goto (bridge_me,s,1)
-- Executing [s at bridge_me:1] SendText("SIP/webrtc_form_cloud2_10_326_1370433026-00000003", "ANSWERED") in new stack
-- Executing [s at mix_me:2] Wait("IAX2/myprovider-14409", "1") in new stack
-- Executing [s at bridge_me:2] Bridge("SIP/webrtc_form_cloud2_10_326_1370433026-00000003", "IAX2/myprovider-14409,x") in new stack
== Spawn extension (dai, s, 2) exited non-zero on 'Bridge/IAX2/myprovider-14409<ZOMBIE>'
[Opus] Created decoder #7 (opus->48000)
[Opus] Destroyed encoder #7 (8000->opus)
[Opus] Created encoder #8 (48000->opus)
[Jun 5 13:52:34] WARNING[22108][C-00000003]: channel.c:5083 ast_write: Codec mismatch on channel SIP/webrtc_form_cloud2_10_326_1370433026-00000003 setting write format to slin from slin48 native formats (opus)
[Opus] Destroyed encoder #8 (48000->opus)
[Opus] Created encoder #9 (8000->opus)
[Opus] Destroyed encoder #9 (8000->opus)
[Jun 5 13:52:35] WARNING[22108][C-00000003]: channel.c:5083 ast_write: Codec mismatch on channel SIP/webrtc_form_cloud2_10_326_1370433026-00000003 setting write format to slin48 from opus native formats (opus)
[Opus] Created encoder #10 (48000->opus)
-- Hungup 'IAX2/myprovider-14409'
-- Executing [s at bridge_me:3] Goto("SIP/webrtc_form_cloud2_10_326_1370433026-00000003", "bridge-unlink,s,1") in new stack
-- Goto (bridge-unlink,s,1)
-- Executing [s at bridge-unlink:1] Set("SIP/webrtc_form_cloud2_10_326_1370433026-00000003", "CHANNEL(accountcode)=ANSWERED") in new stack
-- Executing [s at bridge-unlink:2] CELGenUserEvent("SIP/webrtc_form_cloud2_10_326_1370433026-00000003", "3XX5XXXXX,9,20,7") in new stack
-- Executing [s at bridge-unlink:3] Set("SIP/webrtc_form_cloud2_10_326_1370433026-00000003", "CDR(userfield)=6303690") in new stack
-- Executing [s at bridge-unlink:4] Set("SIP/webrtc_form_cloud2_10_326_1370433026-00000003", "CDR(accountcode)=3XX5XXXXX") in new stack
-- Executing [s at bridge-unlink:5] Hangup("SIP/webrtc_form_cloud2_10_326_1370433026-00000003", "") in new stack
== Spawn extension (bridge-unlink, s, 5) exited non-zero on 'SIP/webrtc_form_cloud2_10_326_1370433026-00000003'
[Opus] Destroyed encoder #10 (48000->opus)
[Opus] Destroyed decoder #7 (opus->48000)
so I think that we're alone and we have to find another way to do what we did
or better a way that will play well together with opus...
I'm open to advice :)
Andrea
More information about the asterisk-dev
mailing list