| Summary: | ASTERISK-23718: res_pjsip_incoming_blind_request: crash with NULL session channel | ||
| Reporter: | Jonathan Rose (jrose) | Labels: | |
| Date Opened: | 2014-05-05 16:35:40 | Date Closed: | 2014-05-30 09:58:53 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_pjsip Resources/res_pjsip_refer |
| Versions: | 12.2.0 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | Attachments: | ( 0) backtrace_pjsip_blind_xfer_crash.txt | |
| Description: | I've only been able to reproduce this with Digium Phones on account of them offering a certain level of control over calls during transfers. Still, Asterisk shouldn't crash on any SIP transactions it receives.
extension: <something to dial the other phone with> 001,1,Wait(20) 001,n,Answer() steps to reproduce: * PJSIP/dphone1 dials PJSIP/dphone2, gets into normal 2 party bridge situation * PJSIP/dphone1 uses xfer key to transfer PJSIP/dphone2 to extension 001 * While the transfer is progressing, press the ^ key on the Digium Phone's directional pad to switch the call from the current transfer to the initial session with PJSIP/dphone2 * Press the "Resume" softkey * Attempt to transfer the call to 001 again. This should cause the crash. I'm attaching a backtrace which details the crash. It can be mitigated simply by adding a null check against session->channel and returning 404 (probably anything other than 200 really). I'm not attaching a patch since I think that might be a superficial fix. | ||
| Comments: | By: Kinsey Moore (kmoore) 2014-05-30 09:58:54.018-0500 Fix committed to 12 and trunk. | ||