[Home]

Summary:ASTERISK-09234: Q931 inband information not interpreted as alerting signal
Reporter:Warrick Zedi (wzedi)Labels:
Date Opened:2007-04-09 17:36:34Date Closed:2008-03-06 13:03:16.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 0063165.txt
( 1) aapt.1
( 2) asterisk-it.2
( 3) Disclaimer.jpg
( 4) q931.c
( 5) q931.c-diff-1.2
( 6) q931.c-diff-1.4
Description:We received reports from a customer that they were not hearing a ring tone when making calls to certain extensions in their office even though the extension was ringing.

Further investigation showed that this occurred when calls were made to non-isdn extensions through one particular exchange. In this scenario inband information is received from the network in the PROGRESS signal which should be interpreted as an ALERTING signal.

The libpri implementation of Q931 does not accommodate this scenario.

****** ADDITIONAL INFORMATION ******

When the PROGRESS signal is received with flags 0x02 and 0x08 set an ALERTING signal should be fired. See the attached source with a quick work around implemented. This works but needs to be cleaned up.
Comments:By: Edwin Groothuis (mavetju) 2007-04-09 18:12:41

I have uploaded the patches against 1.2 and 1.4. I don't have access to a -trunk system, but my bet is that the patches from 1.4 are similar enough.
By: Serge Vecher (serge-v) 2007-04-10 08:27:59

wzedi: can you please get a disclaimer on file (see the bottom of main page).
By: Warrick Zedi (wzedi) 2007-04-22 22:19:07

See disclaimer.jpg attached - it has been faxed.
By: Paul Cadach (pcadach) 2007-04-24 19:50:00

wzedi, your assumption is wrong. You cannot definitely treat PROGRESS with INBAND|NON-ISDN as alerting, because non-ISDN part (for example, connected to ISDN-compatible network with R2 signalling) can produce inband announces as well, not ringing tones only. If you like I can provide you with a trace/recording for such call when PROGRESS message with INBAND|NON-ISDN indicator provides inband announcements, not ringing tones.

In your case, an exchange which do not produce ringing tones inband is not ITU-T (and its derivates) compliant. I would like to suggest you to ask your network provider about this issue with particular exchange and let them evaluate this case in terms of ITU-T/ETSI/EuroISDN compliance.
By: Warrick Zedi (wzedi) 2007-05-02 20:49:43

PCadach, thanks for looking into this.
This work is based less on assumption than it is on interpretation. Please refer to Annex K, paragraph K.2 (Procedures) of the Q.931 protocol recommendation.

Since our client experienced an issue receiving a ring tone we decided to implement this patch, inline with para K.2 I believe, and the problem has been resolved.

Now, my implementation is incomplete in that I'm not doing a test for indicator 8, and so you might say that the code is making a wild assumption, but it has solved the problem in the interim.

If you have a different understanding of that paragraph please advise. For your convenience I'll include relevant text here:

K.2 Procedures
As a network option, completion of the transmission path prior to receipt of a call acceptance
indication may be provided in one of three ways:
a) on completion of successful channel negotiation at the destination interface; or
b) on receipt of a message containing an indication that in-band information is being provided;
or
c) not at all, i.e. this option is not supported by the network.

When criteria a) is used to determine that transmission path should be established, the network shall
connect, as a minimum, the backward side of the transmission path upon receipt of either a CALL
PROCEEDING message or an ALERTING message containing an acceptable B-channel indication.
When criteria b) is used to establish the transmission path, the network shall connect, as a minimum,
the backward side of the transmission path upon receipt of either an ALERTING message or a
PROGRESS message containing progress indicator No. 8, in-band information or appropriate
pattern is now available, or progress indicator No. 1, call is not end-to-end ISDN; further call
progress information may be available in-band, respectively.


By: Paul Cadach (pcadach) 2007-05-03 03:02:53

Annex K just describes procedures for establishing backward voice channel for inband tones/announcements. Usage of PROGRESS message mostly described in part 5.4 of Q.931. You also miss "magic" section a) in K.1, progress indicator can be used to "allow the _called_ user to provide internally-generated tones and announcements that are sent in-band to the calling user prior to answer by the called user".

Also, part 5.1.2 says, "After this time, the user shall be connected to the B-channel, provided the equipment does not generate local tone" ("this time" is reception of CALL PROCEEDING/SETUP ACKNOWLEDGE/PROGRESS/ALERTING message with PI=8 or PI=1). That means that remote exchange should generate call progress tones or announcements itself (not local exchange/PBX, i.e. Asterisk).

