[SR-Users] Callee BYE routing issue

Have an issue with BYE routing in a lab setup, any suggestions on what I should be looking at? Topology: UA1 <-> NAT device 1 <-> Proxy1 <-> Registrar/B2BUA <-> Proxy1 <-> NAT device 1 <-> UA2 All UA to UA calls flow through B2BUA. All IP’s are public except for UA1 and UA2. -Both

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Sorry, I read an ANM... Nevermind On Fri, 10 Apr 2020 at 02:19, David Villasmil < david.villasmil.w...@gmail.com> wrote: > An ACM in a 180? > > On Thu, 9 Apr 2020 at 21:37, Luis Rojas G. wrote: > >> Hello, Daniel, >> >> Yes, yes, yes, you are right. I got confused for a moment. Yes, the >>

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

An ACM in a 180? On Thu, 9 Apr 2020 at 21:37, Luis Rojas G. wrote: > Hello, Daniel, > > Yes, yes, yes, you are right. I got confused for a moment. Yes, the > criteria for dispatcher is only for the request. And so, it will have no > effect on the replies. On the replies only the via headers

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Hello, Daniel, Yes, yes, yes, you are right. I got confused for a moment. Yes, the criteria for dispatcher is only for the request.  And so, it will have no effect on the replies. On the replies only the via headers are considered. Wel, moving to round robin increased the throughput for a

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Hello, dispatcher has nothing to do with handling sip replies. It is intended only for routing sip requests. If you use dispatcher for replies, you do it wrong, just let kamailio route them based on Via headers. So maybe I was looking at the wrong message flow processing, I was speaking mainly

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Hello, I just realized that I had the dispatcher configured using a hash of Call-ID.  That means, after recvfrom there must be an extra processing finding the Call-ID header in message, to calculate a hash and then forward() message. The more the processing, the more cases when 200 could

Re: [SR-Users] t_relay failure when dropping all branches in same destination set

Found an old discussion about this issue, https://lists.kamailio.org/pipermail/sr-users/2010-April/027703.html It says that the t_relay error is because after drop of single/all branches, there's none left to relay. However, it is not clear what the solution is, as t_relay failure won't trigger a

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Hello, the sip messages belonging to the same dialog have the same value for Call-Id header. The locking is done based on hashing the Call-Id, so it doesn't need at all the dialog module for its purpose. Cheers, Daniel On 09.04.20 14:19, Luis Rojas G. wrote: > Hello, Daniel, > > I am not so

Re: [SR-Users] kamailio as SBC for Teams

Hi Aydar, Request from MS proxy has VIA: SIP/2.0/TLS 52.114.7.24:5061, that's where your reply should go. You're sending to 52.114.7.24:1024 instead? Also, looks like you're missing "r2=on" on the other RR, only one has it. Cheers, On Thu, Apr 9, 2020 at 11:09 AM Aidar Kamalov wrote: >

[SR-Users] kamailio as SBC for Teams

Hello, I read https://skalatan.de/en/blog/kamailio-sbc-teams and trying to use kamailio for teams. But I faced that MS not responding ACK to my 200OK. Somethin is wrong, but I don't know what. I call from teams to kamailio. Can you help me please This is initial INVITE from Teams: 2020/04/09

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Agreed. Just suggesting an extreme. On Thu, 9 Apr 2020 at 14:51, Alex Balashov wrote: > On Thu, Apr 09, 2020 at 02:26:45PM +0100, David Villasmil wrote: > > > How about just not forwarding the 180 if it’s coming right after the > > 200ok? I know it’s a hack, but a 180 is a provisional response

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

On Thu, Apr 09, 2020 at 02:26:45PM +0100, David Villasmil wrote: > How about just not forwarding the 180 if it’s coming right after the > 200ok? I know it’s a hack, but a 180 is a provisional response > indicating the ring status, not the actual audio for the ring... so if > a 200 is received,

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

