[Home]

Summary:ASTERISK-03048: don't accept h.323 calls
Reporter:andreim (andreim)Labels:
Date Opened:2004-12-20 03:17:55.000-0600Date Closed:2005-04-07 12:37:47
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bug3105log
( 1) h323.conf
( 2) h323.rtf
Description:After last week update on CVS I can't receive h.323 calls from GnuGk (x.x.x.12), asterisk is x.x.x.2. This problem persist in today CVS.
This is the result of the h.323 debug, h.323 trace 3:

*CLI>   0:31.462          H323 Listener:8139e98   transports.cxx(1504)  H323TCP Started connection:  host=x.x.x.12:34460, if=x.x.x.2:1720, handle=10
 0:31.463          H225 Answer:81039a8   transports.cxx(564)   H225    Started incoming call thread
 0:31.467          H225 Answer:81039a8   transports.cxx(1127)  H225    Awaiting first PDU
 0:31.469          H225 Answer:81039a8      h323pdu.cxx(517)   H225    Receiving PDU: setup
 0:31.469          H225 Answer:81039a8   transports.cxx(1136)  H225    Incoming call, first PDU: callReference=31427
 0:31.469          H225 Answer:81039a8     h323caps.cxx(1942)  H323    Added capability: G.711-ALaw-64k <1>
 0:31.469          H225 Answer:81039a8     h323caps.cxx(1942)  H323    Added capability: UserInput/hookflash <2>
 0:31.470          H225 Answer:81039a8     h323caps.cxx(1942)  H323    Added capability: UserInput/RFC2833 <3>
 0:31.470          H225 Answer:81039a8     h323caps.cxx(2008)  H323    Found capability: G.711-ALaw-64k <1>
 0:31.470          H225 Answer:81039a8     h323caps.cxx(2008)  H323    Found capability: UserInput/hookflash <2>
 0:31.471          H225 Answer:81039a8     h323caps.cxx(2008)  H323    Found capability: UserInput/RFC2833 <3>
 0:31.471          H225 Answer:81039a8      rfc2833.cxx(81)    RFC2833 Handler created
       == New H.323 Connection created.
 0:31.471          H225 Answer:81039a8       h323ep.cxx(2227)  H323    Created new connection: ip$x.x.x.12:34460/31427
 0:31.471          H225 Answer:81039a8         h323.cxx(1761)  H225    Handling PDU: Setup callRef=31427
 0:31.472          H225 Answer:81039a8         h323.cxx(1801)  H225    Set remote application name: "Cisco IOS 12.x    181/18"
       --Received SETUP message
   -- Setting up Call
Urgent handler
   --  Call token:  [ip$x.x.x.12:34460/31427]
Urgent handler
   --  Calling party name:  []
Urgent handler
   --  Calling party number:  [214116285]
Urgent handler
   --  Called party name:  [317301111]
Urgent handler
   --  Called party number:  [317301111]
Urgent handler
       -- Call Failed
       -- ClearCall: Request to clear call with token ip$x.x.x.12:34460/31427, cause 7
 0:31.472          H225 Answer:81039a8       h323ep.cxx(1898)  H323    Clearing connection ip$x.x.x.12:34460/31427 reason=EndedByTransportFail
 0:31.473          H225 Answer:81039a8         h323.cxx(1540)  H323    Call end reason for ip$x.x.x.12:34460/31427 set to EndedByTransportFail
 0:31.473          H225 Answer:81039a8         h323.cxx(1558)  H225    Sending release complete PDU: callRef=31427
       -- Sending RELEASE COMPLETE
 0:31.474          H225 Answer:81039a8      h323pdu.cxx(517)   H225    Sending PDU: releaseComplete
 0:31.475                 H323 Cleaner       h323ep.cxx(1955)  H323    Cleaning up connections
 0:31.475                 H323 Cleaner         h323.cxx(1595)  H323    Connection ip$x.x.x.12:34460/31427 closing: connectionState=NoConnectionActive
 0:31.475                 H323 Cleaner      h323neg.cxx(334)   H245    Stopping MasterSlaveDetermination: state=Idle
 0:31.476                 H323 Cleaner      h323neg.cxx(561)   H245    Stopping TerminalCapabilitySet: state=Idle
 0:31.476                 H323 Cleaner   transports.cxx(1109)  H323    H323Transport::Close
 0:31.476          H225 Answer:81039a8   transports.cxx(1166)  H225    Signal channel stopped on first PDU.
 0:31.491                 H323 Cleaner   transports.cxx(1191)  H323    H323Transport::CleanUpOnTermination for H225 Answer:81039a8
 0:31.492                 H323 Cleaner         h323.cxx(1659)  H323    Connection ip$x.x.x.12:34460/31427 terminated.
