Indicates the endpoint sub-type for an endpoint of type "Application".
Assembly: Microsoft.Rtc.Collaboration (in Microsoft.Rtc.Collaboration.dll)
|Indicates that the endpoint does not have a sub-type.|
|Indicates that the endpoint provides communication with the principal associated with the device. The principal can be a human being or an application. (Advanced)|
|Indicates that the endpoint provides communication with an application that will take messages and deliver them to the principal.|
|Indicates that the endpoint provides communication with an application that will act as an intermediary in contacting the principal associated with the device, or a substitute.|
|Indicates that the endpoint provides communication with an application that will provide information about the principal.|
The sub-type of an endpoint is only meaningful if its type is "Application". The most common sub-type is "attendant". The sub-type is typically used by any application that interacts with an information worker in an automated fashion by for example using voice user interface technologies such as Automated Speech Recognition, Speech Synthesis, touch tones, or even instant messages. An auto-attendant typically consists of multiple instances fronted by a load balancer for high availability purpose. When communicating with an endpoint of sub-type "attendant", the far-end targets the endpoint Uri as opposed to the Application Uri (Owner Uri) when adding a modality. Unlike human beings who can coordinate the use of multiple endpoints in a communication, an auto-attendant typically requires the multimodal calls of a given conversation to be routed to or originated from the same application instance and endpoint. Advertising that an Application is an auto-attendant is of utmost importance to handle multimodal escalation by information workers. Note that the endpoint sub-type is based on the header parameter actor defined in RFC 3840.