The main difference between PROGRESS and ALERTING messages is PROGRESS does not change call state while ALERTING does. So, you cannot treat PROGRESS message as ALERTING anyway.

Everything above means that when you receive PROGRESS message, remote exchange SHOULD provide tones inband (audio path is established from remote exchange up to calling user, and calling user's exchange isn't generates local tones anymore), and can issue another messages (ALERTING, etc.) when call state changes. As I remember, Asterisk is able to handle inband progress tones and generate events corresponding to those tones (Alerting, Busy, etc.).


So, if remote exchange does not provide adequate inband tones after it requests to establish backward voice channel - this exchange is buggy and does not complies with ITU-T specs, without relation to Asterisk.

For more reference about Q.931/ISDN/etc, you could look for ETSI specs too - sometimes it describe behaviors more accurately than Q.931.
By: Warrick Zedi (wzedi) 2007-05-03 17:06:43

Thanks for that.

The ITSP was initially involved and they insisted they were sending all the necessary signals to trigger ALERTING. When we were finally called upon another session was setup with an engineer from the ITSP and he did some call traces and gave the same report, they are sending the right stuff and we are not interpreting it correctly.

What do you make of the following exchange (I'll attach the files)?

I got the trace of AAPT, attached as aapt.1. The interesting messages
are in trace event field and start with PA-:

00:00:000 PA-MSG: PA-JC=H'0021 SILC=H'03 GP-A                       2  
                SETUP                                                  
00:00:004 PA-CMD: PA-JC=H'0020 SILC=H'03 GP-A                       2  
                STATUS                                                
00:00:016 PA-CMD: PA-JC=H'0020 SILC=H'03 GP-A                       2  
                CALL PROCEEDING                                        
00:04:408 PA-CMD: PA-JC=H'0020 SILC=H'03 GP-A                       2  
                PROGRESS                                              
00:05:296 PA-MSG: PA-JC=H'0021 SILC=H'03 GP-A                       2  
                DISCONNECT                                            
00:05:336 PA-CMD: PA-JC=H'0020 SILC=H'03 GP-A                       2  
                RELEASE                                                
00:05:356 PA-MSG: PA-JC=H'0021 SILC=H'03 GP-A                       2  
                RELEASE COMPLETE                                      


According to the AAPT guy, the magic sits in the PROGRESS message,
it states that there is inband information available and that we
should start accepting it. The verbose interpretation of the PROGRESS
is at the bottom of the file.


And the asterisk traces are as follows, attached as asterisk-it.2
and with reference 2888/0xB48:

-- Processing IE 24 (cs0, Channel Identification)
< Protocol Discriminator: Q.931 (8)  len=13
< Call Ref: len= 2 (reference 2888/0xB48) (Terminator)
< Message type: PROGRESS (3)
< [1e 02 82 88]
< Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
<                               Ext: 1  Progress Description: Inband information or appropriate pattern now available. (8) ]
< [1e 02 82 82]
< Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
<                               Ext: 1  Progress Description: Called equipment is non-ISDN. (2) ]
-- Processing IE 30 (cs0, Progress Indicator)
By: Paul Cadach (pcadach) 2007-05-04 03:15:13

PI=8 (inband information available) means that call progress tones should be passed inband, and you should hear them. If you cannot hear them and ztmonitor shows quiet channel - you can complain them. If you hear tones, you can configure callprogress/busydetect options in zaptel.conf to enable detection of call progress tones and their conversion into internal Asterisk's events (ALERTING, BUSY, etc.).

As you see, both ITSP's log and your trace doesn't have ALERTING message, just PROGRESS.
By: Edwin Groothuis (mavetju) 2007-05-04 07:02:01

I've run the tests with and without the patches of wzedi:

Without the patches:
- ztmonitor shows an silent "channel" while it should be ringing. I put channel between quotes because according to asterisks "show channels", there isn't a channel, it's still in the ringing state. It isn't until the moment that the call gets answered (and the channels gets Up, and the channel gets moved to the final destination (Moving call from channel 93 to channel 80) that I get sounds.

With the patches
- ztmonitor shows a ringing signal on the channel when it should be ringing. This happens the moment the channel gets moved to the final destination (Moving call from channel 93 to channel 76).
By: Paul Cadach (pcadach) 2007-05-04 13:02:24

Which call path do you observe? You should monitor outgoing channel, not incoming. When you put ALERTING message into bridged channel, Asterisk will generate ringing tone itself, and as I see you acknowledge this.

Caller -> (1) -> Asterisk -> (2) -> Called

