reSIProcate

Mailing Lists

Source Code

Google Search:



< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate-users] Handling re-INVITE before ACK

Hey, thanks for fixing this so quickly! Resiprocate rocks (and has superb support)! 

Scott Godin wrote:

Hi Jacques,

Sorry for the late response.  I did a review of the InviteSession
state machine, and I agree with your assesment.  I've modified any
states where we are waiting for an ACK to send a 491 response to any
inbound INVITE or UPDATE requests, instead of ending the InviteSession
entirely.  The changes have been checked into SVN main line.

Thanks for the report.

Scott

On Thu, Nov 13, 2008 at 6:40 PM, Jacques de Broin <jdebroin@xxxxxxxx> wrote:

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

_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/