[Home]

Summary:ASTERISK-03015: Chan_h323 dials out incorrectly again
Reporter:nirsim (nirsim)Labels:
Date Opened:2004-12-16 11:04:31.000-0600Date Closed:2011-06-07 14:05:22
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) H323_Dials_out_wrong.txt
( 1) trace_from_gatekeeper.txt
Description:As this was removed by drumkila, I'll re-post in a more elaborate manner. The new version of chan_h323 in the CVS head appears to be dialing out incorrectly. Upon dialing, h.323 debug and logger debug shows that the outgoing dial command has the @ symbol on the IP number, instead of the actual IP that is supposed to be there.

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

In order to validate that this is not a presentation issue, I've forwarded the calls to a GnuGK gatekeeper, and ran a trace level 4, which shows the actual headers of the session. The Called-Party-Number field is missing from there, and does not appear in the header. This same had been exhibited in bug report number 0002659.

Here are the lines I extracted from the Asterisk CLI:

   -- Dec 21 17:01:22 DEBUG[1168]: app_queue.c:371 changethread: Device 'SIP/nirs' changed to state '2'
Executing Dial("SIP/nirs-89b7", "H323/1010397299611212@81.27.72.10|120") in new stack
Dec 21 17:01:22 DEBUG[1169]: chan_h323.c:1033 oh323_request: type=H323, format=256, data=1010397299611212@81.27.72.10.
Dec 21 17:01:22 DEBUG[1169]: chan_h323.c:1066 oh323_request: Extension: 1010397299611212 Host: 81.27.72.10
Dec 21 17:01:22 DEBUG[1169]: chan_h323.c:952 find_peer: Could not find peer 81.27.72.10 by name or address
Allowed Codecs:
        Table:
  G.729A{sw} <1>
  G.729{sw} <2>
  UserInput/hookflash <3>
  UserInput/RFC2833 <4>
Set:
  0:
    0:
      G.729A{sw} <1>
      G.729{sw} <2>
    1:
      UserInput/hookflash <3>
    2:
      UserInput/RFC2833 <4>

Dec 21 17:01:22 DEBUG[1169]: chan_h323.c:518 oh323_call: Placing outgoing call to 1010397299611212@@@@@@@@@@@@:1720, 101
-- Making call to 1010397299611212@@@@@@@@@@@@:1720 without gatekeeper.
       == New H.323 Connection created.
       -- root is calling host 1010397299611212@@@@@@@@@@@@:1720

While in GnuGK the call setup looks like this:

