[Asterisk-Users] Problems with PRI with T410 messages

[CW_ASN]

> 
> 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

Tim:

Call proceeding is not mandatory in local termination (at least in
EuroISDN). Alerting is mandatory (obviously). Some class 5 switches sends
Call Proceeding only when the received SETUP will be routed thru CCS or CAS
routes, and only when a timer (I can't remember the timer number) expires.
The Call Proceeding must be retransmitted to A side. Call Proceeding message
is used mostly in transit environments.
Obviously, Ringing can't be used when unallocated or busy conditions are
detected.

The correct procedure for successful call with Call Proceeding and Setup
Acknowledge:
1) A->Setup
2) Setup acknowledge <-B
3) Call Proceeding <-B
4) Ringing <-B
5) Answer <-B
Or
5) Release A<->B (by expiration time)

The correct procedure for unsuccessful (1 or 17 cause) call without Call
Proceeding, with Setup Acknowledge:
1) A->Setup
2) Setup acknowledge <-B
3) Release <-B (ITU-T release cause i.e.: 1 or 17)


As you said, it needs to be fixed.

Regards,

Gus