Hi all, Polycom is looking for input from the sipXecs community on a possible phone enhancement. Namely, would be use it and do we have any other suggested use cases?
------------------------- Polycom is considering supporting a resource list attribute that will allow the specification of differing actions towards a BLF monitored user. One such difference is easily understood using Call park as an example. Ex) Your phone monitors the following BLFs, ext 200 (a regular user) and ext 5555 (a park orbit). Suppose you have an active call with Alice, and you press the BLF line key associated with 200. Alice will be placed on hold and a new call will be placed to the user at extension 200. The same situation however, when pressing the key for the monitored park orbit, would instead perform a blind transfer thereby parking Alice at 5555. Which action to execute for a particular monitored user would be determined in one of two ways. First, through the automata parameter in the contact header of the 2XX response to the subscribe or the contact header in the first notify received. If the resource type is not learned via the signaling then the phone would fall back on a resource type parameter in the Polycom configuration files to serve as a default type. We hope to grow the actions available but for now the sip.automata feature tag ( a boolean value) would indicate whether the UA represents an automata (such as a voicemail server, conference server, IVR, or recording device) or a human. See http://tools.ietf.org/html/rfc3840#section-10.7 We envision usage to be something like this (see the 6th line for the new parameter): <?xml version="1.0"?> <list xmlns="urn:ietf:params:xml:ns:rlmi" uri="sip:[email protected]" version="7" fullState="true"> <name xml:lang="en">Buddy List</name> <resource uri="sip:[email protected];automata <sip:[email protected];automata> "> <name>Bob Smith</name> <instance id="juwigmtboe" state="active" cid="[email protected]"/> </resource> </resource> </list> The scheme for the above xml is here http://tools.ietf.org/html/rfc4662#section-5.1 Are there any alternative actions or use cases that users would see as beneficial? Would this be something you would consider supporting on sipX? ------------------------- Thanks. -Paul [email protected] _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
