Dale, thanks for the issue analysis. I have set Server Type to
Broadsoft in phone’s settings and the "Supported: replaces, eventlist"
header has appeared. However, with a new SPA942 configuration sipXecs
sends the reply with an error "415 Unsupported Media Type or Content
Encoding" to the phone’s SUBSCRIBE message. I have read your message
concerning the same error in the sipx-users mailing list. It seems to
me that SPA942 phone SUBSCRIBE message contains all necessary
information. I have made new snapshot:
http://track.sipfoundry.org/secure/attachment/26632/sipx-snapshot-BLF-problem--SPA942-server-type-Broadsoft.tar.gz
In my sipXecs configuration BLF is used by users 203 and 209.
Problem Call-IDs are: [email protected] and
[email protected]
--
Sincerely yours,
Alexey Kanukhin
On Wed, Sep 8, 2010 at 12:11 AM, Worley, Dale R (Dale)
<[email protected]> wrote:
> ________________________________________
> 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/
>
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
