|Subject:||Re: [osip-dev] implicit subscription|
|Date:||Mon, 12 Jun 2017 10:04:06 +0000|
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
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>:
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 ?
2017-06-07 16:33 GMT+02:00 FEICHTER Christoph <address@hidden>:
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
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
What do you think?
|[Prev in Thread]||Current Thread||[Next in Thread]|