[Home]

Summary:ASTERISK-15483: [patch] Random DTMF duplicate emulation on bridged OOH323 channel on outgoing calls
Reporter:Vladimir Mikhelson (vmikhelson)Labels:
Date Opened:2010-01-21 00:44:41.000-0600Date Closed:2010-03-06 18:32:19.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Addons/chan_ooh323
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) full.txt
( 1) h323_log_2010-02-23.txt
( 2) h323_log-call4.txt
( 3) ooh323-dtmf-duplicate-2.patch
( 4) ooh323-dtmf-duplicate-3.patch
( 5) ooh323-keypad-dtmf-duplicated.patch
Description:In majority of cases DTMF tones are duplicated by Asterisk when bridging a SIP or DAHDI channel with OOH323 channel on outgoing calls.

In case of a normal DTMF processing the following sequence is observed:

[Jan 20 19:59:56] DTMF[21084]: channel.c:2855 __ast_read: DTMF begin '9' received on SIP/464-00000012
[Jan 20 19:59:56] DTMF[21084]: channel.c:2865 __ast_read: DTMF begin passthrough '9' on SIP/464-00000012
[Jan 20 19:59:56] DTMF[21084]: channel.c:2783 __ast_read: DTMF end '9' received on SIP/464-00000012, duration 120 ms
[Jan 20 19:59:56] DTMF[21084]: channel.c:2823 __ast_read: DTMF end accepted with begin '9' on SIP/464-00000012
[Jan 20 19:59:56] DTMF[21084]: channel.c:2839 __ast_read: DTMF end passthrough '9' on SIP/464-00000012

In case of a problematic DTMF processing it looks like that:

[Jan 20 19:18:54] DTMF[20916]: channel.c:2855 __ast_read: DTMF begin '9' received on SIP/464-00000011
[Jan 20 19:18:54] DTMF[20916]: channel.c:2865 __ast_read: DTMF begin passthrough '9' on SIP/464-00000011
[Jan 20 19:18:54] DTMF[20916]: channel.c:2783 __ast_read: DTMF end '9' received on OOH323/172.17.135.2:1720-9915, duration 0 ms
[Jan 20 19:18:54] DTMF[20916]: channel.c:2809 __ast_read: DTMF begin emulation of '9' with duration 100 queued on OOH323/172.17.135.2:1720-9915
[Jan 20 19:18:54] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_21
[Jan 20 19:18:54] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_21
[Jan 20 19:18:54] DTMF[20916]: channel.c:2932 __ast_read: DTMF end emulation of '9' queued on OOH323/172.17.135.2:1720-9915
[Jan 20 19:18:54] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_21
[Jan 20 19:18:54] DTMF[20916]: channel.c:2783 __ast_read: DTMF end '9' received on SIP/464-00000011, duration 120 ms
[Jan 20 19:18:54] DTMF[20916]: channel.c:2823 __ast_read: DTMF end accepted with begin '9' on SIP/464-00000011
[Jan 20 19:18:54] DTMF[20916]: channel.c:2839 __ast_read: DTMF end passthrough '9' on SIP/464-00000011
[Jan 20 19:18:55] WARNING[20916]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_21


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

SIP dtmfmode=rfc2833

OOH323 dtmfmode=h245alphanumeric


In case of a normal DTMF processing h323_log contained:

19:59:56:675  Sending H.245 Message = {
19:59:56:675     indication = {
19:59:56:675        userInput = {
19:59:56:676           alphanumeric = {
19:59:56:676              "9"
19:59:56:677           }
19:59:56:677        }
19:59:56:678     }
19:59:56:678  }
19:59:56:678  Building Facility message for tunneling ? (outgoing, ooh323c_o_22)
19:59:56:678  UserInfo encoding - successful
19:59:56:678  Q931 Message = {
19:59:56:678     protocolDiscriminator = 8
19:59:56:678     callReference = 32
19:59:56:678     from = originator
19:59:56:678     messageType = 62
19:59:56:678     Display IE = {
19:59:56:678        ThinkPad T60p
19:59:56:678     }
19:59:56:678     h323_uu_pdu = {
19:59:56:679        h323_message_body = {
19:59:56:679           facility = {
19:59:56:679              protocolIdentifier = {
19:59:56:680                 {
19:59:56:681  0 0 8 2250 0 4 }
19:59:56:681              }
19:59:56:682              reason = {
19:59:56:682                 transportedInformation = {
19:59:56:683                    NULL
19:59:56:684                 }
19:59:56:685              }
19:59:56:685              callIdentifier = {
19:59:56:686                 guid = {
19:59:56:687                    '6f6f68333233632dcff095ffffffffff'H
19:59:56:687                 }
19:59:56:688              }
19:59:56:689           }
19:59:56:689        }
19:59:56:689        h245Tunneling = {
19:59:56:690           TRUE
19:59:56:690        }
19:59:56:691        h245Control = {
19:59:56:691           elem[0] = {
19:59:56:692              '6d400139'H
19:59:56:692           }
19:59:56:693        }
19:59:56:693     }
19:59:56:693  UUIE decode successful
19:59:56:693  }


In case of a problematic DTMF processing h323_log contained:

19:18:54:745  Q931 Message = {
19:18:54:745     protocolDiscriminator = 8
19:18:54:745     callReference = 31
19:18:54:745     from = originator
19:18:54:745     messageType = 7b
19:18:54:745     Display IE = {
19:18:54:745        ThinkPad T60p
19:18:54:745     }
19:18:54:745     Keypad IE = {
19:18:54:745        9
19:18:54:745     }
19:18:54:745     h323_uu_pdu = {
19:18:54:745        h323_message_body = {
19:18:54:746           information = {
19:18:54:746              protocolIdentifier = {
19:18:54:747                 {
19:18:54:748  0 0 8 2250 0 4 }
19:18:54:748              }
19:18:54:749              callIdentifier = {
19:18:54:749                 guid = {
19:18:54:750                    '6f6f68333233632d8418d9ffffffffff'H
19:18:54:751                 }
19:18:54:752              }
19:18:54:752           }
19:18:54:753        }
19:18:54:753        h245Tunneling = {
19:18:54:753           TRUE
19:18:54:754        }
19:18:54:754     }
19:18:54:754  UUIE decode successful
19:18:54:754  }


Please note, H.245 message with 'alphanumeric = {"9"}' is missing in the second case, and Q931 message contains "Keypad IE = {9}"


