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
ELSE
behaviour remains as before
br,
christoph
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.
Regards
Aymeric
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.
regarding
EXOSIP_CALL_RELEASED:
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 ?
br,
christoph
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)
MODIFICATION REQUIRED:
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?
Regards
Aymeric
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.
br,
christoph
From: Aymeric Moizard [mailto:address@hidden]
Sent: Samstag, 06. Mai 2017 11:29
To: FEICHTER Christoph
Cc: address@hidden
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 ;-)
Great!
Ay
br,
christoph
From: Aymeric Moizard [mailto:address@hidden]
Sent: Freitag, 05. Mai 2017 16:08
To: FEICHTER Christoph
Cc: address@hidden
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.)
Regards
Aymeric
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:
http://www.tech-invite.com/fo-sip/tinv-fo-sip-service-04.html#top
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 ?
regards,
christoph
--
Antisip - http://www.antisip.com
--
Antisip
- http://www.antisip.com
--
Antisip -
http://www.antisip.com