[Home]

Summary:ASTERISK-02614: Chan_H323 dials out incorrectly
Reporter:nirsim (nirsim)Labels:
Date Opened:2004-10-15 06:43:45Date Closed:2004-12-17 09:51:24.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) aster-head-log
( 1) call-from-xlite-to-asterisk-out-from-h323-ch.dump
( 2) extensions.conf
( 3) h323.conf
( 4) h323debug.gz
Description:When dialing out from chan_h323, the dialed_party field is not transmitted. Here is a an example of what's going on in the machine:

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

Calling from a SIP phone to Asterisk, then dialing out via an H323 channel:

*CLI>
   -- Executing Dial("SIP/208-268a", "H323/10103447903048021@81.27.72.10") in new stack
Allowed Codecs:
        Table:
  G.711-uLaw-64k <1>
  G.711-ALaw-64k <2>
Set:
  0:
    0:
      G.711-uLaw-64k <1>
      G.711-ALaw-64k <2>

-- Making call to 81.27.72.10 using gatekeeper.
       == New H.323 Connection created.
       -- 97299611212 is calling host 81.27.72.10
       -- Call token is ip$localhost/8346
       -- Call reference is 8346
   -- Called 10103447903048021@81.27.72.10
       -- Sending SETUP message
       -- Received RELEASE COMPLETE message...
       -- Sending RELEASE COMPLETE
       ExternalRTPChannel Destroyed
       ExternalRTPChannel Destroyed
       ExternalRTPChannel Destroyed
       ExternalRTPChannel Destroyed
       ExternalRTPChannel Destroyed
       ExternalRTPChannel Destroyed
-- Call to ip$81.27.72.10:1720 aborted, insufficient bandwidth.
       == H.323 Connection deleted.
 == No one is available to answer at this time
   -- Executing Hangup("SIP/208-268a", "") in new stack
 == Spawn extension (mwisepbxoutgoing, 00447903048021, 2) exited non-zero on 'SIP/208-268a'

Now, the gateway located at 81.27.72.10 is actually a GnuGK, willing to accept calls from anyone, utilizing the prefix 10103. Now, according to GnuGK side, the dialed number doesn't exist in the prefixes list. Here is the output from GnuGK trace log:

