attended_transfer/caller_local_blond: Make more reliable#147
Conversation
* Trying to figure out how the test actually works took most of the time. To make it easier to understand, instead of using names like referer, referee, etc. the scenarios are now named after our usual actors: alice, bob and charlie. * Numerous naming clarifications were made to the scenario files. * The test description has been re-written to include both a high-level and low-level flow. * Instead of having the 4 sipp scenarios all bind to 127.0.0.1 with different ports, they bind to 127.0.0.2, 3, 4, 5 port 5060. * The usual test failure was in the alice_calls_bob scenario when it's supposed to receive 2 sipfrag NOTIFYs. For some reason, sipp would occasionally just end the scenario after the first NOTIFY with no indication as to why. To get around this, alice_calls_bob.xml no longer explicitly deals with the NOTIFYs and instead lets sipp deal with them by virtue of the `-aa` option. * Also fixed an issue in sipp.py that prevented SIP packets from being output to the Asterisk logs when there was only 1 asterisk instance.
|
cherry-pick-to: 20 |
github-actions
Bot
added
pr-submit-testing-in-progress
pr-submit-tests-passed
and removed
pr-submit-testing-in-progress
labels
|
Workflow Check completed successfully |
mbradeen
left a comment
mbradeen
left a comment
There was a problem hiding this comment.
sipp changed some end-of-scenario timing with regard to overall timeouts and to coordinated scenario shutdown, which I think is what causes the alice-to-bob scenario to end early. I had put some extra cmd exchanges in at the end to a bunch of the tests to try and deal with it, but as you noted it still shuts down early for some reason. If we con't care about the NOTIFY messages then the -aa should be fine.
|
It doesn't appear that it's "ending" early, sipp actually terminates with a "1" return code after it received the first sipfrag NOTIFY. Here's the output... No errors, no unexpected messages, no timeouts, etc. It just ends. |
|
@gtjoseph - looking at https://github.com/asterisk/asterisk/actions/runs/27999754131/job/82869878857 ... i think this is a 3pcc thing (I know different test) - if you look at the logs, the referee finishes which I think is triggering sipp to close the referer with a 1 because of what I mentioned before with the change in teardown by sipp on 3pcc scenarios. I'm wondering if a pause or timewait at the end of both scenarios would allow the linked scenario to finish. Maybe swapping the -3pcc flag for -3pcc-C ... |
|
In this test, the referee (alice_calls_charlie) isn't ending before the referer (alice_calls_bob). alice_calls_charlie sends the ACK to the 603 then the sendCmd that's supposed to tell alice_calls_bob to end but alice_calls_bob has already died at that point. Here's the log and pcap. If you see something different, let me know. Just FYI... I ran over 300 iterations with this change without an error. |
|
If we don't care about the NOTIFY messages, then I am all for just using the -aa method on this and all other failing transfer tests :) |
2 participants
To make it easier to understand, instead of using names like referer, referee,
etc. the scenarios are now named after our usual actors: alice, bob and charlie.
low-level flow.
ports, they bind to 127.0.0.2, 3, 4, 5 port 5060.
to receive 2 sipfrag NOTIFYs. For some reason, sipp would occasionally just
end the scenario after the first NOTIFY with no indication as to why. To get
around this, alice_calls_bob.xml no longer explicitly deals with the NOTIFYs
and instead lets sipp deal with them by virtue of the
-aaoption.to the Asterisk logs when there was only 1 asterisk instance.