Re: [reSIProcate-users] [Fwd: reINVITE/BYE glare condition?]
Hi Scott:
I found today that part of the cause for this issue was that I was
calling "end()" on the InviteSession just after doing the provideOffer()
which made DUM send the Re-invite.
The end() is in response to a control event from an application server.
As a workaround, I made my code refrain from calling end() before the
re-Invite transaction is finished.
By holding back on calling end(), DUM sees the BYE, processes it
correctly and cleans up the call.
So, it was by making the InviteSession transition between "ReInviteSent"
to "Waiting for termination" that made it kind of clam up and not do
anything when the BYE came in.
Maybe end() was occuring after the BYE from the UAC had already came in.
Not sure.
Scott Godin wrote:
I think the right thing to happen here, would be for the far end to
send some kind of response to the re-invite - ie. 481. However, I
think it also makes sense to modify DUM to handle this more gracefully
(ie. send CANCEL, or cleanup properly on some timeout). You may also
want to check
out http://tools.ietf.org/html/draft-ietf-sipping-race-examples-06 for
guidance.
Scott
On Thu, Apr 16, 2009 at 10:51 PM, Michael Trank <mtrank@xxxxxxxxxxxxx
<mailto:mtrank@xxxxxxxxxxxxx>> wrote:
I remember reading that one, and I just looked back at it.
In that case, DUM *received* a re-Invite, immediately followed by
a BYE.
In my case, DUM *sends* out a re-INVITE, and then *recieves* a
BYE very soon after... no response to the re-INVITE.
( The UAS below is DUM. I've had results like this with a couple
of different UA's on the UAC side. )
Do you know what is supposed to happen in a situation like this?
Should DUM do a CANCEL on the re-INVITE when the BYE comes in
from the other side?
Scott Godin wrote:
Hi Michael,
This sounds identical to an issue that was reported 2 weeks
back on the mailing list. It looked like a DUM bug to me. I
plan on fixing this when a get some spare time. In the
meantime, the person that reported the issue, also posted a
reasonable looking patch, you should check out the mailing
list archives for this.
It looks like this:
UAC UAS
Invite --->
200 OK <---
ACK --->
some seconds pass by....
Re-Invite ( with BlackHole ) <---
BYE --> ( almost simultaneous with the
re-invite
above, oops! )
Re-Invite ( with BlackHole ) <--- ( repeat )
100 Trying <--- ( response from uac to re-invite )
BYE --->
100 Trying <--- ( provisional for BYE from DUM )
BYE --->
100 Trying <--- ( provisional for BYE from DUM )
BYE --->
100 Trying <--- ( provisional for BYE from DUM )
BYE --->
100 Trying <--- ( provisional for BYE from DUM )
BYE --->
100 Trying <--- ( provisional for BYE from DUM )
and thats it. The UAC never responds to my Re-invite, and DUM
never does anything with the BYE.
What is supposed to happen here?
Am I suppsed to get some callback after a certain amount of
time?
My applications session variables never get a chance to clear
themselves out when this happens, since I believe that DUM
isn;t
calling any of the callbacks in my InviteSessionHandler.
Thanks in advance for any help you can offer.
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
<mailto:resiprocate-users@xxxxxxxxxxxxxxx>
<mailto:resiprocate-users@xxxxxxxxxxxxxxx
<mailto:resiprocate-users@xxxxxxxxxxxxxxx>>
List Archive:
http://list.resiprocate.org/archive/resiprocate-users/