Hi,
our scenario is the following: We have two clients registered to our Kamailio server, one with a TLS capable phone, one via websocket. Now, when a call comes in, the call is forked and is sent out to both clients. rtpengine handling is done in the branch route, so there are two offers, and we use the "via-branch" parameter.
Now, when one branch answers the call, what happens to the other branch? I there a way to delete the other branch? How and in which route? Or does Kamailio do this automatically?
I'm happy for a hint.
Regards, Sebastian
On 22/01/2020 11.06, Sebastian Damm wrote:
Hi,
our scenario is the following: We have two clients registered to our Kamailio server, one with a TLS capable phone, one via websocket. Now, when a call comes in, the call is forked and is sent out to both clients. rtpengine handling is done in the branch route, so there are two offers, and we use the "via-branch" parameter.
Now, when one branch answers the call, what happens to the other branch? I there a way to delete the other branch? How and in which route? Or does Kamailio do this automatically?
You do it the same way as you handle an answer: You issue a delete with the via-branch option.
Cheers
On Wed, 22 Jan 2020 at 18:28, Richard Fuchs rfuchs@sipwise.com wrote:
On 22/01/2020 11.06, Sebastian Damm wrote:
Hi,
our scenario is the following: We have two clients registered to our Kamailio server, one with a TLS capable phone, one via websocket. Now, when a call comes in, the call is forked and is sent out to both clients. rtpengine handling is done in the branch route, so there are two offers, and we use the "via-branch" parameter.
Now, when one branch answers the call, what happens to the other branch? I there a way to delete the other branch? How and in which route? Or does Kamailio do this automatically?
You do it the same way as you handle an answer: You issue a delete with the via-branch option.
Doesn't this happen automatically when one uses rtpengine_manage() in the failure_route?
Cheers
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
It is. In this case manage = delete
On Wed, 22 Jan 2020, 19:16 George Diamantopoulos, georgediam@gmail.com wrote:
On Wed, 22 Jan 2020 at 18:28, Richard Fuchs rfuchs@sipwise.com wrote:
On 22/01/2020 11.06, Sebastian Damm wrote:
Hi,
our scenario is the following: We have two clients registered to our Kamailio server, one with a TLS capable phone, one via websocket. Now, when a call comes in, the call is forked and is sent out to both clients. rtpengine handling is done in the branch route, so there are two offers, and we use the "via-branch" parameter.
Now, when one branch answers the call, what happens to the other branch? I there a way to delete the other branch? How and in which route? Or does Kamailio do this automatically?
You do it the same way as you handle an answer: You issue a delete with the via-branch option.
Doesn't this happen automatically when one uses rtpengine_manage() in the failure_route?
Cheers
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On 22/01/2020 13.15, George Diamantopoulos wrote:
On Wed, 22 Jan 2020 at 18:28, Richard Fuchs <rfuchs@sipwise.com mailto:rfuchs@sipwise.com> wrote:
On 22/01/2020 11.06, Sebastian Damm wrote: > Hi, > > our scenario is the following: We have two clients registered to our > Kamailio server, one with a TLS capable phone, one via websocket. Now, > when a call comes in, the call is forked and is sent out to both > clients. rtpengine handling is done in the branch route, so there are > two offers, and we use the "via-branch" parameter. > > Now, when one branch answers the call, what happens to the other > branch? I there a way to delete the other branch? How and in which > route? Or does Kamailio do this automatically? You do it the same way as you handle an answer: You issue a delete with the via-branch option.Doesn't this happen automatically when one uses rtpengine_manage() in the failure_route?
I would think it does, as long as you supply the via-branch parameter.
Cheers
On 22.01.20 19:19, Richard Fuchs wrote:
On 22/01/2020 13.15, George Diamantopoulos wrote:
On Wed, 22 Jan 2020 at 18:28, Richard Fuchs <rfuchs@sipwise.com mailto:rfuchs@sipwise.com> wrote:
On 22/01/2020 11.06, Sebastian Damm wrote: > Hi, > > our scenario is the following: We have two clients registered to our > Kamailio server, one with a TLS capable phone, one via websocket. Now, > when a call comes in, the call is forked and is sent out to both > clients. rtpengine handling is done in the branch route, so there are > two offers, and we use the "via-branch" parameter. > > Now, when one branch answers the call, what happens to the other > branch? I there a way to delete the other branch? How and in which > route? Or does Kamailio do this automatically? You do it the same way as you handle an answer: You issue a delete with the via-branch option.Doesn't this happen automatically when one uses rtpengine_manage() in the failure_route?
I would think it does, as long as you supply the via-branch parameter.
A remark for kamailio transaction states point of view: in failure route the entire transaction is in failed state, so there is not active branch, so at that point it should delete all (previous) rtpengine sessions/branches.
Re-routing to a new destinations should go via a branch route where a new session is initiated in the rtpengine.
As I got it, the use of via-branch flag for deleting a session makes sense in event route for branch-failure, when other branches can still be active or one was answered.
Btw, a few questions for further clarifications: if a call has parallel forking and rtpengine offer is executed for each branch, one is answered, but the other branch-sessions are not not deleted, what does rtpengine? It times them out, or keeps them for the duration of the call?
Also in the case of parallel forking, if via-branch is not give to rtpengine offer command, does the 2nd (and the next) rtpengine offer command overwrite the previous one, so the rtpengine keeps only the data from the last one?
Cheers, Daniel
On 22/01/2020 14.26, Daniel-Constantin Mierla wrote:
Btw, a few questions for further clarifications: if a call has parallel forking and rtpengine offer is executed for each branch, one is answered, but the other branch-sessions are not not deleted, what does rtpengine? It times them out, or keeps them for the duration of the call?
Those branches would remain open. When the call is finished, it will depend on how the delete is executed: if the delete is done from the side which branched the call (side A, caller), then the entire call including other branches are deleted. If the delete is done from the opposite side (B, one of the branches), the other branches would still remain open, keeping the entire call alive. The call would then eventually time out depending on the config, but it might take a while.
Also in the case of parallel forking, if via-branch is not give to rtpengine offer command, does the 2nd (and the next) rtpengine offer command overwrite the previous one, so the rtpengine keeps only the data from the last one?
Correct, with possibly some undesired side effects depending on which flags were used (e.g codec changes).
Cheers
Hi,
On Wed, Jan 22, 2020 at 8:29 PM Daniel-Constantin Mierla miconda@gmail.com wrote:
A remark for kamailio transaction states point of view: in failure route the entire transaction is in failed state, so there is not active branch, so at that point it should delete all (previous) rtpengine sessions/branches.
This is what I had in mind. I don't think I end up in failure route if one branch is answered. My Question was, how to handle the canceled branch.
As I got it, the use of via-branch flag for deleting a session makes sense in event route for branch-failure, when other branches can still be active or one was answered.
Do branches that get cancelled due to another branch answering the call go through the branch failure route?
Also in the case of parallel forking, if via-branch is not give to rtpengine offer command, does the 2nd (and the next) rtpengine offer command overwrite the previous one, so the rtpengine keeps only the data from the last one?
We stumbled upon this problem only because we used rtpengine without the branch parameter. And what we saw was that the second rtpengine_offer overwrote the first one, making the first branch impossible to be answered in certain scenarios.
Regards and thanks for all the answers so far. Sebastian
On a side note, I think I might have found a bug for rtpengine_manage(): I'm under the impression that if called from within a branch_failure_route, it will do an offer instead of a delete. Do you confirm and is this intentional?
On Thu, 23 Jan 2020 at 11:06, Sebastian Damm damm@sipgate.de wrote:
Hi,
On Wed, Jan 22, 2020 at 8:29 PM Daniel-Constantin Mierla miconda@gmail.com wrote:
A remark for kamailio transaction states point of view: in failure route
the entire transaction is in failed state, so there is not active branch, so at that point it should delete all (previous) rtpengine sessions/branches.
This is what I had in mind. I don't think I end up in failure route if one branch is answered. My Question was, how to handle the canceled branch.
As I got it, the use of via-branch flag for deleting a session makes
sense in event route for branch-failure, when other branches can still be active or one was answered.
Do branches that get cancelled due to another branch answering the call go through the branch failure route?
Also in the case of parallel forking, if via-branch is not give to
rtpengine offer command, does the 2nd (and the next) rtpengine offer command overwrite the previous one, so the rtpengine keeps only the data from the last one?
We stumbled upon this problem only because we used rtpengine without the branch parameter. And what we saw was that the second rtpengine_offer overwrote the first one, making the first branch impossible to be answered in certain scenarios.
Regards and thanks for all the answers so far. Sebastian
-- Sebastian Damm Voice Engineer __________________________________________ sipgate GmbH Gladbacher Straße 74 | 40219 Düsseldorf
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel-Constantin Mierla -
George Diamantopoulos -
Richard Fuchs -
Sebastian Damm -
Yuriy Gorlichenko