Could you show messge flow in the sngrep?
Which command used to start sipp for UAC and UAS? (-t t1 or -t tn)
On Mon, Dec 5, 2022 at 10:26 PM Jawaid Bazyar <baz...@gmail.com> wrote:
> Hello Sergey,
>
>
>
> That did seem to help serialize the messages at 1000 cps – using
> t_relay_to_tcp for outbound routing. At higher cps rates (2000 cps and up)
> I did get some call failures again.
>
>
>
> I will have to give some consideration as to implications of this model –
> in my application, I will have a relatively static community of SIP agents
> talking to the proxy (maximum of a few thousand), with pretty high volume
> from each speaker. This would mean a relatively manageable “thousands” of
> TCP connections spread out over several clusters.
>
>
>
>
>
>
>
> *From: *sr-users <sr-users-boun...@lists.kamailio.org> on behalf of
> Sergey Safarov <s.safa...@gmail.com>
> *Reply-To: *"Kamailio (SER) - Users Mailing List" <
> sr-users@lists.kamailio.org>
> *Date: *Monday, December 5, 2022 at 11:59 AM
> *To: *"Kamailio (SER) - Users Mailing List" <sr-users@lists.kamailio.org>
> *Subject: *Re: [SR-Users] Packet processing order
>
>
>
> Could you try TCP/TLS transport?
>
>
>
> In this case, packets will be ordered back at the TCP/TLS transport level.
>
>
>
> On Mon, Dec 5, 2022 at 9:35 PM Jawaid Bazyar <baz...@gmail.com> wrote:
>
> Hi,
>
>
>
> I have experienced out of order packet processing when testing a simple
> Kamailio config.
>
>
>
> The configuration is as follows, basically:
>
>
>
> request_route{
>
> record_route();
>
>
>
> enum_query();
>
> xlog("INVITE ENUM query - To URI $tU");
>
> forward();
>
> }
>
>
>
> I saw this thread from 2020:
>
>
>
> https://www.mail-archive.com/sr-users@lists.kamailio.org/msg11786.html
>
>
>
> The issue seems to be that kamailio process scheduling is naïve – i.e.,
> incoming SIP packets are processed without regard to whether packets
> received before this one, are currently being processed. This means any
> packets after the initial INVITE that require more processing, can get
> reordered.
>
>
>
> In my test lab I have:
>
> SIPp – UAC
>
> Kamailio Proxy
>
> SIPp – UAS
>
>
>
> The proxy uses enum NAPR lookups to route calls to +13038151000 to the UAS.
>
>
>
> Now, if I do SIPp UAC o SIPp UAS directly, I have no problems – no out of
> order packets.
>
>
>
> It is only when I introduce Kamailio in the middle that I get OOO packets.
>
>
>
> See the images attached: uac-to-proxy, proxy, and proxy-to-uas.
>
>
>
> In this example, Kamailio OOO causes SIPp UAC to fail to “generate audio”
> – because UAC does not see packets in the correct order, I never turns on
> the simulated audio. Calls that have in-order dialogs, work fine, and SIPP
> UAC “pauses” 10 seconds to simulate a phone call.
>
>
>
> So far, the error rate runs from 1/1000 to around 1/200 – pretty bad.
>
>
>
>
>
> In the thread, a few things were suggested.
>
>
>
> Have fewer kamailio processes than cores:
>
> Did not resolve issue.
>
>
>
> Try route_locks_size = 256
>
> Did not resolve issue. Though, it did alter it somewhat.
> But, it is not clear to me how this works – would this setting restrict the
> number of open calls to 256?
>
>
>
> Have only one kamailio process: (“children=1”)
>
> This works. “Works”, I should say, because this would
> greatly restrict total platform scalability to a point where it is probably
> useless for my application.
>
>
>
>
>
> I saw the same issue discussed in the OpenSIPS mailing list from 2010, and
> the response was “this is not a bug”.
>
>
>
> Well, I respectfully beg to differ with both OpenSIPS and Kamailio – it IS
> a bug. I don’t think a proxy should reorder packets involved in a call in a
> non-deterministic way. In the Kamailio list thread, Alex Balashov discusses
> the contortions he has to go through to avoid repercussions from this issue.
>
>
>
> Kamailio as-is probably works fine for relatively low-volume operations.
> And a lot of the feedback is “why are out of order packets a problem?” OK,
> sure, in the very specific example given in the 2020 thread, maybe who
> cares. But in my thinking, there is absolutely nothing preventing Kamailio
> from generating much more serious OOO scenarios that would cause calls to
> fail. In my example, Kamailio OOO causes SIPp to fail to “generate audio”.
> Who knows how other SIP stacks will behave?
>
>
>
> But the more one will try to scale Kamailio, the more significantly this
> out of order processing issue will become.
>
>
>
> The solution to this seems very simple and straightforward – put packets
> to be processed into a queue PER Call-ID, or something along those lines.
>
>
>
> In short, the parallelism should be by call, not by packet.
>
>
>
> What say ye? Have I misunderstood something here?
>
>
>
> Cheers,
>
>
>
> Jawaid
>
>
>
>
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> __________________________________________________________ Kamailio -
> Users Mailing List - Non Commercial Discussions
> sr-users@lists.kamailio.org Important: keep the mailing list in the
> recipients, do not reply only to the sender! Edit mailing list options or
> unsubscribe: https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
Edit mailing list options or unsubscribe:
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
