[asterisk-users] asterisk 13.18.0: pjsip: unnecessary 603 decline because of wrong codec decision

Michael Maier m1278468 at mailbox.org
Wed Nov 1 06:15:08 CDT 2017

On 11/01/2017 at 10:14 AM Antony Stone wrote:
> On Wednesday 01 November 2017 at 08:10:36, Michael Maier wrote:
>> 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.
> So, you're claiming to the provider that you can support all those codecs.
>> - Provider sends 183 Session progress SDP: g729, alaw
>> - Provider sends g729 rtp packages
>> But: there is no license to transcode g729.
> So, you shouldn't be offering it.

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:

>> 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.
> Once the codec's been agreed on,

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.

> between what the two sides offer to each 
> other, you can't change it later.  Only offer what you're prepared to accept.
>> Workaround:
>> My workaround is to disable g729 and things are working fine again for
>> me (for this special case).
> 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.

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


More information about the asterisk-users mailing list