________________________________________ From: [email protected] [[email protected]] On Behalf Of Alexey Kanukhin [[email protected]]
Therefore I have decided to update an issue #XX-7011. I have attached two sipX snapshots for two operating modes of SPA942 phone - with the settings used for work with Asterisk based PBXs and with settings which close to recommended for manual BLF feature configuration (http://sipx-wiki.calivia.com/index.php/HowTo_manually_configure_BLF_in_a_phone). In last case SPA942 phone tries to subscribe to <sip:~~rl~f~[us...@sipx_ip_address> URI and use RFC3265_4235 as Server Type. _______________________________________________ Good work with those snapshot. Although you should have told what the particular user-names were, which would have made it easier to extract from the snapshots the relevant messages. The fundamental problem is that the SPA-942 is not including in its SUBSCRIBE "Supported: eventlist", which would indicate that it is willing to accept NOTIFYs containing event-list information. (That is what the 421 error responses are telling.) This requirement is documented in RFC 4662 section 4.1: Any client that supports the event list extension will include an option tag of "eventlist" in a "Supported" header field of every SUBSCRIBE message for a subscription for which it is willing to process a list. You will need to get Linksys to fix the firmware in the SPA-942. Alternatively, you could change the first line of code in function RlsSubscribePolicy::isAuthorized in file sipXrls/src/RlsSubscribePolicy.cpp from: UtlBoolean ret = subscribeRequest.isInSupportedField(SIP_EVENTLIST_EXTENSION); to: UtlBoolean ret = 1; But I wouldn't recommend doing that in a production system, as then if someone puts a resource-list URI into his BLF monitoring list, the RLS might try to generate infinitely large NOTIFYs. Depending on your application, you may want to use the user-part "~~rl~C~[user]" rather than "~~rl~F~[user]". The "F" form follows the rules of RFC 4662 strictly. But many devices are unwilling to do the work to process such NOTIFYs, and need the form obtained from the "C" user-part, which combines all of the reported dialogs from all the monitored phones into the status of one (fictitious) phone. In particular, phones that expect to be subscribing to a Broadsoft server will often require this format. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