2004/10/15 12:22:35.457 4       ProxyChannel.cxx(379)   Q931    Received: {
 q931pdu = {
   protocolDiscriminator = 8
   callReference = 32326
   from = originator
   messageType = Setup
   IE: Bearer-Capability = {
     80 90 a5                                           ...
   }
   IE: Display = {
     39 37 32 39 39 36 31 31  32 31 32 00               97299611212.
   }
   IE: Calling-Party-Number = {
     81 39 37 32 39 39 36 31  31 32 31 32               .97299611212
   }
   IE: User-User = {
     20 a8 06 00 08 91 4a 00  04 01 05 00 ca 5c c9 44    .....J......\.D
     54 52 2c 09 00 00 3d 37  54 68 65 20 4e 75 46 6f   TR,...=7The NuFo
     6e 65 20 4e 65 74 77 6f  72 6b 27 73 20 48 2e 33   ne Network's H.3
     32 33 20 43 68 61 6e 6e  65 6c 20 44 72 69 76 65   23 Channel Drive
     72 20 66 6f 72 20 41 73  74 65 72 69 73 6b 00 00   r for Asterisk..
     19 31 2e 30 2e 30 20 28  4f 70 65 6e 48 33 32 33   .1.0.0 (OpenH323
     20 76 31 2e 31 34 2e 34  29 00 00 00 51 1b 48 0a    v1.14.4)...Q.H.
     06 b8 00 c8 c0 10 20 1c  1d d9 11 93 76 00 02 b3   ...... .....v...
     e9 8c 4e 00 c5 1d 80 04  07 00 3e 5a 31 37 96 11   ..N.......>Z17..

 Now, in most sessions, there would usually be a field indicated as "IE: Called-Party-Number", which here doesn't exist. A good thing is, the system doesn't crash now :-)

Nir S
Comments:By: Brian West (bkw918) 2004-10-15 06:59:46

This is just minor now.
By: jerjer (jerjer) 2004-10-15 16:44:42

yes, I pulled the old caller*id support to get the code to compile.  Slowly working on adding it back in
By: sev (sev) 2004-10-18 06:17:16

I added additional tcp dump log about absence Called Number field in SETUP message.
By: nirsim (nirsim) 2004-10-18 10:28:30

Any news about this bug?
By: Andrey S Pankov (casper) 2004-10-30 07:24:28

chan_h323 is broken for now in CVS HEAD and CVS v1-0 a.f.a.i.k.

JerJer: this bug is about Called-Party-Number, not Calling. It seems like dimitel had noticed the absence of Called-Party-Number before you broke/removed Caller*ID support. sev's dump shows up the absence of both elements, but sourceAddress is root and no destinationAddress present.

All: please note that both Called-Party-Number and Calling-Party-Number may be missing. Common practice is to check first whether H225_Setup_UUIE has optional field destinationAddress (native H.323 element). If not, then check for Q931::CalledPartyNumberIE.
By: nirsim (nirsim) 2004-11-11 10:19:12.000-0600

Any progress with this issue? It's been going on for almost a month now, and still, no viable solution. I believe that problem is now earned it's way to be raised to a level of more than minor. This bug is currently blocking some developments and application my company is currently developing, using H323 connectivity.
By: jerjer (jerjer) 2004-11-11 13:51:17.000-0600

People, if you want a solution to a possible problem, I require valid H.323 stack traces with the PDUs decoded (In Open H.323 terms this is a Level 4 Trace)

Find a clue before complaining
By: pbd (pbd) 2004-11-20 19:47:22.000-0600

I've been able to reproduce this bug as well.  I'm running 1.0.2 stable (source tarball) downloaded 2 days ago.  Environment is stock- I'm only running a custom MeetMe config (standard MeetMe appication, but my own .conf files to make it a little nicer for our users).  The meetme works just fine- we're connected to Cisco Callmanager 3.3.3 via GnuGK and an H.225 trunk.  Calls from Callmanager to Asterisk are perfect- we've got the app in production.  Calls made using OhPhone connected to the GnuGK to either Asterisk or to Callmanager extensions work perfectly as well.  Calls from DIAX through Asterisk to Callmanager via GnuGK fail every time- h323debug.gz has a level 4 trace (-vvvvvdc, h.323 trace 4) of the problem.  At around line 1345, a broken pipe is detected- CallManager shuts us out right after the initial Q.931 SETUP message.

tcpdump of the calls that work (OhPhone -> GnuGK -> Callmanager) shows that both  Called-Party-Number IE and Calling-Party-Number IE are being sent, whereas the h323 channel driver leaves out the Calling-Party-Number, but I'm not sure that's significant.

Please let me know if you need more traces- happy to oblige.
By: jerjer (jerjer) 2004-11-20 19:49:27.000-0600

the stable branch of chan_h323 is not supported or desired.  Use cvs -head.
\
By: pbd (pbd) 2004-11-20 20:54:41.000-0600

No can do, for one highly important reason- Stable is just that- 'stable'.  I'm running a production system here- I can't risk a client's business on something that might not work tomorrow.  As the stable tarballs are being updated (I diffed the h323 channel driver between 1.0-RC2 and 1.0.2 to show it), it's my assumption that -head is being integrated as it's been vetted.

Net effect- code that is reported broken in much the same (if not identical) way in stable and head will not be reviewed at all? Sorry to say it- that's frustrating and probably not helpful to anyone.

I will continue to monitor- hopefully, -head will get integrated into -stable at some point, so I can be of some use.
By: pbd (pbd) 2004-11-21 12:03:23.000-0600

Ok, it's perhaps against my better judgement, and certainly not condusive to domestic bliss, but I've spent the last 12 hours or so building up a test machine, adding the newer versions of openh323 and pwlib, and getting cvs-head (11/21) put on the machine.  I've copied the relevant configurations, sounds, etc, made the appropriate modifications so that it's essentially an identical server to the 1.0.2 machine we run in production.

Net effect?  Same result, but with more debugging information (perhaps).  I've attached the aster-head-log, which is a -vvvvvdc h.323 debug h.323 trace 4.  I've also attached my h323.conf and extensions.conf, based on some of the oddities I observed in the trace (odd to me, anyway).

Around line 1494, we see a socket read error- Cisco closed the connection before we thought it should close.  I do see more IE's passed on the Q.931 messages, but some of them are a little strange- to my untrained eye, I would say the caller-id would have been populated with the prefix digits I put on the h.323 channel, not the information from my DIAX client setup- the call doesn't go through, so I'll leave that one as an academic question.

Now that I've got a test environ working, I'll be even more happy to throw tests out as needed.  Please let me know if I can provide more.
By: nirsim (nirsim) 2004-12-01 01:29:40.000-0600

The new version of chan_h323 dials out correctly, however, the peer support that was supposed to be available in this version is currently broken (according to JerJer). The correct notation for now is:

exten XXX => 1,Dial,H323/target@ip/fqdn|timeout|options
By: pbd (pbd) 2004-12-01 10:02:04.000-0600

I'm still not seeing any changes from my side.  On my -HEAD box (updated every other day- updated this morning), I show chan_h323.c with a date of 11/16, and a ast_h323.cpp with a date of 11/11.  Is there a newer version not yet appearing in CVS?
By: nirsim (nirsim) 2004-12-01 14:05:34.000-0600

The version you are stating is the latest one. JerJer uploaded that version to the CVS, while at the airport, I verified that it dialed out correctly according to the below mentioned extension format 5 minutes after the CVS update.
By: jerjer (jerjer) 2004-12-15 19:59:38.000-0600

Fixed in cvs -head.   Please Test.  Reopen/Resubmit if issues found.