Re: [osip-dev] TCP transport_error with SUBSCRIBE

[FEICHTER Christoph]

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 <address@hidden>
Subject: Re: TCP transport_error with SUBSCRIBE

 

 

 

2017-09-15 5:51 GMT-07:00 FEICHTER Christoph <address@hidden>:

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 <address@hidden>
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 <address@hidden>:

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