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

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3990/
-----------------------------------------------------------

(Updated Sept. 18, 2014, 1:25 p.m.)


Review request for Asterisk Developers, Matt Jordan and rmudgett.


Changes
-------

Add a break in the function to remove an entry from the datastore.  I don't think it's possible to have the same channel in there for two separate events, but there's no sense in continuing to traverse past the found entry anyway.


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 (updated)
-----

  /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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140918/9928e28d/attachment.html>