[OpenSIPS-Users] Trouble with forked calls and rtpengine

[Robert Dyck]

As mentioned in one of my previous notes I use via-branch=extra and set the 
avp to $T_branch_idx. That solved my problem. I had doubts about sequential 
INVITEs because the index would always be 0 and the call may have been 
establihed with a different index. My testing with rtpenigine debug logs showed 
that after the totag gets installed by the initial answer, via-branch is 
ignored. So no problem.

My concern now is with the documentation. via-branch=1 or 2 for answer do 
nothing for forked calls. Omitting via-branch accomplishes the same thing.
Because with via-branch=1 the result is identical for each branch, rtpengine 
just overwrites whatever flags it has already received.

In the documentation the bit about via-branch could be eliminated and opensips 
could arbitrarily set it to the branch index. It would work whether the call 
forked or not. If we actually wanted the via branch that opensips sends 
downstream we would need some mechanism that made it available to the script. 
The branch index is enough however so it's not worth the bother.
In general, opensips has no interest in a transaction ID from an upstream 
node. It is only of interest to that node.

On Friday, February 4, 2022 3:06:40 A.M. PST Răzvan Crainea wrote:
> Hi, Robert!
> 
> For a request, VIA 1 is always the previous hop - therefore, if you want
> to have different offer messages, you need to use something else - my
> proposal is to use the via-branch=3 and set the extra_avp to
> $T_branch_idx. You can do the same thing for replies, and that should
> cover all cases.
> 
> Best regards,
> 
> Răzvan Crainea
> OpenSIPS Core Developer
> http://www.opensips-solutions.com
> 
> On 1/27/22 19:23, Robert Dyck wrote:
> > Opensips adds its via ( with branch info ) after script processing but
> > before forwarding. Opensips branch info is not available to the script
> > when processing an INVITE. I have attached some text of an INVITE with
> > rtpengine and with "offer via-branch=1". What rtpengine receives is the
> > branch parameter added by the upstream node. The upstream node has no
> > knowledge of any forking that may occur after lookup.
> > 
> > The branch parameter is a legacy of rfc2543. That rfc stated that a
> > forking
> > proxy would add branch info in a via parameter called branch. This
> > parameter could be added by any hop but is ignored. It was only
> > meaningful in a response received by the forking proxy.
> > 
> > Rfc3261 retained the via parameter name, I assume for compatibility.
> > Rfc3261 was clear however that "branch" was now a transaction ID. This is
> > only of interest to the node that added it in a request. Now in the case
> > of a forking proxy the branch parameter has the dual role of being a
> > transaction ID and a branch ID. Opensips does this by adding the branch
> > index as a suffix to the transaction ID.
> > 
> > The opensips script may not have access to the eventual transaction ID but
> > the branch index is available. Passing the branch index to rtpengine
> > causes it to create a different profile for each branch rather than
> > stacking the profiles. That stacking was causing trouble for me.
> > 
> > When rtpengine is simply providing a public address to relay media the
> > stacking does not appear to have any consequence. However when mixing
> > WEBRTC and non-WEBRTC stacking the profiles in a single entry in
> > rtpengine gives inconsistent results.
> > 
> > On Thursday, January 27, 2022 3:57:07 A.M. PST Răzvan Crainea wrote:
> >> Hi, Robert!
> >> 
> >> Are you sure that via-branch=2 does not set different branches, and sets
> >> the same param as via-branch=1?
> >> If you are going to use the extra_id_pv, you should make sure that you
> >> persist it over dialog, i.e. also provide it during sequential
> >> offer/answer/delete commands.
> >> 
> >> Best regards,
> >> 
> >> 
> >> _______________________________________________
> >> Users mailing list
> >> Users at lists.opensips.org
> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users