[asterisk-dev] [Code Review] 3990: CDRs/Dial: Fix an assertion caused by advancing a neutral state channel straight into dial pending without going through dial

[Jonathan Rose]

> 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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140911/97ee4356/attachment-0001.html>