+- Yealink Forums (http://forum.yealink.com/forum)
+-- Forum: IP Phone Series (/forumdisplay.php?fid=4)
+--- Forum: T4x Series (/forumdisplay.php?fid=31)
+--- Thread: T48G Intercom Auto-answer (/showthread.php?tid=37497)
Pages: 1 2
RE: T48G Intercom Auto-answer - Travis_Yealink - 11-22-2016 08:41 PM
(11-22-2016 02:49 PM)cm21 Wrote: Yealink Support, to answer your questions:
1) I want an intercom button, that also monitors the status of that extension. Before I call the extension, I want to know whether they are already on the phone with someone else. That is why I want it to show the BLF status.
2) I understand the difference in the features. I was asking about how the phone handles the two different types of DSS keys "Intercom" and "BLF". It appears to me that the phone handles them both the exact same way, but just shows a different icon.
3) I understand how an Intercom call should work, but was asking what SIP headers (or similar) the phone needs to see from the server to handle a call as an Intercom call instead of a regular call.
Based on the response from "jolouis" below, he's stating that the auto-answer header (Alert-Info:answer-after=0) is what is needed.
However, I'm wondering if the phones consider "Auto-Answer" and "Intercom" to be two different things, because:
* If I set "Allow Intercom" to Disabled on a phone (and restarted just to be sure), it STILL auto-answers when given that SIP header.
* Also, at least so far, the (new?) features.intercom.headset_prior.enable setting doesn't seem to be having an effect - goal is to force speakerphone for incoming intercom calls, regardless of whether the headset button is currently on/off before the intercom call comes in.
1) Ok, i understood your secnario now, but I don't think BLF can work with Intercom in one single button.
2) Still confused me. BLF is to monitor an extension, why do you said it's exact same way with intercom?
3) Yes, jolouis metioned a good way. The auto- answer feature won't be influenced by the "Allow Intercom" disabled, as long as the header has the cooresponding info, the call will be answered automatically.
Also, do you connect the headset on the phone? Does it work properly?
RE: T48G Intercom Auto-answer - cm21 - 11-28-2016 08:29 PM
1) I would really request this feature. The latest firmware supports updating the "BLF" status on an Intercom button (I've tried it), but it doesn't work if a dialing prefix (e.g. *80) is added on. Having the ability to use a prefix that only affects dialing (but not BLF monitoring) would be very useful.
2) As noted, above, the latest firmware includes BLF-capability on "Intercom" buttons. When that is enabled, it seems like the buttons work the same way, just display a different icon. That is all I was asking/confirming.
3) You wrote "the auto-answer feature won't be influenced by the "Allow Intercom" disabled" -- So, what is the "Allow Intercom" setting for? Again, this implies that auto-answer and Intercom are two different things, but I don't know how to make the phone see an incoming call as "Intercom"
4) Yes, I have a headset connected and it works fine for normal calls. But for incoming Intercom calls, I'm trying to make sure they are always answered on Speakerphone (since the person may not be right at his phone), even if the phone has the headset button lit when the call comes in. I'm not clear whether that's the purpose of the features.intercom.headset_prior.enable setting, but I have experimented with that both ways (0 and 1) and it seems to have no effect on how incoming calls are handled that have the Auto-Answer flag. Please clarify.
RE: T48G Intercom Auto-answer - cm21 - 01-17-2017 04:27 PM
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.
RE: T48G Intercom Auto-answer - anonymous1712222627012 - 01-19-2017 06:51 AM
There's a function to "priorize" the speakerphone when you get a page. 2AM here, i'll post back in around 7-8 hours when i'll get to work
RE: T48G Intercom Auto-answer - engine411 - 03-06-2017 08:48 PM
(01-17-2017 04:27 PM)cm21 Wrote: 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.
I don't have these settings (bolded) in my T46G default template on latest 3CX and latest Yealink firmware. Are these features available only for T48G?
(01-19-2017 06:51 AM)fraukas Wrote: There's a function to "priorize" the speakerphone when you get a page. 2AM here, i'll post back in around 7-8 hours when i'll get to work
@fraukas Did you ever find more on this?