18 Jul
2017
18 Jul
'17
9:53 p.m.
If Request-URI hostpart is a domain name with more than one SRV record,
it appears that each SRV destination creates its own Kamailio branch.
If branch route is set before t_relay(), it is executed only on the
first SRV destination. If the first SRV destination fails, Kamailio
tries automatically the second one, but any branch flags set in the
branch route are lost.
What is the simplest way to make Kamailio preserve the stuff set in the
branch route for all SRV destinations?
-- Juha
19 Jul
19 Jul
9:09 a.m.
Juha Heinanen writes:
If Request-URI hostpart is a domain name with more
than one SRV record,
it appears that each SRV destination creates its own Kamailio branch.
If branch route is set before t_relay(), it is executed only on the
first SRV destination. If the first SRV destination fails, Kamailio
tries automatically the second one, but any branch flags set in the
branch route are lost.
Is the above the intended behavior in general? It seems a bit weird
that K does automatic serial forking to SRV destinations without
executing the branch route set before t_relay() for each of them.
-- Juha
10:22 a.m.
On 19.07.17 09:09, Juha Heinanen wrote:
Juha Heinanen writes:
AFAIK, this was the implementation from the first time of DNS SRV serial
forking.
Btw, is the branch index changed, or is reusing the same branch (is the
branch param in Via chaging for each leg sent out)?
Anyhow, changing the current behaviour would require c coding in tm.
Probably not that much.
Due to poor implementation of DNS SRV in the past and problems with
propagation, I tried to avoid it as much as possible. But I have several
deployments where it works fine, so all should be ok with it, however I
didn't need any customization for related branches.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com
If Request-URI hostpart is a domain name with
more than one SRV record,
it appears that each SRV destination creates its own Kamailio branch.
If branch route is set before t_relay(), it is executed only on the
first SRV destination. If the first SRV destination fails, Kamailio
tries automatically the second one, but any branch flags set in the
branch route are lost.
Is the above the intended behavior in general? It seems a
bit weird
that K does automatic serial forking to SRV destinations without
executing the branch route set before t_relay() for each of them.
10:23 a.m.
I did more some more tests.
The branch route was properly executed before INVITE to the first SRV
destination was sent. The branch route set some headers, branch flags,
etc. After the first SRV destination failed, INVITE was sent to the
second SRV destination and the branch route was not re-executed. In the
second INVITE, headers that were added in branch route were correctly
preserved. However, branch flags that were set in the branch route were
not preserved. As result, processing of positive reply from the second
srv destination failed.
This looks like a bug to me. Also branch flags that were set in the
branch route before the first INVITE was sent out should have been
preserved for processing of the second INVITE.
-- Juha
10:27 a.m.
On 19.07.17 10:23, Juha Heinanen wrote:
I did more some more tests.
The branch route was properly executed before INVITE to the first SRV
destination was sent. The branch route set some headers, branch flags,
etc. After the first SRV destination failed, INVITE was sent to the
second SRV destination and the branch route was not re-executed. In the
second INVITE, headers that were added in branch route were correctly
preserved. However, branch flags that were set in the branch route were
not preserved. As result, processing of positive reply from the second
srv destination failed.
This looks like a bug to me. Also branch flags that were set in the
branch route before the first INVITE was sent out should have been
preserved for processing of the second INVITE.
Is the branch parameter in the top Via of the second INVITE sent out
different than for the first INVITE (last digit incremented by 1 or so)?
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com
10:44 a.m.
Daniel-Constantin Mierla writes:
Is the branch parameter in the top Via of the second
INVITE sent out
different than for the first INVITE (last digit incremented by 1 or
so)?
Thanks for your reply. Yes it is:
In the first INVITE:
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bKa049.25c648aa425f43b7b2382d86a63054bb.0;i=1.
In the second INVITE:
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bKa049.25c648aa425f43b7b2382d86a63054bb.1;i=1.
-- Juha
10:51 a.m.
On 19.07.17 10:44, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
OK, so it is creating a new branch structure. That could explain why the
branch flags from previous INVITE are not there. If it is only the
branch flags missing (and the headers changes are already propagated), I
expect to be an easy patch. I will look into it very soon if nobody else
does it meanwhile.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com
Is the branch parameter in the top Via of the
second INVITE sent out
different than for the first INVITE (last digit incremented by 1 or
so)?
Thanks for your reply. Yes it is:
In the first INVITE:
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bKa049.25c648aa425f43b7b2382d86a63054bb.0;i=1.
In the second INVITE:
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bKa049.25c648aa425f43b7b2382d86a63054bb.1;i=1.
11 a.m.
Daniel-Constantin Mierla writes:
OK, so it is creating a new branch structure. That
could explain why the
branch flags from previous INVITE are not there. If it is only the
branch flags missing (and the headers changes are already propagated), I
expect to be an easy patch. I will look into it very soon if nobody else
does it meanwhile.
I did more checking and looks like only branch flags are gone. In
addition to adding headers and setting branch flags, branch route adds
record-route params using add_rr_param calls and also those params are
preserved in the second INVITE.
-- Juha
11:15 a.m.
On 19.07.17 11:00, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Sounded rather simple, so I did a quick search in the code and just
pushed a patch for it -- very small, but hopefully it fixes this. If all
tests are fine for you, then you can backport as needed to stable branches.
Cheers,
Daniel
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - www.kamailioworld.com
OK, so it is creating a new branch structure.
That could explain why the
branch flags from previous INVITE are not there. If it is only the
branch flags missing (and the headers changes are already propagated), I
expect to be an easy patch. I will look into it very soon if nobody else
does it meanwhile.
I did more checking and looks like only branch flags are gone.
In
addition to adding headers and setting branch flags, branch route adds
record-route params using add_rr_param calls and also those params are
preserved in the second INVITE.
11:24 a.m.
Daniel-Constantin Mierla writes:
Sounded rather simple, so I did a quick search in the
code and just
pushed a patch for it -- very small, but hopefully it fixes this. If all
tests are fine for you, then you can backport as needed to stable branches.
Thanks, will test and backport.
-- Juha
12:26 p.m.
Daniel,
After your patch, branch flags are now preserved to the second SRV
destination. Thanks,
-- Juha
4:35 p.m.
Just curious, in what version of Kamailio would this patch be implemented?
is the backport to previous versions automatic or do we have to manually
apply and build?
Cheers,
Joel.
On Wed, Jul 19, 2017 at 3:26 AM, Juha Heinanen <jh(a)tutpro.com> wrote:
Daniel,
After your patch, branch flags are now preserved to the second SRV
destination. Thanks,
-- Juha
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
5:15 p.m.
Joel Serrano writes:
Just curious, in what version of Kamailio would this
patch be implemented?
is the backport to previous versions automatic or do we have to manually
apply and build?
I think backports are usually done on per need basis. So if you need
this patch in some version earlier that 5.0, you can backport it.
-- Juha
8:54 p.m.
Thanks for the info!
On Wed, Jul 19, 2017 at 8:15 AM, Juha Heinanen <jh(a)tutpro.com> wrote:
Joel Serrano writes:
Just curious, in what version of Kamailio would
this patch be
implemented?
is the backport to previous versions automatic or
do we have to manually
apply and build?
I think backports are usually done on per need basis. So if you need
this patch in some version earlier that 5.0, you can backport it.
-- Juha
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2479
days inactive
2480
days old
13 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
Joel Serrano -
Juha Heinanen