|
From: | Aymeric Moizard |
Subject: | Re: [osip-dev] TCP transport_error with SUBSCRIBE |
Date: | Wed, 20 Sep 2017 01:35:20 -0700 |
hi aymeric,
the event EXOSIP_SUBSCRIPTION_NOANSWER is really not used in the moment.
I guess a solution using this event would be better.
My first attempt with simply removing the whole block for SUBSCRIBE request
in cb_transport_error has a potential risk.
In my use-case (TCP transport timeout) I do receive the second callback cb_xixt_kill_transaction
right after cb_transport_error. So I let cb_xixt_kill_transaction
do the cleanup and everything is fine.
But what about other transport errors ?
If cb_xixt_kill_transaction is not called, we would have a resource-leak !
can you tell me, if cb_xixt_kill_transaction is always called – even after a timeout –
for cleaning up hanging subscribe transactions ?
If not, I will try to find a solution using the event EXOSIP_SUBSCRIPTION_NOANSWER
and leave the cleanup in cb_transport_error as it is.
br,
christoph
From: Aymeric Moizard [mailto:address@hidden]
Sent: Mittwoch, 20. September 2017 03:10
To: FEICHTER Christoph <Christoph.FEICHTER@frequentis.com >
Subject: Re: TCP transport_error with SUBSCRIBE
2017-09-15 5:51 GMT-07:00 FEICHTER Christoph <Christoph.FEICHTER@
frequentis.com >:hi aymeric,
Hi Christoph,
did you already find time to have a look at this problem ?
can you reproduce it ?
Unfortunatly, I had no time to try. (and I have no more active app that
use SUBSCRIBE...)
I guess it’s not easy to fix, since there are some more code-branches,
from where the cb_transport_error is called.
removing the mentioned section in jcallback.c does work,
but I am not sure about the side effects.
If I'm correct, EXOSIP_SUBSCRIPTION_NOANSWER was the expected
event for such "no answer use-case".
The current code doesn't use any more EXOSIP_SUBSCRIPTION_NOANSWER.
(I'm not sure I ever did)
I guess your proposal is the simplest way to implement the no answer.
Tks
Aymeric
br,
christoph
From: Aymeric Moizard [mailto:address@hidden]
Sent: Mittwoch, 13. September 2017 00:43
To: FEICHTER Christoph <Christoph.FEICHTER@frequentis.com >
Cc: address@hidden
Subject: Re: TCP transport_error with SUBSCRIBE
Hi Christophe,
You sent previous email (and this one) to the wrong address: address@hidden
instead of "address@hidden".
I will take a look at your report.
Regards,
Aymeric
2017-09-11 3:56 GMT-07:00 FEICHTER Christoph <Christoph.FEICHTER@
frequentis.com >:hi aymeric,
my suggestion for a fix is to
remove the following section from cb_transport_error (jcallback.c):
if (js != NULL && MSG_IS_SUBSCRIBE (tr->orig_request)
&& type == OSIP_NICT_TRANSPORT_ERROR) {
/* delete the dialog! */
REMOVE_ELEMENT (excontext->j_subscribes, js);
_eXosip_subscribe_free (excontext, js);
}
thus, cb_xixt_kill_transaction is able to specify the sid in the
EXOSIP_SUBSCRIPTION_REQUESTFAILURE to the application
what do you think about this ?
br,
christoph
From: FEICHTER Christoph
Sent: Freitag, 8. September 2017 10:29
To: address@hidden
Subject: TCP transport_error with SUBSCRIBE
hi,
it seems that, if you have an outgoing SUBSCRIBE request with transport=tcp
and the peer is not reachable, the transport-error is not signaled to the application.
in detail:
- first cb_transport_error ist called,
which deletes reserved5, by calling eXosip_delete_reserved
- then cb_xixt_kill_transaction is called,
but since reserved5 is already cleared, this function is not able
to send a EXOSIP_SUBSCRIPTION_REQUESTFAILURE to the application
what do you think ?
I guess cb_transport_error shall NOT call _eXosip_subscribe_free !
btw: the transport_error does work fine for UDP as transport-protocl, and for INVITE requests;
only SUBSCRIBE via TCP is the problem.
br,
Christoph
--
Antisip - http://www.antisip.com
--
Antisip - http://www.antisip.com
[Prev in Thread] | Current Thread | [Next in Thread] |