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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
16 matches
Mail list logo
