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

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


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