It may be related to variations in H323 negotiation. All I can say the configuration did not change between calls, call was made from the same SIP client.

Avaya IP Office 403 was being called.  Calls coming from Avaya are always processed properly.
Comments:By: Evgeni (kukan) 2010-01-21 16:38:01.000-0600

Hi vmikhelson,

I'm fighting this problem for several weeks now.

I have simular setup with quintumDX dtmf=h245alphanumeric and expirience very simular issues in terms of h323.log "alphanumeric" "Keypad IE" log entries.
same behavior; when alphanumeric seen dtmf passed ok, when Keypad IE it fails.
I would say 80% dtmf fails and 20% passes.

I've tried all dtmf combinations both client/server/trunk w/o success.

I was running on * ver 1.6 and out of ideas downgraded to 1.4 now but the problem still exsist.

hope to find a solution soon!!!
By: Vladimir Mikhelson (vmikhelson) 2010-01-21 22:14:05.000-0600

Hi kukan,

Thank you for the update. It is two of us now!!

A quick update. Upgrade to Asterisk 1.6.0.21 did not change the behavior.

-Vladimir
By: Vladimir Mikhelson (vmikhelson) 2010-01-24 15:02:26.000-0600

Another noticeable symptom.

In case Asterisk establishes an outgoing OOH323 connection with described DTMF problems the connection hangs up at exactly 394 seconds. The end point on another end of the H.323 link is unaware about the connection drop and does not send a busy signal or otherwise indicate the conversation termination to a user.


[Jan 22 19:17:27] VERBOSE[19618] logger.c:     -- Called 352@172.17.135.2:1720
[Jan 22 19:17:27] VERBOSE[19618] logger.c:     -- OOH323/172.17.135.2:1720-10ec is ringing
[Jan 22 19:17:30] VERBOSE[19618] logger.c:     -- OOH323/172.17.135.2:1720-10ec answered SIP/435-00000001
[Jan 22 19:17:30] WARNING[19618] chan_ooh323.c: Don't know how to indicate condition 20 on ooh323c_o_3
[Jan 22 19:24:04] VERBOSE[19618] logger.c:     -- Executing [h@macro-dialout-trunk:1] Macro("SIP/435-00000001", "hangupcall,") in new stack
[Jan 22 19:24:04] VERBOSE[19618] logger.c:     -- Executing [s@macro-hangupcall:1] GotoIf("SIP/435-00000001", "1?skiprg") in new stack
[Jan 22 19:24:04] VERBOSE[19618] logger.c:     -- Goto (macro-hangupcall,s,4)



[Jan 22 19:24:22] VERBOSE[19639] logger.c:     -- Called 352@172.17.135.2:1720
[Jan 22 19:24:23] VERBOSE[19639] logger.c:     -- OOH323/172.17.135.2:1720-ee44 is ringing
[Jan 22 19:24:27] VERBOSE[19639] logger.c:     -- OOH323/172.17.135.2:1720-ee44 answered SIP/435-00000002
[Jan 22 19:24:27] WARNING[19639] chan_ooh323.c: Don't know how to indicate condition 20 on ooh323c_o_4
[Jan 22 19:31:01] VERBOSE[19639] logger.c:     -- Executing [h@macro-dialout-trunk:1] Macro("SIP/435-00000002", "hangupcall,") in new stack
[Jan 22 19:31:01] VERBOSE[19639] logger.c:     -- Executing [s@macro-hangupcall:1] GotoIf("SIP/435-00000002", "1?skiprg") in new stack
[Jan 22 19:31:01] VERBOSE[19639] logger.c:     -- Goto (macro-hangupcall,s,4)
By: Alexander Anikin (may213) 2010-01-24 16:48:45.000-0600

Hi,
can you reproduce bugs with latest trunk? I must to understand bugs are related to previous version of chan_ooh323 or current also?
By: Vladimir Mikhelson (vmikhelson) 2010-01-24 20:15:03.000-0600

May213,

I do not have a test box. The problems are observed in production.

I will be happy to try the newer version of chan_ooh323 if there is one available for Asterisk 1.6.0.21 which I currently run.

Please advise.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2010-01-28 23:33:37.000-0600

Found a workaround for the 394 seconds disconnect issue.

It is sufficient to send a DTMF from an Asterisk side of the connection shortly before it is expected to disconnect.

Sounds like a keep alive kind of a problem to me.
By: Vladimir Mikhelson (vmikhelson) 2010-02-04 13:24:13.000-0600

May213,

If you are still around please advise if I can run the current version on 1.6.0.21.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2010-02-18 11:54:08.000-0600

Just checking if there is any life here....
By: Alexander Anikin (may213) 2010-02-20 16:41:28.000-0600

Hi,

was in holiday last two weeks.
Pls, try attached patch, i hope it solve trouble with keypad dtmf duplcation.
Can't say anything about 394 sec trouble without tcpdump file with signalling of call or h323_log.
By: Vladimir Mikhelson (vmikhelson) 2010-02-21 16:48:39.000-0600

May213,

Tried the patch, ran into problems with 'make'.

Here are my steps:
1. wget http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-addons-1.6.0-current.tar.gz
2. ungzipped/untarred to /usr/src/asterisk-addons-1.6.0.4
3. cd /usr/src/asterisk-addons-1.6.0.4
4. wget 'https://issues.asterisk.org/file_download.php?file_id=25367&type=bug' -O - | patch -p0
5. make
6. received an error, details below.

Please advise.

I will submit h323_log with 394 sec. disconnect details later.

Thank you,
Vladimir



[root@pbx asterisk-addons-1.6.0.4]# wget 'https://issues.asterisk.org/file_download.php?file_id=25367&type=bug' -O - | patch -p0
--2010-02-21 16:32:57--  https://issues.asterisk.org/file_download.php?file_id=25367&type=bug
Resolving issues.asterisk.org... 76.164.171.231
Connecting to issues.asterisk.org|76.164.171.231|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1105 (1.1K) [text/plain]
Saving to: `STDOUT'

100%[======================================>] 1,105       --.-K/s   in 0s

2010-02-21 16:32:58 (3.83 MB/s) - `-' saved [1105/1105]

