Asterisk 13.18.0: Pjsip: Unnecessary 603 Decline Because Of Wrong Codec Decision

Home » Asterisk Users » Asterisk 13.18.0: Pjsip: Unnecessary 603 Decline Because Of Wrong Codec Decision
Asterisk Users 4 Comments

Hello!

I’m facing the following scenario:

– Initial call opened to asterisk: SDP g722,alaw,ulaw

– Outgoing call to provider started with Invite / SDP alaw, g726 and
g729.

– Provider sends 183 Session progress SDP: g729, alaw

– Provider sends g729 rtp packages

But: there is no license to transcode g729.

What is asterisk doing?
Asterisk decides to stop the call at all:
– Sends cancel to provider and 603 decline to internal caller.

What would have been correct?
It would have been correctly to switch to alaw as provider offered it, too.

Workaround:
My workaround is to disable g729 and things are working fine again for me (for this special case).

I’m seeing here two basic problems:
1. Asterisk prevents a call which could have been working fine if
asterisk would have done the switch to alaw which is offered by
provider.
2. Asterisk would have done completely unnecessary transcoding even if
g729 transcoding would have been supported.

I would be glad, if Asterisk would take better care of what it’s deciding which codec to use. g729 was the codec with the lowermost priority in the own offered SDP to the provider but it anyway accepts this codec even though provider offers the own most desired alaw!

Thanks, Michael

4 thoughts on - Asterisk 13.18.0: Pjsip: Unnecessary 603 Decline Because Of Wrong Codec Decision

  • So, you’re claiming to the provider that you can support all those codecs.

    So, you shouldn’t be offering it.

    Once the codec’s been agreed on, between what the two sides offer to each other, you can’t change it later. Only offer what you’re prepared to accept.

    That’s not a workaround – that’s correct configuation.

    If you don’t have a G.729 licence, don’t offer G.729 to the peer.

    Antony.

  • Why? Asterisk lists this codec as supported – it just cannot transcode it (but it could be passed through). And it wouldn’t be necessary to transcode at all, because provider offered alaw, too.

    BTW: here is a g729 library to transcode:
    https://gist.github.com/worldadventurer/c80e4d051937db887b40f3ab0084ce06

    Asterisk didn’t agree! There has been no 200 ok sdp. Therefore Asterisk would have the chance to pick the other codec. But it didn’t try it at all. It just canceled the call.

    Passthrough would work if there would be a phone on the other side supporting g729. Therefore it’s ok to offer it.

    Michael

  • I don’t think it’s possible to tell Asterisk either:

    – only to offer a codec for pass-through without also offering it for transcoding

    – to select a codec based on pass-through in preference to another which needs transcoding

    It cancelled the call because it couldn’t bridge the two legs. It offered G.729 and it was accepted by the peer, so that’s what this leg was going to use.

    Agreed.

    Only if you can offer it for pass-through but not for transcoding. I don’t think Asterisk supports this.

    I can see why you think alaw would have been a good choice for this call, but I can’t think of way to explain that to Asterisk without simply removing G.729
    from what it offers to handle.

    Antony.