New FreePBX install: no re-invite and unwanted transcoding

General Help
1

I am unable to get re-invite to work on a new system. Also, unwanted transcoding is occurring on PSTN calls.

The new system (FreePBX 2.11.0.37, Asterisk 11.9.0, CentOS 6.5) will eventually replace an old system (FreePBX 2.8.1, Asterisk 1.8.7.2, CentOS 5.8) currently in production. Both systems are on VPS with public IP addresses. Goals for the new system include: HD (g722) connections on internal calls, Asterisk only proxies audio when necessary, no unwanted transcoding.

For initial testing, I’ve set up two Yealink T26P extensions and one Localphone trunk. Internal and external calls work, except for the problems above. The extensions are behind a NAT, but are set up with STUN, unique SIP and RTP ports, and proper forwarding. The router handles hairpin connections properly. When registered to the old system, calls between the test extensions re-invite correctly. On the new system, no re-invites are attempted and I see nothing logged to indicate why. There is also no re-invite on inbound or outbound trunk calls, or on a trunk-to-trunk call (tested by setting follow-me to an external number).

The extensions are coded with:
Asterisk Dial Options: r
canreinvite: Yes
nat: No - RFC3581
disallow: all
allow: g722&ulaw&alaw
Recording Options (all): Never

The trunk (both PEER and USER Details) has:
canreinvite=yes

In Advanced Settings -> Device Settings I have:
SIP canrenivite (directmedia): Yes

In Asterisk SIP Settings I have:
NAT: No
IP Configuration: Public IP
Codecs: ulaw, alaw
Reinvite Behavior: Yes

Other settings are defaults, except for a non-standard bindport.

On outbound PSTN calls, Asterisk is accepting the phone’s first codec (g722), speaking ulaw on the trunk side and transcoding, resulting in degraded quality. Incoming calls escape this problem; Asterisk offers ulaw/g722/alaw, the phone accepts the first (ulaw) and no transcoding occurs. How can I tell Asterisk to prefer ulaw over g722, when it would otherwise need to transcode? (The transcoding issue also affected the old system, but I just gave up on HD and disabled g722 on the phones.)

Any advice will be gratefully appreciated.

Thanks,

Stewart

2

it is in the order of the codecs you define that are acceptable, asterisk will always accept the first agreed codec in the list.

3

Thanks for the reply. By “first agreed”, do you mean the first codec in the originating phone’s offering that is in the ‘allow’ list for that extension? If so, that’s what seems to be happening but is in most cases not what would be wanted. Better would be to accept the first offered codec that is allowed by both extension and destination channel. Only if there are none, would transcoding be done.

There are a huge number of deployed Asterisk systems that have HD-capable phones and also connect to the PSTN. I’d guess that the number is north of 100,000. Surely someone has set up their system so that on calls to the PSTN, the phones connect in G.711 so no transcoding is needed, yet on internal calls, a wideband codec is used. How can this be achieved?

4

Make sure the PSTN trunk can only do ulaw. Setup the phone for g.722 and ulaw.

Asterisk will probably still transcode the call down, why, I can’t tell you. My guess is because the first leg of the call is negotiated before the bearer capabilities are even analyzed on the second leg.

5

Is there no way for a “reinvite” to renegotiate the audio somehow? I’m wanting to do the same thing- I’m wanting the server to function more as a proxy. I was also hoping (perhaps stupidly), that use of SIP Info for DTMF would allow the system to still receive “DTMF” even though the audio wasn’t going through the system (for some of those features that listen mid-call)…

6

Yes, you can reinvite but that is not how Asterisk works and most carriers other than wholesale backbone don’t accept third party diversions.

As you pointed out this is more of a proxy function than a B2BUA, that’s what Asterisk is.

You also need to brush up on SIP DTMF auto simple attempts to detect the DTMP transmission method.

To understand the complex functions your are trying to implement I highly recommend: http://sipknowledge.com/elearn.html