You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

Bit-Savva Mikhail f9051c4986 MT#65396 fix B2B updates racing a pending re-INVITE being 491d/dropped ... Mirrors the sems-pbx fix for the shared apps/sbc and core code. When a mid-transfer call is picked up (BLF), SEMS sends a re-INVITE with the picker's media towards the caller while another re-INVITE is still pending on that leg. It used to answer 491 and drop the update, so the call connects with no audio on either side. The P-Force-491: 0 marker exists to prevent exactly this: it tells the receiving leg to queue the update instead of 491ing it. But onB2BEvent() read the marker from the relayed request hdrs - which SBCCallLeg::relayEvent() has already run the profile's header filter over. Whitelist profiles don't list the header, so it was stripped and the 491 fired anyway. Read the marker earlier, in AmB2BSession::onSipRequest() while the hdrs are still unfiltered, and carry it as a skip_491 flag on the event. The queued update is replayed once the pending transaction ends, as before. This CE codebase has no call_transfer module, so t/test-xdsm-race.py reproduces the race with generic sbc.putOnHold/sbc.resumeHeld DSM actions over the same CallLeg.cpp path: the basic race, two stacked self-updates ahead of a collision, a plain unmarked glare that must still get 491, and the marker surviving the whitelist filter. Each collision carries the marker like the real pickup does, so the tests 491 on unpatched code. Also make the tests robust on a loaded CI: recvB2BINVITE() skips in-dialog INVITEs (those with a To-tag), and the queued updates are read by CSeq freshness, so timer-A retransmissions of earlier re-INVITEs piling up in the socket buffer aren't mistaken for the awaited update. Change-Id: Ie55f0a2f33a0dde5e2c3dd8dd2fb2c82c67a06c4		3 weeks ago
..
race_test.conf	MT#65396 fix B2B updates racing a pending re-INVITE being 491d/dropped	3 weeks ago