patching file channels/ooh323c/src/ooq931.c
[1]+  Exit 127                https://issues.asterisk.org/file_download.php?file_id=25367
[root@pbx asterisk-addons-1.6.0.4]# make
make[1]: Entering directory `/usr/src/asterisk-addons-1.6.0.4/channels'
  [CC] chan_ooh323.c -> chan_ooh323.o
  [CC] ooh323c/src/ooCmdChannel.c -> ooh323c/src/ooCmdChannel.o
  [CC] ooh323c/src/ooLogChan.c -> ooh323c/src/ooLogChan.o
  [CC] ooh323c/src/ooUtils.c -> ooh323c/src/ooUtils.o
  [CC] ooh323c/src/ooGkClient.c -> ooh323c/src/ooGkClient.o
  [CC] ooh323c/src/context.c -> ooh323c/src/context.o
  [CC] ooh323c/src/ooDateTime.c -> ooh323c/src/ooDateTime.o
  [CC] ooh323c/src/decode.c -> ooh323c/src/decode.o
  [CC] ooh323c/src/dlist.c -> ooh323c/src/dlist.o
  [CC] ooh323c/src/encode.c -> ooh323c/src/encode.o
  [CC] ooh323c/src/errmgmt.c -> ooh323c/src/errmgmt.o
  [CC] ooh323c/src/memheap.c -> ooh323c/src/memheap.o
  [CC] ooh323c/src/ootrace.c -> ooh323c/src/ootrace.o
  [CC] ooh323c/src/oochannels.c -> ooh323c/src/oochannels.o
  [CC] ooh323c/src/ooh245.c -> ooh323c/src/ooh245.o
  [CC] ooh323c/src/ooports.c -> ooh323c/src/ooports.o
  [CC] ooh323c/src/ooq931.c -> ooh323c/src/ooq931.o
ooh323c/src/ooq931.c:43: error: conflicting types for 'ooQ931Decode'
ooh323c/src/ooq931.h:338: error: previous declaration of 'ooQ931Decode' was here
make[1]: *** [ooh323c/src/ooq931.o] Error 1
make[1]: Leaving directory `/usr/src/asterisk-addons-1.6.0.4/channels'
make: *** [channels] Error 2
By: Vladimir Mikhelson (vmikhelson) 2010-02-24 22:23:36.000-0600

May213,

Here come the logs collected when ooh323 outbound calls were dropped:
1. Started Feb 23 10:48:36, dropped Feb 23 10:55:08 -- 392 seconds
2. Started Feb 23 10:55:25, dropped Feb 23 11:01:58 -- 392 seconds
3. Started Feb 23 11:02:12, ended normally Feb 23 11:04:34

Attached:
full.txt
h323_log_2010-02-23.txt

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2010-02-24 22:30:22.000-0600

May213,

As you see the ooh323 call drop occurs not exactly at 394 as I observed originally.

It can be 392, 393 or 394 seconds.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2010-03-02 13:29:50.000-0600

May213,

Here is the CLI output for a dropped OOH323 call with "ooh323 set debug"

Is it "ooh323_indicate 20 on call ooh323c_o_7" causing the trouble?

   -- Executing [352@from-internal:1] Macro("SIP/462-00000009", "user-callerid,                              SKIPTTL,") in new stack
   -- Executing [s@macro-user-callerid:1] Set("SIP/462-00000009", "AMPUSER=462"                              ) in new stack
   -- Executing [s@macro-user-callerid:2] GotoIf("SIP/462-00000009", "0?report"                              ) in new stack
   -- Executing [s@macro-user-callerid:3] ExecIf("SIP/462-00000009", "1?Set(REA                              LCALLERIDNUM=462)") in new stack
   -- Executing [s@macro-user-callerid:4] Set("SIP/462-00000009", "AMPUSER=462"                              ) in new stack
   -- Executing [s@macro-user-callerid:5] Set("SIP/462-00000009", "AMPUSERCIDNA                              ME=Vladimir -- HCI Office") in new stack
   -- Executing [s@macro-user-callerid:6] GotoIf("SIP/462-00000009", "0?report"                              ) in new stack
   -- Executing [s@macro-user-callerid:7] Set("SIP/462-00000009", "AMPUSERCID=4                              62") in new stack
   -- Executing [s@macro-user-callerid:8] Set("SIP/462-00000009", "CALLERID(all                              )="Vladimir -- HCI Office" <462>") in new stack
   -- Executing [s@macro-user-callerid:9] ExecIf("SIP/462-00000009", "0?Set(CHA                              NNEL(language)=)") in new stack
   -- Executing [s@macro-user-callerid:10] GotoIf("SIP/462-00000009", "1?contin                              ue") in new stack
   -- Goto (macro-user-callerid,s,19)
   -- Executing [s@macro-user-callerid:19] NoOp("SIP/462-00000009", "Using Call                              erID "Vladimir -- HCI Office" <462>") in new stack
   -- Executing [352@from-internal:2] Set("SIP/462-00000009", "INTRACOMPANYROUT                              E=YES") in new stack
   -- Executing [352@from-internal:3] Set("SIP/462-00000009", "_NODEST=") in ne                              w stack
   -- Executing [352@from-internal:4] Macro("SIP/462-00000009", "record-enable,                              462,OUT,") in new stack
   -- Executing [s@macro-record-enable:1] GotoIf("SIP/462-00000009", "1?check")                               in new stack
   -- Goto (macro-record-enable,s,4)
   -- Executing [s@macro-record-enable:4] ExecIf("SIP/462-00000009", "0?MacroEx                              it()") in new stack
   -- Executing [s@macro-record-enable:5] GotoIf("SIP/462-00000009", "0?Group:O                              UT") in new stack
   -- Goto (macro-record-enable,s,16)
   -- Executing [s@macro-record-enable:16] GotoIf("SIP/462-00000009", "0?IN") i                              n new stack
   -- Executing [s@macro-record-enable:17] ExecIf("SIP/462-00000009", "1?MacroE                              xit()") in new stack
   -- Executing [352@from-internal:5] Macro("SIP/462-00000009", "dialout-trunk,                              13,352,,") in new stack
   -- Executing [s@macro-dialout-trunk:1] Set("SIP/462-00000009", "DIAL_TRUNK=1                              3") in new stack
   -- Executing [s@macro-dialout-trunk:2] GosubIf("SIP/462-00000009", "0?sub-pi                              ncheck,s,1") in new stack
   -- Executing [s@macro-dialout-trunk:3] GotoIf("SIP/462-00000009", "0?disable                              trunk,1") in new stack
   -- Executing [s@macro-dialout-trunk:4] Set("SIP/462-00000009", "DIAL_NUMBER=                              352") in new stack
   -- Executing [s@macro-dialout-trunk:5] Set("SIP/462-00000009", "DIAL_TRUNK_O                              PTIONS=tr") in new stack
   -- Executing [s@macro-dialout-trunk:6] Set("SIP/462-00000009", "OUTBOUND_GRO                              UP=OUT_13") in new stack
   -- Executing [s@macro-dialout-trunk:7] GotoIf("SIP/462-00000009", "0?nomax")                               in new stack
   -- Executing [s@macro-dialout-trunk:8] GotoIf("SIP/462-00000009", "0?chanful                              l") in new stack
   -- Executing [s@macro-dialout-trunk:9] GotoIf("SIP/462-00000009", "1?skipout                              cid") in new stack
   -- Goto (macro-dialout-trunk,s,12)
   -- Executing [s@macro-dialout-trunk:12] ExecIf("SIP/462-00000009", "1?AGI(fi                              xlocalprefix)") in new stack
   -- Launched AGI Script /var/lib/asterisk/agi-bin/fixlocalprefix
   -- <SIP/462-00000009>AGI Script fixlocalprefix completed, returning 0
   -- Executing [s@macro-dialout-trunk:13] Set("SIP/462-00000009", "OUTNUM=352"                              ) in new stack
   -- Executing [s@macro-dialout-trunk:14] Set("SIP/462-00000009", "custom=AMP"                              ) in new stack
   -- Executing [s@macro-dialout-trunk:15] ExecIf("SIP/462-00000009", "0?Set(DI                              AL_TRUNK_OPTIONS=M(setmusic^)tr)") in new stack
   -- Executing [s@macro-dialout-trunk:16] Macro("SIP/462-00000009", "dialout-t                              runk-predial-hook,") in new stack
   -- Executing [s@macro-dialout-trunk-predial-hook:1] MacroExit("SIP/462-00000                              009", "") in new stack
   -- Executing [s@macro-dialout-trunk:17] GotoIf("SIP/462-00000009", "0?bypass                              ,1") in new stack
   -- Executing [s@macro-dialout-trunk:18] GotoIf("SIP/462-00000009", "1?custom                              trunk") in new stack
   -- Goto (macro-dialout-trunk,s,22)
   -- Executing [s@macro-dialout-trunk:22] Set("SIP/462-00000009", "pre_num=AMP                              :OOH323/") in new stack
   -- Executing [s@macro-dialout-trunk:23] Set("SIP/462-00000009", "the_num=OUT                              NUM") in new stack
   -- Executing [s@macro-dialout-trunk:24] Set("SIP/462-00000009", "post_num=/a                              vaya") in new stack
   -- Executing [s@macro-dialout-trunk:25] GotoIf("SIP/462-00000009", "1?outnum                              :skipoutnum") in new stack
   -- Goto (macro-dialout-trunk,s,26)
   -- Executing [s@macro-dialout-trunk:26] Set("SIP/462-00000009", "the_num=352                              ") in new stack
   -- Executing [s@macro-dialout-trunk:27] Dial("SIP/462-00000009", "OOH323/352                              /avaya,300,tr") in new stack
