> On Sept. 11, 2014, 5:12 p.m., Jonathan Rose wrote: > > I've got a small change to the above patch that I'm still not sure that is > > appropriate, but it addresses the lack of a dial end for the outgoing dial > > from pjsip/pj123's second channel to pj1603 -- see link below for the > > results: > > http://pastebin.com/c0AXSFfH > > > > > > It also changes the Changes the CDR log to this though and I'm not sure > > whether or not that's appropriate since I confirmed the previous results > > with Matt once already: > > > > "","123","1601","default",""""" > > <123>","PJSIP/pj123-00000000","PJSIP/1601-00000001","Dial","PJSIP/1601,,tT","2014-09-11 > > 22:05:15","2014-09-11 22:05:20","2014-09-11 > > 22:05:42",27,21,"ANSWERED","DOCUMENTATION","1410473115.0","" > > "","1601","1603","default",""""" > > <1601>","PJSIP/pj123-00000002","PJSIP/1603-00000003","Dial","PJSIP/1603","2014-09-11 > > 22:05:33",,"2014-09-11 22:05:42",9,0,"NO > > ANSWER","DOCUMENTATION","1410473133.6","" > > "","1601","1603","default",""""" > > <1601>","PJSIP/1601-00000001","PJSIP/1603-00000003","AppDial","(Outgoing > > Line)","2014-09-11 22:05:42","2014-09-11 22:05:42","2014-09-11 > > 22:07:40",118,118,"ANSWERED","DOCUMENTATION","1410473115.1","" > > > > > > Note that there are only 3 logs instead of 4... which might be more > > appropriate considering that there were really only 3 dials involved (from > > pj123 to pj1601, from pj123 to 1603, and the masqueraded 1601 to 1603 > > > > The only change to this patch need to achieve that result is: > > > > ast_channel_publish_dial_forward(new_chan, ds->peer_chan, NULL, > > ds->dialstring, NULL, NULL); > > + ast_channel_publish_dial_forward(old_chan, ds->peer_chan, NULL, > > ds->dialstring, "NOANSWER", NULL); > > > > in dial_masquerade_breakdown (dial.c) > >
Oh, it looks like there are actually only three CDRs in the above example as well. Odd since the one I sent to mjordan yesterday had four... I'm just going to chalk it up to issues then since I've been through it a couple more times since then and got three every time. - Jonathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3990/#review13287 ----------------------------------------------------------- On Sept. 11, 2014, 4:59 p.m., Jonathan Rose wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3990/ > ----------------------------------------------------------- > > (Updated Sept. 11, 2014, 4:59 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 > /branches/12/main/dial.c 422882 > /branches/12/include/asterisk/dial.h 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
