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: 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 ?
_______________________________________________
--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
