asterisk 1.8 codec negotiation

Home » Asterisk Users » asterisk 1.8 codec negotiation
Asterisk Users 4 Comments

Hi. I am using asterisk 1.8 and everything was working fine when I was
at svn 342661. I then upgraded to vrsion 349339 and discovered the
following problem — one of the end points is a freeswitch box which
offers a number of codecs, including PCMU. However, when I tried to
make a call I got a 488 response and a message “multiple audio streams
not supported” in the log.

Is this by design? I found an issue 18859, but that referenced where
the end point offered both regular rtp and srtp. But it seems to me if
an endpoint offers various codecs, that asterisk could only complain if
none of them match one that asterisk likes.

If I only offer one codec, it works, but that seems an unnecessary
restriction to me.

Any assistance on this would be appreciated.

4 thoughts on - asterisk 1.8 codec negotiation

  • Can you show us how the previous INVITE Looked like vs the current one?

    *José Pablo Méndez
    *********

  • “multiple audio streams” != “multiple audio codecs”. For some reason
    Asterisk is receiving an INVITE with an offer for more than one audio
    stream (m=audio), and that is not supported.

  • Kevin P. Fleming wrote:

    OK, but if I have a phone or in my case a server which offers a choice
    of codecs, why can’t asterisk just pick the ones it has rather than
    reject the call? Is there a way to do this correctly as far as asterisk
    is concerned?

  • Did you read the message I sent? It seems that every time you post a
    question here, you ascribe behavior to Asterisk that isn’t supported by
    the logs you have posted, or really, anything at all.

    Asterisk does *not* reject calls just because more codecs were offered
    than it can support (or has been configured to allow). It never has, and
    never will. It has *always* acted in exactly the fashion you have
    requested: if an offer is received that contains at least one codec that
    Asterisk can support, and has been configured to allow, then the offer
    will be accepted with all supported-and-enabled codecs.

    The error message you posted above has *nothing* to do with codecs being
    offered, it is caused by multiple audio streams being offered.