[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [osip-dev] implicit subscription

From: FEICHTER Christoph
Subject: Re: [osip-dev] implicit subscription
Date: Mon, 26 Jun 2017 21:28:54 +0000



sorry – my fault.

everything fine !


your patch v4 partly works.

Nevertheless I have some improvements / hardening issues; attached as v5.


here are my explanations:


-          jcallback.c, function cb_rcv2xx
for performance reasons I put the handling of NOTIFY and REFER in an else-if cascade

-          jcallback.c, function cb_rcv2xx
eXcall_api.c, function
I re-worked the parsing a bit:

o   searching for the expires-parameter did not work, due to the different length of “active” and “pending”

o   you forgot to take into account the “;” between “active”/”pending” and the “expires” parameter

o   the length of “expires” is 7, not 6 chars
à I added const char’s for the strings to search for; so we can use strlen to get the right length

o   I did not like the double “if (ss_expires!=NULL)

o   I use “;expires=” for searching for the expires-parameter

o   check “sub_state->hvalue != NULL” was missing
otherwise crash in case of empty “Subscription-State” header

o   check “refer_sub->hvalue != NULL” was missing
otherwise crash in case of empty “Refer-Sub” header

-          Although the expires parameter should be present in the Subscription-State header of the NOTIFY
I added to use the default (
excontext->implicit_subscription_expires) in this case.






From: Aymeric Moizard [mailto:address@hidden
Sent: Freitag, 23. Juni 2017 13:46
To: FEICHTER Christoph
Cc: address@hidden
Subject: Re: implicit subscription


Hi Christoph!


Tks for looking/testing the patch.


My intention is to be able to send/recv a NOTIFY after the BYE.


Images intégrées 1


As you can see above, I was able to do so when I close the call on the REFER sender



I do think, in theory, it should also work if the BYE is coming from the other side.


The "magic" is supposed to happen here, in "_eXosip_pending_subscription_exist "


      else if (0 == _eXosip_pending_subscription_exist (excontext, jc, jd)) {


      else if (0 == _eXosip_release_finished_calls (excontext, jc, jd)) {


The objective when a subscription exist, is to NOT call _eXosip_release_finished_calls, unless

implicit_subscription_expire_time is expired.


Thus, if it doesn't work for a scenario, this is because implicit_subscription_expire_time

wasn't above "now" and _eXosip_pending_subscription_exist returned !=SUCCESS.


let me know the exact scenario and try to find out why _eXosip_pending_subscription_exist







2017-06-23 13:31 GMT+02:00 FEICHTER Christoph <address@hidden>:

hi aymeric,


I just tried your latest patch (v4).

which function would you use to build a NOTIFY request after the BYE has been sent/received ?

eXosip_call_build_request ?


this fails, because you did not prevent the call from being freed.

I guess we will need the return for leaving, in case of an active implicit subscription – like this:


static int

_eXosip_release_finished_calls (struct eXosip_t *excontext, eXosip_call_t * jc, eXosip_dialog_t * jd)


  osip_transaction_t *tr;

  time_t now = osip_getsystemtime (NULL);


  tr = _eXosip_find_last_inc_transaction (jc, jd, "BYE");

  if (tr == NULL)

    tr = _eXosip_find_last_out_transaction (jc, jd, "BYE");


  if (tr != NULL && (tr->state == NIST_TERMINATED || tr->state == NICT_TERMINATED)) {

    int did = -2;


    if (jd != NULL)

      did = jd->d_id;


>    if (now < jd->implicit_subscription_expire_time)

>    {

>       /* keep this call & dialog, although it's terminated */

>       return OSIP_SUCCESS;

>    }


    OSIP_TRACE (osip_trace (__FILE__, __LINE__, OSIP_INFO2, NULL, "eXosip: _eXosip_release_finished_calls remove a dialog (cid=%i did=%i)\n", jc->c_id, did));


    /* Remove existing reference to the dialog from transactions! */

    _eXosip_call_remove_dialog_reference_in_call (jc, jd);

    REMOVE_ELEMENT (jc->c_dialogs, jd);

    _eXosip_dialog_free (excontext, jd);

    return OSIP_SUCCESS;











From: Aymeric Moizard [mailto:address@hidden]
Sent: Dienstag, 20. Juni 2017 13:59

To: FEICHTER Christoph
Cc: address@hidden
Subject: Re: implicit subscription


Hi Christoph,


I have made additionnal minor modification and I think the patch

is 100% ready for integration.


The change:


When receiving OR sending a BYE after a REFER, the "dialog" is kept.

This change allow to still accept NOTIFY after receiving OR sending a



When receiving the final NOTIFY with reason=terminated, the dialog is

released immediatly and CALL_RELEASE will happen.


If no NOTIFY with terminated is received, the CALL_RELEASE will

still happen once the subscription is expired.


Please review the attached v4 patch and let me know. I will then







2017-06-17 15:18 GMT+02:00 Aymeric Moizard <address@hidden>:

Hi Christoph,


This is a V3 patch.


The patch looks more consistent compared to what I was



I think there might still be minor issue, but should be 95%



What do you think?




2017-06-12 12:04 GMT+02:00 FEICHTER Christoph <address@hidden>:

hi aymeric,


yes, that’s exactly what my intention was with the patch.


in pseudo code:

IF (an implicit subscription is active)

  BYE triggers only EXOSIP_CALL_CLOSED

  NOTIFY (state=terminated) triggers EXOSIP_CALL_RELEASED   


  behaviour remains as before





From: Aymeric Moizard [mailto:address@hidden]
Sent: Montag, 12. Juni 2017 11:26

To: FEICHTER Christoph
Cc: address@hidden
Subject: Re: implicit subscription


I have read the patch quickly and I think it is still not what I want.

May be closer ;)


About EXOSIP_CALL_RELEASED: this event is supposed to happen 

for ANY call, whatever it was estbalished or not. And it indicates that

ALL ressources (and not part of them) were released.


I will try to be more precise in my next email.





2017-06-10 7:41 GMT+02:00 FEICHTER Christoph <address@hidden>:

hi aymeric,


thanks for your input.


it’s clear so far for the meaning of EXOSIP_CALL_CLOSED;

I have adapted the patch accordingly.


you are right regarding the timeout.

The idea to implement this timeout in the app – and call eXosip_call_remove on timeout –

was not so good for exisiting applications; I moved it into eXosip.

The default is 60 sec. but could also made configureable using eXosip_set_option.



If the timeout of an implicit subscription happens, EXOSIP_CALL_RELEASED

is now sent. I was just wondering why this event is not consistently

called when the call-context is released inside eXosip.

As far as I know this event is only used for

-          cancelling a call, at the callee

-          sending an INVITE failure, also at the callee


btw: I am doing it now without this new function eXosip_call_remove,

since the timeout is no more up to the application.


see my new attempt attached.

what do you think about this second try ?






From: Aymeric Moizard [mailto:address@hidden]
Sent: Donnerstag, 08. Juni 2017 14:34

To: FEICHTER Christoph
Cc: address@hidden
Subject: Re: implicit subscription



2017-06-07 16:33 GMT+02:00 FEICHTER Christoph <address@hidden>:

hi aymeric,


Hi Christoph


Tks for the patch! Here are my comments:

First, I think it's important to make sure current application

won't get affected by the new behavior.


1/ EXOSIP_CALL_CLOSED should remain as it should fire

"at the same time" as before. (when receving BYE).


sidenote: even if dialog is still alive, the "call" can be

considered CLOSED. CLOSED is something related

to audio/video/media being active or not.


2/ the same is true for EXOSIP_CALL_RELEASED


sidenote: RELEASED is an event that allow to verify

that resource are RELEASED internally. If you remove

it for some use-case, it will break this idea. And currently

it would introduce leaks into all my apps ;)


3/ If I'm correct, an implicit subscription has a timeout

and I was expecting this "expires" to be the exact reason

for delaying the "dialog deletion" and the RELEASED event.


In your proposed change, there is no "delay" idea. It's just ON

and OFF.


Thus, it would introduce some leak risk: if the APP don't call

"eXosip_call_remove", the context would remain. (existing app

would suffer much from this)




According to me, the new variable "implicitSubscriptionActive" 

should be something like implicitSubscriptionExpireTime and should

contains the time subscription will expire. Once expires, the

dialog would be internally deleted and EXOSIP_CALL_RELEASED

would fire.


What do you think?




see the attached git-diffs

for a try to keep calls in terminated state

to be able to send an receive NOTIFY requests for implicit subscriptions.


I set the flag ‘implicitSubscriptionActive’

in case of REFER requests as well as NOTIFY requests.


please have a look and give me some feedback.






From: Aymeric Moizard [mailto:address@hidden]
Sent: Samstag, 06. Mai 2017 11:29
To: FEICHTER Christoph
Subject: RE: implicit subscription




Le 6 mai 2017 9:38 AM, "FEICHTER Christoph" <address@hidden> a écrit :

hi aymeric,


thanks for your information and assessment.


I think the logic for keeping a dialog alive must be even more intelligent;

it should be:

-          there was a REFER transaction

-          there was a NOTIFY transaction

-          the subscription state of the last NOTIFY was NOT “terminated”


That was exactly what I meant by: "to be complete" ;)


because in case the call to the transfer target has been completed

before the BYE between transferor and transferee, the dialog can be release as it works now.


I will give this a try and see, how we could add this to eXosip.

… and send you a patch for review ;-)









From: Aymeric Moizard [mailto:address@hidden]
Sent: Freitag, 05. Mai 2017 16:08
To: FEICHTER Christoph
Subject: Re: implicit subscription


Hi Christoph,


Unfortunatly, there is no support for sending a NOTIFY

after a BYE has been received or sent.


I have the feeling that it would require a minor modification

to "_eXosip_release_finished_calls". 


If a REFER transaction exist, we could decide to maintain

the dialog for a period. Even a static period could be useful

and enough simple to make it possible. To be complete,

it would require to analyse NOTIFY, if any....


In pseudo-code, if REFER exists, then returns 0 (and do

not delete the dialog.)






2017-05-03 15:22 GMT+02:00 FEICHTER Christoph <address@hidden>:

hi aymeric,


how is it intended to generate a NOTIFY request of an

implicit subscription, which is sent after the original call is already terminated ?


the scenario which I address is shown here:


the NOTIFY request that I mean is message #15.


such a NOTIFY request after the BYE,

shall it be built as out-of-dialog request ? (using eXosip_message_build_request)

or is there a mechanism in eXosip to keep the call alive,

when there is an implicit subscription active ?


















Attachment: git_diff_implicit-subscription_v5.patch
Description: git_diff_implicit-subscription_v5.patch

reply via email to

[Prev in Thread] Current Thread [Next in Thread]