Export (0) Print
Expand All

3 Protocol Details

The server can publish itself by creating a serviceConnectionPoint object in Active Directory with B1A37774-E3F7-488E-ADBFD4DB8A4AB2E5 as a keyword and the client discovers the Telephony Remote Protocol servers that are published in the domain by searching Active Directory for serviceConnectionPoint objects with the same keyword.<5>

The client uses the serviceDNSName attribute to make RPC calls to the Telephony Remote Protocol servers, if the server is currently valid. To determine if the server is valid, the client uses information in the serviceBindingInformation.

The serviceBindingInformation attribute of the object contains the information which is used by the client to identify Telephony Remote Protocol servers. The attribute contains a substring of the format S{<Serverstate>}TTL{<TimeToLive>}. <TimeToLive> string is the concatenation of Year, Month, Date, Hour, Minute, Second, Milliseconds. There are 5 digits allocated for year, 3 digits for milliseconds, and 2 digits for the remaining fields. All the numbers are prefixed with zeros to fill the extra space. The client determines a server as a valid Telephony Remote Protocol servers if <ServerState> is 'Active' and <TimeToLive> is ahead of the current SystemTime. After identifying the Telephony Remote Protocol servers, the client uses the serviceDNSName attribute to make RPC calls to the server.

The client side of the Telephony Remote Protocol MUST call the ClientAttach method on the tapsrv interface to obtain a context handle before calling any other methods of the tapsrv interface.

The obtained context handle is used in subsequent ClientRequest method invocations.

The context handle MUST be passed in a ClientDetach method call to the server after the client is finished using telephony devices on the server. This allows the server to free the resources allocated for the client as identified by the context handle.

A context handle freed by passing it to the server in a ClientDetach method call cannot be used again; instead, the client MUST invoke the ClientAttach method again to obtain a fresh context handle.

Connection-oriented clients of the protocol MUST be listening on the remotesp interface on the RPC protocol sequence and endpoint specified to the server in ClientAttach before invoking the ClientAttach method.

Connectionless clients of the protocol MUST first create a mailslot and then pass the mailslot details to the server in a ClientAttach request.

For asynchronous TAPI operations, the higher-layer protocol or application on the client side needs to maintain the request ID returned by the server. The stored request ID is needed to match the completion notification from the server against the corresponding ClientRequest method call.

The client side of this protocol is simply a pass-through except for the dependencies noted above. That is, there are no additional timers or other states required on the client side of this protocol. Calls made by the higher-layer protocol or application are passed directly to the transport, and the results returned by the transport are passed directly back to the higher-layer protocol or application.

© 2016 Microsoft