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

Re: [reSIProcate] DUM state machine


Thanks for the quick response!  An onAck() callback does sound nice.  Otherwise, checks via InviteSession::isConnected() and some timers will have to suffice.

Steve

-----Original Message-----
From: Scott Godin
Sent: 16/11/2005 10:37 AM
If memory serves me correctly - the decision was made a while back with
the assumption that a UA would want to go connected (connect media
streams) as soon as possible and would not wait for the ACK to do so.
An onAckNotReceived callback was added in order to detect cases where an
ACK is lost, the app can decide to end the call or not.  Of course, if
the answer is in the ACK, (due to no offer in invite), then onConnected
is delayed until the ACK arrives.

Recently we've considered adding some kind of onAck callback, if the app
is for some reason interested in an ACK state isn't carrying SDP.

Scott

  
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
    
[mailto:resiprocate-
  
devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Steve Robichaud
Sent: Wednesday, November 16, 2005 10:26 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] DUM state machine

Hi everyone,

I have a question about the UAS state machine in DUM.

void
ServerInviteSession::accept(int code)
{
...
      case UAS_OfferProvidedAnswer:
      case UAS_EarlyProvidedAnswer:
         transition(UAS_Accepted);
         sendAccept(code, mCurrentLocalSdp.get());
         handler->onConnected(getSessionHandle(), mInvite200);
         break;
...

I am curious as to why the state transitions to UAS_Accepted, and the
onConnected handler is called.  I thought that the onConnected handler
would be called after the ACK arrives.

Also,

void
ServerInviteSession::dispatchAccepted(const SipMessage& msg)
{
...
      case OnAck:
      {
         mCurrentRetransmit200 = 0; // stop the 200 retransmit timer
         transition(Connected);
         // handler->onConnected(getSessionHandle(), msg);  // not
needed since onConnected is called when 200 is sent
         break;
      }

I noticed that in the ServerInviteSession::dispatchAccepted(const
SipMessage& msg) method that there used to be a call to the
    
onConnected
  
handler function in the OnAck case that has been commented out
    
although
  
the state transitions to Connected.  Again, why is onConnected
    
commented
  
out?

The reason I am asking is that I am using DUM to build a B2BUA and
    
came
  
across an exception when calling requestOffer() if the state is not
'connected'.  It's just a small window from sending the response to
getting the ACK that the session is in the state UAS_Accepted before
    
it
  
truly gets to the COnnected state.

Thanks,
Steve Robichaud
Upstream Works

_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel