#161 incorrect handling of prov responses in B2buaSafeFSM

[Gregory W Bond]

I was wondering why did u add:

/** If a provisional response is received *after* the INVITE transaction is complete,
* just ignore it. It's too late to do anything with it.
*/
transition SUCCESS - callee ? UnreliableProvisionalResponse -> DEEP_HISTORY;

to B2buaInviteFSM

when there is already:

/** Handle orphaned provisional responses (by dropping them). These could occur if
* the provisional response arrives after the final response. Such responses
* received at the appropriate time will be handled by the appropriate nested machine,
* because of the Source Coverage Rule (the nested machine has a more specific source state).
*/
transition TRANSPARENT - port1 ? ProvisionalResponse -> TRANSPARENT.DEEP_HISTORY;
transition TRANSPARENT - port2 ? ProvisionalResponse -> TRANSPARENT.DEEP_HISTORY;

in TransparentFSM

is it for some special case?

---

first of all, if we assume that B2buaInviteFSM can be used independent of the TransparentFSM then these transitions serve a useful purpose namely, absorbing late provisional responses

however, when the two machines are combined, as they are in the B2buaSafeFSM, there appear to be problems:

o a very minor problem is that if an unreliable provisional response arrives late for a mid-dialog transaction that has ended, and the INVITE dialog is in the SUCCESS state, then the transition in the B2BuaInviteFSM will absorb the unreliable provisional response, instead of the TransparentFSM - this is undesirable because the B2BuaInviteFSM should only be concerned with messages associated with the INVITE transaction - this problem can (and will) be fixed by adding a guard to the transition to ensure that the unreliable provisional response is associated with the INVITE dialog before absorbing the response

o a bigger problem was discovered when eric and i took a closer look at the B2buaInviteFSM machine - there is another transition there:

transition MONITOR_CALLEE - callee ? ProvisionalResponse / {
intPort ! message;
} -> [ RECV_PROVISIONAL_RESPONSE, PROVISIONAL_RECEIVED.YES ];

which does not check that the provisional response is associated with the initial INVITE dialog - this means it is possible for this transition to unintentionally absorb provisional responses intended for active mid-dialog transactions that exist in the TransparentFSM - furthermore, subsequent processing of the provisional response by B2buaInviteFSM will result in the response being unintentionally forwarded to the caller - eric discovered that this problem problem was introduced recently when the B2buaInviteFSM was modified to support reliable provisional responses - this problem can (and will) be fixed by adding a guard to the transition to ensure that the provisional response is associated with the INVITE dialog