> 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
In the above case, it seems that the question is whether the sip.automata feature tag is present as a field-parameter in the Contact header in a request or response from the device in question. E.g.: Contact: <[email protected]>;automata (Due to the oddities of how SIP feature tags are handled, the "sip." is not written here -- see RFC 3840 section 5.) This mechanism seems to only be available if the phone is making a subscription directly to the device in question, which bypasses sipX, so I don't have anything to say about that. (Cleaned up:) > 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"> > <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 In this case, we're using "automata" as a URI-parameter, which seems risky -- we are assuming that we can arbitrarily add the parameter to the URI without changing its meaning, the device it routes to. (I doubt that adding a parameter would change the device a URI routes to, but it easily might prevent it from routing to the device.) Instead of a URI-parameter, it seems to me to be better to add elements to the <resource> element to carry UA capabilities. Of course, we have to put them in a proprietary extension namespace: <?xml version="1.0"?> <list xmlns="urn:ietf:params:xml:ns:rlmi" xmlns:plcm="http://polycom.com/extensions/capabilities"; uri="sip:[email protected]" version="7" fullState="true"> <name xml:lang="en">Buddy List</name> <resource uri="sip:[email protected]"> <plcm:param pname="automata"/> <name>Bob Smith</name> <instance id="juwigmtboe" state="active" cid="[email protected]"/> </resource> </resource> </list> (This syntax is copied from dialog events, RFC 4235 section 4.1.6.2.) But in any case, having the phone decide how to treat the button based on whether the target URI is an automaton seems unwise. E.g., an extension which provides a recorded message giving weather conditions is an automaton, but you might not want to have a button assigned to that extension perform the blind-transfer function. Instead, why not have the proprietary extension of the <resource> element *configure* what the button should do? Then we could write: <resource uri="sip:[email protected]"> <plcm:button function="xfer"/> ... </resource> <resource uri="sip:[email protected]"> <plcm:button function="call"/> ... </resource> > Are there any alternative actions or use cases that users would see as > beneficial? Would this be something you would consider supporting on > sipX? In the case of the sipX RLS, if sipXconfig adds a proprietary extension tag to a <resource> element in resource-lists.xml, the RLS copies it directly into the RLMI XML in the event-list NOTIFYs that it generates. So sipXconfig could use this mechanism to convey configuration information to subscribing phones. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
