[Home]

Summary:ASTERISK-00557: [patch] FastStart and PSTN intercepted announcements don't work when call is originated by h323 driver
Reporter:mdu113 (mdu113)Labels:
Date Opened:2003-11-21 12:57:22.000-0600Date Closed:2008-01-15 15:07:55.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk.log
( 1) asterisk.log-recommended
( 2) asterisk-progresstone.diff
( 3) h323-latest.log
( 4) intercept.patch-1.0RC2
( 5) intercept.patch-cvs092004
Description:FastStart doesn't work when call is originated by h323 driver.
The other side of connection is Lucent MAX TNT gateway that definitely supports faststart.
Not quite sure if this is a result of faststart not working, but PSTN intercepted announcements don't work with h323 driver.
Faststart seems to work with incoming h323 calls from the same gateway. So far I used the driver compiled with recommended pwlib and openh323 libraries versions.
Then I've tried to recompile driver with the latest pwlib and openh323. According to traces, faststart does get enabled now, but intercepted announcements don't work anyway.
Attached is traces of the call to disconnected number with  driver compiled with recommended libraries.
212-812-9977 is disconnected number where "number is not in service" message should be heard
Comments:By: Paul Cadach (pcadach) 2003-11-29 01:23:39.000-0600

I've don't see any OpenLogicalChannel/OpenLogicalChannelAck messages. Try to snap trace again with trace level of 5 at least. Also, lines
 0:24.834           H323 Cleaner        h323.cxx(4396) H323 Bandwidth request: -0.0kb/s, available: 10000.0kb/s
 0:24.835           H323 Cleaner        h323.cxx(4396) H323 Bandwidth request: -0.0kb/s, available: 10000.0kb/s

says, that no codecs was started (which started with OpenLogicalChannel messages)...
By: Paul Cadach (pcadach) 2003-11-30 14:39:17.000-0600

Yesterday I've played with Cisco's gateway about in-band passing ringing indication to PSTN. The situation with Cisco's gateways is next:
1) If you send SETUP message with IE:Progress-Indicator = 3, this tells to gateway (and calling party) that your equipment is not handling self-generating progress tones and it needs to cut-through receive audio channel for progress tones;
2) If you get PROGRESS message, that gateway is ready to pass to you any progress messages available on line;
3) If you want to send progress tones in-band, you must send ALERT message with IE:Progress-Indicator=8.
By: Paul Cadach (pcadach) 2003-12-01 03:28:28.000-0600

I think attached patch is required to bypass calling tones correctly (patching of chan_h323 also requires, and it is much different story)... Also, don't use any "m" or "r" options to your dial command until channel driver isn't support PROGRESS messages (as it is for now)...

Heavily patched chan_h323 and included patch works for me very pretty, but patching of chan_h323 still needed about generating Asterisk's control frames on incoming ALERT/PROGRESS H.323 messages.

edited on: 12-01-03 03:23
By: mdu113 (mdu113) 2003-12-04 15:49:45.000-0600

I've tried to apply both this patch and your cumulative chan_h323 patch from http://bugs.digium.com/bug_view_page.php?bug_id=0000469, but intercepted announcements don't work anyway.
I've uploaded log of trace level 5 (h323-latest.log). Driver is compiled with latest pwlib and openh323 libraries.
Please let me know if you want me to collect any additional info or if there's any way I can help with troubleshooting this issue.
By: Paul Cadach (pcadach) 2003-12-04 16:09:49.000-0600

There is very old patch. I'll finish and polish my latest changes (make some things configurable) then will upload new patch to ticket ASTERISK-465 (and notify you, of course).

