Pjsip Codec Negotiation
Here's a question for the wideband fans: I'm setting up a new system (FreePBX 2.11.0.37, Asterisk 11.9.0, CentOS 6.5) that will eventually replace my old PBX (FreePBX 2.8.1, Asterisk 1.8.7.2, CentOS 5.8). One goal (never achieved on the old), is for internal calls to be HD, but PSTN calls to use G.711, without transcoding. For initial testing, I've set up two Yealink T26P extensions and one Localphone trunk.
When I manually print using PDFLite as the printer (ie. Open the file, click print, select PDFLite, select a location and name the file), the file opens fine in Adobe, any version. I have been searching the internet trying to find other people who had the same problem. When I use the code above, there is a file format error when trying to open the file. Adobe pdf printer download.
SDP Negotiation State Machine (Offer/Answer Model. AMR fmtp 'octet-align' field can be adjusted with the offer when the codec implementation support both.
Internal and external calls work, except for the transcode issue. The phones are set for g722, ulaw and alaw in that order. The extensions are coded with allow=g722&ulaw&alaw; the trunk with allow=ulaw&alaw. Internal calls are g722, as expected. But on outbound PSTN calls, Asterisk is accepting the phone's first-preference codec (g722), speaking ulaw on the trunk side and transcoding, resulting in degraded quality. Incoming calls work properly; 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? Thanks, Stewart. Said by: Is Asterisk planning to fix this mess? If so when?It's not a bug, it's a feature! ™ This effect is because of the architecture of Asterisk as a B2BUA. There has been a lot of discussion about this over the years and I while understand a new SIP implementation, pjsip, is supposed to come to the rescue for a lot of things, I am not sure if this will improve on codec selection. It would be quite nice to select codec based on highest quality mutually supported codecs of two remote endpoints.
Pjsip Video
Many thanks for all the replies. It is disappointing to hear that proper codec selection is still not 'automatic' in Asterisk. Given that nearly all IP desk and cordless phones sold in the past five years have wideband capability, it would seem that the majority of office PBX systems would want this. @Michael: Order of codec preference does not help.
If the originating phone has g722 first, you get the unwanted transcoding. If it's later in the list, you don't get wideband at all, unless forced as suggested by Trev. You are correct that getting Asterisk out of the media path does eliminate the gratuitous transcode, and that's a good thing to do for reduced latency and jitter, not to mention that when running on a cheap (i.e. Grossly oversold) VPS, if you run out of horsepower, quality gets unusably bad.
Ideally, I'd like to re-invite on every call, but there are some upstream carriers that don't handle it properly, so the case where Asterisk proxies audio still needs to work correctly. I'm also having trouble getting the new system to re-invite (the old one does it when told) and will start another thread about that. @Trev: 'Clunky' is an understatement. It sounds pretty simple to just force ulaw on trunk calls, or g722 on internal calls. However, the former won't work for me, because sometimes alaw (rather than ulaw) is needed, and on some trunks that gets decided by an upstream carrier and isn't consistent. Though transcoding between ulaw and alaw results in only a tiny reduction in quality, I don't want that to preclude a reinvite. So, I'll probably set g722 as last in the phones, then force g722 on calls that can benefit.
Sip Vs Pjsip
Of course, the decision must be made before the Dial command, which means that one can't find out what the remote end can actually accept. In some cases that gets really ugly - if some iNum contacts can do wideband and others not, I'd need a manually created database to distinguish them. @kaila: Your example does not agree with my current understanding. In my present situation, it's the inbound leg's codec that's wrong, and what would need to be forced.
I believe that forcing ulaw on the outbound leg would not prevent the inbound from going g722, with undesired transcoding. I believe this » is a working example; mine would be more complex, as we don't dial 9 or 0 to mark an outside call. When this is all working, I'll post an update. Said by: Many thanks for all the replies.
It is disappointing to hear that proper codec selection is still not 'automatic' in Asterisk. Given that nearly all IP desk and cordless phones sold in the past five years have wideband capability, it would seem that the majority of office PBX systems would want this.I don't know if this only happens with. Nevertheless, you can try to explore other B2BUA, i.e., etc. You can try a Windows version of + GUI for FS if that is your preference on your Windows computer. Not sure if you have seen this: » If I follow you correctly, you basically only want to use g722 only when both endpoints have g722 ability? My provider (voip.ms) does not support g722, so I feel your pain.
I have all of these fancy phones which sound great when you call each other 'internally'. I use a VPS to host my PBX (used to be at home). CPU is a pricey commodity on a VPS. The transcoding overhead for 722-711 isn't that high, but I've noticed garbling at times. I'm to the point where I'm probably going to just turn g722 off until I can find a solution. The 'codec by route' fix would help tremendously. At least I could enjoy the call quality on 'internal' calls.