2004/12/16 16:42:36.410 4        ProxyThread.cxx(675)   ProxyH(1) 1 sockets selected from 1, total 2/1
2004/12/16 16:42:36.410 3       ProxyChannel.cxx(423)   Q931s   Received: Setup CRV=15176 from 213.238.133.83:47381
2004/12/16 16:42:36.416 4       ProxyChannel.cxx(379)   Q931    Received: {
 q931pdu = {
   protocolDiscriminator = 8
   callReference = 15176
   from = originator
   messageType = Setup
   IE: Bearer-Capability = {
     80 90 a5                                           ...
   }
   IE: Display = {
     6e 69 72 73 00                                     nirs.
   }
   IE: Calling-Party-Number = {
     81 6e 69 72 73                                     .nirs
   }
   IE: User-User = {
     20 b8 06 00 08 91 4a 00  04 01 40 03 00 72 00 6f    .....J...@..r.o
     00 6f 00 74 22 c0 09 00  00 3d 37 54 68 65 20 4e   .o.t"....=7The N
     75 46 6f 6e 65 20 4e 65  74 77 6f 72 6b 27 73 20   uFone Network's
     48 2e 33 32 33 20 43 68  61 6e 6e 65 6c 20 44 72   H.323 Channel Dr
     69 76 65 72 20 66 6f 72  20 41 73 74 65 72 69 73   iver for Asteris
     6b 00 00 19 31 2e 30 2e  30 20 28 4f 70 65 6e 48   k...1.0.0 (OpenH
     33 32 33 20 76 31 2e 31  34 2e 34 29 00 00 00 01   323 v1.14.4)....

Attached are two files of the full traces, from which these extracts are taken from. In both cases, the call should have been made to 1010397299611212@81.27.72.10
Comments:By: Clod Patry (junky) 2004-12-16 12:32:47.000-0600

can i ask how can ya've version 12/21/04-10:42:38 if today's 12/16/04?

next time, try to copy & paste the output of asterisk -V.
example: asterisk:/etc/asterisk# asterisk -V
Asterisk CVS-HEAD-12/13/04-09:27:05
asterisk:/etc/asterisk#

Thanks for understanding.
By: nirsim (nirsim) 2004-12-16 13:01:33.000-0600

Well, simple reason, it's a testing machine and the time is not set correctly on the box:

[root@gw00 root]# date
Tue Dec 21 18:58:24 GMT 2004
[root@gw00 root]# asterisk -V
Asterisk CVS-HEAD-12/21/04-10:42:38
[root@gw00 root]#

That is all. The entry in /usr/src/asterisk/channels/CVS for chan_h323.c file is: /chan_h323.c/1.96/Thu Dec 16 04:25:49 2004//

Which indicates the currention revision of the chan_h323.c is 1.96, if we check the e-mail from the CVS mailing list, the version indicated in the e-mail is also 1.96:

retrieving revision 1.95
retrieving revision 1.96
diff -u -d -r1.95 -r1.96
--- chan_h323.c 16 Dec 2004 02:03:19 -0000 1.95
+++ chan_h323.c 16 Dec 2004 04:25:49 -0000 1.96

Which means, I'm using the latest version of chan_h323.

I'm really sorry for the confusion, wasn't intentional.
Thanks for heads up, I'll modify the time on that bugger.

Thanks,
DimiTel

edited on: 12-16-04 13:04
By: Clod Patry (junky) 2004-12-16 21:20:09.000-0600

you said "As this was removed by drumkila", can i know to which bug you are referring exactly?

When you submit a new bug related to another one, try to specify it, in that way, we'll all know in first read to what problems we're facing exactly, and which is the exact context.

Thanks.
By: jerjer (jerjer) 2004-12-16 21:30:59.000-0600

unable to duplicate

cd /usr/src/asterisk
cvs update
cd channels/h323
make clean
make
cd /usr/src/asterisk
make install
By: nirsim (nirsim) 2004-12-17 04:43:10.000-0600

JerJer,

 Can we co-ordinate you logging into the box, and looking at it? I've compiled the channel exactly to your installation instructions.
By: nirsim (nirsim) 2004-12-19 13:30:28.000-0600

Ok, I've digging into the code a little myself, and I managed to find a very weird behaviour inside chan_h323.c, and I was wondering if any one can help out. I may not be the saviest C/C++ programer around, but I have learned that when all else fails, resort to good-old debugging techniques always works. So,
I've modified the chan_h323 code slightly, to print out the fields making the called_addr variable, so now it looks like this:

if (pvt->exten) {
  ast_log(LOG_DEBUG, "addr=%s\n",addr);
  ast_log(LOG_DEBUG, "target=%s\n",&pvt->exten);
  ast_log(LOG_DEBUG, "port=%d\n",pvt->options.port);
  sprintf(called_addr, "%s@%s:%d", &pvt->exten, addr, pvt->options.port);
  ast_log(LOG_DEBUG, "called_addr: %s\n",called_addr);
} else {
  ast_log(LOG_DEBUG, "In case 2 : addr=%s",addr);
  sprintf(called_addr, "%s:%d",addr, &pvt->options.port);
}
ast_log(LOG_DEBUG, "Placing outgoing call to %s\n", called_addr);
res = h323_make_call(called_addr, &(pvt->cd), &pvt->options);

Now check out what happens inside asterisk, when I run a call via this code:

Dec 24 19:21:26 DEBUG[14621]: chan_h323.c:514 oh323_call: before if - called_addr=
Dec 24 19:21:26 DEBUG[14621]: chan_h323.c:517 oh323_call: addr=81.27.72.10
Dec 24 19:21:26 DEBUG[14621]: chan_h323.c:518 oh323_call: target=10103972544482826
Dec 24 19:21:26 DEBUG[14621]: chan_h323.c:519 oh323_call: port=1720
Dec 24 19:21:26 DEBUG[14621]: chan_h323.c:521 oh323_call: called_addr: 10103972544482826@6@6@6@6@6@6:1720
Dec 24 19:21:26 DEBUG[14621]: chan_h323.c:527 oh323_call: Placing outgoing call to 10103972544482826@6@6@6@6@6@6:1720
-- Making call to 10103972544482826@6@6@6@6@6@6:1720 without gatekeeper.

Now, we can clearly see that the addr field which was initially 81.27.72.10 for some strange reason, turned into 6@6@6@6@6@6.

Has anyone got some thoughts on the matter ?
By: jerjer (jerjer) 2004-12-19 19:20:04.000-0600

fixed in cvs -head