Your latest log shows misconfiguration of your PSTN network or gateway. When PSTN asks to cut-through connection it must indicate this with Progress-Indicator information element at messages:
1) SETUP;
2) CALL PROCEEDING;
3) ALERTING;
4) PROGRESS.
As I can see there is no Progress-Indicator field at any of messages. So, check your gateway configuration to pass-though Progress-Indicator elements or to generate it when channel is opened (for example, Cisco's gateways generates PROGRESS message when sound channel is opened by PSTN).

I'll provide configurable option of Progress-Indicator field for Setup packet, but if your gateway didn't pass it to PSTN you will not hear any progress announcements... One more possible hack - to simulate "PROGRESS" signal by chan_h323 if you have opened receiving channel, but it must be configurable (of course).

I'll check what I can do to solve your situation. Thank you for your detailed log.
By: mdu113 (mdu113) 2003-12-04 16:53:34.000-0600

I'll see what I can find in MAX TNT (PSTN gateway) config, but the strange thing is that I have pure H.323 endpoint (quintum tenor) that talks to MAX TNT
directly and everything works fine. I can hear "number not in service" message when calling from it without any additional configuration on MAX TNT.
Thank you very much.
By: Paul Cadach (pcadach) 2003-12-04 21:45:24.000-0600

Endpoint (I've tried OpenPhone from OpenH323 project) usually starts up one-way sound channel (from peer to endpoint), but for ISDN network it's not so usual. ISDN equipment can work in two modes:
1) locally generated call tones;
2) terminating exchange generates call tones/announces.
To save network traffic when call goes through IP, choice 1) is the best because it will not require any bandwith to pass calling tones from gateway to endpoint, and endpoint must be capable to generate tones locally (Asterisk is ;-) ).

As specified at Cisco's documentaton, Progress Indicator element will be added when remote exchange starts up voice channel(s), so, at H.323 level this will inform endpoint (in our case it is Asterisk, which works as endpoint for PSTN gateway) about opening voice channel(s) (and will perform voice channels negotiation and startup by faststart or regular H.245 procedures). So, to save network bandwidth, starting of voice pass-through just when voice channels opened by gateway is not best effort, and must be configurable at gateway (Cisco variant) or PBX (i.e. Asterisk, your variant).

If you will not find any option at gateway to inform Asterisk about sound channel is required (i.e. which will set/pass Progress Indicator element in H.323 messages), there would require a configurable "hack" - to generate AST_CONTROL_PROGRESS message by channel driver (chan_h323) when sound channel(s) is/are opened.

The patch will be available at next week.

BTW, try to disable fastStart and check would MAX TNT pass "number not in service" message - at least Cisco's gateway will start up sound channel by fastStart (anyway, not depending on required sound channel) or usual "slow start" when sound must be available for endpoint (and pointing this with Progress Indicator). If your gateway is "right" one (works as Cisco), it will start up sound channel(s) not depending on fast start option. Decision of fastStart provision for H.323 is to make sound channel(s) startup more quickly to reduce delay between answer by one party and sound availability. Theoretically you can disable fastStart which will provide you with slightly "cutted" sound at startup - for about 0.1-0.5 sec.
By: mdu113 (mdu113) 2003-12-09 14:21:34.000-0600

Well, after failing to find a meaningfull explanation in Lucent MAX TNT documentation regarding passing call-progress tones/indicator/whatever it's called I've just tried to change all parameters that might be related in all combinations :) (there are quite a few parameters so I might miss some possible combinations) without any luck at all. I know it's not the best method, but I'm just getting despaired.
Here's what I noticed:
1. If I don't specify 'r' to Dial application (I'm calling from SIP endpoint to h323 to MAX TNT to PSTN) I can hear nothing, not even ring tone before the call is answered. Then it works fine.
2. h.323 trace log says fastStartState=FastStartAcknowledged even if I disable faststart on MAX TNT. This happens if the driver compiled with latest pwlib and h323 libraries. If compiled with recommended libraries faststart is always disabled.
3. PSTN announcements work with Quintum Tenor H323 endpoint whatever I did to MAX TNT configuration assuming faststart is enabled. If I disable faststart PSTN announcements do not work.
I don't really understand how h323 driver would generate progress tones if it doesn't receive any indications from gateway. Would it be possible to have a configurable option to always start one-way sound channel on outgoing calls like you think Quintum Tenor does?
Thank you.
By: Paul Cadach (pcadach) 2003-12-09 14:49:57.000-0600

Now I'm testing configurable version of my changes. Passing sounds if remote party just opens sound channel is one of configurable options now. Just still waiting a bit until testing and "polishing" is finished (about 2-3 days).

WBR,
Paul.
By: Paul Cadach (pcadach) 2003-12-21 02:15:34.000-0600

