That is another problem I hope the developers would pay attention to. ulaw codec segfaulting when it is used by h323 side of connection for both incoming and outgoing calls. At least with chan_oh323. If I set alaw codec for h323 it works fine regardless of codec on SIP side.
Michael On Thursday 17 July 2003 03:36 am, Mark Thompson wrote: > This also happened to me when I was using the same codec with both oh323 > and SIP, if I forced it to alaw on oh323 and ulaw on SIP the connection > worked. I also tried h323 instead of oh323 which works okay but you have > to use earlier versions of pwlib and openh323. > Mark > > -----Original Message----- > From: Michael Ulitskiy [mailto:[EMAIL PROTECTED] > Sent: 16 July 2003 23:44 > To: [EMAIL PROTECTED] > Subject: [Asterisk-Users] Segmentation fault with chan_oh323 > > > Hi, > > I'm trying to interconnect sip and h323 endpoints using asterisk and > asterisk crashes with segmentation fault whenever h323 > connection needs to be established. It registers with gatekeeper ok > though. Here are the symptoms. If the call initiated by SIP device, > asterisk replies to it "Trying" and then silently crashes (it launched > as asterisk -vvvvcd). In debug log I can see the following: Jul 16 > 18:11:52 DEBUG[196621]: File pbx.c, Line 1123 (pbx_extension_helper): > Launching 'Dial' Jul 16 18:11:52 DEBUG[196621]: File chan_oh323.c, Line > 1393 (oh323_request): In oh323_request. Jul 16 18:11:52 DEBUG[196621]: > File chan_oh323.c, Line 1394 (oh323_request): type=oh323, format=4, > data=<phone number>. Jul 16 18:11:52 DEBUG[196621]: File chan_oh323.c, > Line 1440 (oh323_request): Created new call structure 0 (2428 bytes). > That's it. If the call initiated by H323 device, then I see > *CLI> > WrapH323Connection::WrapH323Connection: WrapH323Connection created. > Segmentation fault and debug log shows: Jul 16 18:33:12 DEBUG[196621]: > File chan_oh323.c, Line 2141 (init_h323_connection): In > init_h323_connection... Jul 16 18:33:12 DEBUG[196621]: File > chan_oh323.c, Line 2180 (init_h323_connection): Created new call > structure 0 (2428 bytes). Jul 16 18:33:12 DEBUG[196621]: File > chan_oh323.c, Line 1527 (copy_call_details): --- CALL DETAILS --- Jul 16 > 18:33:12 DEBUG[196621]: File chan_oh323.c, Line 1528 > (copy_call_details): call_token = ip$192.168.0.227:5018/92 Jul 16 > 18:33:12 DEBUG[196621]: File chan_oh323.c, Line 1529 > (copy_call_details): call_source_alias = tnt [192.168.0.227] > Jul 16 18:33:12 DEBUG[196621]: File chan_oh323.c, Line 1530 > (copy_call_details): call_dest_alias = 12125551234 12125551234 > ip$192.168.0.70:1720 > Jul 16 18:33:12 DEBUG[196621]: File chan_oh323.c, Line 1531 > (copy_call_details): call_source_e164 = phone number Jul 16 18:33:12 > DEBUG[196621]: File chan_oh323.c, Line 1532 (copy_call_details): > call_dest_e164 = 12125551234 That's it. And gatekeeper log shows that > after normal ARQ-ACF exchange originating device immediately sent DRQ. > If anybody knows a reason for this (and the way to fix it of course ;)), > I'd appreciate if you let me know. If you need any additional info to > troubleshoot it, let me know too. Thank a lot. > > Michael > > _______________________________________________ > Asterisk-Users mailing list > [EMAIL PROTECTED] > http://lists.digium.com/mailman/listinfo/asterisk-users > > _______________________________________________ > Asterisk-Users mailing list > [EMAIL PROTECTED] > http://lists.digium.com/mailman/listinfo/asterisk-users > _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
