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

[Daniel Pocock]

Dmitry Semyonov wrote:

>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.
>  
>
The re-INVITE does imply that an ACK was sent (or that the client is 
poorly written, which is not the case here) - I would tend to agree that 
DUM should treat any other in-dialog requests (re-INVITE, BYE) as an 
implicit ACK, and should therefore act as if the ACK had been received.

>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?
>
>  
>