---   ooh323_request - data 352/avaya format 0x4 (ulaw)
---   ooh323_alloc
+++   ooh323_alloc
---   find_peer "avaya"
     comparing with "172.17.135.2"
     found matching peer
+++   find_peer "avaya"
---   ooh323_new - avaya
+++   h323_new
+++   ooh323_request
---   ooh323_call- 352/avaya
+++   ooh323_call
   -- Called 352/avaya
---   onNewCallCreated ooh323c_o_7
---   find_call
+++   find_call
setting callid number 462
Outgoing call avaya(ooh323c_o_7) - Codec prefs - (ulaw)
pbx*CLI>Adding capabilities to call(outgoing, ooh323c_o_7)
pbx*CLI>Adding g711 ulaw capability to call(outgoing, ooh323c_o_7)
---   configure_local_rtp
+++   configure_local_rtp
+++   onNewCallCreated ooh323c_o_7
---   setup_rtp_connection
---   find_call
+++   find_call
+++   setup_rtp_connection
--- onAlerting ooh323c_o_7
---   find_call
+++   find_call
+++ onAlerting ooh323c_o_7
   -- OOH323/avaya-bd1d is ringing
---   onCallEstablished ooh323c_o_7
---   find_call
+++   find_call
   -- OOH323/avaya-bd1d answered SIP/462-00000009
----- ooh323_indicate 20 on call ooh323c_o_7
[Mar  2 13:05:48] WARNING[10230]: chan_ooh323.c:1054 ooh323_indicate: Don't know                               how to indicate condition 20 on ooh323c_o_7
++++  ooh323_indicate 20 on ooh323c_o_7
+++   onCallEstablished ooh323c_o_7
---   close_rtp_connection
---   find_call
+++   find_call
+++   close_rtp_connection
---   onCallCleared ooh323c_o_7
---   find_call
+++   find_call
   -- Executing [h@macro-dialout-trunk:1] Macro("SIP/462-00000009", "hangupcall                              ,") in new stack
   -- Executing [s@macro-hangupcall:1] GotoIf("SIP/462-00000009", "1?skiprg") i                              n new stack
   -- Goto (macro-hangupcall,s,4)
   -- Executing [s@macro-hangupcall:4] GotoIf("SIP/462-00000009", "1?skipblkvm"                              ) in new stack
   -- Goto (macro-hangupcall,s,7)
   -- Executing [s@macro-hangupcall:7] GotoIf("SIP/462-00000009", "1?theend") i                              n new stack
   -- Goto (macro-hangupcall,s,9)
   -- Executing [s@macro-hangupcall:9] Hangup("SIP/462-00000009", "") in new st                              ack
 == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'SIP/462-000000                              09' in macro 'hangupcall'
 == Spawn extension (macro-dialout-trunk, h, 1) exited non-zero on 'SIP/462-000                              00009'
---   ooh323_hangup
   hanging avaya
