[Asterisk-Users] Segmentation fault with chan_oh323

Michael Ulitskiy mulitskiy at acedsl.com
Thu Jul 17 13:10:10 MST 2003


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:mulitskiy at acedsl.com] 
> Sent: 16 July 2003 23:44
> To: asterisk-users at lists.digium.com
> 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
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> 
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
> 




More information about the asterisk-users mailing list