New cumulative patch available at ticket ASTERISK-465.

WBR,
Paul.
By: mdu113 (mdu113) 2003-12-22 13:12:29.000-0600

PCadach, thanks a lot for your work.
Unfortunately it doesn't work for me anyway. First of all when I'm trying to apply your patch to today's cvs I get:
root@pbx1:~/src/cvs# patch -p0 <chan_h323_pcadach.patch
patching file asterisk/channels/h323/ast_h323.cpp
Hunk ASTERISK-21 succeeded at 1129 with fuzz 1.
Hunk ASTERISK-25 succeeded at 1445 (offset -5 lines).
patching file asterisk/channels/h323/chan_h323.h
patching file asterisk/channels/h323/ast_h323.h
patching file asterisk/channels/h323/h323.conf.sample
patching file asterisk/channels/chan_h323.c
Hunk #4 succeeded at 261 (offset 2 lines).
Hunk ASTERISK-2 succeeded at 483 (offset 2 lines).
Hunk ASTERISK-4 succeeded at 592 (offset 2 lines).
Hunk ASTERISK-6 succeeded at 629 (offset 2 lines).
Hunk ASTERISK-8 succeeded at 689 (offset 2 lines).
Hunk ASTERISK-10 succeeded at 756 (offset 2 lines).
Hunk ASTERISK-12 succeeded at 854 (offset 2 lines).
Hunk ASTERISK-14 succeeded at 958 (offset 2 lines).
Hunk ASTERISK-16 succeeded at 1081 (offset 2 lines).
Hunk ASTERISK-17 succeeded at 1129 (offset -6 lines).
Hunk ASTERISK-18 FAILED at 1152.
Hunk ASTERISK-20 succeeded at 1200 (offset -6 lines).
Hunk ASTERISK-22 succeeded at 1233 (offset -6 lines).
Hunk ASTERISK-23 FAILED at 1246.
Hunk ASTERISK-24 succeeded at 1268 (offset -2 lines).
Hunk ASTERISK-25 succeeded at 1308 (offset -6 lines).
Hunk ASTERISK-26 succeeded at 1330 (offset -2 lines).
Hunk ASTERISK-27 succeeded at 1474 (offset -6 lines).
Hunk ASTERISK-28 succeeded at 1636 (offset -2 lines).
Hunk ASTERISK-29 succeeded at 1648 with fuzz 1 (offset -5 lines).
Hunk ASTERISK-30 succeeded at 1723 (offset -2 lines).
Hunk ASTERISK-31 FAILED at 1966.
Hunk ASTERISK-32 succeeded at 2016 (offset -8 lines).
Hunk ASTERISK-33 succeeded at 2082 (offset -2 lines).
Hunk ASTERISK-34 succeeded at 2115 (offset -8 lines).
3 out of 38 hunks FAILED -- saving rejects to file asterisk/channels/chan_h323.c.rej

I went ahead and fixed the rejections manually and it compiles ok.
Then I tried to play with new configuration options in h323.conf, but it didn't help either.
I've attached another log of trace level 5 (asterisk.log) and hope you could look into it and see what's going wrong. Also I noticed that now I can hear ringtone without specifying 'r' option to Dial. So this log was done by launching "Dial(h323/12128129977,,t)".
New configuration options were set to:
progress_setup = 3
progress_alert = 8
progress_audio = yes
Thank you.
By: jerjer (jerjer) 2003-12-23 15:04:47.000-0600

what is the status of this?  will someone voutch for this patch as working/won't crash?
By: mdu113 (mdu113) 2003-12-23 16:30:32.000-0600

It doesn't crash (for 2 days I've been using it), it does make some improvements - from what I noticed it's no longer neccessary to specify 'r' option to Dial application. Ringtone is passed from PSTN gateway. Also it does fix problems with callerid that is present in h323 driver.
It doesn't fix my problem though. So far PSTN announcements still not working.
As for the voutch, I guess it would take someone more knowledgable in h323 and driver source code than me to notice core advantages/disadvantages.
It works for me.
By: jerjer (jerjer) 2003-12-23 16:48:15.000-0600