you should monitor channel associated with call leg (2), not (1). In both cases (without dependence on this patch) you should see the same, becase replacing PROGRESS sent by Called replaced with ALERTING and goes to Caller over leg (1), leg (2) isn't affected.

And, you should see both channels (1) and (2) in Asterisk's "show channels".


WBR,
Paul.
By: Edwin Groothuis (mavetju) 2007-05-04 17:44:06

I have also done the tests on the location 2 in your diagram. This is tested on a SIP phone because I don't have access to a PRI connected phone during the weekends.

- Without the patches there is no RTP traffic flowing from the Asterisk machine to the SIP gateway, but there is traffic flowing from the SIP gateway to the Asterisk machine.

- With the patches there is RTP traffic flowing in both directions.
By: Paul Cadach (pcadach) 2007-05-05 03:58:20

How can you do tests on call leg (2) without access to Asterisk connected to PRI, because it is PRI's leg, and, as I understood, (1) is SIP's leg. Isn't it?

Could you hold exclusive access to this Asterisk box, enable PRI, SIP and RTP debugging then post traces here? Also, "core set debug channel all" is helpful command which will how all messages flowing between channels...
By: Edwin Groothuis (mavetju) 2007-05-06 00:30:18

I was talking about a PRI connected phone, not a PRI connected asterisk server.

The things I've done now are:

SIP phone -> Asterisk -> PRI called number
PRI phone -> Asterisk -> PRI called number

Both results were the same as described in note 0063116
By: Paul Cadach (pcadach) 2007-05-07 12:53:17

I clearly understand you will have the same issues when you use SIP or ZAP endpoint for originating call. All problems are around outgoing call leg, not incoming, and in both cases it is the same (ZAP with PRI signalling), so behavior should be the same.

I still do not hear anything results of monitoring Asterisk->PRI call leg. Is it possible?

Can you provide SIP/RTP/"debug channel all" debug output for SIP call in isolated environment (no other calls active at the time of collecting this debugging information)?


WBR,
Paul.
By: Edwin Groothuis (mavetju) 2007-05-15 16:57:10

I will give you the information tonight.
By: Edwin Groothuis (mavetju) 2007-05-16 07:46:23

the uploade file has:

sip debug peer
rtp debug ip
pri debug span [1234]

The call comes in from 10.252.11.130, out via Zap/G3. Let me know if you need more information.
By: Edwin Groothuis (mavetju) 2007-05-28 00:28:22

Any more information required?
By: Edwin Groothuis (mavetju) 2007-07-02 00:26:39

Any news on this one?
By: Edwin Groothuis (mavetju) 2007-07-23 01:47:24

Any news on this one?
By: Edwin Groothuis (mavetju) 2007-08-14 07:00:01

Any more information required?
By: Edwin Groothuis (mavetju) 2007-08-29 20:24:50

Is there more information required before this one can be handled?
By: Paul Cadach (pcadach) 2007-09-25 03:44:47

As I can see there are problems on remote (not Asterisk) side. You should resolve this issue with your telephony (PRI) provider, or ask them for national ISDN PRI specification describing exact behavior on PI=2/8 for your country. At least for EuroISDN/ANSI/ITU variants of PRI handling of PI=8 is correct, and should never be treated as ALERTING.

Do not hesitate to re-open the bug if you will have additional information from your provider.


Thanks,
Paul.
By: Warrick Zedi (wzedi) 2007-09-25 17:59:13

I am reopening this issue to give our client an opportunity to comment.
By: Edwin Groothuis (mavetju) 2007-09-25 18:12:05

AAPT, our telco, says that there is nothing wrong from their side.
If we call the number via the same PRI connected to an Alcatel4400 we hear the sound.
If the number is dialed via one of our other providers (accessed via a SIP channel) we hear the sound.

So why can Asterisk not handle this?

Even if the patch supplied is wrong (but gives the right result), it should give enough information to somebody with enough knowledge about the system (and then I'm looking at you at Digium) to resolve the issue instead of ignoring the fact that there is a problem in this situation.
By: Edwin Groothuis (mavetju) 2007-11-01 01:48:35

Any news on this one?
Any more information required?
By: jmls (jmls) 2008-02-17 12:43:14.000-0600

PCadach, any further comments ?
By: Edwin Groothuis (mavetju) 2008-03-06 04:59:50.000-0600

This has been resolved with the patch in http://bugs.digium.com/view.php?id=11917
By: Kevin P. Fleming (kpfleming) 2008-03-06 13:03:15.000-0600

Closing issue at tester/reporter's request, as it appears that the issue has been resolved by a patch for a different issue.