[SR-Users] Parallel forking and rtpengine handling

[George Diamantopoulos]

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 at sipgate.de> wrote:

> Hi,
>
> On Wed, Jan 22, 2020 at 8:29 PM Daniel-Constantin Mierla
> <miconda at 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 at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200124/ba22071f/attachment.html>