[asterisk-bugs] [Asterisk 0010509]: channel appear as UP before call being picked up (and wrong indication in CDR)

noreply at bugs.digium.com noreply at bugs.digium.com
Thu Aug 23 07:33:44 CDT 2007


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10509 
====================================================================== 
Reported By:                keepitcool
Assigned To:                phsultan
====================================================================== 
Project:                    Asterisk
Issue ID:                   10509
Category:                   Channels/chan_gtalk
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:            1.4.10  
SVN Branch (only for SVN checkouts, not tarball releases):  1.4  
SVN Revision (number only!): 80165 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             08-21-2007 03:55 CDT
Last Modified:              08-23-2007 07:33 CDT
====================================================================== 
Summary:                    channel appear as UP before call being picked up
(and wrong indication in CDR)
Description: 
Hello,

First of all, nice work on the xmpp/gtalk support as a first approach to
support jingle.
My first bug report here, so if something is missing (or wrong) please let
me know.

In all my testing scenarios with established calls everything seems to be
working ok - including the audio (but  I tested only with the gsm codec).
The problems I detected seem to be more related to signaling when the call
do not go through because one party ends the call before it being picked
up.
Please read bellow a detailed description:
 
1) PROBLEM: Channel appear as UP before call being picked up (and wrong
indication in CDR)
 
Testing components: 
- Fedora core 3 + Asterisk server 1.4.10 (no zaptel, no libpri) + iksemel
1.3 (also tested with 1.2)
- 1 google talk credentials for asterisk server connection
- 3 clients on different PC’s for testing: 1 zoiper iax client
(IAX_CLIENT), 2 google talk clients (GTALK_CLIENT_1, GTALK_CLIENT_2)

Testing Flow: Clients trying to call each other (once at a time) and one
of the parties ending the call before the call being picked up.
 
In the next points I will detail the problems according to the direction
of establishment of the call:
 
1.a) IAX_CLIENT -> GTALK_CLIENT_1
 
In both the following situations:
- call is disconnected by the IAX_CLIENT before the GTALK_CLIENT_1 pick it
up
- or call being rejected by the GTALK_CLIENT_1
the channels appear always as UP (“show channels”) and in the CDR (in
the end of the call attempt) appears as “ANSWERED”. This is not
correct.
 
1.b) GTALK_CLIENT_1 -> GTALK_CLIENT_2
 
In both the following situations:
- call is disconnected by the GTALK_CLIENT_1 before the GTALK_CLIENT_2
pick it up
- or call being rejected by the GTALK_CLIENT_2
the channels appear always as UP (“show channels”) and in the CDR (in
the end of the call attempt) appears as “ANSWERED”. This is not
correct.
 
1.c) GTALK_CLIENT_1 -> IAX_CLIENT
 
In both situations:
- Call is disconnected by the GTALK_CLIENT_1 before the IAX_CLIENT pick it
up
- or call being rejected by the IAX_CLIENT
the channels appear only as Ringing/Ring (“show channels”) and in the
CDR (in the end of the call attempt) appears as “NO ANSWER”. So, in
these situation everything seems to be OK!
 
The problem in this last scenario is that when it is the IAX_CLIENT that
rejects the call the GTALK_CLIENT_1 keeps ringing until it goes to the
google voice mail. (It seems not to be notified about the call end)
When the call is rejected by the IAX_CLIENT in the asterisk CLI appears:
[Aug  9 17:34:08] NOTICE[21377]: chan_gtalk.c:1371 gtalk_indicate: Don't
know how to indicate condition '-1'
  == Auto fallthrough, channel 'Gtalk/rpinto-12d3' status is
'CHANUNAVAIL'
[Aug  9 17:34:08] NOTICE[21377]: chan_gtalk.c:1371 gtalk_indicate: Don't
know how to indicate condition '8'

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0008970 [patch] Asterisk to GoogleTalk client c...
====================================================================== 

---------------------------------------------------------------------- 
 keepitcool - 08-23-07 07:33  
---------------------------------------------------------------------- 
Thank you for the fast answer.

Just tested your patch (using asterisk 1.4.10.1) and all the same
configuration and testing scenario described before.

Regarding the channels appearing as "UP" before the calls being picked up,
that was solved, so also the CDR issues are solved and it now appear always
a "NO ANSWER" record.

But (why is there always a but ?! :)) there are still some scenarios where
one side keeps ringing even after the call being ended or rejected:
(Note: Do not forget that in any scenario the calls are picked up, they
are always ended by one side)

1.a) IAX_CLIENT -> GTALK_CLIENT_1
When the call is rejected by the GTALK_CLIENT_1 the IAX_CLIENT keeps
ringing and the channel is in the state "Busy".

When the call is ended by the IAX_CLIENT everything is ok.

1.b) GTALK_CLIENT_1 -> GTALK_CLIENT_2

When the call is rejected by the GTALK_CLIENT_2 the GTALK_CLIENT_1 keeps
ringing and the channel is in the state "Busy".
 
When the call is disconnected by the GTALK_CLIENT_1 everything is Ok.

1.c) GTALK_CLIENT_1 -> IAX_CLIENT
 
When the call is rejected by the IAX_CLIENT the GTALK_CLIENT_1 keeps
ringing and the channel is in the state "Busy".

When the Call is disconnected by the GTALK_CLIENT_1 everyhing is Ok.

So, the common in the previous 3 scenarios is that the problem seems to
exist only when the receiving party (gtalk or iax) reject the call.

Hope this will help. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
08-23-07 07:33  keepitcool     Note Added: 0069292                          
======================================================================




More information about the asterisk-bugs mailing list