Review Board 1.7.16

Fix SEGFAULT in remote_bridge_loop after a SIP to SIP attended transfer with external IAX2 or DAHDI call

Review Request #1128 - Created Feb. 28, 2011 and submitted

Alec Davis
When an external call originating from IAX2 a SEGFAULT (or from DAHDI a BAD MAGIC NUMBER) happens as the transfer between 2 internal SIP extensions completes.

Initially before the transfer is complete and the before masquerade happens the glue0 and glue1 pointers are pointing to update_peer (which is a reference to sip_set_rtp_peer)
Then after transfer completes and masquerading happens, glue0 and glue1 don't change, but the channel is now an IAX channel.
calling glue0->update_peer(c0, NULL, NULL, NULL, 0, 0)) is now fatal.

If the channel condition is one of the following after breaking out of the loop, don't try to update_peer
 2). cx->tech_pvt != pvtx
 3). gluex != ast_rtp_instance_get_glue(c0->tech->type))

Multiple transfers for now nearly 2 weeks, on a production box handling ~ 800 calls a day. runs on a server provided by Digium, Inc. and uses bandwidth donated to the open source Asterisk community by API Digital Communications in Huntsville, AL USA.
Please report problems with this site to