Re: [Asterisk-Users] asterisk-ooh323, asterisk 1.2.6 and netmeeting
On 04/06/06 05:36 Avi Miller said the following: If I dialled from a SIP phone on Asterisk 1 to the Phone on the Avaya, it worked fine. If I dialled from a phone on the Avaya, the SIP phone would ring, but the call would drop as soon as it was answered because of codec negotiation failure. absolutely the same symptoms. my architecture is as follows: OHPHONE Asterisk SIP Client calls from the SIP client to OHPHONE work fine with audio et al passed both ways. calls from OH PHONE to the SIP client dont. just after the SIP client answers, the call dies. i tried your suggestion of removing all disallow and allow lines in ooh323.conf, but with that, even calls from SIP to H323 (which were working) stop working. it does lend credence to the theory that it's a codec nego issue though. the debug and verbose output of a failed H323 to SIP call is below (6262 is the SIP exten and 6996 is the OHPHONE H.323): Apr 6 13:59:37 VERBOSE[201] logger.c: -- Executing Dial(OOH323/192.168.1.169-0361, SIP/6262|40|owWtT) in new stack Apr 6 13:59:37 DEBUG[201] chan_sip.c: Setting NAT on RTP to 0 Apr 6 13:59:37 DEBUG[201] chan_sip.c: Setting NAT on VRTP to 0 Apr 6 13:59:37 DEBUG[201] acl.c: # Testing 192.168.1.164 with 192.168.1.0 Apr 6 13:59:37 DEBUG[201] chan_sip.c: Outgoing Call for 6262 Apr 6 13:59:37 VERBOSE[201] logger.c: -- Called 6262 Apr 6 13:59:37 DEBUG[201] chan_sip.c: (Provisional) Stopping retransmission (but retaining packet) on '[EMAIL PROTECTED]' Request 102: Found Apr 6 13:59:37 VERBOSE[201] logger.c: -- SIP/6262-960b is ringing Apr 6 13:59:37 DEBUG[201] channel.c: Driver for channel 'OOH323/192.168.1.169-0361' does not support indication 3, emulating it Apr 6 13:59:37 DEBUG[201] channel.c: Prodding channel 'OOH323/192.168.1.169-0361' Apr 6 13:59:37 DEBUG[201] channel.c: Scheduling timer at 160 sample intervals Apr 6 13:59:37 DEBUG[201] chan_sip.c: Auto destroying call '[EMAIL PROTECTED]' Apr 6 13:59:37 DEBUG[201] acl.c: # Testing 192.168.1.151 with 192.168.1.0 Apr 6 13:59:37 DEBUG[201] chan_sip.c: SIP message could not be handled, bad request: [EMAIL PROTECTED] Apr 6 13:59:38 DEBUG[201] chan_sip.c: Acked pending invite 102 Apr 6 13:59:38 DEBUG[201] chan_sip.c: Stopping retransmission on '[EMAIL PROTECTED]' of Request 102: Match Found Apr 6 13:59:38 DEBUG[201] chan_sip.c: build_route: Contact hop: sip:[EMAIL PROTECTED]:5060 Apr 6 13:59:38 VERBOSE[201] logger.c: -- SIP/6262-960b answered OOH323/192.168.1.169-0361 Apr 6 13:59:38 WARNING[201] src/chan_h323.c: Don't know how to indicate condition -1 on ooh323c_7 Apr 6 13:59:38 DEBUG[201] channel.c: Scheduling timer at 0 sample intervals Apr 6 13:59:38 VERBOSE[201] logger.c: -- Attempting native bridge of OOH323/192.168.1.169-0361 and SIP/6262-960b Apr 6 13:59:38 DEBUG[201] channel.c: Didn't get a frame from channel: OOH323/192.168.1.169-0361 Apr 6 13:59:38 DEBUG[201] channel.c: Bridge stops bridging channels OOH323/192.168.1.169-0361 and SIP/6262-960b Apr 6 13:59:38 DEBUG[201] chan_sip.c: update_call_counter(6262) - decrement call limit counter Apr 6 13:59:38 DEBUG[201] app_dial.c: Exiting with DIALSTATUS=ANSWER. Apr 6 13:59:38 VERBOSE[201] logger.c: == Spawn extension (macro-stdexten, s-DIAL, 1) exited non-zero on 'OOH323/192.168.1.169-0361' in macro 'stdexten' Apr 6 13:59:38 VERBOSE[201] logger.c: == Spawn extension (macro-stdexten, s-DIAL, 1) exited non-zero on 'OOH323/192.168.1.169-0361' Apr 6 13:59:39 DEBUG[201] chan_sip.c: Stopping retransmission on '[EMAIL PROTECTED]' of Request 103: Match Found Apr 6 13:59:40 DEBUG[201] chan_sip.c: Auto destroying call '[EMAIL PROTECTED]' note that channel.c says it didnt get a frame from OHPHONE and that it subsequent stops bridging the channels. now to go figure out why this is so. any pointers would be appreciated. -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] asterisk-ooh323, asterisk 1.2.6 and netmeeting
Dinesh Nair wrote: the symptoms are that calls from a SIP client to NetMeeting rings on NetMeeting, but upon answering the call in NetMeeting, no audio is passed between the two. eventually, the call times out and hangs up. I had a similar problem connecting Asterisk to an Avaya IP403 via OOH323: In the end, I removed all the disallow=all and allow=codec lines in Asterisk. This seems to have allowed the two systems to overcome the codec negotiation problems they were having and proceed with actual audio transfer. :) I have no idea if this is related, but I thought I'd just throw that out there, if only for testing purposes. cYa, Avi -- National Manager - Special Projects Sydney / Melbourne / Canberra / Hobart / London / 2/340 Gore Street T: +61 (0) 3 9486 0411 Fitzroy, VIC F: +61 (0) 3 9486 0611 3065 W: http://www.squiz.net/ . Open Source - Own it - Squiz.net ./ ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] asterisk-ooh323, asterisk 1.2.6 and netmeeting
On 04/05/06 13:52 Dinesh Nair said the following: On 04/05/06 13:17 Avi Miller said the following: I had a similar problem connecting Asterisk to an Avaya IP403 via OOH323: In the end, I removed all the disallow=all and allow=codec lines in Asterisk. This seems to have allowed the two systems to overcome the codec negotiation problems they were having and proceed with actual audio transfer. :) we'll try with this, but further testing reveals that the H.323 negotiation over port 1720 happens fine, with H.245 then being done over another TCP port tuple. we didnt see the RTP port session being created/negotiated. i'm assuming from the asterisk-ooh323 docs that it uses asterisk's builtin RTP mechanism, and this should be over UDP. there were no UDP packets being exchanged at all. we will try your suggestion however. more tests reveal that with ohphone, calls from SIP-ohphone work fine with audio passed both ways. however when ohphone calls a SIP device, the call is hungup when the SIP device answers. obviously, SIP-IAX and SIP-SIP calls work fine, so there's nothing wrong with the SIP device per se. -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] asterisk-ooh323, asterisk 1.2.6 and netmeeting
has anyone managed to get these three beasties to work together ? we're using ooh323 from asterisk-addons-1.2.2, asterisk 1.2.6 and microsoft netmeeting default from windows xp. the symptoms are that calls from a SIP client to NetMeeting rings on NetMeeting, but upon answering the call in NetMeeting, no audio is passed between the two. eventually, the call times out and hangs up. on a reverse call from NetMeeting to the SIP client, the SIP client rings and when it's answered, the same thing happens, i.e. no audio is passed. the same happens when netmeeting calls an IVR-related app like Directory, SayDigits et al. my ooh323.conf file is attached. also, here's the asterisk console output with ooh323 debug on: NetMeeting H323 to SIP --- onNewCallCreated ooh323c_7 +++ onNewCallCreated ooh323c_7 --- ooh323_onReceivedSetup ooh323c_7 --- find_user +++ find_user Adding capabilities to call(incoming, ooh323c_7) --- configure_local_rtp +++ configure_local_rtp +++ ooh323_onReceivedSetup - Determined context default, extension 6384 --- onAlerting ooh323c_7 --- find_call +++ find_call +++ onAlerting ooh323c_7 -- Executing Dial(OOH323/mms mms-fa6a, SIP/6384|40|owWtT) in new stack -- Called 6384 -- SIP/6384-d9f2 is ringing - ooh323_indicate 3 on call ooh323c_7 ooh323_indicate 3 on ooh323c_7 -- SIP/6384-d9f2 answered OOH323/mms mms-fa6a - ooh323_indicate -1 on call ooh323c_7 Apr 4 18:16:34 WARNING[3021]: src/chan_h323.c:952 ooh323_indicate: Don't know how to indicate condition -1 on ooh323c_7 ooh323_indicate -1 on ooh323c_7 --- ooh323_answer +++ ooh323_answer -- Attempting native bridge of OOH323/mms mms-fa6a and SIP/6384-d9f2 --- onCallEstablished ooh323c_7 --- find_call +++ find_call +++ onCallEstablished ooh323c_7 --- onCallCleared ooh323c_7 --- find_call +++ find_call == Spawn extension (macro-stdexten, s-DIAL, 1) exited non-zero on 'OOH323/mms mms-fa6a' in macro 'stdexten' == Spawn extension (macro-stdexten, s-DIAL, 1) exited non-zero on 'OOH323/mms mms-fa6a' --- ooh323_hangup hanging mms mms +++ ooh323_hangup --- ooh323_destroy Destroying mms mms +++ ooh323_destroy SIP to H323 NetMeeting -- Executing Dial(SIP/6384-b575, OOH323/6985|40|owWtT) in new stack --- ooh323_request - data 6985 format 0x8 (alaw) --- find_peer +++ find_peer +++ ooh323_request --- ooh323_call- 6985 +++ ooh323_call -- Called 6985 --- onNewCallCreated ooh323c_o_3 --- find_call +++ find_call setting callid number 6384 Outgoing call 6985(ooh323c_o_3) - Codec prefs - (ulaw) Adding capabilities to call(outgoing, ooh323c_o_3) Adding g711 ulaw capability to call(outgoing, ooh323c_o_3) --- configure_local_rtp +++ configure_local_rtp +++ onNewCallCreated ooh323c_o_3 --- onAlerting ooh323c_o_3 --- find_call +++ find_call +++ onAlerting ooh323c_o_3 -- OOH323/6985-e521 is ringing --- onCallEstablished ooh323c_o_3 --- find_call +++ find_call +++ onCallEstablished ooh323c_o_3 -- OOH323/6985-e521 answered SIP/6384-b575 -- Attempting native bridge of SIP/6384-b575 and OOH323/6985-e521 --- ooh323_hangup hanging 6985 +++ ooh323_hangup == Spawn extension (macro-stdexten, s-DIAL, 1) exited non-zero on 'SIP/6384-b575' in macro 'stdexten' == Spawn extension (macro-stdexten, s-DIAL, 1) exited non-zero on 'SIP/6384-b575' --- onCallCleared ooh323c_o_3 --- find_call +++ find_call +++ onCallCleared --- ooh323_destroy Destroying 6985 +++ ooh323_destroy -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ [general] h323id=QubeTalkECS callerid=QubeTalkECS gatekeeper=DISABLE ; DISCOVER or IP addy logfile=/var/spool/asterisk/log/h323_log gateway=no ; or yes faststart=yes h245tunneling=yes port=1720 bindaddr=0.0.0.0 context=default [6970] ip=192.168.1.160
Re: [Asterisk-Users] asterisk-ooh323, asterisk 1.2.6 and netmeeting
On 04/05/06 13:17 Avi Miller said the following: I had a similar problem connecting Asterisk to an Avaya IP403 via OOH323: In the end, I removed all the disallow=all and allow=codec lines in Asterisk. This seems to have allowed the two systems to overcome the codec negotiation problems they were having and proceed with actual audio transfer. :) we'll try with this, but further testing reveals that the H.323 negotiation over port 1720 happens fine, with H.245 then being done over another TCP port tuple. we didnt see the RTP port session being created/negotiated. i'm assuming from the asterisk-ooh323 docs that it uses asterisk's builtin RTP mechanism, and this should be over UDP. there were no UDP packets being exchanged at all. we will try your suggestion however. -- Regards, /\_/\ All dogs go to heaven. [EMAIL PROTECTED](0 0)http://www.alphaque.com/ +==oOO--(_)--OOo==+ | for a in past present future; do| | for b in clients employers associates relatives neighbours pets; do | | echo The opinions here in no way reflect the opinions of my $a $b. | | done; done | +=+ ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] asterisk-ooh323, asterisk 1.2.6 and netmeeting
Dinesh Nair wrote: more tests reveal that with ohphone, calls from SIP-ohphone work fine with audio passed both ways. however when ohphone calls a SIP device, the call is hungup when the SIP device answers. This was sort of my problem too. I have two Asterisk servers, with an IAX2 trunk between them: Phone - Asterisk 1 - IAX - Asterisk 2 - H323 - Avaya IP403 - Phone If I dialled from a SIP phone on Asterisk 1 to the Phone on the Avaya, it worked fine. If I dialled from a phone on the Avaya, the SIP phone would ring, but the call would drop as soon as it was answered because of codec negotiation failure. After removing the various disallow= and allow= lines, the codec negotation is now successful in both directions. cYa, Avi -- National Manager - Special Projects Sydney / Melbourne / Canberra / Hobart / London / 2/340 Gore Street T: +61 (0) 3 9486 0411 Fitzroy, VIC F: +61 (0) 3 9486 0611 3065 W: http://www.squiz.net/ . Open Source - Own it - Squiz.net ./ ___ --Bandwidth and Colocation provided by Easynews.com -- Asterisk-Users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
