Re: LINE_NEWCALL during TSPI_lineOpen or TSPI_lineSetDefaultMediaDetection

Tech-Archive recommends: Fix windows errors by optimizing your registry



Hi,

"Andreas Marschall [MVP TAPI]" <Andreas.Marschall@xxxxxxxxxx> wrote
> "Stephan" <eonline@xxxxxxxxxxxxx> wrote
>> when using the Microsoft remote tapi service provider the behaviour is as
>> follows:
>>
>> When the first client application uses lineopen to open a line, the
>> existing
>> calls on the the line are already available in linegetnewcalls.
>> That can be used for example to pick up information for the call that has
>> been put in the calldata or appspecific members of linecallinfo. (For
>> example put in by a server application that had the line open on the
>> server).
>>
>>
>> I want to have the same behaviour with an own tsp. That can be simulated
>> as
>> Andreas Marschall wrote by having an own tapi app running that already
>> has
>> the line open. If a second app now opens the line it can get the existing
>> calls by calling linegetnewcalls.
>
> Stephan,
> in your scenario there is already an app (the "server application" you
> mentioned) running with the line open.
> You can think of Remote.TSP as a second app (from TAPISRV / TSP's
> perspective
> running on the server).
> So this seem to be the same scenario like I suggest (with the difference
> that
> one "app" is running remotely on the client).
>
> What happens with Remote.TSP on lineOpen when absolutely no one has the
> correpsonding line on the server opened before?
> I guess you don't get preexisting calls by lineGetNewCalls but only
> (automatically) via LINE_APPNEWCALL if the correspodning TSP on the server
> is
> capeable of detecting existing calls at TSPI_lineOpen.
> Is your TSP capable of that?

Yes, my TSPs are capable of reporting new calls like that. That is the
reason for asking. I wanted to report these new calls in a way that the
first starting application gets them with linegetnewcalls and not as if the
calls were created afterwards.

Think about a PBX where you may connect several "First party" TSPs (all
connected via TCP/IP to the PBX). They should work as if they were 3rd Party
Clients. A Server Application puts some CallData inside and the application
on the client computer gets it out.

That could all be easily realised if only own software is used.
The system should support applications that rely on the fact that existing
calls (the ones that have already been processed by the server) are not
reported after lineOpen but picked up with linegetnewcalls.

Best regards,
Stephan Eckbauer





.



Relevant Pages

  • RE: Using kerberosSecurity Throws Security Exception
    ... I am experiencing this error while trying to use a Windows XP client ... application to access a web service located on a W2k3 server. ... client app on the server, ... > Account with a Custom Principal Name using SetSPN.exe utility. ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Re: Slow opening of files
    ... I have disabled the AMON module on the server, on the member server we had ... Yes NOD32 is on the servers, and is setup according to NOD32 support ... You've tried it without your *client* antivirus enabled, ... App itself the file opens immediately. ...
    (microsoft.public.windows.server.sbs)
  • Re: Slow opening of files
    ... will post the IP config tomorrow when I can access a workstation, ... if they open the file via the Office App itself the file opens ... The client has a member server and the same ...
    (microsoft.public.windows.server.sbs)
  • Re: Questions about Remoting, objects, threading. lease lifetime and object cleanup, and a couple of
    ... so long as the Client app is ... always refering to the same server object. ... it sets its ClassOne object to nothing and goes away. ... >>The client app at some point is going to become an ASP.Net app also. ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Remoting or windows service
    ... Thanks for writing up such a decent overview of the remoting dev process ... the client and the server. ... > 2) Implement this class in the server app and say that it can be accessed ...
    (microsoft.public.dotnet.framework.remoting)