28 May
2015
28 May
'15
5:11 a.m.
when kamailio forwards invite request, it adds to it a new via header.
for example, incoming invite:
SIP/2.0/TCP 192.168.43.192:48089;branch=z9hG4bK4e1ab219cbde6190;rport
outgoing invite:
SIP/2.0/TCP 192.98.102.10;branch=z9hG4bK27b9.597e97c43da7ddd6be8520b662d616b9.0;i=5
SIP/2.0/TCP
192.168.43.192:48089;received=192.98.102.10;branch=z9hG4bK4e1ab219cbde6190;rport=49582
is it somehow possible to find out in the config script, what will the
branch value of the new via header be?
if that value would be known, it could be assigned to rtpengine
extra_id_pv pseudo variable before making the offer and could then be
used in rtpengine_delete to delete the right branch.
if the new via branch value cannot be known, any suggestions on how to
uniquely identify the outgoing branched of the invite?
-- juha
28 May
28 May
5:23 a.m.
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.
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Sent from my BlackBerry.
5:41 a.m.
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
5:43 a.m.
That you can get. :-)
http://www.kamailio.org/wiki/cookbooks/4.2.x/pseudovariables#t_branch_idx
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Sent from my BlackBerry.
Original Message
From: Juha Heinanen
Sent: Thursday, May 28, 2015 11:41
To: Kamailio (SER) - Users Mailing List
Reply To: Kamailio (SER) - Users Mailing List
Subject: Re: [SR-Users] next via branch value
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5:44 a.m.
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:
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, May 27-29, 2015
Berlin, Germany - http://www.kamailioworld.com
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5:52 a.m.
On 05/28/2015 05:44 AM, Daniel-Constantin Mierla wrote:
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?
As far as I know, there is no reason why this should not work for Juha's
aspiration, which I understood to be branch-granular rtpproxy forwarding
control.
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
6:20 a.m.
Alex Balashov writes:
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
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?
6:21 a.m.
On 05/28/2015 06:20 AM, Juha Heinanen wrote:
Alex Balashov writes:
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.
Indeed, and my glance at the source code confirms that all these
functions operate on the incoming message body.
Well, that is puzzling...
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
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?
6 a.m.
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
6:03 a.m.
On 05/28/2015 06:00 AM, Juha Heinanen wrote:
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().
Is there a reason you specifically need to identify the next branch,
rather than operating on the ID of an incoming branch?
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
6:16 a.m.
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
6:19 a.m.
On 05/28/2015 06:16 AM, Juha Heinanen wrote:
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.
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.
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
6:31 a.m.
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
1 Jun
1 Jun
6:25 a.m.
On Thursday 28 May 2015, Juha Heinanen wrote:
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.
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.
--
Greetings,
Alex Hermann
3548
days inactive
3552
days old
14 comments
4 participants
participants (4)
-
Alex Balashov -
Alex Hermann -
Daniel-Constantin Mierla -
Juha Heinanen