Michael Maier
2017-Nov-01 07:10 UTC
[asterisk-users] 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
Antony Stone
2017-Nov-01 09:14 UTC
[asterisk-users] asterisk 13.18.0: pjsip: unnecessary 603 decline because of wrong codec decision
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.
Guido Falsi
2017-Nov-01 10:02 UTC
[asterisk-users] asterisk 13.18.0: pjsip: unnecessary 603 decline because of wrong codec decision
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: sipro.com/G729.html -- Guido Falsi <mad at madpilot.net>
Michael Maier
2017-Nov-01 11:15 UTC
[asterisk-users] asterisk 13.18.0: pjsip: unnecessary 603 decline because of wrong codec decision
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: 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