Re: [reSIProcate] DUM based UAS is not robust against packet loss
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?