[Home]

Summary:ASTERISK-07596: Incomming calls generate two call proceeding messages
Reporter:Sven Hirschmueller (sodom)Labels:
Date Opened:2006-08-24 11:05:45Date Closed:2006-08-25 10:14:52
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I'am in the process to adjust the libpri to accept a arinc 746 protocol. In the process of changing the various IEs i hit following problem.

Outgoing calls from directly connected ISDN-Phones run more of less well but incomming calls are rejected by the generater system because the setup message is answered by asterisk with two call proceeding messages. Any idea why asterisk sends to call proceeding messages ?

I implemented a native switchtype for arinc 746 so no other switchtype is set, maybe this will confuse the libpri.

I haven't changed anything in the state mashine till now. Don't wonder about the form of some of the ies e.g bearer capability is very short in arinc 746.

The system setup is as follows:
SATCOM emulator PBX(te) as call source is connected via a TE405P. (Span 1)
Receiving system PRI(nt) should route the call via a BN8S0 to a normal ISDN-Phone.

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

< Protocol Discriminator: Q.931 (8)  len=23
< Call Ref: len= 1 (reference 54/0x36) (Originator)
< Message type: SETUP (5)
< [04 01 e1]
< Bearer Capability (len= 3) [ Ext: 1  Q.931 Std: 3  Info transfer capability: Unknown (1)
<                              Ext: 0  Trans mode/rate: Multirate (Nx64kbps) (24)
<                              Ext: 0  Transfer rate multiplier: 3 x 64
< [18 03 a1 83 01]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Preferred Dchan: 0
<                        ChanSel: Reserved
<                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
<                       Ext: 0  Channel: 1 ]
< [6d 03 a0 00 10]
< Calling Sub-Address (len= 5) [ Ext: 1  Type: User Specified (2) O: 0 '' ]
< [70 04 98 31 30 30]
< Called Number (len= 6) [ Ext: 1  TON: International Number (1)  NPI: National Standard Numbering Plan (8) '100' ]
-- Making new call for cr 54
-- Processing Q.931 Call Setup
-- Processing IE 4 (cs0, Bearer Capability)
-- Processing IE 24 (cs0, Channel Identification)
-- Processing IE 109 (cs0, Calling Party Subaddress)
-- Processing IE 112 (cs0, Called Party Number)
SENDING CALL PROCEEDING !!!!!
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 1 (reference 54/0x36) (Terminator)
> Message type: CALL PROCEEDING (2)
> [18 03 a9 83 81]
> 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 ]
SENDING CALL PROCEEDING !!!!!
> Protocol Discriminator: Q.931 (8)  len=13
> Call Ref: len= 1 (reference 54/0x36) (Terminator)
> Message type: CALL PROCEEDING (2)
> [18 03 a9 83 81]
> 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 ]
> [1e 02 81 88]
> Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]
< Protocol Discriminator: Q.931 (8)  len=4
< Call Ref: len= 1 (reference 54/0x36) (Originator)
< Message type: STATUS ENQUIRY (117)
> Protocol Discriminator: Q.931 (8)  len=11
> Call Ref: len= 1 (reference 54/0x36) (Terminator)
Comments:By: Matthew Fredrickson (mattf) 2006-08-24 11:17:00

What is happening to cause proceeding to be sent?  Are you using the Proceeding() application in your dialplan, or have you hacked chan_zap/libpri in some sort of way to make it occur.  In an unmodified form, there are protections in chan_zap about keeping from sending proceeding twice.
By: Sven Hirschmueller (sodom) 2006-08-24 11:32:03

No i have a very simple externsion.conf that directly forward the calls to other Port. Here is a sample of the config. As i mentioned i "hacked" the libpri but i only changed the parsing and sampling of the various IEs as arinc 746 is very near to DSS1 but .. only near :)

The local context are the local phones connected at the BN8S0 and the outgoing is the "world" connected by the TE405P.

[general]
static=yes
writeprotect=no
autofallthrough=yes
clearglobalvars=no
priorityjumping=no

[locale]
exten => 100,1,Dial(misdn/1/${EXTEN})
exten => 105,1,Dial(misdn/4/${EXTEN})
exten => 33,1,Dial(misdn/2/${EXTEN})
include => default
include => outgoing

[outgoing]
exten => _XX,1,Dial(Zap/g1/${EXTEN})
include => default
include => locale
By: Sven Hirschmueller (sodom) 2006-08-25 09:07:18

Hi,

i found the "problem". If overlapdial=no is set the call proceeding is called just after setup reception. The second time it's generated by the AST_CONTROLL_PROCEEDUING section.

Don't know if this work as intended but that's the problem.
By: Matthew Fredrickson (mattf) 2006-08-25 10:11:36

Ok, fixed in 1.2 and trunk.