Re: Reason for LINEDISCONNECTMODE_NOANSWER
- From: "Martin Richter [MVP]" <martin.richter@xxxxxxxx>
- Date: Wed, 19 Oct 2005 11:34:47 +0200
Hallo Andreas!
The Docs say simply about: LINEDISCONNECTMODE_NOANSWER The remote user's station does not answer
I can also read in the LINECALPARAMS docu: dwNoAnswerTimeout Number of seconds, after the completion of dialing, that the call should be allowed to wait in the PROCEEDING or RINGBACK states, before it is automatically abandoned by the service provider with a LINECALLSTATE_DISCONNECTED and LINEDISCONNECTMODE_NOANSWER. A value of 0 indicates that the application does not desire automatic call abandonment.
Now this is the reason were I get into trouble: If I dial a number via lineMakeCall that is not complete (missing last digit)
Martin, Do use partially dialling for this?
No! It is a full number given from a DB.
it takes some time and the connection is disconnected and nearly all tapi drivers I checked (4 up to know, elmeg, Alcatel) returned as disconnect reason LINEDISCONNECTMODE_NOANSWER. And I can understand this, because I get no answer. Shouldn't it be LINEDISCONNECTMODE_BADADDRESS (The destination address is invalid)?
Now I'm confused: At 1st you said you understand why it is _NOANSWER, then you suggested it should be _BADADDRESS !? Btw. why should it be _BADADDRESS? The address isn't invalid but only incomplete.
Yes but for the user, if he uses his phone the number does not yoield into a connection, and will never do this! So the address is bad!
But in the case above, when the TSP disconects due to timeout reasons I get a LINEDISCONNECTMODE_NOANSWER too. But the situation is different. In one case had a connection but nobody gets on the phone, in the other case there is no connection at all.
Are you refering to UniModem.TSP that is firing LINECALLSTATE_CONNECTED immediately after dialling is complete?
No! I am talking about a callcenter application that dial numbers thoughout TSP from different vendors, I tested some elmeg, Alcatel TSPs.
What events should be and are covered by LINEDISCONNECTMODE_NOANSWER.
As you have already noticed the the TAPI specification has only a brief description of this, it is actually up to the TSP developer to decide. This decision is of course influenced by the information the TSP has available from the corresponding telephone devices.
Conclusion: a TAPI app needs to be tested with _every_ TSP it desires to _properly_ run with!
Bad. Very bad. I alwys thought (maybe I am fool thinking that), that TAPI is a standard Interface and TSP programmers should use disconnect reasons in a way that they fir the docs and specs.
Btw. what is your actual problem with this (or is this "only" academically)?
For further discussion it will be helpfull to post TB20.logs (incl. logged params) for the various scenarious and TSPs.
Yes the discussion is more academically!
We have several disconnect reasons.
Our application needs to decide what to happen with a call that was not connected:
The call was made, nobody replies on the rings and after a timeout may application drops the call. Conclusion for our application: Need to rery later until a retry count is reached. So this is not a problem.
Now we have the cases were we receive a LINEDISCONNECTMODE. Each of the modes is assigned to one of the categories below (this was done by reading the docs very carefully).
- Failures that need special messages and action:
LINEDISCONNECTMODE_UNKNOWN LINEDISCONNECTMODE_PICKUP LINEDISCONNECTMODE_FORWARDED LINEDISCONNECTMODE_CONGESTION LINEDISCONNECTMODE_UNAVAIL LINEDISCONNECTMODE_NODIALTONE LINEDISCONNECTMODE_TEMPFAILURE LINEDISCONNECTMODE_QOSUNAVAIL LINEDISCONNECTMODE_BLOCKED LINEDISCONNECTMODE_CANCELLED
- The categorie the call is Busy and we need to retry it in a view minutes:
LINEDISCONNECTMODE_NORMAL LINEDISCONNECTMODE_BUSY
- The categorie were there was no connection because of timeouts or temporary failures and need to be retried later:
LINEDISCONNECTMODE_REJECT LINEDISCONNECTMODE_NOANSWER LINEDISCONNECTMODE_UNREACHABLE LINEDISCONNECTMODE_DONOTDISTURB
LINEDISCONNECTMODE_OUTOFORDER
- The categorie were we have to decide that the number is wrong and there is no need and the need to check the address:
LINEDISCONNECTMODE_NUMBERCHANGED LINEDISCONNECTMODE_BADADDRESS LINEDISCONNECTMODE_INCOMPATIBLE
Now I am in conflict with a address (phonenumber) that is incomplete. The TSP's I tested returned LINEDISCONNECTMODE_NOANSWER.
So the academic question is: What is the correct use of LINEDISCONNECTMODE_NOANSWER.
-- Martin Richter [MVP] WWJD "In C we had to code our own bugs. In C++ we can inherit them." FAQ : http://www.mpdvc.de Samples: http://www.codeguru.com http://www.codeproject.com .
- Follow-Ups:
- Re: Reason for LINEDISCONNECTMODE_NOANSWER
- From: Andreas Marschall [MVP TAPI]
- Re: Reason for LINEDISCONNECTMODE_NOANSWER
- References:
- Q: Reason for LINEDISCONNECTMODE_NOANSWER
- From: Martin Richter [MVP]
- Re: Reason for LINEDISCONNECTMODE_NOANSWER
- From: Andreas Marschall [MVP TAPI]
- Q: Reason for LINEDISCONNECTMODE_NOANSWER
- Prev by Date: Re: Reason for LINEDISCONNECTMODE_NOANSWER
- Next by Date: Re: Help! LineCallBack not being called?
- Previous by thread: Re: Reason for LINEDISCONNECTMODE_NOANSWER
- Next by thread: Re: Reason for LINEDISCONNECTMODE_NOANSWER
- Index(es):
Relevant Pages
|
Loading
