asterisk users - Nov 2017 - asterisk 13.18.0: pjsip: unnecessary 603 decline because of wrong codec decision

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

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.
> 
> 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, 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.


Antony.

-- 
"It would appear we have reached the limits of what it is possible to
achieve
with computer technology, although one should be careful with such statements; 
they tend to sound pretty silly in five years."

 - John von Neumann (1949)

                                                   Please reply to the list;
                                                         please *don't* CC
me.

On 11/01/2017 10:14, Antony Stone wrote:
> 
> If you don't have a G.729 licence, don't offer G.729 to the peer.
AFAIK the g729 patents have expired or are granted royalty free for the
holder's declaration:

http://www.sipro.com/G729.html

-- 
Guido Falsi <mad at madpilot.net>

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:
https://gist.github.com/worldadventurer/c80e4d051937db887b40f3ab0084ce06
> 
>>
>> 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.


Michael