Raphael Coeffic wrote: > On 20.10.10 21:12, Stefan Sayer wrote: >> Jeremya wrote: >>> Hi, >>> >>> I have an example of requests being continually retried after the >>> initiating dialog has terminated >>> The recipient does not respond at any stage. >>> > > That's the most important point: SEMS should not send a BYE for a > dialog that has never been started (never received an answer to the > initial INVITE). Instead, the dialog will be terminated on reception > of the 408 timeout which is internally generated. > > If the dialog was already established, and the remote party crashed > before receiving the BYE, then it is completely normal. > If the dialog was in an early stage (some 1xx has been received of > somo sort), then we should send CANCEL. > > If this is not what is happening, then it looks like we have a bug. > > A wireshark trace showing the issue would help a lot ;-)
I have a wireshark trace. My dialog issues a CANCEL first but then issues a BYE as a result of an 'onKicked' event later to the dialog. This is my problem :-( Not related to this, but I did raise an earlier problem without identifying a particular cause. I found that if there are comms problems with an intermediate SIP router that result in delays in SIP traffic ( ~ seconds of delay) then it seems SEMS can get 'twisted up'. My initial report was a question on this list about nanosleep. I've now fixed up the bad SIP router and the problems don't exist any more, but when it was happening I saw - via logs - that SEMS was retaining parts of dialogs that kept on being sent up to 30 minutes after the initial request. I suspect that there is a problem in SEMS. Very unfortunately, my SEMS logs for the incident are lost I suspect that there is a timer problem in SEMS that does not account for outgoing delays and results in send requests being recycled unnecessarily. _______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