+++   ooh323_hangup
 == Spawn extension (macro-dialout-trunk, s, 27) exited non-zero on 'SIP/462-00                              000009' in macro 'dialout-trunk'
 == Spawn extension (from-internal, 352, 5) exited non-zero on 'SIP/462-0000000                              9'
   -- Executing [h@from-internal:1] Macro("SIP/462-00000009", "hangupcall") in                               new stack
   -- Executing [s@macro-hangupcall:1] GotoIf("SIP/462-00000009", "1?skiprg") i                              n new stack
   -- Goto (macro-hangupcall,s,4)
   -- Executing [s@macro-hangupcall:4] GotoIf("SIP/462-00000009", "1?skipblkvm"                              ) in new stack
   -- Goto (macro-hangupcall,s,7)
   -- Executing [s@macro-hangupcall:7] GotoIf("SIP/462-00000009", "1?theend") i                              n new stack
   -- Goto (macro-hangupcall,s,9)
   -- Executing [s@macro-hangupcall:9] Hangup("SIP/462-00000009", "") in new st                              ack
 == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'SIP/462-000000                              09' in macro 'hangupcall'
 == Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/462-00000009'
---   ooh323_destroy
Destroying avaya
+++   ooh323_destroy
By: Vladimir Mikhelson (vmikhelson) 2010-03-02 13:53:02.000-0600

Here is another CLI output with "ooh323 set debug" DTMF sequence "*7" was dialing after the connection was established.

Asterisk upgraded to 1.6.0.25. Asterisk-addons upgraded to 1.6.0.4.

   -- Executing [1**352@from-internal:1] Macro("SIP/462-0000000c", "user-callerid,SKIPTTL,") in new stack
   -- Executing [s@macro-user-callerid:1] Set("SIP/462-0000000c", "AMPUSER=462") in new stack
   -- Executing [s@macro-user-callerid:2] GotoIf("SIP/462-0000000c", "0?report") in new stack
   -- Executing [s@macro-user-callerid:3] ExecIf("SIP/462-0000000c", "1?Set(REALCALLERIDNUM=462)") in new stack
   -- Executing [s@macro-user-callerid:4] Set("SIP/462-0000000c", "AMPUSER=462") in new stack
   -- Executing [s@macro-user-callerid:5] Set("SIP/462-0000000c", "AMPUSERCIDNAME=Vladimir -- HCI Office") in new stack
   -- Executing [s@macro-user-callerid:6] GotoIf("SIP/462-0000000c", "0?report") in new stack
   -- Executing [s@macro-user-callerid:7] Set("SIP/462-0000000c", "AMPUSERCID=462") in new stack
   -- Executing [s@macro-user-callerid:8] Set("SIP/462-0000000c", "CALLERID(all)="Vladimir -- HCI Office" <462>") in new stack
   -- Executing [s@macro-user-callerid:9] ExecIf("SIP/462-0000000c", "0?Set(CHANNEL(language)=)") in new stack
   -- Executing [s@macro-user-callerid:10] GotoIf("SIP/462-0000000c", "1?continue") in new stack
   -- Goto (macro-user-callerid,s,19)
   -- Executing [s@macro-user-callerid:19] NoOp("SIP/462-0000000c", "Using CallerID "Vladimir -- HCI Office" <462>") in new stack
   -- Executing [1**352@from-internal:2] Set("SIP/462-0000000c", "INTRACOMPANYROUTE=YES") in new stack
   -- Executing [1**352@from-internal:3] Set("SIP/462-0000000c", "_NODEST=") in new stack
   -- Executing [1**352@from-internal:4] Macro("SIP/462-0000000c", "record-enable,462,OUT,") in new stack
   -- Executing [s@macro-record-enable:1] GotoIf("SIP/462-0000000c", "1?check") in new stack
   -- Goto (macro-record-enable,s,4)
   -- Executing [s@macro-record-enable:4] ExecIf("SIP/462-0000000c", "0?MacroExit()") in new stack
   -- Executing [s@macro-record-enable:5] GotoIf("SIP/462-0000000c", "0?Group:OUT") in new stack
   -- Goto (macro-record-enable,s,16)
   -- Executing [s@macro-record-enable:16] GotoIf("SIP/462-0000000c", "0?IN") in new stack
   -- Executing [s@macro-record-enable:17] ExecIf("SIP/462-0000000c", "1?MacroExit()") in new stack
   -- Executing [1**352@from-internal:5] Macro("SIP/462-0000000c", "dialout-trunk,13,*352,,") in new stack
   -- Executing [s@macro-dialout-trunk:1] Set("SIP/462-0000000c", "DIAL_TRUNK=13") in new stack
   -- Executing [s@macro-dialout-trunk:2] GosubIf("SIP/462-0000000c", "0?sub-pincheck,s,1") in new stack
   -- Executing [s@macro-dialout-trunk:3] GotoIf("SIP/462-0000000c", "0?disabletrunk,1") in new stack
   -- Executing [s@macro-dialout-trunk:4] Set("SIP/462-0000000c", "DIAL_NUMBER=*352") in new stack
   -- Executing [s@macro-dialout-trunk:5] Set("SIP/462-0000000c", "DIAL_TRUNK_OPTIONS=tr") in new stack
   -- Executing [s@macro-dialout-trunk:6] Set("SIP/462-0000000c", "OUTBOUND_GROUP=OUT_13") in new stack
   -- Executing [s@macro-dialout-trunk:7] GotoIf("SIP/462-0000000c", "0?nomax") in new stack
   -- Executing [s@macro-dialout-trunk:8] GotoIf("SIP/462-0000000c", "0?chanfull") in new stack
   -- Executing [s@macro-dialout-trunk:9] GotoIf("SIP/462-0000000c", "1?skipoutcid") in new stack
   -- Goto (macro-dialout-trunk,s,12)
   -- Executing [s@macro-dialout-trunk:12] ExecIf("SIP/462-0000000c", "1?AGI(fixlocalprefix)") in new stack
   -- Launched AGI Script /var/lib/asterisk/agi-bin/fixlocalprefix
   -- <SIP/462-0000000c>AGI Script fixlocalprefix completed, returning 0
   -- Executing [s@macro-dialout-trunk:13] Set("SIP/462-0000000c", "OUTNUM=*352") in new stack
   -- Executing [s@macro-dialout-trunk:14] Set("SIP/462-0000000c", "custom=AMP") in new stack
   -- Executing [s@macro-dialout-trunk:15] ExecIf("SIP/462-0000000c", "0?Set(DIAL_TRUNK_OPTIONS=M(setmusic^)tr)") in new stack
   -- Executing [s@macro-dialout-trunk:16] Macro("SIP/462-0000000c", "dialout-trunk-predial-hook,") in new stack
   -- Executing [s@macro-dialout-trunk-predial-hook:1] MacroExit("SIP/462-0000000c", "") in new stack
   -- Executing [s@macro-dialout-trunk:17] GotoIf("SIP/462-0000000c", "0?bypass,1") in new stack
   -- Executing [s@macro-dialout-trunk:18] GotoIf("SIP/462-0000000c", "1?customtrunk") in new stack
   -- Goto (macro-dialout-trunk,s,22)
   -- Executing [s@macro-dialout-trunk:22] Set("SIP/462-0000000c", "pre_num=AMP:OOH323/") in new stack
   -- Executing [s@macro-dialout-trunk:23] Set("SIP/462-0000000c", "the_num=OUTNUM") in new stack
   -- Executing [s@macro-dialout-trunk:24] Set("SIP/462-0000000c", "post_num=/avaya") in new stack
   -- Executing [s@macro-dialout-trunk:25] GotoIf("SIP/462-0000000c", "1?outnum:skipoutnum") in new stack
   -- Goto (macro-dialout-trunk,s,26)
   -- Executing [s@macro-dialout-trunk:26] Set("SIP/462-0000000c", "the_num=*352") in new stack
   -- Executing [s@macro-dialout-trunk:27] Dial("SIP/462-0000000c", "OOH323/*352/avaya,300,tr") in new stack
