RE: [reSIProcate] Handling the case where one side Re-INVITE and other side BYE simutanesouly

[Scott Godin <slgodin@xxxxxxxxxxxx>]

I think this is a valid fix.  I changed it around a little, since I fixed
the state transition if we send a queued bye - so the isResponse case should
not be needed now.  This fix is checked in with my last COMMIT.

Thanks!

Scott

-----Original Message-----
From: kaiduan xie [mailto:kaiduanx@xxxxxxxx] 
Sent: Wednesday, September 29, 2004 5:14 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] Handling the case where one side Re-INVITE and other
side BYE simutanesouly

Hi,

I suggested to add the processing for case where one
side Re-INVITE, for instance, HOLD a call, and the
othre side hangup the call simutanesouly in 
InviteSession.cxx:

  case ReInviting:
     ....
     else
     {
      ErrLog ( << "Spurious message sent to UAS " <<
msg );
      //xkd-2004-9-28
      if (msg.header(h_CSeq).method() == BYE)
      {
        if (msg.isResponse())
        {
          mState = Terminated;
         
mDum.mInviteSessionHandler->onTerminated(getSessionHandle(),msg);
        }
        else
        {
        // I am sending re-INVITE, other side send BYE
          mState = Terminated;
         
mDum.mInviteSessionHandler->onTerminated(getSessionHandle(),msg);
          mDialog.makeResponse(mLastResponse, msg, 200);
          send(mLastResponse);
        }
      }//if (msg.header(h_CSeq).method() == BYE)
      // end xkd-2004-9-28

Any comments are welcome.

kaiduan


______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel