[asterisk-users] asterisk sending connects when it shouldn't

2006-07-17 Thread Simone Cittadini
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.
Since the calls comes from a SIP connected GSM gateway, is there some 
SIP code which corresponds to the 'pass audio but don't connect' we want 
here ?


that's roughly the extension :


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

--
Simone Cittadini
2K Elektronika
Tel +39.02.26265583
___
--Bandwidth and Colocation provided by Easynews.com --

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


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

2006-07-17 Thread Simone Cittadini
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/[EMAIL PROTECTED]) in new stack
   -- Called [EMAIL PROTECTED]
Tx-Frame Retry[000] -- OSeqno: 001 ISeqno: 002 Type: IAX Subclass: 
ACCEPT

  Timestamp: 00014ms  SCall: 2  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: 2 [IP:4569]
Rx-Frame Retry[ No] -- OSeqno: 002 ISeqno: 002 Type: VOICE   Subclass: 8
  Timestamp: 00090ms  SCall: 00188  DCall: 2 [IP:4569]
Tx-Frame Retry[-01] -- OSeqno: 002 ISeqno: 003 Type: IAX Subclass: ACK
  Timestamp: 00090ms  SCall: 2  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: 2  DCall: 00188 [IP:4569]
Rx-Frame Retry[ No] -- OSeqno: 003 ISeqno: 003 Type: IAX Subclass: ACK
  Timestamp: 04698ms  SCall: 00188  DCall: 2 [IP:4569]
Tx-Frame Retry[000] -- OSeqno: 003 ISeqno: 003 Type: VOICE   Subclass: 8
  Timestamp: 04764ms  SCall: 2  DCall: 00188 [IP:4569]
Rx-Frame Retry[ No] -- OSeqno: 003 ISeqno: 004 Type: