[reSIProcate] DUM based UAS is not robust against packet loss

[Dmitry Semyonov <dsemyonov@xxxxxxx>]

Hello All!

Recently I encountered the following situation:

SBC     DUM
-------------
INV-->
        <--OK
ACK-->  !this ACK has not arrived!
reINV-->
        <--481 Call/Transaction Does Not Exist
        <--400 Bad request (for the initial INV)
-------------

SBC is used for NAT traversal. SBC knows by some means that DUM is 
behind non-symmetric NAT. Therefore, SBC tries to release RTP stream, 
and sends re-INVITE _immediately_ after ACK. Note that this is 
entirely legal! ACK is lost (or reordered with re-INV) on the way to 
DUM. DUM replies with 4xx for both re-INVITE and original INVITE.

I could understand 481 reply, but why to send 400? Calling party 
SHOULD (per RFC) terminate the session itself in case of 481 reply. 
(Note the SHOULD, but not MUST!)

I believe in this case DUM should understand that the ACK was lost, 
and accept re-INVITE as if the ACK was received, instead of dropping 
everything.

Note 1: The same applies to all possible in-dialog requests, but 
not only to re-INVITEs. (There could be other scenarios, not 
necessarily involving NAT and SBC.)

Note 2: In the above example offer-answer exchange was completed 
before the ACK, but what if DUM is waiting for answer in the ACK? For 
me, the most appropriate solution would be to delay the in-dialog 
request until the ACK is finally received, and then process the 
request immediately after the ACK. (Or drop if on ACK timeout.) Does 
DUM already have some means to implement such delaying of the incoming 
in-dialog requests?

-- 
...Bye..Dmitry.