I noticed in the UCS 3.3.1 release notes that there are some new configuration parameters for controlling server-based DND and call forwarding using feature codes. I'm running an Asterisk/FreePBX system in which I'm using a somewhat goofy macro that dials *76 to trigger the server DND, plus the local DND function for the phone, and this workflow can cause the two to get out of sync sometimes.
There seems to be a lack of documentation on the new configuration parameters (such as "reg.x.serverFeatureControl.activateCodeSequence.dnd") and how they can be used to do server-based DND. Can these config parameters be used with something like an Asterisk/FreePBX system, and if so, how?
Solved! Go to Solution.
To my knowledge, previous support for server-based DND did not encompass star code dial strings.
Some PBX's like Asterisk utilize star codes instead of signaling via SIP messages to initialize and control server-based features.
reg.x.serverFeatureControl.deActivateCodeSequence.dnd is a string value that will be the sequence of digits to activate DND status on the server when dialed. This is usually a star code.
Try testing with this added to your configuration file:
(voIpProt.SIP.serverFeatureControl.dnd will need to be enabled as well)
If your Asterisk server has support for other star codes to control the various 'statuses' for DND (enable/disable for 'always, busy, noanswer', etc), you would want to utilize the other reg.x.serverFeatureControl parameters listed in the Release Notes.
Hi James, thanks for the response.
I tried your suggestion, but it doesn't seem to be doing anything. I know I'm using version 3.3.1.
I put for each of my line registrations:
I also tried setting reg.1.serverFeatureControl.dnd="1" and reg.2.serverFeatureControl.dnd="1" as well. Checking the logs on Asterisk, the phone doesn't seem to be sending the feature codes to it when I press the DND button. Local DND is showing on the phone, but that's it.
I also see these in the release notes, with no mention of how to use them (so I haven't tried them). Not sure if they are a piece of the puzzle, or not:
OK, I feel like I am actually very, very close on this. After spending way too much time on this, I figured out how to get the phone to enable DND using the feature code, and subscribe to get presence notifications. What the phone does not seem to do, is listen to the SIP NOTIFY that it is receiving from Asterisk, so I don't think it knows it's in DND, and consequently it will not issue the feature code to clear the server-side DND status (because I'm assuming it thinks it's not in DND). With the SIP NOTIFY, I did go so far as to figure out that part of it was formatting, and after actually editing chan_sip.c and recompiling Asterisk, it is sending the presence message and the phone is responding "200 OK" to it, but I still don't think it's listening to the notification.
And so the question to Polycom..... Can you give me an example of a working SIP NOTIFY that the phone will listen to for enabling its DND status? Below is an example of what Asterisk is trying to send it now (I replaced revealing items in the SIP URI, put in some spaces where emoticons were appearing):
<?xml version="1.0" encoding="ISO-8859-1"?> <presence xmlns="urn: ietf: params: xml: ns: pidf" xmlns: pp="urn: ietf: params: xml: ns: pidf: person" xmlns: es="urn: ietf: params: xml: ns: pidf: rpid: status: rpid-status" xmlns: ep="urn: ietf: params: xml: ns: pidf: rpid: rpid-person" entity="sip:email@example.com"> <pp: person> <status> <ep:activities> <ep:busy/> </ep:activities> </status> </pp: person> <note>On the phone</note> <tuple id="myext"> <contact priority="1">sip:my firstname.lastname@example.org</contact> <status> <basic>closed</basic> </status> </tuple> </presence>
Please, please help. I am so close, I think......so very, very close.
Seems like this topic has generated a bit of interest. The release notes refer to an ID # 55059, which doesn't seem to be posted as a technical document online that I can see. I'm eager to finally get this working and then share the whole solution for the benefit of us Polycom & Asterisk/FreePBX users. Again, all I need to know is the acceptable format of the pidf+xml (or xpidf+xml, with a pidf+xml header?) SIP NOTIFY that'll tell the Polycom that it's supposed to be in DND. It's frustrating that there's no documentation on this yet, and I gotta believe we can get this working somehow.
I just bought another SoundPoint IP 650 yesterday for our company, and was hoping to be able to consult on this and recommend these phones to other clients of mine who are considering going VoIP. As such, I'm very grateful for the creation of this new support community and I'm hoping that we can come up with good solutions for some of the remaining nagging issues that Polycoms and Asterisk-based systems have with some of these features.
Are there any Polycom engineers, developers....who can give the answer to this?
my colleague James suggested the serverFeatureControl.activateCodeSequence / deActivateCodeSequence configuration Parameters.
I have looked through the UCS 3.3.0 Admin Guide and the UCS 3.3.1 Rev F template files and none of these Parameters seem to be mentioned yet for this Software Version.
We have some upcoming releases that include the Functionality to use Feature Access Code to set the Feature and a SIP NOTIFY message to inform the phone of the feature state but as far as I am aware this is not yet documented in the current Software (UCS 3.3.1).
Looking at the Polycom Spectralink 8400 Admin Guide at http://support.polycom.com/global/documents/support/setup_maintenance/products/voice/UC_Software_4_0...
I can see these Parameters and their values documented (PLEASE BE AWARE THAT THIS SOFTWARE HAS NOT YET BEEN RELEASED FOR YOUR HARDWARE!) and it mentions in addition reg.x.serverFeatureControl.signalingMethod.
The default setting for this is subscribeAsFeatureEvent and another value can be inviteFACSubscribePresence.
There is also a reg.x.serverFeatureControl.subscribeToUri with an interpretation of "The URL to subscribe to when sending the server-controlled feature requests".
Please be aware that these features are not yet documented in the UCS 3.3.1 Release and have most likely been added for Interop Partners so Polycom Support may be unable to provide any further assistance until the Documentation has been updated and the feature is officially released to the public.
Thank you, Steffen, for your response, and the link to the 4.0 guide. The parameters are indeed mentioned in the release notes for UCS 3.3.1F (but not documented as they are in the 4.0 guide). So I was hoping that the functionality would work on some level.
That said, though, I'm sorry to say that I am, at least, that far along in getting this set up. After beefing up the phone logging, I was able to find the "inviteFACSubscribePresence" value because the logs told me it was a valid value. Also, I think I figured out for myself that I also needed to use the subscribeToUri (I'm using "sip:email@example.com", with a hint specified for the same extnum on Asterisk's end, like how hints work for BLF presence).
Ergo, I can hit DND, it'll send the feature code to put the phones in DND, and I can see Asterisk send the SIP NOTIFY with the presence information back to the phone, and the phone replies with a "200 OK" to that, but then doesn't do anything to recognize that it's in DND. It doesn't seem to be interpreting the notify. Because of that, I can only bring the phone out of DND on the server-side by manually dialing the feature codes for each line registration. Because the Polycom doesn't know it's in DND, it doesn't let me clear DND status because it thinks its still off....so it won't dial the deactivation feature code. My boss jokes that we've created a DED...."Don't Ever Disturb". It only goes one way, and can't be turned off.
Now, getting into detail about the the subscribe/notify that Asterisk is sending but the Polycom is not apparently interpreting.....
For BLF presence, the Polycoms want, and use, the xpidf+xml format that Asterisk delivers to it....and it does this quite well, for on-the-phone and DND indications. When the Polycoms subscribe to this presence, it notifies Asterisk correctly that it accepts xpidf+xml as a format, so that's what Asterisk sends it. And that part of the whole presence thing works great.
For the DND subscription, though, the Polycom tells Asterisk that it only accepts pidf+xml. Curiously, the current programming of chan_sip.c says that, in effect, Polycoms only "really" listen to xpidf+xml, even if they say they want pidf+xml, so they hardcoded it to always send xpidf no matter what the Polycom asks for. If I left Asterisk the way it was written, the Polycom responds "415 Media Type Not Supported" when it receives the SIP NOTIFY of DND status from Asterisk. I suppose that makes sense, as the Polycom did in fact only state in the subscribe that it wanted pidf+xml. OK, so I edited chan_sip.c and recompiled it, so that Asterisk would send the Polycom what it asked for....pidf+xml. Asterisk sends the notify for DND, the Polycom responds "200 OK" to it, but does nothing. I scour the Internet for the various options in formatting a pidf presence indication (because apparently Asterisk, Cisco phones, and others, all have slightly different schema. As this is not documented for Polycoms, not even in the document you gave me the link to, I don't know for sure what the Polycom is really looking for in the notify).
Given that the Polycoms do respond to BLF presence notifications in xpidf format correctly, I also tried hacking chan_sip.c in Asterisk to send the same xpidf message that it does for BLF, but to avoid the 415 error, I told the SIP header that the Content-type is pidf+xml as the phone asked for. So then it was sending a SIP NOTIFY with a Content-type of pidf+xml, but the contents of the message is the same xpidf format that the Polycom gets, and acts on correctly for, BLF notifications. The phone responds "200 OK" to the message again, but still, it does nothing. I've cranked up all of the logging possible on the phone, but it isn't giving me any intel as to what it's looking for, so it can recognize from the notify that it's in DND. I've now tried several variants of pidf and xpidf presence messages, to no avail. I don't know if this is actually a bug in 3.3.1F that is going to be addressed in 4.0 (I don't suppose that's in public beta for the newer SoundPoint phones, is it?). Or if this is just a case where the Polycom is looking for a very specific schema that Asterisk is not sending to it.....in which case if I knew that schema, I could edit chan_sip.c so that Asterisk sends the right thing to the Polycom....and then beseech the Asterisk community to make those changes on their end, so non-Asterisk hackers can also enjoy the feature.
That is basically the full extent of where I am with this. The main problem is that this has turned into a vendetta. For such a seemingly trivial thing, you have no idea the sense of accomplishment I will feel if there is a resolution to this that can be shared in some way.
at this moment in time, we from Support do not hold any public information on formatting the SIP Notify response for a working DND example.
I can only advise you to make yourself familiar with the Polycom ARENA Program at http://www.polycom.com/partners/interoperability/polycom_arena/voip_interoperability_partner_program...
Above is designed for VoIP Interoperability Platforms and enables manufacturers of SIP-based call control platforms to interact with Polycom.
Polycom Global Services
OK, very well. Having said that, if Polycom intends to tout the added feature of FAC/Notify for DND/CFWD in their software releases, then as a member of the Polycom Community, I can only advise that Polycom generate and release some public information on the formatting of the SIP Notify messages so that we can actually use this new feature. Otherwise, why even mention its existence?
I completely agree with you, proper documentation helps maintain and grow the community ecosystem around Polycom products.