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

RE: [reSIProcate] DUM state machine


I'd have to agree with Steve that the current implementation is probably
not ideal.

Many UAs will not connect the media stream until the 200 is received,
which will cause a problem in the following scenarios:
1) Our outgoing 200 is lost. We will eventually retransmit until we get
the ACK, but by that time, if we've already connected our media stream,
the start of the media stream is lost. That's more of a problem for
servers such as auto-attendants, voicemail, etc. than for two-way
voicecalls.
2) Our outgoing 200 is delayed more than the media stream (e.g. in a
loaded QoS network where the RTP packets are expedited). Same problem as
1) but not as bad.

I'd say the proper mode of callback behavior would be:
- Calling onAccepted() when the 200 is sent
- Calling onConnected when the ACK is received

Calling onConnected() when the 200 is sent is improper, since there's no
indication at all from the remote side that we are in fact "connected".

   - joe

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

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
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel