OK, after many emails back and forth with Yealink support, and many frustrating inabilities to communicate and fully understand each other, I wanted to pass along several things that I've learned and clarified surrounding the topic of Intercom calls. There are a few new features related to Intercom in firmware 35.81.x.x (V81) and I will include comment on those as well:
1. The phones have "always" allowed creating DSS keys with various "Types": Line, Speed Dial, Transfer, etc. One of those types is "BLF" (Busy Lamp Field - displays busy/idle status of that station) and one of those types is "Intercom". I had assumed that if a DSS key was created with a type of "Intercom" that, when pressed, there was some information sent with the outgoing call headers that told the remote phone that this was an Intercom call, and the remote phone would respond accordingly. This is NOT the case as best I've found or been told. There is no difference in how the call is placed. Basically the only difference between BLF and Intercom DSS keys is the icon displayed on the screen for that DSS key.
2. So whether a phone sees an incoming call as "Intercom" or "regular" is determined solely by the SIP headers that the server sends. It is common practice for the calling phone to indicate to the server whether it wants Intercom by including a dialing prefix to the server, e.g. *80, so to intercom to extension 101, you might dial *80101. But obviously the server has to do something useful with that prefix to glue everything together. In this case, the server would add headers to indicate Intercom, and then place the call to extension 101. I'll discuss the specific headers and their combinations and options further down.
3. In previous firmware versions, only "BLF" keys could monitor and display the status of a remote station referred to on a DSS key (e.g. red when busy, green when idle, etc). Now in V81, that support is also available with "Intercom" keys, given the new configuration settings of features.intercom.led.enable and features.intercom.subscribe.enable are both set to 1. In our setup, I like having a visual difference on the screen of a different icon for a BLF key compared to an Intercom key, so you know at a glance whether you're placing a regular call or intercom call. But I also like to see the busy/not busy status of the remote station, so the new ability of the Intercom button to show that is welcomed.
4. However, at least in my default Asterisk installation, if I define an Intercom DSS key on the phone that points to *80101, then the station status monitoring does not work. Yealink has stated that it is NOT possible to define an Intercom key that
dials *80101 and yet
monitors 101 for the status. However, if you're using Asterisk, it's very easy to add the "hint" line that allows the station status to be monitored under either extension, for example:
exten => 101,hint,SIP/101
exten => *80101,hint,SIP/101
With that in place, all is well for either type of DSS key.
5. So, what headers must a phone see on an incoming call to see it as an "Intercom" call? Previous replies (thank you) mentioned this answer from Yealink:
http://support.yealink.com/faq/faqInfo?id=308 The one I will work with is: Call-info:answer-after=0
6. However, what that does NOT mention is that there is a definite difference between "Intercom" and "Auto Answer" in Yealink's terminology. If Answer-After=0, then that's considered "Intercom". But if Answer-After=X (some non-zero number), then it will sound a warning tone/ring for X seconds, and then "Auto Answer" the call. But this is NOT CONSIDERED Intercom. What does that mean in practice? If you send the header including Answer-After=2, the phone will still auto answer the call
even if the phone's setting of "Allow Intercom" is Disabled. That seems very counter-intuitive. Similarly, the "Intercom Tone" setting and the new features.intercom.headset_prior.enable setting only take effect if Answer-After=0, but not if a nonzero ring period is specified. To me, that's very unhelpful, but that's the way it is.
8. In our situation, we like to give the callee some notice that an Intercom call is coming in, so we use Answer-After=2 so there is some decent warning tone/ring first (BTW, the "Intercom Tone" setting when Answer-After=0 does give a brief tone, but just seems very short and easily missed). We also use headsets, and after a headset call the headset button stays illuminated (unless you manually press it after each call). If an Intercom/Auto Answer call then comes in, it defaults to staying in headset mode, which is not very useful it the person doesn't happen to be wearing the headset at the time. If we were using Answer-After=0 (Intercom), then we could use the new features.intercom.headset_prior.enable=0 setting to force the call to be answered using Speakerphone. However, with Answer-After=X that doesn't work, but Yealink has been able to provide info on another header that can solve the problem:
Call-Info: <sip:10.1.1.2>;Answer-After=2;device=speaker
They specify you should give your server's IP address in place of 10.1.1.2.
9. I've tried various scenarios with that header and found as follows:
* The <sip> portion is required. It won't force to speakerphone without it. Not sure why.
* But you can omit the IP address and still work, e.g.: <sip>;Answer-After=2;device=speaker
* For normal Intercom calls, you can use the Call-Info: header or the Alert-Info: header and they work the same. But for this case, it won't successfully force Speakerphone unless you use Call-Info. Alert-Info works for everything except forcing Speakerphone. Again, not sure why.
10. If you're writing your own Asterisk extensions.conf your intercom lines might look something like this:
exten => _*80XXX,1,SIPAddHeader(Call-Info: <sip>\;Answer-After=2\;device=speaker)
exten => _*80XXX,n,Goto(${EXTEN:3},1)
11. So having learned those things, we are able to implement a pretty good solution. Some additional "wishlist" things that would top it off that I don't think are available:
* Enforcing a minimum warning tone/ring volume on incoming intercom/auto answer calls. Helpful if the user has their ringer turned down.
* Specifying a custom wav file for ring on auto answer calls, like you can do on regular calls. As far as I know, you cannot currently do this, but you can specify custom frequency patterns using the voice.tone.autoanswer setting (web interface Settings/Tones/Auto Answer). I'm not super-familiar with all the options available there, but it seems like it's difficult or not possible to set the relative volume of the Auto Answer warning tone, as compared to the volume of the regular ringer, which would be nice to be able to do.
I'm not an expert on VOIP stuff, so any other comments or feedback would certainly be welcome.
