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
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
On 19.07.17 09:09, Juha Heinanen wrote:
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.
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
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
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 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
On 19.07.17 10:44, Juha Heinanen wrote:
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.
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 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
On 19.07.17 11:00, 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.
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.
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 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
Daniel,
After your patch, branch flags are now preserved to the second SRV destination. Thanks,
-- Juha
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@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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
Thanks for the info!
On Wed, Jul 19, 2017 at 8:15 AM, Juha Heinanen jh@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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Daniel-Constantin Mierla -
Joel Serrano -
Juha Heinanen