Hi, thanks for responding
it's centos 7 and gcc 4.8.5.
What should be the best corrective actions? Is it not compatible with
Centos7?
On Sat, Nov 25, 2023 at 12:37 AM Daniel-Constantin Mierla
wrote:
> Hello,
>
> what OS and gcc version do you have?
>
> Some old gcc version "mistakenly"
Hello,
during the Kamailio Development Meeting that took place in Dusseldorf
earlier this month, one topic was related to administrative tasks
related to project development and management, how to
simplify/automatize such tasks.
To reduce the work load on volunteering contributors, GitHub
Hi Daniel
> the B should not do record_route() when forwards back INVITE to A.
Right, moving record_route() from the beginning of request_route{} to
the branch routes requiring this, solved this for the RR header on my
registrar node.
> Via is for routing back replies, if you remove it, node B
Hello,
On 27.11.23 14:04, Benoit Panizzon via sr-users wrote:
> Hi List
>
> Two Kamailio Nodes situation.
>
> Node A: Routing Instance.
> Node B: Registrar Instance.
>
> An invite is sent from Node A to B.
>
> Customer registered on B is 'busy' as example.
>
> B initiates Call Forwarding by
Hi Alex
> If you're having to think about how to do things that break basic SIP
> semantics, it may be time to rethink your design.
:-) We went into production far down that rabbit hole now. It would be
quite hard to pull out from that far in.
> More particularly, passing requests from A to B
If you're having to think about how to do things that break basic SIP
semantics, it may be time to rethink your design.
More particularly, passing requests from A to B back to A, when A and B are
both proxies, is problematic. It will lead to potential call loops if the
request should find
Hi List
Two Kamailio Nodes situation.
Node A: Routing Instance.
Node B: Registrar Instance.
An invite is sent from Node A to B.
Customer registered on B is 'busy' as example.
B initiates Call Forwarding by adding a Diversion Header and sending
the Invite back to A with a new R-URI towards the
Hello,
we should consider an online devel meeting sometime soon to summarize
what was done at (and still needs to be done after) devel meeting in
Dusseldorf and plan a bit the targets for next major release (5.8 or 6.0)?
If considered useful, I propose Dec 5 at 15:00UTC (16:00
