Re: [reSIProcate-users] 491 Glare retry suport in DUM

[Scott Godin <sgodin@xxxxxxxxxxxxxxx>]

Hi Mike,

This problem was fixed in Git repo on January 21, 2016 by Francis Joanis.  :)

SHA-1: c96de908193ade6b3f378a7126902262a9c84f17

* -Fixed issue with DUM ServerInviteSession not automatically re-issuing an INVITE after received a 491. Also added tfdum test.

Thanks,

Scott

On Wed, Jan 4, 2017 at 11:04 AM, mike@xxxxxxxxxx mike@xxxxxxxxxx <mike@xxxxxxxxxx> wrote:

Hello Resiprocate Friends:

I have a DUM-based application which accepts a call session as a UAS, and then a little while later sends a mid-call re-INVITE transaction back to the caller.

Sometimes this re-INVITE gets a 491 response, for which I would expect that DUM would wait a short time and then retry the re-INVITE. Indeed, this is the case when DUM makes the original call rather than receives it. But nothing heppens when it is DUM that originally accepted the call (and the InviteSession object is a ServerInviteSession).

From the logging, I can see that the "DumTimeout::Glare" timer gets set. But when the timer goes off, ServerInviteSession::dispatch(resip::DumTimeout) gets called, rather than InviteSession::dispatch(resip::DumTimeout)..... and the way the "if" statements are formed in ServerInviteSession::dispatch(DumTimeout), the Timeout event gets ignored, since InviteSession::dispatch(DumTimeout) never gets called.

Is this a mistake?

From ServerInviteSession::dispatch(DumTimeout):

...

else if (timeout.type() == DumTimeout::Glare)
{
if (mState == UAS_SentUpdateGlare)
{
transition(UAS_SentUpdate);
InfoLog (<< "Retransmitting the UPDATE (glare condition timer)");
mDialog.makeRequest(*mLastLocalSessionModification, UPDATE); // increments CSeq
send(mLastLocalSessionModification);
}
}
else
{
InviteSession::dispatch(timeout);
}
}

_______________________________________________
resiprocate-users mailing list
resiprocate-users@resiprocate.org
List Archive: http://list.resiprocate.org/archive/resiprocate-users/