| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
|
Here’s an updated patch with the
dynamic_casts removed, and the fix in handleSessionTimerResponse() From: I'm
going to take the opportunity to say I don't like the
"dynamic_cast<>(this)" technique of figuring out whether we're
UAS or UAC. How about we just put virtual bool isUAS() and virtual bool isUAC()
in InviteSession? (Or, we could create an enum and declare a virtual UAType
getUAType()) This would be more efficient, more terse, and less fragile. Aside
from that, the patch looks sane to me (so far), but we need to fix another part
of the code (region around InviteSession.cxx:2217). Best regards,
Hi, I’m seeing
odd behaviour with session timers in the following case. I have a fix
that I’ve tested out (see attached patch), but I’d like to run it by you (Scott) before committing it
as I believe you’re more familiar with that code... (note that
the default Session-Expires used in the following is 90 seconds) DUM
------------------- proxy INVITE
----> (no refresher preference specified) <---- 100 <---- 180 <---- 200
(refresher=”uas”) ACK ----> … 45 seconds
go by … <----
INVITE (refresher=”uas”) 200 ---->
(refresher=”uas”) … 45 seconds
go by … <----
INVITE (refresher=”uas”) INVITE
----> (refresher=”uac”) At this
point, DUM is confused and thinks that it is the refresher, so we get the
INVITE glare condition, and things go downhill from there. The problem
seems to be logic in InviteSession that gets executed when it receives the
first refresh after 45 seconds. I’ve tested
out the attached patch, but please let me know if you think I’ve missed
something… Thanks, -
Jeremy - Jeremy Geras Software
Developer CounterPath
Solutions Inc. (formerly
NewHeights Software Corp.) <session_timers_fix_sipfoundry.patch> _______________________________________________ resiprocate-devel mailing list |
Attachment:
session_timers_fix_no_more_dynamic_cast.patch
Description: Binary data