rtpengine-offer function documentation tells this about via-branch flag:
via-branch=... - Include the “branch” value of one of the “Via” headers in the request to the RTP proxy. Possible values are: “1” - use the first “Via” header; “2” - use the second “Via” header; “auto” - use the first “Via” header if this is a request, or the second one if this is a reply; “extra” - don't take the value from a header, but instead use the value of the “extra_id_pv” variable. This can be used to create one media session per branch on the RTP proxy. When sending a subsequent “delete” command to the RTP proxy, you can then stop just the session for a specific branch when passing the flag '1' or '2' in the “rtpengine_delete”, or stop all sessions for a call when not passing one of those two flags there. This is especially useful if you have serially forked call scenarios where the RTP proxy gets an “offer” command for a new branch, and then a “delete” command for the previous branch, which would otherwise delete the full call, breaking the subsequent “answer” for the new branch.
Is the note about "serial forking" correct or should it be about "parallel forking" instead? In case of serial forking, it would not matter if the whole call is deleted, because a new offer would be issued for the next branch. Or perhaps I just don't understand the meaning of the note?
-- Juha
Hi,
On Tue, Jul 18, 2017 at 9:42 AM, Juha Heinanen jh@tutpro.com wrote:
Is the note about "serial forking" correct or should it be about "parallel forking" instead? In case of serial forking, it would not matter if the whole call is deleted, because a new offer would be issued for the next branch. Or perhaps I just don't understand the meaning of the note?
If the proxy that does the parallel forking is the same that issues the rtpengine call, it shouldn't matter because there won't be a delete command for the cancelled branch. If you have a scenario where the proxy sends out multiple branches and for example a load balancer does the rtpengine stuff, then the load balancer should use the via branch flag or the cancelled branch will kill the call.
In serial forking, the new INVITE could go out before the CANCEL is sent out. If that happens, the Via branch is needed to not kill the whole call.
So one can think of scenarios with both serial and parallel forking, where the via-branch flag can be useful.
Regards, Sebastian
Sebastian Damm writes:
In serial forking, the new INVITE could go out before the CANCEL is sent out. If that happens, the Via branch is needed to not kill the whole call.
There would not be a CANCEL when a serial branch returns negative response. In the case where waiting for final response from a branch times out, there would be cancel, but also a proxy generated negative response. I would think that in both cases it is safe to delete the whole call in failure route and then make a new rtpengine-offer.
-- Juha
-
Juha Heinanen -
Sebastian Damm