-- Call with  ended abnormally
       == H.323 Connection deleted.
 0:31.492                 H323 Cleaner         h323.cxx(1490)  H323    Connection ip$x.x.x.12:34460/31427 deleted.
Comments:By: Clod Patry (junky) 2004-12-20 07:31:38.000-0600

when you report a bug, please provide the CVS Date or Stable Version.
it clearer for everyone. Even if you said it's today's CVS, there's a field only for that purpose, so try to use it.
By: nirsim (nirsim) 2004-12-20 17:38:12.000-0600

Andreim,

 I suggest that you enable DEBUG level in your logger.conf, it will enable JerJer to see if there is something in there to provide information. Most of the times, the information provided by logger is crucial.
By: Mark Spencer (markster) 2004-12-20 18:56:43.000-0600

also, can you be sure you did a "make clean ; make install" on asterisk followed by the same in the h323 directory?
By: jerjer (jerjer) 2004-12-21 01:36:14.000-0600

Why are you calling someone on port 34460?   Call ended by TransportFail usually means operator error.
By: andreim (andreim) 2004-12-21 01:45:06.000-0600

I don't force the call on port 34460. It is the same configuration which worked before.
Just to show you good faith I'll do again "cvs update asterisk; make clean; make install" and I'll enable DEBUG in logger. I want to tell me what do you need from logs or from configuration.

Andrei
By: andreim (andreim) 2004-12-21 02:52:02.000-0600

I did again a CVS update, make clean, make install and run the same tests.
I don't see anything related to H323 in debug file.
By: nirsim (nirsim) 2004-12-21 06:33:18.000-0600

Andreim,

In /etc/asterisk/logger.conf modify the current console directive
to the following:

console => notice,warning,error,debug

 This will through the DEBUG lines from asterisk into the running
Asterisk console, be it a background CLI or a forground running Asterisk.
If you want, I'm willing to help you out on this, and see if I can debug
the situation further with you. Please contact me via MSN at nirs@dimitel.com,
and maybe I'll find more information to help JerJer out on this one, if it's
a "true" bug, and not a false-positive.
By: tdriscoll (tdriscoll) 2004-12-25 00:30:45.000-0600

I'm having a simular issue. My stable works fine but my head verion dated 12/24/04 cannot receive h323 calls. The far end reports fast busy. Debug reports the incoming call but then ends its reporting. Could this just be a problem with our h323.conf files and lack of understanding? I know that h323 head was completely overhauled and version 1.0 seemed a little more forgiving. Keep in mind my h323 is used to connect to other gateways and not phone sets.

My bad again. It was a h323.conf issue. I should learn to read my own writing.

edited on: 12-29-04 12:11
By: andreim (andreim) 2004-12-30 02:06:20.000-0600

tdriscoll you are saying that you solve the problem changing h323.conf?
My tests were made with the same h323.conf, in stable release is working and in CVS is not.
Can you share the h323.conf modification you did in order to solve this problem?

Thanks,
Andrei
By: tdriscoll (tdriscoll) 2004-12-30 12:02:29.000-0600

If this report is the same I think this person may just have a config issue. Here is some simple information I came up with. If you have questions contact me at tdriscoll@itstx.net

With out [BCM35] Version = Head

H323 debug enabled
*CLI>   == New H.323 Connection created.
       --Received SETUP message
   -- Setting up Call
   --  Call token:  [ip$192.168.1.99:4215/32232]
   --  Calling party name:  [BCM35 Office]
   --  Calling party number:  [9722981193]
   --  Called party name:  [5001]
   --  Called party number:  [5001]
       -- Call Failed
       -- ClearCall: Request to clear call with token ip$192.168.1.99:4215/32232, cause 7
       -- Sending RELEASE COMPLETE
-- Call with  ended abnormally
       == H.323 Connection deleted.

Note: This is not required for the stable version!!!!!!


After adding the statement!
With [bcm35]
-- Executing Dial("H323/ip$192.168.1.99:4220/32233", "SIP/5001|20") in new stack
   -- Called 5001
   -- SIP/5001-0a29 is ringing
   -- SIP/5001-0a29 answered H323/ip$192.168.1.99:4220/32233
 == Spawn extension (default, 5001, 1) exited non-zero on 'H323/ip$192.168.1.99:4220/32233'
