----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3990/#review13358 -----------------------------------------------------------
Ship it! Ship It! - rmudgett On Sept. 18, 2014, 5:50 p.m., Jonathan Rose wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3990/ > ----------------------------------------------------------- > > (Updated Sept. 18, 2014, 5:50 p.m.) > > > Review request for Asterisk Developers, Matt Jordan and rmudgett. > > > Bugs: ASTERISK-24237 > https://issues.asterisk.org/jira/browse/ASTERISK-24237 > > > Repository: Asterisk > > > Description > ------- > > Reproduction: > pj123 calls 1601 > pj123 does a SIP blonde transfer to 1603 > 1603 answers > FRACK occurs > all are PJSIP endpoints. > > Basically what happens is there is a second outbound dial from another pj123 > channel. Before the dial is answered, the pj123 gets masqueraded out of the > picture and replaced with a channel that isn't in the dial state. > > This patch fixes that by advancing the incoming channel to the dial state in > the channel breakdown function of a datastore on the pj123 channel. Honestly, > I'm not sure this is entirely adequate, but it seems to work in all of the > conditions I've tried so far and it doesn't impede normal attended transfers. > I might need to try and figure out what happens if I masquerade in a channel > that is already dialing though. I'm not sure if that's something we can > really expect to happen under normal conditions, but that seems like > something that would screw up this approach. > > Note that I think this patch is the right idea, I just don't know if I need > to account for the possibility that the channel that masquerades into pj123's > dialing channel might not be in the neutral state. > > > Diffs > ----- > > /branches/12/main/stasis_channels.c 422882 > > Diff: https://reviewboard.asterisk.org/r/3990/diff/ > > > Testing > ------- > > Ran against reproduction of the above scenario. Assertion was gone and the > CDR results were as follows: > > "","123","1601","default",""""" > <123>","PJSIP/pj123-00000000","PJSIP/1601-00000001","Dial","PJSIP/1601,,tT","2014-09-11 > 21:48:51","2014-09-11 21:48:53","2014-09-11 > 21:48:57",5,4,"ANSWERED","DOCUMENTATION","1410472131.0","" > "","123","","default",""""" > <123>","PJSIP/pj123-00000002","PJSIP/1603-00000003","Dial","PJSIP/1603","2014-09-11 > 21:48:55",,"2014-09-11 21:48:57",2,0,"NO > ANSWER","DOCUMENTATION","1410472135.6","" > "","1601","1603","default",""""" > <1601>","PJSIP/1601-00000001","PJSIP/1603-00000003","AppDial","(Outgoing > Line)","2014-09-11 21:48:57","2014-09-11 21:48:57","2014-09-11 > 21:49:04",6,6,"ANSWERED","DOCUMENTATION","1410472131.1","" > > And dial events reported by AMI: > http://pastebin.com/tWuwL7xa > (note that there is a mismatch between the number of dial end and dial begin > events... not sure if this is a problem, but I might be able to fix it just > by updating the old chan, not sure what status code to use though). > > Ran against normal attended transfer, feature attended transfers, and blind > transfers with no noticeable effect. > > Ran against testsuite blonde transfer tests, some attended transfer tests, > some blind transfer tests, and all pjsip transfer tests (at least ones that > will run on my box... a few won't due to sipp version requirements that I > really need to get around to fixing eventually) for comparison purposes. All > passed exhibiting the same behavior as before as far as warning messages and > such go. > > > Thanks, > > Jonathan Rose > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