---   ooh323_request - data *352/avaya format 0x4 (ulaw)
---   ooh323_alloc
+++   ooh323_alloc
---   find_peer "avaya"
     comparing with "172.17.135.2"
     found matching peer
+++   find_peer "avaya"
---   ooh323_new - avaya
+++   h323_new
+++   ooh323_request
---   ooh323_call- *352/avaya
---   onNewCallCreated ooh323c_o_10
---   find_call
+++   find_call
+++   ooh323_call
   -- Called *352/avaya
setting callid number 462
Outgoing call avaya(ooh323c_o_10) - Codec prefs - (ulaw)
       Adding capabilities to call(outgoing, ooh323c_o_10)
       Adding g711 ulaw capability to call(outgoing, ooh323c_o_10)
---   configure_local_rtp
+++   configure_local_rtp
+++   onNewCallCreated ooh323c_o_10
---   setup_rtp_connection
---   find_call
+++   find_call
+++   setup_rtp_connection
--- onAlerting ooh323c_o_10
---   find_call
+++   find_call
+++ onAlerting ooh323c_o_10
   -- OOH323/avaya-127b is ringing
---   onCallEstablished ooh323c_o_10
---   find_call
+++   find_call
   -- OOH323/avaya-127b answered SIP/462-0000000c
----- ooh323_indicate 20 on call ooh323c_o_10
[Mar  2 13:46:59] WARNING[10429]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10
++++  ooh323_indicate 20 on ooh323c_o_10
+++   onCallEstablished ooh323c_o_10
[Mar  2 13:47:04] DTMF[10429]: channel.c:2856 __ast_read: DTMF begin '*' received on SIP/462-0000000c
[Mar  2 13:47:04] DTMF[10429]: channel.c:2866 __ast_read: DTMF begin passthrough '*' on SIP/462-0000000c
---   ooh323_digit_begin
+++   ooh323_digit_begin
---   find_call
+++   find_call
[Mar  2 13:47:04] DTMF[10429]: channel.c:2784 __ast_read: DTMF end '*' received on OOH323/avaya-127b, duration 0 ms
[Mar  2 13:47:04] DTMF[10429]: channel.c:2810 __ast_read: DTMF begin emulation of '*' with duration 100 queued on OOH323/avaya-127b
----- ooh323_indicate 20 on call ooh323c_o_10
[Mar  2 13:47:04] WARNING[10429]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10
++++  ooh323_indicate 20 on ooh323c_o_10
----- ooh323_indicate 20 on call ooh323c_o_10
[Mar  2 13:47:04] WARNING[10429]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10
++++  ooh323_indicate 20 on ooh323c_o_10
[Mar  2 13:47:04] DTMF[10429]: channel.c:2933 __ast_read: DTMF end emulation of '*' queued on OOH323/avaya-127b
----- ooh323_indicate 20 on call ooh323c_o_10
[Mar  2 13:47:04] WARNING[10429]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10
++++  ooh323_indicate 20 on ooh323c_o_10
----- ooh323_indicate 20 on call ooh323c_o_10
[Mar  2 13:47:04] WARNING[10429]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10
++++  ooh323_indicate 20 on ooh323c_o_10
[Mar  2 13:47:04] DTMF[10429]: channel.c:2784 __ast_read: DTMF end '*' received on SIP/462-0000000c, duration 300 ms
[Mar  2 13:47:04] DTMF[10429]: channel.c:2824 __ast_read: DTMF end accepted with begin '*' on SIP/462-0000000c
[Mar  2 13:47:04] DTMF[10429]: channel.c:2840 __ast_read: DTMF end passthrough '*' on SIP/462-0000000c
---   ooh323_digit_end
+++   ooh323_digit_end
----- ooh323_indicate 20 on call ooh323c_o_10
[Mar  2 13:47:05] WARNING[10429]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10
++++  ooh323_indicate 20 on ooh323c_o_10
----- ooh323_indicate 20 on call ooh323c_o_10
[Mar  2 13:47:05] WARNING[10429]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10
++++  ooh323_indicate 20 on ooh323c_o_10
[Mar  2 13:47:10] DTMF[10429]: channel.c:2856 __ast_read: DTMF begin '7' received on SIP/462-0000000c
[Mar  2 13:47:10] DTMF[10429]: channel.c:2866 __ast_read: DTMF begin passthrough '7' on SIP/462-0000000c
---   ooh323_digit_begin
+++   ooh323_digit_begin
---   find_call
+++   find_call
[Mar  2 13:47:10] DTMF[10429]: channel.c:2784 __ast_read: DTMF end '7' received on OOH323/avaya-127b, duration 0 ms
[Mar  2 13:47:10] DTMF[10429]: channel.c:2810 __ast_read: DTMF begin emulation of '7' with duration 100 queued on OOH323/avaya-127b
----- ooh323_indicate 20 on call ooh323c_o_10
[Mar  2 13:47:10] WARNING[10429]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10
++++  ooh323_indicate 20 on ooh323c_o_10
----- ooh323_indicate 20 on call ooh323c_o_10
[Mar  2 13:47:10] WARNING[10429]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10
++++  ooh323_indicate 20 on ooh323c_o_10
[Mar  2 13:47:10] DTMF[10429]: channel.c:2933 __ast_read: DTMF end emulation of '7' queued on OOH323/avaya-127b
----- ooh323_indicate 20 on call ooh323c_o_10
[Mar  2 13:47:10] WARNING[10429]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10
++++  ooh323_indicate 20 on ooh323c_o_10
[Mar  2 13:47:10] DTMF[10429]: channel.c:2784 __ast_read: DTMF end '7' received on SIP/462-0000000c, duration 300 ms
[Mar  2 13:47:10] DTMF[10429]: channel.c:2824 __ast_read: DTMF end accepted with begin '7' on SIP/462-0000000c
[Mar  2 13:47:10] DTMF[10429]: channel.c:2840 __ast_read: DTMF end passthrough '7' on SIP/462-0000000c
----- ooh323_indicate 20 on call ooh323c_o_10
[Mar  2 13:47:10] WARNING[10429]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10
++++  ooh323_indicate 20 on ooh323c_o_10
----- ooh323_indicate 20 on call ooh323c_o_10
[Mar  2 13:47:34] WARNING[10429]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10
++++  ooh323_indicate 20 on ooh323c_o_10
   -- Executing [h@macro-dialout-trunk:1] Macro("SIP/462-0000000c", "hangupcall,") in new stack
   -- Executing [s@macro-hangupcall:1] GotoIf("SIP/462-0000000c", "1?skiprg") in new stack
   -- Goto (macro-hangupcall,s,4)
   -- Executing [s@macro-hangupcall:4] GotoIf("SIP/462-0000000c", "1?skipblkvm") in new stack
   -- Goto (macro-hangupcall,s,7)
   -- Executing [s@macro-hangupcall:7] GotoIf("SIP/462-0000000c", "1?theend") in new stack
   -- Goto (macro-hangupcall,s,9)
   -- Executing [s@macro-hangupcall:9] Hangup("SIP/462-0000000c", "") in new stack
 == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'SIP/462-0000000c' in macro 'hangupcall'