If it doesn't fix the problem, what good is it?
By: mdu113 (mdu113) 2003-12-23 17:22:14.000-0600

It doesn't fix one particular problem that I believe is very important for production use. People do need to know whether the number they dialed is disconnected or just nobody was available to answer. I'm eager to see it fixed. I believe it's a major problem.
On the other hand it fixes others, less important problems and according to PCadach should fix PSTN announcements too. Not for me unfortunately, so I do agree that patch requires some more work.
By: Paul Cadach (pcadach) 2003-12-23 22:52:40.000-0600

Looks like MAX TNT (or your exchange) violates something - it must provide CallProceeding immediately after Setup message is sent to indicate that call is being set up by exchange.

Could you try to configure your gateway to use h245 tunneling? It will be more faster for voice path setup...

I'll carefully check without h245 tunneling how it sets up audio streams and notify you about my research.
By: mdu113 (mdu113) 2003-12-26 13:04:43.000-0600

There's no configurable options to set h245 tunneling in MAX TNT. As I understand it MAX TNT sets h245tunelling automatically according to the other endpoint capability. Here's what its manual says: "A calling endpoint can include both a fastStart element and can set the h245Tunneling field to TRUE within the same setup message. Similarly, a called endpoint can include both a fastStart element and can set the h245Tunneling field to TRUE within the same Q.931 response."
Also it says the following "Note: In the H.323(v2) standard, the calling endpoint must include one, but not both of the following in the same setup message:
- a fastStart element.
- an encapsulated H.245 messages in H245Control.
The presense of the encapsulated H.245 message in this instance overrides the Fast Connect procedure".
I see parallelH245Control field in asterisk's Setup PDU. Could it be the problem?
By: jerjer (jerjer) 2004-01-14 03:12:32.000-0600

what is this status of this?
By: Paul Cadach (pcadach) 2004-01-14 03:17:30.000-0600

I've found some inconsistence with different settings of H.245 tunneling and FastStart at chan_h323.conf and gateway (sometimes sound gets works for one-direction). Now I'm finishing setting up our local Cisco's H.323 gateway and trying to prepare complex tests on changed chan_h323. So, it is needs some more time.
By: Paul Cadach (pcadach) 2004-02-08 00:57:06.000-0600

