I do not believe you are correct. We see CALL PROCEEDING in both directions as part of
the normal ISDN call setup process. See trace below.
Asterisk sends 'CALL PROCEEDING' followed immediately by 'ALERTING'. CALL PROCEEDING
is normally an acknowledgement to a SETUP. See Q931 below:
3.1.2 CALL PROCEEDING
This message is sent by the called user to the network or by the network to the
calling user to indicate that requested call establishment has been initiated and no
more call establishment information will be accepted. See Table 3-3.
ALERTING has a very specific meaning:
3.2.1 ALERTING
This message is sent by the called user to the network to indicate that called user
alerting has been initiated. See Table 3 23.
i.e. the channel to the called party has been established, and the phone at the other
end is physically ringing or making some other indication that an incoming call is
there to be answered.
It is 'ALERTING' that is being sent in the wrong place, as Asterisk sends 'ALERTING'
before the remote party (be it a SIP or IAX channel) is actually 'ringing'. Receipt
of 'ALERTING' from the called party is the trigger for the calling party to be
presented with 'ringback tone'. So to send a 'RELEASE' message with 'busy' after the
caller has been told the phone is ringing is not a logical thing to do, and causes a
lot of problems here.
It needs fixing!!!!
Rgds
Tim
Connected to Asterisk CVS-D2004.05.25.23.00.00-06/14/04-12:46:31 currently running on
localhost (pid = 4875)
mote UNIX connection
< Protocol Discriminator: Q.931 (8) len=40
< Call Ref: len= 1 (reference 1/0x1) (Originator)
< Message type: SETUP (5)
< Sending Complete (len= 4)
< Bearer Capability (len= 3) [ Ext: 1 Q.931 Std: 0 Info transfer capability: 3.1kHz
audio (16)
< Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
< Ext: 1 User information layer 1: A-Law (35)
< Channel ID (len= 3) [ Ext: 1 IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
< ChanSel: B1 channel
]
< Progress Indicator (len= 2) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0
Location: Network beyond the interworking point (10)
< Ext: 1 Progress Description: Call is not end-to-end
ISDN; further call progress information may be available inband. (1) ]
< Calling Number (len=18) [ Ext: 0 TON: Unknown Number Type (0) NPI: Unknown Number
Plan (0)
< Called Number (len= 5) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number
Plan (0) '14' ]
-- Making new call for cr 1
-- Processing Q.931 Call Setup
-- Processing IE 33 (Sending Complete)
-- Processing IE 4 (Bearer Capability)
-- Processing IE 24 (Channel Identification)
-- Processing IE 30 (Progress Indicator)
-- Processing IE 108 (Calling Party Number)
-- Processing IE 112 (Called Party Number)
> Protocol Discriminator: Q.931 (8) len=7
> Call Ref: len= 1 (reference 129/0x81) (Terminator)
> Message type: CALL PROCEEDING (2)
> Channel ID (len= 3) [ Ext: 1 IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
> ChanSel: B1 channel
]
> Protocol Discriminator: Q.931 (8) len=7
> Call Ref: len= 1 (reference 129/0x81) (Terminator)
> Message type: ALERTING (1)
> Channel ID (len= 3) [ Ext: 1 IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
> ChanSel: B1 channel
]
-- Executing Wait("Zap/1-1", "2") in new stack
-- Accepting call from '00441256790000' to '14' on channel 1, span 1
-- Executing Goto("Zap/1-1", "default|8714|1") in new stack
-- Goto (default,8714,1)
-- Executing SetMusicOnHold("Zap/1-1", "default") in new stack
-- Executing Answer("Zap/1-1", "") in new stack
> Protocol Discriminator: Q.931 (8) len=11
> Call Ref: len= 1 (reference 129/0x81) (Terminator)
> Message type: CONNECT (7)
> Channel ID (len= 3) [ Ext: 1 IntID: Implicit, Other Spare: 0, Exclusive Dchan: 0
> ChanSel: B1 channel
]
> Progress Indicator (len= 2) [ Ext: 1 Coding: CCITT (ITU) standard (0) 0: 0
> Location: Private network serving the local user (1)
> Ext: 1 Progress Description: Called equipment is
> non-ISDN. (2) ]
-- Executing SayDigits("Zap/1-1", "00441256790000") in new stack
-- Playing 'digits/0' (language 'en')
< Protocol Discriminator: Q.931 (8) len=4
< Call Ref: len= 1 (reference 1/0x1) (Originator)
< Message type: CONNECT ACKNOWLEDGE (15)
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of CW_ASN
Sent: 17 June 2004 12:13
To: [EMAIL PROTECTED]
Subject: Re: [Asterisk-Users] Problems with PRI with T410 messages
>
> This is a problem I pointed out to Digium a while back, but I am not
> sure
Markster understood the issue and I didn't really have the time to follow it up. It
does need fixing though, as it is a major drawback in the current architecture.
>
> Rgds
> Tim
>
> Hi all,
> I have a box running asterisk with T410 connected to a Nortel DMS 100
switch and another box running SER with grandstream phones on it So if there is a call
from the pstn it goes from the Nortel to the asterisk and then to the SER box and
finally to the phones.if the phone is busy or the number is invalid the * box will
first send an ALERT message to the Nortel and say the call is going on and the phone
is ringing (which is not the case )and after it will send a RELEASE message saying
that the line is busy or the # is invalid .is there any way * can send a progress
message instead of the alerting message until it gets the correct message from SER?
>
>
> Thanks
> Habiyakare Aimable
Call Proceeding can be sent only by transit network, not by the local switch or pbx.
AFAIK, * behavior for this scenario is like as local switch. Certainly, this is not a
normal behavior.
Regards,
Gus
_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
