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

Re: [reSIProcate] handling requestOffer and provideOffer when waitingfor ACK (SentReinviteAnswered session state)


Scott,
thank you for your comment.
The fix about transition to Answer state upon sending
200 OK for reInvite is really important and it was
actually a problem in my case. 
My application invoked provideAnswer which made
session transition to Connected state and therefore
the subsequent invocation of requireOffer caused
Connected -> SentReinviteNoOffer transition and
reInvite was sent. 
ACK that came for the previous 200 OK was handled
InviteSession::dispatchReceivedReinviteSentOffer where
?Got Ack with no answer? treatment resulted in
ReceivedReinviteSentOffer -> Connected transition and
onOfferRejected callback.

Thanks,
Boris


--- Scott Godin <slgodin@xxxxxxxxxxxx> wrote:

> Boris,
> 
> Answered - is a state that is used when we have
> provided an answer to an
> inbound Re-Invite and are waiting for an ACK.
> SentReinviteAnswered - is a state that is used when
> we have sent a
> re-invite with no-offer and have received the 200
> (with offer) and are
> waiting for the application to call provideAnswer
> 
> The application should not be calling provideOffer
> or requestOffer until
> it has called provideAnswer for the onOffer callback
> (from receiving the
> 200 with offer).
> 
> A good reference for all of this is the
> dum-invite-connected-state.dot
> file under dum/doc.
> 
> While looking into your request and the
> InviteSession states I
> discovered something interesting.  We are not
> actually using the
> Answered state at all.  When we receive a 200 (with
> answer) after
> sending a re-invite we transition directly to
> Connected.  This means
> that we will allow the application to send out
> another re-invite request
> before the ACK arrives to the previous one.  I think
> this should be
> fixed to transition to Answered instead and follow
> the logic in
> dum-invite-connected-state.dot.
> 
> Does anyone have a reason not to fix this?
> 
> Scott 
> 
> 
> > -----Original Message-----
> > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx
> [mailto:resiprocate-
> > devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Boris
> Rozinov
> > Sent: Tuesday, November 13, 2007 11:59 PM
> > To: resiprocate-devel@xxxxxxxxxxxxxxx
> > Subject: [reSIProcate] handling requestOffer and
> provideOffer when
> > waitingfor ACK (SentReinviteAnswered session
> state)
> > 
> > Hi,
> > 
> > Can treatment be similar for both
> SentReinviteAnswered
> > and Answered state, i.e. SentReinviteAnswered can
> be
> > added to Answered state in both
> > InviteSession::requestOffer and
> > InviteSession::provideOffer
> > 
> >  case Answered:
> >  case SentReinviteAnswered:
> >          // queue the offer to be sent after the
> ACK
> > is received
> >          transition(WaitingToOffer);
> >          mProposedEncryptionLevel = level;
> >          mProposedLocalSdp =
> > InviteSession::makeSdp(offer, alternative);
> >          break;
> > 
> > Thanks,
> > Boris
> > 
> > 
> > 
> >       Ask a question on any topic and get answers
> from real people. Go
> > to Yahoo! Answers and share what you know at
> > http://ca.answers.yahoo.com
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxx
> >
>
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> 
> 



      ____________________________________________________ 
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
favourite sites. Download it now at
http://ca.toolbar.yahoo.com.