[reSIProcate-users] Handling re-INVITE before ACK

[Jacques de Broin <jdebroin@xxxxxxxx>]

Hi,

I'm having problems with this scenario:
 
  UAS                    NETWORK                    UAC
   |                       | |                       |
   |                       | |<-INVITE (1 INVITE)----|
   |<-INVITE (1 INVITE)----| |                       |
   |                       | |                       |
   |--200 (1 INVITE)------>| |                       |
   |                       | |                       |
   |--200 (1 INVITE)------>| |                       |
   |                       | |                       |
   |                       | |--200 (1 INVITE)------>|
   |                       | |                       |
   |                       | |<-ACK (1 ACK)----------|
   |                       | |                       |
   |                       | |<-INVITE (2 INVITE)----|
   |                       | |                       |
   |<-INVITE (2 INVITE)----| |                       |
   |                       | |                       |
   |                       | |                       |
   |                       | |                       |
   |--481 (2 INVITE)------>| |                       |
   | Call/Transaction Does Not Exist                 |
   |                       | |--481 (2 INVITE)------>|
   |                       | | Call/Transaction Does N
   |                       | |                       |
   |--400 (1 INVITE)------>| |                       |
   | Bad Request           | |                       |
   |                       | |<-ACK (2 ACK)----------|
   |                       | |                       |

For some reason the ACK for the 1st INVITE is lost or received by the UAS too
late. The UAC sends a re-INVITE while the UAS stack is still in UAS_Accepted
state. The re-INVITE gets handled by dispatchUnknown which sends a 481 response
to the 1st INVITE, a 400 response to the 2nd INVITE and terminates the invite
session.

Do you think it would make sense to instead simply respond to the 2nd INVITE 
with
the 481 response and not do anything to the initial INVITE session? The ACK 
would
eventually make it and the UAC could retry the 2nd INVITE so that call would 
have
a chance to go through.

So, perhaps ServerInviteSession.cxx could be changed, something like:

void
ServerInviteSession::dispatchAccepted(const SipMessage& msg)
{
   ...
   case OnInviteReliableOffer:
   case OnInviteOffer:
   case OnInviteReliable:
   case OnInvite:
   {
      SharedPtr<SipMessage> r481(new SipMessage); // !jf! what should we send 
here? 
      mDialog.makeResponse(*r481, msg, 481);
      send(r481);
      break;
   }
   ...
}
 
Thanks!

- Jacques