Re: [reSIProcate] DUM InviteSession state during Re-Invite
That change will be fine for what you want, it's just a little strange as a
general solution, since this will also cause onConnectedConfirmed for
session timer re-invites - which normally happen without any callbacks.
-----Original Message-----
From: Kovar, William (Bill) [mailto:bkovar@xxxxxxxxx]
Sent: March-15-07 6:41 PM
To: Kovar, William (Bill); Scott Godin; Jason Fischl
Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] DUM InviteSession state during Re-Invite
Scott, Jason,
I've added the following to InviteSession::dispatchConnected()
Line 959 I changed the case onAck: to the following:
case OnAck:
mCurrentRetransmit200 = 0; // stop the 200 retransmit timer
// add the callback for all ACKs during Connected state
handler->onConnectedConfirmed(getSessionHandle(), msg);
break;
Will this achieve what I want without breaking anything??
Bill Kovar
bkovar@xxxxxxxxx
Avaya, Inc.
(732) 852-2609
> -----Original Message-----
> From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On
> Behalf Of Kovar, William (Bill)
> Sent: Thursday, March 15, 2007 6:07 PM
> To: Scott Godin; Jason Fischl
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] DUM InviteSession state during Re-Invite
>
> I nice thing to have would be to have a DUM callback when the
> ACK comes back from 200 OK I send to satisfy the re-invite.
>
> It seems that onConnectedConfirmed() only happens on the
> initial invite.
>
> Can we add it to all ACK's????
>
> Bill Kovar
> bkovar@xxxxxxxxx
> Avaya, Inc.
> (732) 852-2609
>
>
> > -----Original Message-----
> > From: Scott Godin [mailto:slgodin@xxxxxxxxxxxx]
> > Sent: Thursday, March 15, 2007 1:04 PM
> > To: Kovar, William (Bill); Jason Fischl
> > Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> > Subject: RE: [reSIProcate] DUM InviteSession state during Re-Invite
> >
> > FYI - this may not solve all your problems, but I've been
> considering
> > adding queuing of the re-invite request within dum, for cases when
> > re-invites are already in progress, for
> > example: in the middle of a re-invite initiated by the far
> end, or in
> > the middle of a local re-invite due to session timer (of
> which the app
> > is not aware). I just haven't had the time to get this
> done yet. : (
> >
> > Scott
> >
> > > -----Original Message-----
> > > From: Kovar, William (Bill) [mailto:bkovar@xxxxxxxxx]
> > > Sent: Thursday, March 15, 2007 11:49 AM
> > > To: Jason Fischl; Scott Godin
> > > Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> > > Subject: RE: [reSIProcate] DUM InviteSession state during
> Re-Invite
> > >
> > > Jason,
> > >
> > > When operating as a B2B, a 3rd party controller may want to
> > put one of
> > > the controlled parties on Hold. This involve a re-invite
> > and shuffle.
> > > The SBC I work with uses re-invites as a session refresh.
> > >
> > > So if the B2B is in the process of re-invite(HOLD) and the
> > SBC sends a
> > > re-invite(session refresh) we have an uncontrollable glare
> > condition.
> > >
> > > What is desirable is to allow the refresh to finish (if it
> > got there
> > > first), and then allow the 3rd party Hold to execute.
> Hence the need
> > to
> > > know that a re-invite is in progress.
> > >
> > > Conversely, if the Hold started first, we 491 the refresh
> > and it comes
> > > back. If we're no longer shuffling the Hold, we handle
> the refresh.
> > > Otherwise we 491 again.
> > >
> > > Bill Kovar
> > > bkovar@xxxxxxxxx
> > > Avaya, Inc.
> > > (732) 852-2609
> > >
> > >
> > > > -----Original Message-----
> > > > From: jason.fischl@xxxxxxxxx [mailto:jason.fischl@xxxxxxxxx] On
> > > > Behalf Of Jason Fischl
> > > > Sent: Thursday, March 15, 2007 11:38 AM
> > > > To: Scott Godin
> > > > Cc: Kovar, William (Bill);
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> > > > Subject: Re: [reSIProcate] DUM InviteSession state during
> > Re-Invite
> > > >
> > > > This would be relatively easy to add though since the
> > internal state
> > > > machine knows.
> > > >
> > > > What use case requires this knowledge?
> > > >
> > > > Jason
> > > >
> > > >
> > > > On 3/15/07, Scott Godin <slgodin@xxxxxxxxxxxx> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > There is currently no way to determine this. : (
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx
> > > > > [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On
> > > > Behalf Of
> > > > > Kovar, William (Bill)
> > > > > Sent: Wednesday, March 14, 2007 4:26 PM
> > > > > To: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> > > > > Subject: [reSIProcate] DUM InviteSession state
> during Re-Invite
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Is there a way to ascertain, from within DUM, whether
> or not a
> > > > > particular session is in a re-invite sequence.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > The session->isConnected() stays true after the first
> Invite is
> > > > > connected but doesn't change when a re-invite is happening.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I'm also interested in knowing when it started and finished.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Any ideas?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Bill Kovar
> > > > > _______________________________________________
> > > > > resiprocate-devel mailing list
> > > > > resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> > > > >
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
> > > > >
> > > >
> >
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>