Hello, On 08.04.20 23:03, Luis Rojas G. wrote: > Hello, Daniel, > > I looked into that parameter, but I need to use with the dialog > module, and I'm pretty afraid to use that.
who said or where is written than you need to load the dialog module? You definitely don't. Cheers, Daniel > I was looking more into the stateless proxy, because I need to process > a lot of traffic. > > My target is 4200CAPS. with duration between 90s and 210. Let's say, > 150 seconds. That would mean 630.000 simultaneous dialogs. I don't > think the solution can go that way. > > it would really help me to be able to use completely stateless proxy > plus Async in reply_route(), to introduce an artificial delay before > forwarding 200 OK to Invite.. As someone mentioned, it would help me > on request_route(), for race conditions between ACK and Re-Invite. > > Any idea why Async is not allowed in reply_route()? > > Best regards, > > Luis > > > On 4/8/20 1:07 PM, Daniel-Constantin Mierla wrote: >> >> Hello, >> >> you have to keep in mind that Kamailio is a SIP packet router, not a >> telephony engine. If 180 and 200 replies are part of a call is not >> something that Kamailio recognize at its core. Its main goal is to >> route out as fast as possible what is received, by executing the >> configuration file script. Now, a matter of your configuration file, >> processing of some SIP messages can take longer than processing >> other. And the processing is done in parallel, a matter of children >> parameter (and tcp_children, sctp_children). >> >> With that in mind, a way to try to cope better with the issue you >> face is to set route_locks_size parameter, see: >> >> * >> https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size >> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.kamailio.org%2Fwiki%2Fcookbooks%2Fdevel%2Fcore%23route_locks_size&data=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481963069&sdata=CWh4qvJwYloHLPCOFUdVXRuge3l2rvuAUDM6FBNjFMA%3D&reserved=0> >> >> Probably is what you look for. >> >> But if you want more tight constraints, like when receiving a 180 >> after a 200ok and not route it out, you have to make the logic in >> configuration file by combining modules such as dialog or htable (as >> already suggested). >> >> Cheers, >> Daniel >> >> On 08.04.20 16:04, Luis Rojas G. wrote: >>> Hi, Henning, >>> >>> No need to be ironic. As I mentioned on my first post, I tried >>> stateful proxy and I observed the same behavior. >>> >>> /"I tried using stateful proxy and I obtained the same result."/ >>> >>> The asynchronous sleep seems promising. I will look into it. >>> >>> Thanks, >>> >>> Luis >>> >>> >>> On 4/8/20 9:30 AM, Henning Westerholt wrote: >>>> >>>> Hi Luis, >>>> >>>> >>>> >>>> I see. Well, you want to use Kamailio as a stateless proxy, on the >>>> other hand it should do things that are inherently stateful. 😉 >>>> >>>> >>>> >>>> As mentioned, have a look to the dialog module to track the state >>>> of dialogs that you process. This will not work in a stateless >>>> mode, though. >>>> >>>> >>>> >>>> You can also use the htable module to just store some data about >>>> the processed messages in a shared memory table and use this to >>>> enforce your ordering. There is also the option to do an >>>> asynchronous sleep (with the async) module on the message that you >>>> want to delay but still processing other messages during it. >>>> >>>> >>>> >>>> Cheers, >>>> >>>> >>>> >>>> Henning >>>> >>>> >>>> >>>> -- >>>> >>>> Henning Westerholt – https://skalatan.de/blog/ >>>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F&data=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481973065&sdata=ISKj4Fc0FlBemyJhLFeDaXPQjpOrjIceeXURx2OccqU%3D&reserved=0> >>>> >>>> Kamailio services – https://gilawa.com >>>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgilawa.com%2F&data=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481983060&sdata=vsVGfGjX4ZgDN%2FyaxzSCmc5BHNa%2Buu0Y%2FFQLbW7ETOc%3D&reserved=0> >>>> >>>> >>>> >>>> *From:* Luis Rojas G. <[email protected]> >>>> *Sent:* Wednesday, April 8, 2020 3:00 PM >>>> *To:* Henning Westerholt <[email protected]>; Kamailio (SER) - Users >>>> Mailing List <[email protected]> >>>> *Subject:* Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF >>>> ORDER >>>> >>>> >>>> >>>> Hello, Henning, >>>> >>>> >>>> >>>> I am worried about this scenario, because it's a symptom of what >>>> may happen in other cases. For instance, I've seen that this >>>> operator usually sends re-invites immediate after sending ACK. >>>> This may create race conditions like 3.1.5 of RFC5407 >>>> >>>> https://tools.ietf.org/html/rfc5407#page-22 >>>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5407%23page-22&data=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481983060&sdata=FekMqBnzvOj4%2FVFnS9x0X5KdcA0Ov1gcb975iEzfWZE%3D&reserved=0> >>>> >>>> I'd understand that one happens because of packet loss, as it's in >>>> UDP's nature, but in this case it would be artificially created by >>>> Kamailio. if there was no problem at network level (packet loss, >>>> packets following different path on the network and arriving out of >>>> order), why Kamailio creates it? >>>> >>>> I'd expect that the shared memory is used precisely for this. If an >>>> instance of kamailio receives a 200 OK, it could check on the shm >>>> and say "hey, another instance is processing a 180 for this call. >>>> Let's wait for it to finish" (*). I know there could still be a >>>> problem, the instance processing the 180 undergoes a context switch >>>> just after it receives the message, but before writing to shm, but >>>> it would greatly reduce the chance. >>>> >>>> >>>> >>>> In our applications we use a SIP stack that always sends messages >>>> to the application in the same order it receives them, even though >>>> is multi-threaded and messages from the network are received by >>>> different threads. So, they really syncronize between them. Why >>>> Kamailio instances don't? >>>> >>>> I am evaluating kamailio to use it as a dispatcher to balance load >>>> against our several Application Servers, to present to the operator >>>> just a couple of entrance points to our platform (they don't want >>>> to establish connections to each one of our servers). This operator >>>> is very difficult to deal with. I am sure they will complain >>>> something like "why are you sending messages out of order? Fix >>>> that". The operator will be able to see traces and check that >>>> messages entered the Kamailio nodes in order and left out of order. >>>> They will not accept it. >>>> >>>> (*) Not really "wait", as it would introduce a delay in processing >>>> all messages. it should be like putting it on a queue, continue >>>> processing other messages, and go back to the queue later. >>>> >>>> Well, thanks for your answer. >>>> >>>> Luis >>>> >>>> >>>> >>>> >>>> >>>> On 4/8/20 3:01 AM, Henning Westerholt wrote: >>>> >>>> Hello Luis, >>>> >>>> >>>> >>>> as the 1xx responses are usually send unreliable (unless you >>>> use PRACK), you should not make any assumption on the order or >>>> even the arrival of this messages. It can also happens on a >>>> network level, if send by UDP. >>>> >>>> >>>> >>>> Can you elaborate why you think this re-ordering is a problem >>>> for you? >>>> >>>> >>>> >>>> One idea to enforce some ordering would be to use the dialog >>>> module in combination with reply routes and the textops(x) module. >>>> >>>> >>>> >>>> About the shared memory question – Kamailio implement its own >>>> memory manager (private memory and shared memory pool). >>>> >>>> >>>> >>>> Cheers, >>>> >>>> >>>> >>>> Henning >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Henning Westerholt – https://skalatan.de/blog/ >>>> >>>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fskalatan.de%2Fblog%2F&data=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624481993053&sdata=E%2BY%2BNYI0%2FtTIOzOXEKwDkZn%2BexDCKcl2giC%2FKNecLoE%3D&reserved=0> >>>> >>>> Kamailio services – https://gilawa.com >>>> >>>> <https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgilawa.com%2F&data=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624482003051&sdata=nDoL%2BEeMl0r6Kc4gIZ0MaAWWza9Mv8gMlZkWBTCOo80%3D&reserved=0> >>>> >>>> >>>> >>>> >>>> *From:* sr-users <[email protected]> >>>> <mailto:[email protected]> *On Behalf Of >>>> *Luis Rojas G. >>>> *Sent:* Tuesday, April 7, 2020 10:43 PM >>>> *To:* [email protected] >>>> <mailto:[email protected]> >>>> *Subject:* [SR-Users] Kamailio propagates 180 and 200 OK OUT OF >>>> ORDER >>>> >>>> >>>> >>>> Good day, >>>> >>>> I am testing the dispatcher module, using Kamailio as stateless >>>> proxy. I have a pool of UAC (scripts in SIPP) and a pool of UAS >>>> (also scripts in SIPP) for the destinations. Kamailio version >>>> is kamailio-5.3.3-4.1.x86_64. >>>> >>>> Problem I have is, if UAS responds 180 and 200 OK to Invite >>>> immediately, sometimes they are propagated out of order. 200 OK >>>> before 180, like this : >>>> >>>> UAS is 172.30.4.195:5061. UAC is 172.30.4.195:5080. Kamailio is >>>> 192.168.253.4:5070 >>>> >>>> Difference between 180 and 200 is just about 50 microseconds. >>>> >>>> My guess is that both messages are received by different >>>> instances of Kamailio, and then because of context switches, >>>> even though the 180 is received before, that process ends after >>>> the processing of 200. However, I had the idea that in order to >>>> avoid these problems the kamailio processes synchronized with >>>> each other using a shared memory. I tried using stateful proxy >>>> and I obtained the same result. >>>> >>>> By the way, anyone has any idea about how Kamailio's share >>>> memory is implemented? It clearly does not use the typical >>>> system calls shmget(), shmat(), because they are not shown by >>>> ipcs command. >>>> >>>> Before posting here I googled, but I couldn't find anything >>>> related to this. I can't believe I am the only one who ever had >>>> this problem, so I guess I am doing something wrong... >>>> >>>> Please, any help. I'm really stuck on this. >>>> >>>> Thanks. >>>> >>>> -- >>>> >>>> >>>> >>>> -- >>>> Luis Rojas >>>> Software Architect >>>> Sixbell >>>> Los Leones 1200 >>>> Providencia >>>> Santiago, Chile >>>> Phone: (+56-2) 22001288 >>>> mailto:[email protected] >>>> http://www.sixbell.com >>>> <https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sixbell.com%2F&data=02%7C01%7C%7C1bde0e5c47434fa230df08d7dbdf4eb4%7Cab4a33c2b5614f798601bc921698ad08%7C0%7C0%7C637219624482003051&sdata=tGs20FsV%2FwXvEg1FSIdB7nByjdj0Xw6tVtKlYa5byyU%3D&reserved=0> >>> >>> >>> -- >>> Luis Rojas >>> Software Architect >>> Sixbell >>> Los Leones 1200 >>> Providencia >>> Santiago, Chile >>> Phone: (+56-2) 22001288 >>> mailto:[email protected] >>> http://www.sixbell.com >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> [email protected] >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >> -- >> Daniel-Constantin Mierla -- www.asipto.com >> www.twitter.com/miconda -- www.linkedin.com/in/miconda > > > -- > Luis Rojas > Software Architect > Sixbell > Los Leones 1200 > Providencia > Santiago, Chile > Phone: (+56-2) 22001288 > mailto:[email protected] > http://www.sixbell.com -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda
_______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
