1. sailfin
  2. SAILFIN-2104

UA state changes to RUNNING in case of crossing re-invites


    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0, 2.0, 25, b05
    • Fix Version/s: 1.0, 2.0
    • Component/s: sip_container
    • Labels:


      We have a scenario where there are two UAs (in a chained B2B scenario).
      A call is established and then both sides simulateously do a reinvite in order to change the SDP.

      One of the re-invites is rejected with a 491 result, which is good.
      What is not good is that this rejection means that the UA that rejected it goes back to RUNNING.
      This means that later 200 OKs are just dropped.

      The flow is shown below.

      (enter this text in websequencediagrams...I'll attach the figure as well)

      UA1->network: INVITE 1
      note over UA1: RE_INVITE_INITIAL_UAC
      network->UA1: 100 trying 1
      note over UA1: RE_INVITE_INITIAL_UAC
      UA2->network: INVITE 2
      note over UA2: RE_INVITE_INITIAL_UAC
      network->UA2: INVITE 1
      UA2->network: 491 1
      note over UA2: RUNNING !!!!
      note over UA2: Should be the 'old' state
      network->UA1: 491 1
      note over UA1: RUNNING
      network->UA1: INVITE 2
      note over UA1: RE_INVITE_UAC
      UA1->network: 200 OK 2
      network->UA2: 200 OK 2
      note over UA1,UA2:
      Since UA2 is in state RUNNING
      it will NOT inform the application!
      it will try to deliver a stored ACK
      But since it does not have an ACK
      stored for this INVITE cseq it will
      just not do anything

      I.e., the problem is that the state is set to the incorrect value when the crossing invite is rejected.
      It should just NOT change the state, IMO.

      This code is in the for doRequestUAS.
      I've shown the line that should be commented and the reasons why in the code

      case RE_INVITE_EARLY_UAC: {
      if (method.equals("BYE"))

      { m_State = CLOSING_UAS; }

      else if (method.equals("INVITE"))

      { // OK, a remote INVITE arrived while processing // a locally generated INVITE already // EVDV: COMMENT NEXT LINE. // IT IS OK TO REJECT THE INVITE, BUT NOT TO JUST CHANGE THE // STATE BACK TO RUNNNING. // WE STILL HAVE NOT RECEIVED A RESPONSE TO THE OUTGOING INVITE // CHANGING IT TO RUNNING MEANS THAT RESPONSE WILL NOT BE HANDLED // CORRECTLY // EVDV: COMMENTED: m_State = RUNNING; // // need to immediately respond with a pending response resp = req.createTerminatingResponse(491); }

      // Can't sent response on ACK, cf
      // SipServletResponseImpl.populateResponse()
      else if (!method.equals("PRACK") && !method.equals("UPDATE") &&

      { resp = req.createTerminatingResponse(403); }



        There are no comments yet on this issue.


          • Assignee:
          • Votes:
            0 Vote for this issue
            0 Start watching this issue


            • Due: