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

Boris Rozinov borisrozinov at yahoo.ca
Fri Nov 16 00:28:24 CST 2007


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 at icescape.com> 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 at resiprocate.org
> [mailto:resiprocate-
> > devel-bounces at resiprocate.org] On Behalf Of Boris
> Rozinov
> > Sent: Tuesday, November 13, 2007 11:59 PM
> > To: resiprocate-devel at resiprocate.org
> > 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 at resiprocate.org
> >
>
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.



More information about the resiprocate-devel mailing list