Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2016-01-11 Thread Bogdan-Andrei Iancu
Hi Maxim, A Happy New Year to you too ! Sorry for the slow reply, many things to catch up with. So, I understand the original problem (retransmissions and cancelling for slowly answered invites) is solved by the patch I sent you. Hoping the are no side effects on this change, I can start sch

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-12-28 Thread Maxim Sobolev
Hi Bogdan, happy holidays for you and OpenSIPS team! So, what's the next step to get those early CANCEL changes merged? Basic testing seems to be confirming its functionality. I'd also like to get your opinion on the 100 Trying generation when t_newtran() is used. Thanks! On Wed, Dec 23, 2015 at 7

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-12-23 Thread Maxim Sobolev
OK, further investigation revealed that the lack of the provisional reply is caused by the usage of the t_newtran() in our routing script, which then causes different code path in the t_relay(), i.e. t_forward_nonack() function is used instead of t_relay_to(). Which appears to be triggering a separ

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-12-23 Thread Maxim Sobolev
Sorry, Bogdan, please disregard my previous message. After closer look at the log it seems that my initial diagnosis was not quite correct. The problem appears that provisional response generation is broken somehow, so that the originating UA keeps sending INVITEs over and over again and could not

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-12-23 Thread Maxim Sobolev
Hi Bogdan, that patch is not fully functional. Yes, it did restore INVITE re-transmits, so that the second 100 Trying is stimulated properly, but the CANCEL to the egress call leg is not generated until 180 Ringing response comes in. You can see full log here: https://s3.amazonaws.com/archive.trav

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-12-14 Thread Bogdan-Andrei Iancu
Maxim, Please check the attached patch for 1.11 Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 14.12.2015 22:46, Maxim Sobolev wrote: Thanks Bogdan, I will be working on test case this week. I'll drop you a note when it's ready. On Fri, Dec 1

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-12-14 Thread Maxim Sobolev
Thanks Bogdan, I will be working on test case this week. I'll drop you a note when it's ready. On Fri, Dec 11, 2015 at 8:42 AM, Bogdan-Andrei Iancu wrote: > Roger that, thanks for the detailed explanations - let's be consistent in > handling the INVITE cancelling, in terms of letting all the time

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-12-11 Thread Bogdan-Andrei Iancu
Roger that, thanks for the detailed explanations - let's be consistent in handling the INVITE cancelling, in terms of letting all the time the final UAS to generate the final reply (if still alive). Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-12-10 Thread Maxim Sobolev
Bogdan, please don't get me wrong. There is probably an use case where ability to cancel call locally instead of having to wait for 64*T1 for the outbound INVITE transaction to expire is important. What I am trying to tell you that it needs to be implemented properly. By which I mean that the tm mo

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-12-10 Thread Maxim Sobolev
Bogdan, the point here is that the call cannot be considered cancelled by the proxy until INVITE transaction either timeouts retransmits in 32 seconds or final response is received from the UAS. Cancelling it early violates RFC and creates a possibility of creating inconsistent state on inbound or

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-12-10 Thread Bogdan-Andrei Iancu
Hi Maxim, Basically the strong point of your case is not to stop INVITE retransmissions on receiving CANCEL, just to be sure you can cope with a potential lost of a provisional reply. Still, I say it is better to reply with 487 to the INVITE (see my demonstration that a 487 or a later 408 ar

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-12-08 Thread Maxim Sobolev
Bogdan, I don't think that's about one way being better than the other. Stopping retransmitions after first INVITE went out is in fact against the word and spirit of the RFC, as it opens door wide for various inconsistencies between alice and bob (i.e. actual endpoints). IMHO it's not up for an UAC

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-12-08 Thread Bogdan-Andrei Iancu
Hi Maxim, In the current implementation, if there was no reply received for the INVITE, on canceling opensips stops retransmissions for INVITE and replies with 487 to it. As I understand, you suggest as a better approach to keep doing the retransmissions until either there is an incoming re

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-11-16 Thread Maxim Sobolev
Bogdan, thanks for looking into this for me. So OpenSIPS is somewhat better than original code, but still not perfect. This method would work if the INVITE has been lost or never received, but would still produce inconsistent transaction state if provisional reply has been lost and INVITE in fact i

Re: [OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-11-14 Thread Bogdan-Andrei Iancu
Hi Maxim, Thank you for your detailed email on the matter. Indeed, if there is no reply received on the branch, OpenSIPS internally cancel the branch (stops retransmissions and generates a 487 reply for the INVITE). Nevertheless, the branch gets marked as canceled and as soon as a reply is re

[OpenSIPS-Devel] "Early cancel" issue in the tm module

2015-11-12 Thread Maxim Sobolev
Hi Volks, there seems to be an issue in the way how the tm handles early CANCEL, i.e. when a CANCEL arriving before the downstream UAS gets chance to generate a 100 Trying reply, or that reply is still in flight (or maybe 100 Trying is lost). In that case the OpenSIPS stops outbound INVITE re-trans