asterisk users - Jul 2006 - asterisk sending connects when it shouldn't (is there a q931-INFORMATION equivalent in IAX2 ?)

When asterisk receives those messages you hear when calling an 
unreacheable cellular phone it sends a 'connect' over the terminating 
PRI line (digium TE410P), making the call seen as billed from customer's 
perspective.
I don't know if this behaviour is a bug or something I can resolve with 
some fine tuning, so I'm sending to both lists.

this is the layout of machines :

|gsm gateway| <- sip -> |asterisk client| <- iax2 -> |asterisk
server|
<- zap ->  pri lines (nortel ?)


that's roughly the extension on the server :


exten => _X.,1,AGI(agi://127.0.0.1:54321/SomeAgiHere?someArgumentsHere)
exten =>
_X.,n,GotoIf($["${CALLABLE}"="TRUE"]?chkmax:hangup)
exten => _X.,n(chkmax),Set(GROUP()=${TECH_PRE})
exten => _X.,n,GotoIf($[${GROUP_COUNT(${TECH_PRE})} >= 
${MAX_CALLS}]?hangup:dial)
exten => _X.,n(dial),Dial(${STR_DIAL})
exten => _X.,n(hangup),Hangup

exten => h,1,Set(CDR(userfield)=${USERFIELD}-${HANGUPCAUSE})


Here the provider's trace of a call answered by asterisk :

/HDLU 4/Port
  === LAPD ==   --- ADDRESS ---
   SAPI       : 0 = call control procedures
   CR         : ......1.
   EA0        : .......0
   TEI        : 0 = non-automatic TEI assignment user equipment
   EA1        : .......1
   --- CONTROL ---
   --- I FRAME ---
   I FORMAT   : .......0
   N(S)       : 86
   P          : .......0
   N(R)       : 31
   === ETSI ISDN ==    PROT DISC  : 08h = Q.931 user-network call control
message
    LEN CALL R : 2
    SPARE      : 0
    FLAG       : 1....... = the message is sent to the side that 
originates the call reference
    CALL REF   : 226
    MESS TYPE  : 07h = Connect


Here the complete trace :

/HDLU 4/Port
 0  TEI:  0  CALL REF:  226  Setup  '500'  '[called number]'
 0  TEI:  0  CALL REF:  226  Setup acknowledge
 0  TEI:  0  CALL REF:  226  Call proceeding
 0  TEI:  0  CALL REF:  226  Connect  <== should not
 0  TEI:  0  CALL REF:  226  Connect acknowledge
 0  TEI:  0  CALL REF:  226  Disconnect   16 normal call clearing
 0  TEI:  0  CALL REF:  226  Release
 0  TEI:  0  CALL REF:  226  Release complete


---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Here a trace from a correctly functioning non-voip system :

/HDLU 4/Port
 0  TEI:  0  CALL REF:  246  Setup  '500'
 0  TEI:  0  CALL REF:  246  Setup acknowledge
 0  TEI:  0  CALL REF:  246  Information  'c'
 0  TEI:  0  CALL REF:  246  Information  'a'
 0  TEI:  0  CALL REF:  246  Information  'l'
 0  TEI:  0  CALL REF:  246  Information  'l'
 0  TEI:  0  CALL REF:  246  Information  'e'
 0  TEI:  0  CALL REF:  246  Information  'd'
 0  TEI:  0  CALL REF:  246  Information  'n'
 0  TEI:  0  CALL REF:  246  Information  'u'
 0  TEI:  0  CALL REF:  246  Information  'm'
 0  TEI:  0  CALL REF:  246  Information  'b'
 0  TEI:  0  CALL REF:  246  Call proceeding
 0  TEI:  0  CALL REF:  246  Progress
 0  TEI:  0  CALL REF:  246  Progress
 0  TEI:  0  CALL REF:  246  Disconnect   16 normal call clearing
 0  TEI:  0  CALL REF:  246  Release
 0  TEI:  0  CALL REF:  246  Release complete


On the asterisk client it seems that SIP correctly opens only a leg of 
the call :

asterisk : 102 invite
<- 100 Trying
<- 200 OK
asterisk : ACK (now I hear the audio)
(I hangup)
asterisk : BYE
<- 200 OK

Destroying call 'blabla'@ip

(with a normally answered call I see 183 Session progress instead of the 
first 200 while ringing, and the the destroyed calls are two)

the iax debug : (still talking about the call that shouldn't send the 
connect on isdn line)

    -- Accepting AUTHENTICATED call from IP:
       > requested format = alaw,
       > requested prefs = (),
       > actual format = alaw,
       > host prefs = (alaw),
       > priority = mine
    -- Executing Dial("IAX2/IP:4569-2", "SIP/number@host")
in new stack
    -- Called number@host
Tx-Frame Retry[000] -- OSeqno: 001 ISeqno: 002 Type: IAX     Subclass: 
ACCEPT
   Timestamp: 00014ms  SCall: 00002  DCall: 00188 [IP:4569]
   FORMAT          : 8
astegateway4*CLI>
Rx-Frame Retry[ No] -- OSeqno: 002 ISeqno: 002 Type: IAX     Subclass: ACK
   Timestamp: 00014ms  SCall: 00188  DCall: 00002 [IP:4569]
Rx-Frame Retry[ No] -- OSeqno: 002 ISeqno: 002 Type: VOICE   Subclass: 8
   Timestamp: 00090ms  SCall: 00188  DCall: 00002 [IP:4569]
Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 003 Type: IAX     Subclass: ACK
   Timestamp: 00090ms  SCall: 00002  DCall: 00188 [IP:4569]
    -- SIP/gateway4-20e0 answered IAX2/82.113.204.70:4569-2
Tx-Frame Retry[000] -- OSeqno: 002 ISeqno: 003 Type: CONTROL Subclass: 
ANSWER
   Timestamp: 04698ms  SCall: 00002  DCall: 00188 [IP:4569]
Rx-Frame Retry[ No] -- OSeqno: 003 ISeqno: 003 Type: IAX     Subclass: ACK
   Timestamp: 04698ms  SCall: 00188  DCall: 00002 [IP:4569]
Tx-Frame Retry[000] -- OSeqno: 003 ISeqno: 003 Type: VOICE   Subclass: 8
   Timestamp: 04764ms  SCall: 00002  DCall: 00188 [IP:4569]
Rx-Frame Retry[ No] -- OSeqno: 003 ISeqno: 004 Type: IAX     Subclass: ACK
   Timestamp: 04764ms  SCall: 00188  DCall: 00002 [IP:4569]
Rx-Frame Retry[ No] -- OSeqno: 003 ISeqno: 004 Type: IAX     Subclass: 
HANGUP
   Timestamp: 07167ms  SCall: 00188  DCall: 00002 [IP:4569]
   CAUSE CODE      : 16

Is maybe that ANSWER translated to a CONNECT when passing to the zap 
channel ?