I have a bit of an odd situation here. Using Cisco 79x0 phones, I am able to call to other extensions, other sites on the far side of a tunnel, accept incoming calls, and make outgoing calls. I never have codec problems, as the PBX transcodes as needed.
However, if I am on one call and use the phone’s built-in “Conference” or “Confrn” button to try and join two calls together, I found that it only works if my extension has ulaw enabled. Otherwise, it ends with a reorder and the following error:
chan_sip.c: No compatible codecs, not accepting this offer!
Digging a little deeper, I found that the Asterisk SIP Settings > General page only had g729 (for which we have licenses) and ulaw enabled. My extension only had g729 and gsm enabled ( allow=g729&gsm ). Either adding ulaw to my extension or adding gsm to the General settings made it work.
Why is this? Is it something I have misconfigured? an obscure Cisco setting I missed? I would assume that, if my extension were only allowed to use, say, gsm, that the PBX should handle transcoding the audio in this situation, but for some reason the second leg seems to use the codec specified in the general settings instead of the settings specified in the extension config - and oddly won’t work with g729 when we have plenty of available licenses.
PS: I should reiterate that I am not trying to use a conference room here, I am just trying to use the phones built-in conference capability.
Probably, the 79x0 lacks sufficient horsepower (or perhaps, internal licensing) to simultaneously code and decode two G.729 streams, so when you do a three-way call, at least one leg must be G.711. This is true for Cisco ATAs and SPA IP phones; I’m guessing that it also affects the 79x0.
That’s somewhat surprising. If the extension does not have a disallow parameter (only the allow), I’d expect ulaw to still be enabled and the call to work without changing anything. And if it has disallow=all, that would imply that the phone can do GSM, which I believe it can’t. So there may be a bug here. Have you looked at what codecs actually get used in this situation?
However, why are you using G.729 in the first place? It’s 24 years old and voice quality is IMO poor, especially when the path includes a highly compressed mobile codec. If you have sufficient bandwidth, use ulaw (or better) everywhere. If your tunnel is satellite or G3 cellular, I’d recommend using ulaw on the phone and transcoding to/from Opus on each side of the tunnel (assuming sufficient horsepower in the PBX machines). This might also apply to DSL with very limited upstream speed. Please describe your network configuration and speeds.
Edit: It appears that I was mistaken and Cisco does support GSM in some configurations. However, that also IMO sounds pretty poor, so if you are bandwidth challenged consider transcoding in the PBX.
I actually think you may be right about the 79x0 and GSM. I just swapped my allow parameter to allow=gsm and it failed to work. BTW, I do have a disallow=all parameter.
As for the reason we are using g729a? Bandwidth, of course! Much cheaper to buy licenses for g729 once than to pay extra each and every month for enough bandwidth to carry potentially 200+ channels of ulaw (we’re using fiber, not G3 or cellular). I know some folks don’t like the sound quality of GSM or other low-bandwidth codecs, but I don’t think most people have expectations that high for a phone call. The extensions use g729 to keep the transcoding load down on the PBX, and because…why not? What I really need is a good way to play g729 call recordings on a computer, as we now record all incoming calls to a GSM-encoded WAV file and while that works great, the added load on the server to transcode all calls from g729 to gsm for the recording file would be nice to avoid. Unfortunately, recording in g729 eliminates the transcoding, but results in a file that’s hard to play. We can convert the file manually at the asterisk command prompt, but that’s not really scalable.
Back to the original question, which is why the second leg of this call uses the settings for the general section of sip.conf instead of the settings for this extension?
Instead of guessing what it’s using I’d suggest getting an actual packet capture of the failed call. This can confirm whether or not what @Stewart1 is saying is true. The phone itself may not be able to do G.729, and the offer thus contains ulaw.
@jcolp I’ll give that a go after hours when the amount of junk scrolling past the console is more manageable. However, even if the phone is unable to do g729 on two legs, it should still use the settings for the extension, not the SIP General settings, no? In other words, if the extension has allow=g729&ulaw and SIP General has ```allow=g729&gsm", shouldn’t the call go through, even if the phone requests ulaw?
OK, here we go. It looks like the first call offers g729a and ulaw/alaw, while when using the conference feature, the phone only offers ulaw/alaw. This is a normal call:
FWIW, this is now working as I would expect it. That is, if ulaw and/or alaw are enabled for the extension, then it works. Whether ulaw and alaw are enabled in SIP General is irrelevant. I’d swear that wasn’t the case before, but will assume I was just wrong before.
Thanks to all for the help, and it seems that the takeaway is that ulaw and/or alaw needs to be enabled to use the conference function with these 7940/7960 phones.