search

meetecho / asterisk-opus

Opus (transcoding) and VP8 (passthrough) support for Asterisk, needed for a better WebRTC integration
GNU General Public License v2.0
77 stars 84 forks source link

IAX2 support #1

Open haralambop opened 11 years ago

meetecho commented 11 years ago

I'm unfamiliar with IAX2, so I'm not sure how codecs are negotiated there. Something that needs to be considered is that Opus always negotiates a 48kHz rate, even when it's going to work at lower (e.g., narrow or wideband) ones. Do you know if this might be a dealbreaker for IAX2? When you mean "no voice coming on the other end", do you mean only silence comes out or no RTP is flowing at all?

meetecho commented 11 years ago

I just commited a fix that may be related, as it caused issues with RTP and audio in general: could you try with the new patch?

haralambop commented 11 years ago

Voice is now ok but the bandwidth needed is much higher then g729.

Besides i receive following error

[Opus] Created encoder #7 (48000->opus) [Opus] Created decoder #7 (opus->48000)

000003]: translate.c:362 framein: opustolin48 did not update samples 0 [Opus] Ops! got an error decoding

[Opus] Destroyed encoder #6 (48000->opus) [Opus] Destroyed decoder #6 (opus->48000)

Are you sure that the codec is working in 8000

Thank you

meetecho commented 11 years ago

The codec is able to seamlessly transport different rates (from 8000 to 48000) in a transparent way: in RTP, though, the codec is always reported as a 48kHz one, and Asterisk handles it accordingly. The codec integration in Asterisk takes care of "capping" the rate according to the peer: that is, if you're talking to a GSM peer, there's no sense in using a higher rate, and so Opus encoding is capped at 8kHz as well.

In the debug you pasted, though, I see that encoders and decoders are created with a 48000, which means the codec thinks it is going to talk with an actual 48kHz peer, so this might explain why you're getting a higher bandwidth than necessary. It's likely that the flow actually is 48kHz. For the scenario I mentioned above (talking with a GSM peer) you would see a 8000->opus and opus->8000 debug.

As I said, I'm unfamiliar with IAX2 so I don't know if that's the cause of the issue, that is, the protocol making Asterisk believe it's actually 48kHz. If you check the asterisk-dev mailing list, and in particular this post from a longer thread discussing this work:

http://lists.digium.com/pipermail/asterisk-dev/2013-June/060591.html

you'll see that other users are able to get this to work: nevertheless, I don't think they're using Opus as the codec for trunking (as I think is your case).