[asterisk-users] asterisk 13.18.0: pjsip: unnecessary 603 decline because of wrong codec decision
Antony.Stone at asterisk.open.source.it
Wed Nov 1 07:44:01 CDT 2017
On Wednesday 01 November 2017 at 12:15:08, Michael Maier wrote:
> On 11/01/2017 at 10:14 AM Antony Stone wrote:
> > On Wednesday 01 November 2017 at 08:10:36, Michael Maier wrote:
> >> 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.
I don't think it's possible to tell Asterisk either:
- only to offer a codec for pass-through without also offering it for
- to select a codec based on pass-through in preference to another which
> 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.
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
> > 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.
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.
The first fifty percent of an engineering project takes ninety percent of the
time, and the remaining fifty percent takes another ninety percent of the time.
Please reply to the list;
please *don't* CC me.
More information about the asterisk-users