---   ooh323_hangup
   hanging avaya
+++   ooh323_hangup
 == Spawn extension (macro-dialout-trunk, s, 27) exited non-zero on 'SIP/462-0000000c' in macro 'dialout-trunk'
 == Spawn extension (from-internal, 1**352, 5) exited non-zero on 'SIP/462-0000000c'
---   close_rtp_connection
---   find_call
+++   find_call
+++   close_rtp_connection
---   onCallCleared ooh323c_o_10
---   find_call
+++   find_call
+++   onCallCleared
---   ooh323_destroy
Destroying avaya
+++   ooh323_destroy
By: Alexander Anikin (may213) 2010-03-02 16:28:52.000-0600

Vladimir,

392 sec call is related to there is no reply from ooh323 channel to avaya on roundTripDelayRequest which avaya send every 6 sec. I can't fix problem here due to policy that disable make new functionality in not current version but i can fix it on current trunk. For more detail please contact with me in IRC.
But i think that this behaivour of avaya is configurable because i known people who use ooh323 with avaya without trouble, i seen their ooh323 channel log and don't see any roundTripRequests.

below example of roundTripReqPacket:

10:49:38:620  Tunneled H.245 Message = {
10:49:38:620  Decoding 1 tunneled H245 message. (outgoing, ooh323c_o_4)
10:49:38:620     request = {
10:49:38:620        roundTripDelayRequest = {
10:49:38:620           sequenceNumber = {
10:49:38:621              0
10:49:38:621           }
10:49:38:622        }
10:49:38:622     }
10:49:38:622  }


By: Alexander Anikin (may213) 2010-03-02 16:37:43.000-0600

Vladimir,

i've attached corrected dtfm-duplicate patch (ooh323-dtmf-duplicate-2.patch), please try this patch.
By: Vladimir Mikhelson (vmikhelson) 2010-03-02 22:09:24.000-0600

Re: 0118798

May213,

Thank you for the disconnect issue analysis. I have captured several packet traces which definitely showed the H.245 Round TripDelayRequest messages being ignored by Asterisk's H323 channel.

I do not think fixing this falls into a "new feature request" category. It is a major oversight in the channel design. See http://www.packetizer.com/in/q43.html

The inner workings of the underlying H323 protocol are mostly not configurable on Avaya IPOffice 403. And even if they were I would not suggest to disable the required portion of the protocol.

In some implementations, like for example Cisco ATA 188, the feature is not enabled by default but is easily settable.

If you still think that IRC is a better place to discuss fixing this issue please let me know how I can reach you there.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2010-03-02 23:32:50.000-0600

Re: 118799

May213,

It works better with patch.

Specifically, I do not see "WARNING[10429]: chan_ooh323.c:1054 ooh323_indicate: Don't know how to indicate condition 20 on ooh323c_o_10" in the middle of DTMF dialing. That allows to dial faster without loosing digits.

It seems like calls originated on DAHDI lines work as they should with no missing digits or repetitions.

Calls originated on SIP lines repeat almost every digit 2 times except "*" which is passed correctly.

