[asterisk-dev] asterisk sending connects when it shouldn't (is
there a q931-INFORMATION equivalent in IAX2 ?)
Matthew Fredrickson
creslin at digium.com
Mon Jul 17 10:29:10 MST 2006
Essentially, that's what an "answer" is, it's a CONNECT. If the remote
end sends the CONNECT message, it's counted as a billable call. Not a
whole lot you can do about that unless you want to complain to the
cellular provider.
Matthew Fredrickson
On Jul 17, 2006, at 7:46 AM, Simone Cittadini wrote:
> 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 at host") in new stack
> -- Called number at 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 ?
>
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-dev
More information about the asterisk-dev
mailing list