Call completes

This is from another system with the same issue. As a 1.0 Stable it works well. As a Head incoming calls cannot complete.
Notice the calling party name. Asterisk doesn't know what to do with the call so it rejects it.
CLI> == New H.323 Connection created.
--Received SETUP message
-- Setting up Call
-- Call token: [ip$172.16.1.10:2054/11497]
-- Calling party name: []
-- Called party name: [701]
-- ICalled party number: [701]
-- Call Failed
-- ClearCall: Request to clear call with token ip$172.16.1.10:2054/11497, cause 7
-- Calling party number: []
-- Called party name: [701]
-- Called party number: [701]
test*CLI> -- Sending RELEASE COMPLETE
-- Call with ended abnormally
== H.323 Connection deleted.

h323.conf
; The NuFone Network's
; Open H.323 driver configuration
;
[general]
port = 1720
bindaddr = 192.168.1.2 ; this SHALL contain a single, valid IP address for this machine
tos=lowdelay
;amaflags = default
;accountcode=lss0101
disallow=all
;allow=all ; turns on all installed codecs
;disallow=g723.1 ; Hm...  Proprietary, don't use it...
;allow=gsm
allow=uLaw ; Always allow GSM, it's cool :)
dtmfmode=rfc2833
;gatekeeper = DISABLE
;AllowGKRouted = no
;context=default

;In order to receive a call from a remote gateway I had to define
;that gateway as a user. Unlike stable that does not require this.
;Also in my case the remote gateway is a Nortel BCM. I had to configure
;it to send system name [BCM35] so that Asterisk could identify it. This
;isn't a bad thing! It actually adds some security to h323. Toll fraud is
; a big issue.
;See my debug info.

[BCM35]
type=user
host=192.168.1.99
noFastStart=no
context=default
allow=all
dtmfmode=rfc2833




There is another problem that I am having but I'm not sure it applies to Asterisk or Nortel. I am still working a bug report for that issue. The issue is 1 out of 5 calls fail to open the audio channels when calling from a i2004 nortel phone to a sip phone of any flavor. It works 100% when calling sip to i2004. Again I am still evaluating it before reporting it as a bug

edited on: 12-30-04 12:07

edited on: 12-30-04 12:10
By: tdriscoll (tdriscoll) 2005-01-01 22:28:35.000-0600

I think JerJer needs to see this. From what I can tell all of this has to do with Alias's. My problem is that I don't use a Gatekeeper. My idea would be to allow a setting to turn on or off the requirement for Calling Name. The reason would be some h323 gatways can not send Calling name information or if it can it may interfere other operations example would be a Nortel BCM or Succession. Another possible solution would be to allow for a wild card charactor. As it stands h323 will not allow for
[]
type=user
host=192.168.1.99
noFastStart=no
context=default
allow=all
dtmfmode=rfc2833

This could be a big problem! To me it means that I now have to alias's for every extension on every BCM I have that wants to call or pass a call to my Asterisk network. JerJer please help!
By: tdriscoll (tdriscoll) 2005-01-03 22:27:33.000-0600

Any new information on this? Can anyone confirm my findings
By: ffs (ffs) 2005-01-04 02:15:35.000-0600

hi tdriscoll,

setting 'UserByAlias=no' in the global section in h323.conf solved it for us. This parameter forces a find_user by source ip address.
By: tdriscoll (tdriscoll) 2005-01-04 09:26:12.000-0600

Yep! I missed that. It works great here too. Andreim did you see this? It cleans it right up.
By: andreim (andreim) 2005-01-05 03:19:04.000-0600

Hi guys,

I tried today "UserByAlias=no" and is not working. I get the same error.
We have different test beds.
If I'm not using GnuGk and accept calls directly from Cisco gateway is working ok.
The problem appears when I'm using GnuGk.

Andrei
By: ffs (ffs) 2005-01-05 03:58:54.000-0600

Andreim,

pls notice bug 3233.
Acception of GK routed calls is broken.
By: pbd (pbd) 2005-01-20 20:59:44.000-0600

Added file 'bug3105log' - this is a trace 4 debug on log of what I believe is a related problem.  Using GnuGK, but not using GKRouted calls.  Same gatekeeper and h.323 configuration in working 1.0.2 system, this trace is from HEAD as of today (1-20-05).