Please take a look at the Avaya IPOffice log. The string dialed was "*7352#"

 18975mS CMLineRx: v=9
           CMCapabilityAck
           Line: type=IPLine 9
           Call: lid=9 id=1 in=2
           Product Unknown
  19002mS PRN: Unhandled Facility
  21136mS CMLineRx: v=9
           CMInformation
           Line: type=IPLine 9
           Call: lid=9 id=1 in=2
           Keypad[*]
           Product Unknown
           Display [ThinkPad T60p]
  22789mS CMLineRx: v=9
           CMInformation
           Line: type=IPLine 9
           Call: lid=9 id=1 in=2
           Keypad[7]
           Product Unknown
           Display [ThinkPad T60p]
  31836mS CMLineRx: v=9
           CMInformation
           Line: type=IPLine 9
           Call: lid=9 id=1 in=2
           Keypad[3]
           Product Unknown
           Display [ThinkPad T60p]
  32111mS CMLineRx: v=9
           CMInformation
           Line: type=IPLine 9
           Call: lid=9 id=1 in=2
           Keypad[3]
           Product Unknown
           Display [ThinkPad T60p]
  32673mS CMLineRx: v=9
           CMInformation
           Line: type=IPLine 9
           Call: lid=9 id=1 in=2
           Keypad[5]
           Product Unknown
           Display [ThinkPad T60p]
  32946mS CMLineRx: v=9
           CMInformation
           Line: type=IPLine 9
           Call: lid=9 id=1 in=2
           Keypad[5]
           Product Unknown
           Display [ThinkPad T60p]
  33882mS CMLineRx: v=9
           CMInformation
           Line: type=IPLine 9
           Call: lid=9 id=1 in=2
           Keypad[2]
           Product Unknown
           Display [ThinkPad T60p]
  34154mS CMLineRx: v=9
           CMInformation
           Line: type=IPLine 9
           Call: lid=9 id=1 in=2
           Keypad[2]
           Product Unknown
           Display [ThinkPad T60p]
  35616mS CMLineRx: v=9
           CMInformation
           Line: type=IPLine 9
           Call: lid=9 id=1 in=2
           Keypad[#]
           Product Unknown
           Display [ThinkPad T60p]
  35884mS CMLineRx: v=9
           CMInformation
           Line: type=IPLine 9
           Call: lid=9 id=1 in=2
           Keypad[#]
           Product Unknown
           Display [ThinkPad T60p]

Thank you,
Vladimir
By: Alexander Anikin (may213) 2010-03-03 05:05:55.000-0600

Vladimir, please attach ooh323_log file with dtmf duplication with last patched ooh323 channel. i can't see too much from avaya log.
By: Vladimir Mikhelson (vmikhelson) 2010-03-03 11:55:17.000-0600

May213,

h323_log-call4.txt attached. The call was made from a SIP softphone. Intended sequence was "87*7352ASTERISK-349ASTERISK-883"

Please let me know if you need more samples. Unfortunately the problem is intermittent.

More testing from DAHDI shows consistently reliable DTMF recognition via OOH323 channel.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2010-03-03 12:49:58.000-0600

May213,

The problem with SIP may have been related to the specific sophtphone (Zoiper) I was using. I am trying with another one (Minipax) now and everything is working fine.

Couple of notes. Sometimes DTMF goes out on the h323 channel as H245 "alphanumeric =" sometimes as Q.931 "keypad ie =" In case of "keypad ie" sometimes an extra characters follow a digit dialed in h323_log. For example, "7..", "8cZ.PcZ." It may be a log issue though.

As DTMF issue seems to be under control with your patch we should now tackle the disconnect since it makes the Asterisk / Avaya channel pretty useless. Do you want me to open another case?

Now couple questions. Is this patch going to make into addons 1.6.0.5? Can ooh323c version 0.9 from http://sourceforge.net/projects/ooh323c/files/ be used since we are still on v0.8.3.

Thank you,
Vladimir
By: Alexander Anikin (may213) 2010-03-03 17:27:30.000-0600

Vladimir,

i did not look sources of ooh323 version 0.9 while but i think it still not usable in asterisk due to single thread model of ooh323c stack and this model was general reason for making rework channel with modifications of stack code more than asterisk channel code. It's possible that Objective Systems changed threading model of their stack then implementation channel driver based on 0.9 code will new and big work and will be finished with new version of chan_ooh323 ;)
Also i don't see what serious enhancement is needed for signalling part of code.

IMHO, chan_ooh323 versions before current trunk aren't usable for production due to 1thread and synchronous stack code. Any trouble with network proccesing cause delay in ooh323 stack processing. These delay can be very big for real-time. I don't speak about many memory leaks and other bugs in ooh323 code.
By: Alexander Anikin (may213) 2010-03-03 17:55:17.000-0600

Vladimir, pls try latest patch, i hope it solve log issue.
And i confirm about new case  we can close this case and continue work on roundtrip processing in new case subjected to this problem.


By: Vladimir Mikhelson (vmikhelson) 2010-03-03 19:11:37.000-0600

Re: 0118916

May213,

The reason I asked about 0.9 was their "What is New" listed some interesting enhancements. There was no talk about multi-threading though.

Since they are H.323 version 6 compliant I thought maybe the RoundTripReqPacket processing was in there.

Unfortunately I cannot use the current trunk since the latest version available with AsteriskNOW is 1.6.0.25.

Is it practical to expect that Addons 1.6.0.5 will have any of your enhancements included?

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2010-03-03 19:17:33.000-0600

Re: 0118920

May213,

While applying the new patch I received the following messages and assumed that the patch was cumulative. Should I redownolad the source from SVN?

patching file channels/ooh323c/src/oochannels.c
Reversed (or previously applied) patch detected!  Assume -R? [n] y
patching file channels/ooh323c/src/ooq931.c
Reversed (or previously applied) patch detected!  Assume -R? [n] y
Hunk #2 FAILED at 162.
1 out of 3 hunks FAILED -- saving rejects to file channels/ooh323c/src/ooq931.c.rej
patching file channels/ooh323c/src/ooq931.h
Reversed (or previously applied) patch detected!  Assume -R? [n] y

Thank you,
Vladimir
By: Alexander Anikin (may213) 2010-03-04 05:09:24.000-0600

Vladimir,

you're right about cumulative patch, pls reget svn sources and patch with last patch.

about enhancement. i will include requested enhancements for older (before trunk) versions if it will no major enhancement and if they will applied easy to these versions.

i think that patch for roundrequest will small and approach for both trunk and 1.6.


By: Vladimir Mikhelson (vmikhelson) 2010-03-06 01:25:44.000-0600

May213,

I have opened the new case ASTERISK-1674976 regarding the channel disconnect issue.

Hope you will resolve it soon.

I am ready for testing.

Thank you for your work,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2010-03-06 01:30:14.000-0600

May213,

I was testing the new patch for two (2) days with no problems. Both DTMF and log work fine. No noticeable glitches.

Thank you,
Vladimir
By: Alexander Anikin (may213) 2010-03-06 18:31:02.000-0600

Vladimir,

thank you for testing, i close this issue.
By: Digium Subversion (svnbot) 2010-03-06 18:32:18.000-0600

Repository: asterisk-addons
Revision: 1092

U   branches/1.6.0/channels/ooh323c/src/oochannels.c
U   branches/1.6.0/channels/ooh323c/src/ooq931.c
U   branches/1.6.0/channels/ooh323c/src/ooq931.h

------------------------------------------------------------------------
r1092 | may | 2010-03-06 18:32:16 -0600 (Sat, 06 Mar 2010) | 14 lines

added docallbacks flag in q931decode

backport from trunk rev 239037
add docallbacks flag in q931decode function because
we must do callbacks when we decode received q931 packet and
we must don't when we print sended q931.

(closes issue ASTERISK-15483)
Reported by: vmikhelson
Patches:
     ooh323-dtmf-duplicate-3.patch uploaded by may213 (license 454)
Tested by: vmikhelson


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

http://svn.digium.com/view/asterisk-addons?view=rev&revision=1092