[Home]

Summary:ASTERISK-00691: Zaptel answering on a call proceeding
Reporter:zoa (zoa)Labels:
Date Opened:2003-12-22 04:46:34.000-0600Date Closed:2004-09-25 02:55:31
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:Zaptel seems to think a call got answered on a 'call proceeding' message.

However in my case this means my switch is trying to dial that number, and the person called might not pickup the phone.

So even if the person does not pickup the call, i will still have an answered in the cdr logs, and i will start billing my client on the ringing time.

Shouldnt zaptel only answer on a connect ?


****** ADDITIONAL INFORMATION ******

> Protocol Discriminator: Q.931 (8)  len=34
> Call Ref: len= 2 (reference 9321/0x2469) (Originator)
> Message type: SETUP (5)
> Bearer Capability (len= 3) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
>                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
>                              Ext: 1  User information layer 1: A-Law (35)
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
>                       Ext: 1  Channel: 1 ]
> Calling Number (len= 4) [ Ext: 0  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0)
>                           Presentation: Unknown (67) '' ]
> Called Number (len=14) [ Ext: 1  TON: International Number (1)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '32485397745' ]
> Sending Complete (len= 0)
   -- Called g1/32485397745
< Protocol Discriminator: Q.931 (8)  len=10
< Call Ref: len= 2 (reference 42089/0xA469) (Terminator)
< Message type: CALL PROCEEDING (2)
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
<                        ChanSel: Reserved
<                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
<                       Ext: 1  Channel: 1 ]
-- Processing IE 24 (Channel Identification)
   -- Zap/1-1 answered IAX[xxxx@x.x.x.x:5036]/16149
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 42089/0xA469) (Terminator)
< Message type: ALERTING (1)
< Protocol Discriminator: Q.931 (8)  len=9
< Call Ref: len= 2 (reference 42089/0xA469) (Terminator)
< Message type: DISCONNECT (69)
< Cause (len= 2) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
<                  Ext: 1  Cause: User busy (17), class = Normal Event (1) ]
-- Processing IE 8 (Cause)
   -- Channel 1, span 1 got hangup
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Disconnect Indication, peerstate Disconnect Request
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 9321/0x2469) (Originator)
> Message type: RELEASE (77)
> Cause (len= 2) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                  Ext: 1  Cause: User busy (17), class = Normal Event (1) ]
   -- Hungup 'Zap/1-1'
 == Spawn extension (xxx, 0032485397745, 3) exited non-zero on 'IAX[xxx@x.x.x.x.21:5036]/16149'
< Protocol Discriminator: Q.931 (8)  len=9
< Call Ref: len= 2 (reference 42089/0xA469) (Terminator)
< Message type: RELEASE COMPLETE (90)
< Cause (len= 2) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
<                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
-- Processing IE 8 (Cause)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
   -- Hungup 'IAX[xxx@x.x.x.x:5036]/16149'
cleopatra*CLI>
Comments:By: zoa (zoa) 2003-12-23 17:15:40.000-0600

This guy seemed to have the same problem.

http://lists.digium.com/pipermail/asterisk-users/2003-July/015309.html

I already tried looking at the Q.931.c source but i cannot find where the zaptel/libpri gives iax2 the impression that the call has been answered.

Anyone that could point me in the right direction ? i don't think the solution can be that hard.
By: zoa (zoa) 2003-12-23 18:06:47.000-0600

AST_STATE_UP seems to be the name of the variable holding the answered status... can't find where its going wrong though :(
By: zoa (zoa) 2003-12-23 18:38:45.000-0600

the offending code should be in channels.c  (thnx to diana for having a look!!!)

case AST_STATE_RING:
<diana>                 if (chan->pvt->answer)
<diana>                         res = chan->pvt->answer(chan);
<diana>                 ast_setstate(chan, AST_STATE_UP);
<diana>                 if (chan->cdr)
<diana>                         ast_cdr_answer(chan->cdr);
<diana>                 return res;
<diana>                 break;
<diana>         case AST_STATE_UP:
<diana>                 if (chan->cdr)
<diana>                         ast_cdr_answer(chan->cdr);
<diana>                 break;
<diana>         }
By: zoa (zoa) 2004-02-25 06:30:42.000-0600

Something else related to this was fixed a while ago and it also fixed this.