Alex Balashov writes:

‎As far as I know, there is not a way to do this. It's a limitation we've run into before as well, and it probably arises from the fact that the branch GUID generator isn't run until t_relay() is called.

Thanks for your reply.

How about the index of the next new via branch, i.e., the digit after the . at the end of branch value (1 in the example below):

SIP/2.0/TCP 192.98.102.10;branch=z9hG4bK27b9.597e97c43da7ddd6be8520b662d616b9.1;i=5

-- Juha

There is already something related to the branch in the rtpproxy function flags, see:

- http://kamailio.org/docs/modules/stable/modules/rtpproxy.html#idp125632

Cheers, Daniel

On 28/05/15 11:41, Juha Heinanen wrote:

Alex Balashov writes:

...

‎As far as I know, there is not a way to do this. It's a limitation we've run into before as well, and it probably arises from the fact that the branch GUID generator isn't run until t_relay() is called.

Thanks for your reply.

How about the index of the next new via branch, i.e., the digit after the . at the end of branch value (1 in the example below):

SIP/2.0/TCP 192.98.102.10;branch=z9hG4bK27b9.597e97c43da7ddd6be8520b662d616b9.1;i=5

-- Juha

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Alex Balashov writes:

...

There is already something related to the branch in the rtpproxy function flags, see:

-http://kamailio.org/docs/modules/stable/modules/rtpproxy.html#idp125632

Indeed. As I understand the documentation, this uses the incoming branch ID/Via added by the previous hop, correct?

Yes, and my test verifies it. Even when I call rtpengine_offer after t_relay in branch route with via-branch value 1 (= first via header), I still get the incoming via header branch id as the value of via-branch option.

-- Juha

Daniel-Constantin Mierla writes:

There is already something related to the branch in the rtpproxy function flags, see:

• http://kamailio.org/docs/modules/stable/modules/rtpproxy.html#idp125632

rtpproxy flags 1, 2, 3, and b correspond to rtpengine via-branch values 1, 2, auto, and extra.

the question is if 3 or extra is used, what value can be assigned to extra_id_pv to uniquely identify the next branch to be created by t_relay().

-- juha

Alex Balashov writes:

Is there a reason you specifically need to identify the next branch, rather than operating on the ID of an incoming branch?

Branch id of incoming branch is unique for the whole call. If the call parallel forks and I call rtpengine_offer for each branch, I need to be able to call rtpengine_delete for the failed branches only.

My understanding from the rtpengine README is that if would use branch id of the incoming branch in the offers, I could not delete single failed branches, because rtpengine_delete on the incoming branch id would delete the whole call.

-- Juha

Alex Balashov writes:

Oh, I see. I would agree with your interpretation of the documentation, but that would render such a feature rather useless, since, as you point out, this does not expose branch-level control. So, I'm wondering if the documentation is perhaps unclear about what it really does.

As I mentioned in the previous message, my test shows that README is correct in that via-branch values 1 and 2 refer to incoming via headers. That is why there exists the extra value, which allows taking via-branch value from "extra_id_pv" variable.

The question has been, what value could I assign to extra_id_pv to uniquely identify the branch. Since $T_branch_idx exists, perhaps a good choice could be $sel(via[1].branch) + $T_branch_idx.

-- Juha

Alex Hermann writes:

That would work. Just remember to store the value you use somewhere (RR-param or $sht) to be able to tear down the session when a BYE comes in.

i don't think that that is necessary. based on my observations, at bye rtpengine_delete() does the job.

-- juha