[Asterisk-Users] Segmentation fault with chan_oh323

[Michael Ulitskiy]

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