BTW, which gatekeeper you uses? I found some issues related to GnuGK-2.0.6... GnuGK-2.0.7 just crashes so often with SMP (not tried without SMP)... :(((
By: mdu113 (mdu113) 2004-02-11 14:17:00.000-0600

I'm using gnugk-2.05 a little modified by myself (nothing signalling related). BTW I managed to get it work using patch from
http://bugs.digium.com/bug_view_page.php?bug_id=0000882 and disabling h245tunneling. Have no idea why h245tunning prevents it from working, but apparently noH245Tunneling settings in original driver doesn't work.
By: zoa (zoa) 2004-02-25 07:39:11.000-0600

any updates on this ?
By: Paul Cadach (pcadach) 2004-02-25 11:26:26.000-0600

Still in progress... :((( I'd sent one part of the patch (which not relies to this topic and allows to successfully reload asterisk from 'asterisk -r') to JerJer but still no have any answer about it...
By: jerjer (jerjer) 2004-02-25 13:31:19.000-0600

No clue what your talking about.  The one patch i tried to apply broke lots of things so i refuse to apply anything else with out someone voutching for its sanity.
By: mdu113 (mdu113) 2004-08-20 15:32:06

I'd like to reopen this bug. The problem still exists in asterisk-1.0-RC2 and in the current CVS and I believe this is important.
The patch from http://bugs.digium.com/bug_view_page.php?bug_id=0000882 that fixed the problem for asterisks up to 0.9.1 does not work anymore.
Please let me know if you need any additional information, traces etc. or I can be of any assistance on resolving this.
By: mdu113 (mdu113) 2004-08-23 11:11:06

Reminder sent to bkw918

Hi,

Can I ask you why did you close this bug? It's still there and it's important.

Michael
By: Brian West (bkw918) 2004-08-23 11:22:30

It was closed because:

1. H323 is hopeless
2. No patches to fix it existed.
3. It was just sitting there.

You can do 1 of two things.  

Bug JerJer to fix it or supply an updated patch to fix it then reopen the bug and attach.   I usually have to close bugs out to provoke a response and it usually works 100% of the time.

bkw
By: mdu113 (mdu113) 2004-08-23 12:24:14

I agree that there are better alternatives to H323, but unfortunately in many places H323 infrastructure already exists and cannot be easily replaced.
JerJer I bug you :) Or anyone. Please look what you can do.
Unfortunately I'm not a programmer and I know neither openh323 library nor H323 itself deep enough to fix it all by myself.
By: mdu113 (mdu113) 2004-08-27 18:14:34

Ok, after a week of burying myself in the asterisk and openh323 code, I've produced intercept patch. I have no idea how good/bad the code is (please judge it), as once again, I'm not a programmer, but I guess I can assign it an infamous status ItWorksForMe(tm) :-)
Here's what the patch does. It enables faststart if it's enabled in configuration. Apparently it's not enabled by default in the library and one has to explicitly enable it which is not the case in the current code.
Then in OnAlerting I check if logical channels have already been created by faststart and if so I connect RTP to asterisk (call on_start_logical_channel).
Hurray! I can now hear sounds from PSTN. Faststart also seems to work fine. At least with my equipment (Lucent MAX TNT).
Probably it would be simpler to connect RTP from OnStartLogicalChannel as it would be universal, but this code has already been moved to MyH323_ExternalRTPChannel::OnReceivedAckPDU and I thought there might be a reason for that. So for outgoing calls with faststart I connect RTP from OnAlerting, for outgoing calls without faststart I connect it from OnReceivedAckPDU as it is in the current driver code, for all incoming calls I connect RTP in OnStartLogicalChannel.
Please comment on this as I need to put it in production after all.
By: jerjer (jerjer) 2004-09-19 12:06:04

patching file asterisk/channels/chan_h323.c
Hunk #1 succeeded at 1766 (offset 11 lines).
patching file asterisk/channels/h323/ast_h323.cpp
Hunk #3 succeeded at 359 with fuzz 2.
Hunk ASTERISK-1 succeeded at 511 with fuzz 2 (offset 9 lines).
Hunk ASTERISK-2 FAILED at 525.
Hunk ASTERISK-3 FAILED at 542.
Hunk ASTERISK-4 succeeded at 677 (offset -6 lines).
Hunk ASTERISK-5 FAILED at 768.
Hunk ASTERISK-6 succeeded at 800 (offset 10 lines).
Hunk ASTERISK-7 succeeded at 800 (offset -6 lines).
Hunk ASTERISK-8 FAILED at 864.
Hunk ASTERISK-9 succeeded at 1250 (offset -9 lines).
Hunk ASTERISK-10 succeeded at 1303 (offset 14 lines).
Hunk ASTERISK-11 succeeded at 1330 (offset -9 lines).
4 out of 15 hunks FAILED -- saving rejects to file asterisk/channels/h323/ast_h323.cpp.rej
patching file asterisk/channels/h323/ast_h323.h
Hunk #2 FAILED at 241.
1 out of 2 hunks FAILED -- saving rejects to file asterisk/channels/h323/ast_h323.h.rej
patching file asterisk/channels/h323/chan_h323.h

I applied another patch which prolly broke this one, sorry
By: mdu113 (mdu113) 2004-09-20 10:57:32

I'll try to update it for current CVS.
Please give me some time.
By: mdu113 (mdu113) 2004-09-21 14:04:54

intercept.patch-cvs092004 is for 09/20/2004 cvs
By: jerjer (jerjer) 2004-09-21 14:41:31

fixed in cvs
By: Digium Subversion (svnbot) 2008-01-15 15:07:55.000-0600

Repository: asterisk
Revision: 3815

U   trunk/channels/chan_h323.c
U   trunk/channels/h323/ast_h323.cpp
U   trunk/channels/h323/ast_h323.h
U   trunk/channels/h323/chan_h323.h

------------------------------------------------------------------------
r3815 | jeremy | 2008-01-15 15:07:55 -0600 (Tue, 15 Jan 2008) | 2 lines

support early media/intercept Bug ASTERISK-557

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=3815