Discussion:
CONNECT_IND without CONNECT_RESP
(too old to reply)
Paweł Budzyński
2005-01-24 01:28:49 UTC
Permalink
Hi,
Please help me findout an answer to this question:

My simple application should log to file, if somebody
pick up phone or not when phone is ringing. To do this
I implement the following flow chart of messages exchange
(see below) and Im not sure, is it correct?

App CAPI
CONNECT_IND
<-----------------

ALERT_REQ
----------------->

ALERT_CONF
<-----------------

DISCONNECT_IND Parameter Reason is writen to log file
<-----------------

DISCONECT_RESP
----------------->

PLCI is the same

Based on PLCI state machine diagram (CAPI specification
chapter 7), this is allowed. But based on general message
protocol idea, CONNECT_RESP should be send to CAPI.
but ...
my application can't send CONNECT_RESP{Reject=IGNORE CALL}
immediately after CONNECT_IND, because it must wait for
DISCONNECT_IND and upon analysis Reason parameter write
to log file, if somebody pickup phone or not.

So second question is:
- When my application should send CONNECT_RESP ?

regards
Pawel Budzynski
Jozza
2005-01-24 10:16:28 UTC
Permalink
Your message connect_resp is only needed to keep the state machine from not
breaking down.
If you only want to analyse the caller's phone number, you should not send
alert_req, because you are already interfering into the connection that you
won't accept anyway, instead only
send connect_resp with Reject code IgnoreCall and wait for disconnect_ind.
Post by Paweł Budzyński
DISCONNECT_IND and upon analysis Reason parameter write
to log file, if somebody pickup phone or not.
Impossible. You will never know if someone has picked up the call on this
terminal because capi does not work this way.

J.
Post by Paweł Budzyński
Hi,
My simple application should log to file, if somebody
pick up phone or not when phone is ringing. To do this
I implement the following flow chart of messages exchange
(see below) and Im not sure, is it correct?
App CAPI
CONNECT_IND
<-----------------
ALERT_REQ
----------------->
ALERT_CONF
<-----------------
DISCONNECT_IND Parameter Reason is writen to log file
<-----------------
DISCONECT_RESP
----------------->
PLCI is the same
Based on PLCI state machine diagram (CAPI specification
chapter 7), this is allowed. But based on general message
protocol idea, CONNECT_RESP should be send to CAPI.
but ...
my application can't send CONNECT_RESP{Reject=IGNORE CALL}
immediately after CONNECT_IND, because it must wait for
DISCONNECT_IND and upon analysis Reason parameter write
to log file, if somebody pickup phone or not.
- When my application should send CONNECT_RESP ?
regards
Pawel Budzynski
Paweł Budzyński
2005-01-26 08:50:37 UTC
Permalink
Post by Jozza
Post by Paweł Budzyński
DISCONNECT_IND and upon analysis Reason parameter write
to log file, if somebody pickup phone or not.
Impossible. You will never know if someone has picked up the call on this
terminal because capi does not work this way.
It's mean, that this is impossible using CAPI?

Pawel
Werner Henze
2005-01-24 21:07:11 UTC
Permalink
Hi!

From my understanding of CAPI it is correct. CONNECT_RESP is used
to accept/ignore/reject a call. If you do not send CONNECT_RESP
the network will timeout and disconnect the call. To prevent that
timeout you need to send ALERT_REQ. If you decide to take that
call, you send CONNECT_RESP at some time later.
If the call is disconnect before you send the CONNECT_RESP this
is not a problem. CAPI must and will handle this.

But take care:
If you are alerting and someone rejects the call on the phone,
your app will still be alerting and thus the caller will still
have a ringing tone until the network timeout occurs (2 minutes).
You will get different disconnect reasons for the three cases
1) the phone got the call, 2) another app got the call and 3) the
network timed out.

It might be better to not send ALERT_REQ. That will prevent the
2 minutes timeout. But I do not know how the network will react
if a phone is alerting and the app is not. Maybe the app will
get a disconnect_ind, maybe it will keep ringing. That is to be
tested.

Ciao,
Werner...
--
PGP 8 available
http://home.arcor.de/werner.henze
mm
2005-03-23 11:05:25 UTC
Permalink
Hi Pawel

You don't have to send a Connect Response if you have received the
Disconnect Indication already. And that is what you want to do, don't
you ?

->Connect Indication
<-Alert Request
->Alert Confirmation
during wait :
1. local user picks up a phone somewhere
2. remote user disconnects
<-Disconnect Indication :
1. 0x34?? Cause Non selected user clearing
2. ???? normal call clearing
log
->Disconnect Response

Bye
Michael
Post by Paweł Budzyński
Hi,
My simple application should log to file, if somebody
pick up phone or not when phone is ringing. To do this
I implement the following flow chart of messages exchange
(see below) and Im not sure, is it correct?
App CAPI
CONNECT_IND
<-----------------
ALERT_REQ
----------------->
ALERT_CONF
<-----------------
DISCONNECT_IND Parameter Reason is writen to log file
<-----------------
DISCONECT_RESP
----------------->
PLCI is the same
Based on PLCI state machine diagram (CAPI specification
chapter 7), this is allowed. But based on general message
protocol idea, CONNECT_RESP should be send to CAPI.
but ...
my application can't send CONNECT_RESP{Reject=IGNORE CALL}
immediately after CONNECT_IND, because it must wait for
DISCONNECT_IND and upon analysis Reason parameter write
to log file, if somebody pickup phone or not.
- When my application should send CONNECT_RESP ?
regards
Pawel Budzynski
Loading...