On Thu, Apr 09, 2020 at 08:14:02AM -0400, Luis Rojas G. wrote: > Yes, I know that specifically in this case, from the point fo view of > SIP, it's not "much" important. It's just a symptom than I can't rely > on Kamailio to keep the ordering of messages when they are very very > close in time.

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

How about just not forwarding the 180 if it’s coming right after the 200ok? I know it’s a hack, but a 180 is a provisional response indicating the ring status, not the actual audio for the ring... so if a 200 is received, the call is already established, no need to forward the 180. Yes, you’d

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Actually, I was looking at the code yesterday, trying to figure it if it's just a validation, to not accept reply_route(), or if it needs some more logic to work inside that block.  It's still an option. Best regards, Luis On 4/9/20 4:25 AM, Daniel-Constantin Mierla wrote: On 09.04.20

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Hello, Daniel, I am not so sure. I first tried adding that parameter, but it did not work at all.  Same behavior. Then I read the documentation more carefully : https://www.kamailio.org/wiki/cookbooks/devel/core#route_locks_size route_locks_size Set the number of mutex locks to be

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Yes, I know that specifically in this case, from the point fo view of SIP, it's not "much" important. It's just a symptom than I can't rely on Kamailio to keep the ordering of messages when they are very very close in time. With this customer (a Brazilian mobile operator) I have seen scenarios

Re: [SR-Users] kamailio - IPSEC

Hi, IMS_REGISTRAR _PCSCF module is dependent on IPSEC. so if i comment it, it is throwing me error in registrar module .. can anyone please comment on the below error how to solve it. Apr 9 15:32:13 tel-VirtualBox kamailio[4019]: INFO: [core/udp_server.c:154]: probe_max_receive_buffer():

Re: [SR-Users] kamailio - IPSEC

Hello Pavithra, Not sure if I understand you correctly. If you don’t load this module in your cfg, it will be disabled. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com From: sr-users On Behalf Of Pavithra M Sent:

[SR-Users] kamailio - IPSEC

Hi, Is there any possibility to disable ipsec_pcscf in kamailio 5.3.3. ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Hello, it was a reply to my email where I mentioned the route_locks_size parameter. As he said he looked at that parameter, I assumed it was about the route_locks_size, because there was not other parameter listed in the emails. So using the route_locks_size parameter doesn't require to use

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Hello, I mentioned in some of earlier e-mails as one possible option to track the state of a dialog and to act depending on it. Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com From: Daniel-Constantin Mierla Sent:

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

On 09.04.20 09:47, Daniel-Constantin Mierla wrote: > [...] >> >> Any idea why Async is not allowed in reply_route()? >> Didn't notice this question in the first place to respond in my previous email. Probably the developer that did it needed it for SIP requests. However, you can make a patch

[SR-Users] pcscf logs - error in kamailio

Hi , The error i am facing in kamailio pcscf Apr 9 13:44:31 tel-VirtualBox kamailio[2847]: INFO: rr [rr_mod.c:515]: pv_get_route_uri_f(): No route header present. Apr 9 13:44:31 tel-VirtualBox kamailio[2811]: ERROR: [core/lvalue.c:353]: lval_pvar_assign(): setting pvar failed Apr 9 13:44:31

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

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

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

If you think about it, if the 200 OK is so close to the 180 it doesn’t really matter from a signalling standpoint if the 180 comes first or if it arrives after the 200 OK. It’s the 200 OK that is important. If the 180 comes after, it’s simply ignored and the dialog is established successfully.

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Hello, if you are designing for over 600.000 concurrent calls, you would probably like to look for a distributed/clustered solution anyway, I guess. And this will bring some more topics related to synchronisation and race-conditions to think about. Of course not knowing the details about the

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Hello, Daniel, "Simple" does not mean "without processing". You could search for a word in a file several gigabytes long and it will take a lot of processing. Yet, it's very simple to do. And I have never seen an implementation where Call-ID is at the end of headers. Yes, it could be, but not

Re: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER

Hello, Daniel, I looked into that parameter, but  I need to use with the dialog module, and I'm pretty afraid to use that. 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