Symptoms are that call comes in, message shows up saying that it's sending the call to the appropriate context, but then the call falls apart immediately afterwards.  OpenPhone and Cisco Callmanager both display same problem when attempting inbound calls- I've vetted the dialplan by using IaxComm to hit it via an IAX softphone as well.  Looks like the problem started kicking up about 10 days ago- but I've been travelling and not testing as much with this environment as I used to, so it may have been earlier.

Happy to set up more testing if anyone needs it.  I've read the associated bugnotes with the other reported bugs, this one seems to come closest- apologies if there's a bug that's an even better fit.
By: pbd (pbd) 2005-01-25 22:43:17.000-0600

Reference resolved bug  0003429 for additional detail (resolved as it was ruled duplicate, although I have my suspicions it's not).  This is not a 'feature' type bug, it is a 'major': this represents normal operation that doesn't work at all.  I will attempt to dig into this one myself- it appears that between stable and head, the structure of the callback was changed to include an options structure, which is not filled in- similar to bug 3233, which is classed 'minor'.  There appears to be some code reorg necessary in the incoming call callback function as a result, I'm not entirely certain how/why this is now in HEAD, as I cannot see how it would work to receive an incoming call at all under any circumstance.
By: Paul Cadach (pcadach) 2005-01-25 22:54:51.000-0600

The reason for reject incoming call is NULL value of call_options variable in setup_incoming_call() when calling user is not found. Assigning &pvt->options to call_options rises deadlock somewhere within H.323.
By: Mark Spencer (markster) 2005-02-19 15:29:10.000-0600

So where are we now?
By: Clod Patry (junky) 2005-03-08 22:48:53.000-0600

last chance, any updates to that bug or can we close it?

Thanks for understanding.
By: nirsim (nirsim) 2005-03-09 02:14:44.000-0600

Junky,

 Unfortunatly to say, this bug still persists. I've checked both latest CVS and 1.0.6 Stable, and it still persists. In order to bypass the issue, and as much as it would sound bad, in order to solve the issue on the same box, I'm simply running 2 different instances of Asterisk, one with chan_h323 to send calls, and one with chan_oh323 to receive calls.

 I'm aware it's a f***ed up solution, but it works for now, till JerJer or someone else comes up with a proper solution.

Nir S
By: jerjer (jerjer) 2005-03-09 09:59:34.000-0600

how come I cannot duplicate this problem?
By: pbd (pbd) 2005-03-09 20:29:44.000-0600

JerJer-

Not sure- I just updated my test server to CVS HEAD-03/09/05, still exact same behavior.  Call comes in via gnugk, call is seen by h.323 channel driver, channel driver states that it's putting it into the right context, then call is dropped.  Important that it has to be gnugk calls- although I'm not using gatekeeper routed calls (my gnugk is configed with GKRouted=0) I still use the gatekeeper to manage the endpoints.
If it makes a difference (unlikely), my version of gnugk is:
Gatekeeper(GNU) Version(2.0.8) Ext(pthreads=1,acct=1,radius=0,mysql=0,pgsql=1,ldap=0,large_fdset=0) Build(Jul 17 2004, 14:11:03) Sys(Linux i686 2.4.21-226-tca-ast)

Let me know what/if I can help.
By: Chih-Wei Huang (cwhuang) 2005-03-22 00:36:44.000-0600

Hello, I am working on this problem.
As PCadach said, it is because setup_incoming_call in chan_h323.c
doesn't return a valid pointer to call_options_t in some cases
(usually using with a gatekeeper).
Of course, I'm using Asterisk with GnuGK.
(someone may know I'm the main author of GnuGK)
Since I am very new to Asterisk, I still don't know clearly
the logic and duty the function to do.
Hopefully somebody can give me a hand.
By: Paul Cadach (pcadach) 2005-04-07 07:54:37

Any updates on this? Is current CVS-HEAD (and, possible, ASTERISK-3875) helps?
By: pbd (pbd) 2005-04-07 12:23:07

I now am sucessfully signalling calls using the gatekeeper through to Cisco Callmanager- my test case is (sort of) successful.  I still have a codec negotiation issue, but I'm willing to file that as a separate bug, once I can give some more succinct traces- the signalling appears 100% solid, which is what this one addresses.  I'd call this 'closed', as of (at least) CVS-HEAD-04/07/05-11:55:55

I've tried the patches for codec negotiation in 3967, no luck.
By: jerjer (jerjer) 2005-04-07 12:37:34

fixed in -head
By: jerjer (jerjer) 2005-04-07 12:37:47

not for -stable