[SR-Users] Callee BYE routing issue

[Daniel W. Graham]

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 endpoints can call each other.
-If the caller hangs up first, BYE is routed properly.
-If the callee hangs up first, BYE causes proxy to send 478.

On calls where BYE results in 478:
if(!isdsturiset()) {
………..not executed
handle_ruri_alias()
}
return;

Example issue call: UA2 to UA1, UA1 hang-up.

Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): 
request_route=[DLGURI] c=[/usr/local/etc/kamailio/kamailio.cfg] l=540 a=16 n=if
Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): 
request_route=[DLGURI] c=[/usr/local/etc/kamailio/kamailio.cfg] l=532 a=24 
n=isdsturiset
Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): 
request_route=[DLGURI] c=[/usr/local/etc/kamailio/kamailio.cfg] l=540 a=2 
n=return
………..
Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} tm [ut.h:245]: uri2dst2(): 
bad_uri: [sip::;transport=]
Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} tm [t_fwd.c:1732]: 
t_forward_nonack(): failure to add branches
Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): 
request_route=[RELAY] c=[/usr/local/etc/kamailio/kamailio.cfg] l=275 a=24 
n=sl_reply_error
Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} sl [sl_funcs.c:401]: 
sl_reply_error(): stateless error reply used: Unresolvable destination (478/SL)
Apr 10 00:31:28 edgedev /usr/local/sbin/kamailio[5317]: ERROR: {1 2 BYE 
24dc84a4592515245177483c2a657042@B2BUA_IP:5160} *** cfgtrace:dbg_cfg_trace(): 
request_route=[RELAY] c=[/usr/local/etc/kamailio/kamailio.cfg] l=277 a=2 n=exit

2020/04/10 00:31:28.625060 NAT_Device_IP:57808 -> Proxy_IP:5060
BYE sip:398@B2BUA_IP:5160 SIP/2.0
Via: SIP/2.0/UDP UA1_IP:52884;branch=z9hG4bK-524287-1---43b5f31829f20952
Max-Forwards: 70
Route: 
Contact: 
To: "Dan Test" ;tag=as78671fd9
From: 
;tag=64f4b712
Call-ID: 24dc84a4592515245177483c2a657042@B2BUA_IP:5160
CSeq: 2 BYE
User-Agent: 
Content-Length: 0

#

For comparison, here is a BYE from another test call: UA1 to UA2, UA1 hang-up.

This BYE was routed correctly.

2020/04/10 00:44:02.688608 NAT_Device_IP:57808 -> Proxy_IP:5060
BYE sip:398@B2BUA_IP:5160 SIP/2.0
Via: SIP/2.0/UDP UA1_IP:52884;branch=z9hG4bK-524287-1---ce36df02e8a80a48
Max-Forwards: 70
Route: 
Contact: 
To: ;tag=as5874901f
From: ;tag=9078f232
Call-ID: 103104NGU1NjkxNGZkYmM4MzA3Y2FkMzY1OGNkZTZmMTMyZDU
CSeq: 3 BYE
User-Agent: 
Authorization: Digest username= 
Content-Length: 0

-dan

___
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

[David Villasmil]

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
>> 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 single instance.
>> Now it can process over 1000 CAPS.
>>
>> For the scenario ack-reinvite, the solution adding a small delay for
>> re-invite, using something like async_ms_sleep() will solve it, so I am not
>> worried ( I mentioned on a previous post that I have seen also that
>> scenario happening with this operator. Re-invite immediately after ACK, and
>> it caused us problems)
>>
>> My problem is still 180-200.  it will not matter the number of processes
>> or cores. In the end, it's a classical multi-process/multi-threaded race
>> condition. Considering the architecture of Kamailio, with multiple
>> processes, the problem will appear. And the more the traffic, the more
>> close in time 180 and 200 are, the more it will happen. With my currents
>> test, with 180 and 200 very close,  I am getting around 0.5% of cases
>> suffering from that condition.
>>
>> I know, if you think in "only SIP", yes, it's not so important the 180.
>> it's important in my case, because my customer is very complicated, and
>> they will not like to see messages coming to our platform in one order and
>> going out in other.
>> And the second : it's not only SIP.  they usually have interworking, and
>> 180 then will carry an ISUP ACM body that is important. As I mentioned in a
>> previous post, for instance, the Backward Call Indicators, with very
>> important subfields like the Charge Indicator.
>>
>> I understand. It's UDP. Messages can be lost on the network. OK. Messages
>> can arrive out of order. OK.  But i't s pity that if messages were not lost
>> and arrived in order, they leave kamailio out of order.
>>
>> So far the only solution I see is to try to insert a small delay before
>> forwarding the 200.
>>
>> Best rgards,
>>
>> Luis
>>
>>
>>
>> On 4/9/20 3:58 PM, Daniel-Constantin Mierla wrote:
>>
>>
>> mico...@gmail.com appears similar to someone who previously sent you
>> email, but may not be that person. Learn why this could be a risk
>> 
>> Feedback 
>>
>> 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 about the case when the caller sends quickly the reINVITE
>> after the ACK to the initial INVITE 200ok and the reINVITE gets to callee
>> before the ACK. That was more of a branching in discussion on Alex' remarks
>> and the situation that I enocountered in the past and created troubles.
>> Never had to deal with troubles caused by change of order between 180 and
>> 200. In IP world, if the time between 180 and 200 is very short, it doesn't
>> matter at all, because the 180 is for start play a ring tone, which a human
>> may not even hear it when 200 comes 50ms after it.
>>
>> If you face the re-ordering for replies, then Kamailio doesn't do much
>> internally if you don't have reply_route{} (as well as no onsend_route) in
>> config file, provided that you do not use tm module for sending out (and by
>> that no onreply_route or failure_route).
>>
>> For a sip reply, kamilio is parsing the headers to find the 2nd Via
>> header and use that address to send out the reply. The request route is not
>> executed for sip replies.
>>
>> What you can try is to set number of kamailio processes not to exceed the
>> number of CPU cores, so there is "no real competition" to get CPU cycles.
>> It could improve a bit, but still not a 100% accuracy (ie., there are other
>> processes running on the system).
>>
>> Cheers,
>> Daniel
>> On 09.04.20 21:29, Luis Rojas G. wrote:
>>
>> 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
>> arrive  before 180. I just changed it to round robin, and the amount
>> decreased a lot, but it's still there. If I send a burst of 1000 messages,
>> about 5 of them leave out of order every time.
>>
>> Best regards,
>>
>> Luis
>>
>>
>>
>> On 4/9/20 1:48 PM, Luis Rojas G. wrote:
>>
>> Hello,
>>
>> I have a lot of experience developing mutithreaded applications, and I
>> don't see it so unlikely at all that a process 

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

[David Villasmil]

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 are considered.
> Wel, moving to round robin increased the throughput for a single instance.
> Now it can process over 1000 CAPS.
>
> For the scenario ack-reinvite, the solution adding a small delay for
> re-invite, using something like async_ms_sleep() will solve it, so I am not
> worried ( I mentioned on a previous post that I have seen also that
> scenario happening with this operator. Re-invite immediately after ACK, and
> it caused us problems)
>
> My problem is still 180-200.  it will not matter the number of processes
> or cores. In the end, it's a classical multi-process/multi-threaded race
> condition. Considering the architecture of Kamailio, with multiple
> processes, the problem will appear. And the more the traffic, the more
> close in time 180 and 200 are, the more it will happen. With my currents
> test, with 180 and 200 very close,  I am getting around 0.5% of cases
> suffering from that condition.
>
> I know, if you think in "only SIP", yes, it's not so important the 180.
> it's important in my case, because my customer is very complicated, and
> they will not like to see messages coming to our platform in one order and
> going out in other.
> And the second : it's not only SIP.  they usually have interworking, and
> 180 then will carry an ISUP ACM body that is important. As I mentioned in a
> previous post, for instance, the Backward Call Indicators, with very
> important subfields like the Charge Indicator.
>
> I understand. It's UDP. Messages can be lost on the network. OK. Messages
> can arrive out of order. OK.  But i't s pity that if messages were not lost
> and arrived in order, they leave kamailio out of order.
>
> So far the only solution I see is to try to insert a small delay before
> forwarding the 200.
>
> Best rgards,
>
> Luis
>
>
>
> On 4/9/20 3:58 PM, Daniel-Constantin Mierla wrote:
>
>
> mico...@gmail.com appears similar to someone who previously sent you
> email, but may not be that person. Learn why this could be a risk
> 
> Feedback 
>
> 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 about the case when the caller sends quickly the reINVITE
> after the ACK to the initial INVITE 200ok and the reINVITE gets to callee
> before the ACK. That was more of a branching in discussion on Alex' remarks
> and the situation that I enocountered in the past and created troubles.
> Never had to deal with troubles caused by change of order between 180 and
> 200. In IP world, if the time between 180 and 200 is very short, it doesn't
> matter at all, because the 180 is for start play a ring tone, which a human
> may not even hear it when 200 comes 50ms after it.
>
> If you face the re-ordering for replies, then Kamailio doesn't do much
> internally if you don't have reply_route{} (as well as no onsend_route) in
> config file, provided that you do not use tm module for sending out (and by
> that no onreply_route or failure_route).
>
> For a sip reply, kamilio is parsing the headers to find the 2nd Via header
> and use that address to send out the reply. The request route is not
> executed for sip replies.
>
> What you can try is to set number of kamailio processes not to exceed the
> number of CPU cores, so there is "no real competition" to get CPU cycles.
> It could improve a bit, but still not a 100% accuracy (ie., there are other
> processes running on the system).
>
> Cheers,
> Daniel
> On 09.04.20 21:29, Luis Rojas G. wrote:
>
> 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
> arrive  before 180. I just changed it to round robin, and the amount
> decreased a lot, but it's still there. If I send a burst of 1000 messages,
> about 5 of them leave out of order every time.
>
> Best regards,
>
> Luis
>
>
>
> On 4/9/20 1:48 PM, Luis Rojas G. wrote:
>
> Hello,
>
> I have a lot of experience developing mutithreaded applications, and I
> don't see it so unlikely at all that a process loses cpu just after
> recvfrom(). It's just as probable as to lose it just before, or when
> writing on a cache or just before of after sendto(). If there are many
> messages going through, some of them will fall in this scenario. if I try

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

[Luis Rojas G.]

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 
single instance. Now it can process over 1000 CAPS.


For the scenario ack-reinvite, the solution adding a small delay for 
re-invite, using something like async_ms_sleep() will solve it, so I am 
not worried ( I mentioned on a previous post that I have seen also that 
scenario happening with this operator. Re-invite immediately after ACK, 
and it caused us problems)


My problem is still 180-200.  it will not matter the number of processes 
or cores. In the end, it's a classical multi-process/multi-threaded race 
condition. Considering the architecture of Kamailio, with multiple 
processes, the problem will appear. And the more the traffic, the more 
close in time 180 and 200 are, the more it will happen. With my currents 
test, with 180 and 200 very close,  I am getting around 0.5% of cases 
suffering from that condition.


I know, if you think in "only SIP", yes, it's not so important the 180. 
it's important in my case, because my customer is very complicated, and 
they will not like to see messages coming to our platform in one order 
and going out in other.
And the second : it's not only SIP. they usually have interworking, and 
180 then will carry an ISUP ACM body that is important. As I mentioned 
in a previous post, for instance, the Backward Call Indicators, with 
very important subfields like the Charge Indicator.


I understand. It's UDP. Messages can be lost on the network. OK. 
Messages can arrive out of order. OK.  But i't s pity that if messages 
were not lost and arrived in order, they leave kamailio out of order.


So far the only solution I see is to try to insert a small delay before 
forwarding the 200.


Best rgards,

Luis


On 4/9/20 3:58 PM, Daniel-Constantin Mierla wrote:



mico...@gmail.com appears similar to someone who previously sent you 
email, but may not be that person. Learn why this could be a risk 


Feedback 

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 about the case when the caller sends quickly the 
reINVITE after the ACK to the initial INVITE 200ok and the reINVITE 
gets to callee before the ACK. That was more of a branching in 
discussion on Alex' remarks and the situation that I enocountered in 
the past and created troubles. Never had to deal with troubles caused 
by change of order between 180 and 200. In IP world, if the time 
between 180 and 200 is very short, it doesn't matter at all, because 
the 180 is for start play a ring tone, which a human may not even hear 
it when 200 comes 50ms after it.


If you face the re-ordering for replies, then Kamailio doesn't do much 
internally if you don't have reply_route{} (as well as no 
onsend_route) in config file, provided that you do not use tm module 
for sending out (and by that no onreply_route or failure_route).


For a sip reply, kamilio is parsing the headers to find the 2nd Via 
header and use that address to send out the reply. The request route 
is not executed for sip replies.


What you can try is to set number of kamailio processes not to exceed 
the number of CPU cores, so there is "no real competition" to get CPU 
cycles. It could improve a bit, but still not a 100% accuracy (ie., 
there are other processes running on the system).


Cheers,
Daniel

On 09.04.20 21:29, Luis Rojas G. wrote:

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 arrive  before 180. I just changed it to round robin, 
and the amount decreased a lot, but it's still there. If I send a 
burst of 1000 messages, about 5 of them leave out of order every time.


Best regards,

Luis



On 4/9/20 1:48 PM, Luis Rojas G. wrote:

Hello,

I have a lot of experience developing mutithreaded applications, and 
I don't see it so unlikely at all that a process loses cpu just 
after recvfrom(). It's just as probable as to lose it just before, 
or when writing on a cache or just before of after sendto(). If 
there are many messages going through, some of them will fall in 
this scenario. if I try sending a burst of 100 messages, I see two 
or three presenting the scenario.


Just forward() with a single process does not give the capacity. I'm 
getting almost 1000caps. 

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

[Daniel-Constantin Mierla]

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 about the case when the caller sends quickly the
reINVITE after the ACK to the initial INVITE 200ok and the reINVITE gets
to callee before the ACK. That was more of a branching in discussion on
Alex' remarks and the situation that I enocountered in the past and
created troubles. Never had to deal with troubles caused by change of
order between 180 and 200. In IP world, if the time between 180 and 200
is very short, it doesn't matter at all, because the 180 is for start
play a ring tone, which a human may not even hear it when 200 comes 50ms
after it.

If you face the re-ordering for replies, then Kamailio doesn't do much
internally if you don't have reply_route{} (as well as no onsend_route)
in config file, provided that you do not use tm module for sending out
(and by that no onreply_route or failure_route).

For a sip reply, kamilio is parsing the headers to find the 2nd Via
header and use that address to send out the reply. The request route is
not executed for sip replies.

What you can try is to set number of kamailio processes not to exceed
the number of CPU cores, so there is "no real competition" to get CPU
cycles. It could improve a bit, but still not a 100% accuracy (ie.,
there are other processes running on the system).

Cheers,
Daniel

On 09.04.20 21:29, Luis Rojas G. wrote:
> 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 arrive  before 180. I just changed it to round robin, and the
> amount decreased a lot, but it's still there. If I send a burst of
> 1000 messages, about 5 of them leave out of order every time.
>
> Best regards,
>
> Luis
>
>
>
> On 4/9/20 1:48 PM, Luis Rojas G. wrote:
>> Hello,
>>
>> I have a lot of experience developing mutithreaded applications, and
>> I don't see it so unlikely at all that a process loses cpu just after
>> recvfrom(). It's just as probable as to lose it just before, or when
>> writing on a cache or just before of after sendto(). If there are
>> many messages going through, some of them will fall in this scenario.
>> if I try sending a burst of 100 messages, I see two or three
>> presenting the scenario.
>>
>> Just forward() with a single process does not give the capacity. I'm
>> getting almost 1000caps. More than that and start getting errores,
>> retransmissions, etc. And this is just one way. I need to receive the
>> call to go back to the network (our application is a B2BUA), so I
>> will be down to 500caps, with a simple scenario, with no reliable
>> responses, reinvites, updates, etc. I will end up having as many
>> standalone kamailio processes as the current servers I do have now.
>>
>> I really think the simplest way would be to add a small delay to 200
>> OK. Very small, like 10ms, should be enough. Simple and it should
>> work. As Alex Balashov commented he did for the case with
>> ACK-Re-Invite. 
>>
>> I have to figure out how to make async_ms_sleep() work in reply_route().
>>
>> Thanks for all the comments and ideas
>>
>> Best regards,
>>
>> Luis
>>
>>
>>
>> . On 4/9/20 12:17 PM, Daniel-Constantin Mierla wrote:
>>>
>>> 
>>> mico...@gmail.com appears similar to someone who previously sent you
>>> email, but may not be that person. Learn why this could be a risk
>>> 
>>> Feedback 
>>>
>>> Hello,
>>>
>>> then the overtaking is in between reading from the socket and
>>> getting to parsing the call-id value -- the cpu is lost by first
>>> reader after recvfrom() and the second process get enough cpu time
>>> to go ahead further. I haven't encountered this case, but as I said
>>> previously, it is very unlikely, but still possible. I added the
>>> route_locks_size because in the past I had cases when processing of
>>> some messages took longer executing config (e.g., due to
>>> authentication, accounting, ..) and I needed to be sure they are
>>> processed in the order they enter config execution.
>>>
>>> Then the option is to see if a single process with stateless sending
>>> out (using forward()) gives the capacity, if you don't do any other
>>> complex processing. Or if you do more complex processing, use a
>>> dispatcher process with forwarding to local host or in a similar
>>> manner try to use mqueue+rtimer for dispatching using shared memory
>>> queues.
>>>
>>> Of course, it is open source and there is also the C coding way, to
>>> add a synchronizing mechanism to protect against parallel execution
>>> of the code 

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

[Luis Rojas G.]

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 arrive before 180. I just changed it to round robin, and the 
amount decreased a lot, but it's still there. If I send a burst of 1000 
messages, about 5 of them leave out of order every time.


Best regards,

Luis



On 4/9/20 1:48 PM, Luis Rojas G. wrote:

Hello,

I have a lot of experience developing mutithreaded applications, and I 
don't see it so unlikely at all that a process loses cpu just after 
recvfrom(). It's just as probable as to lose it just before, or when 
writing on a cache or just before of after sendto(). If there are many 
messages going through, some of them will fall in this scenario. if I 
try sending a burst of 100 messages, I see two or three presenting the 
scenario.


Just forward() with a single process does not give the capacity. I'm 
getting almost 1000caps. More than that and start getting errores, 
retransmissions, etc. And this is just one way. I need to receive the 
call to go back to the network (our application is a B2BUA), so I will 
be down to 500caps, with a simple scenario, with no reliable 
responses, reinvites, updates, etc. I will end up having as many 
standalone kamailio processes as the current servers I do have now.


I really think the simplest way would be to add a small delay to 200 
OK. Very small, like 10ms, should be enough. Simple and it should 
work. As Alex Balashov commented he did for the case with ACK-Re-Invite.


I have to figure out how to make async_ms_sleep() work in reply_route().

Thanks for all the comments and ideas

Best regards,

Luis



. On 4/9/20 12:17 PM, Daniel-Constantin Mierla wrote:



mico...@gmail.com appears similar to someone who previously sent you 
email, but may not be that person. Learn why this could be a risk 


Feedback 

Hello,

then the overtaking is in between reading from the socket and getting 
to parsing the call-id value -- the cpu is lost by first reader after 
recvfrom() and the second process get enough cpu time to go ahead 
further. I haven't encountered this case, but as I said previously, 
it is very unlikely, but still possible. I added the route_locks_size 
because in the past I had cases when processing of some messages took 
longer executing config (e.g., due to authentication, accounting, ..) 
and I needed to be sure they are processed in the order they enter 
config execution.


Then the option is to see if a single process with stateless sending 
out (using forward()) gives the capacity, if you don't do any other 
complex processing. Or if you do more complex processing, use a 
dispatcher process with forwarding to local host or in a similar 
manner try to use mqueue+rtimer for dispatching using shared memory 
queues.


Of course, it is open source and there is also the C coding way, to 
add a synchronizing mechanism to protect against parallel execution 
of the code from recvfrom() till call-id lock is acquired.


Cheers,
Daniel



--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
mailto:luis.ro...@sixbell.com
http://www.sixbell.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

[Sergiu Pojoga]

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 failure_route to do
alternative actions.

Ideas?

Thanks,
--Sergiu

On Wed, Apr 8, 2020 at 11:14 PM Sergiu Pojoga  wrote:

> Hi there,
>
> Can someone help figure out why there's this t_relay error, if I decide to
> drop the single master branch either all branches belonging to the same
> destination set, even though there are more serial sets to try later?
>
> *Error:*
> *tm [t_funcs.c:337]: t_relay_to(): t_forward_nonack returned error -6 (-6)*
> *tm [t_funcs.c:355]: t_relay_to(): -6 error reply generation delayed *
>
> *Example:*
>
> request_route {
>seturi("sip:a...@mydomain.net");
>append_branch("sip:b...@mydomain.net", "0.5");
>append_branch("sip:c...@mydomain.net", "0.5");
>append_branch("sip:d@10.22.0.30", "1.0");
># append_branch("sip:e...@mydomain.net", "1.0"); # no error if I add this
> branch with same Q=1.0
>
>t_load_contacts();
>t_next_contacts();
>
>t_on_branch("check_branch");
>t_on_failure("serial");
>
>t_relay();
>break;
> }
>
> branch_route[check_branch] {
>if($rd=="10.22.0.30")
>   drop;
> }
>
> failure_route["serial"] {
>if (!t_next_contacts())
>   exit;
> }
>
>   t_on_branch("check_branch");
>   t_on_failure("serial");
>   t_relay();
> }
>
> Thanks in advance.
>
> --Sergiu
>
___
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

[Daniel-Constantin Mierla]

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 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 used for synchronizing the
> execution of messages sharing the same Call-Id. In other words,
> enables Kamailio to execute the config script sequentially for the
> requests and replies received *within the same dialog* – a new message
> received *within the same dialog* waits until the previous one is
> routed out.
>
> Locks to execute sequentially messages belonging to same dialog. How
> will Kamailio be aware that messages belong to same dialog, without
> the dialog module?. With just stateless proxy it has no idea about
> dialogs, it just forwards messages. I guess that's why just adding
> that parameter did not work.
>
> Am I wrong?
>
> Luis
>
>
>
> On 4/9/20 3:47 AM, Daniel-Constantin Mierla wrote:
>>
>> 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
 

 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.
>>
>>  
>>
>> 

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

[Sergiu Pojoga]

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:

> 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 22:55:17.346092 52.114.7.24:1024 -> KAMAILIO_IP:5061
> INVITE sip:+x@MY_KAMAILIO_FQDN:5061;user=phone;transport=tls
> SIP/2.0
> FROM: Aidar Kamalov ;user=phone>;tag=de28a5b5333b451a97312097f91f5564
> TO: 
> CSEQ: 1 INVITE
> CALL-ID: 3d5ad3cdd01457be94d127fa20478cf1
> MAX-FORWARDS: 70
> VIA: SIP/2.0/TLS 52.114.7.24:5061;branch=z9hG4bKdb903e2c
> RECORD-ROUTE:  ;transport=tls;lr>
> CONTACT:  ;x-i=903eeaac-b19e-43a0-8e75-bb222049922a;x-c=3d5ad3cdd01457be94d127fa20478cf1/d/8/d3d2c2e3f3c14f88bb2fe843b4bc70e4>
> CONTENT-LENGTH: 2426
> USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.4.4.3 i.ASEA.5
> CONTENT-TYPE: application/sdp
> ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
>
> v=0
> o=- 0 0 IN IP4 52.114.252.146
> s=session
> c=IN IP4 52.114.252.146
> b=CT:5
> t=0 0
> m=audio 52939 RTP/SAVP 104 9 111 18 0 8 103 97 13 118 119 101
> a=rtcp:52925
> a=ice-ufrag:rKBm
> a=ice-pwd:BkjUnkfIvYV5pjteSteevL1O
> a=rtcp-mux
> a=candidate:4 1 UDP 184547839 52.114.252.146 52939 typ relay raddr
> 31.13.144.55 rport 57780
> a=candidate:4 2 UDP 184547326 52.114.252.146 52925 typ relay raddr
> 31.13.144.55 rport 57781
> a=candidate:1 1 tcp-act 2121006590 100.78.247.179 1024 typ host
> a=candidate:1 2 tcp-act 2121006590 100.78.247.179 1024 typ host
> a=candidate:2 1 UDP 2130705919 100.78.247.179 39182 typ host
> a=candidate:2 2 UDP 2130705406 100.78.247.179 39183 typ host
> a=candidate:3 1 UDP 1694497791 31.13.144.55 57780 typ srflx raddr
> 100.78.247.179 rport 39182
> a=candidate:3 2 UDP 1694497278 31.13.144.55 57781 typ srflx raddr
> 100.78.247.179 rport 39183
> a=candidate:5 1 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
> 100.78.247.179 rport 41775
> a=candidate:5 2 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
> 100.78.247.179 rport 41775
> a=candidate:6 1 tcp-pass 174453758 52.114.252.130 59925 typ relay raddr
> 31.13.144.55 rport 9761
> a=candidate:6 2 tcp-pass 174453758 52.114.252.130 59925 typ relay raddr
> 31.13.144.55 rport 9761
> a=candidate:7 1 tcp-act 174846462 52.114.252.130 59925 typ relay raddr
> 31.13.144.55 rport 9761
> a=candidate:7 2 tcp-act 174846462 52.114.252.130 59925 typ relay raddr
> 31.13.144.55 rport 9761
> a=x-candidate-info:4 network-type=WWAN
> a=x-candidate-info:1 network-type=WWAN
> a=x-candidate-info:2 network-type=WWAN
> a=x-candidate-info:3 network-type=WWAN
> a=x-candidate-info:5 network-type=WWAN
> a=x-candidate-info:6 network-type=WWAN
> a=x-candidate-info:7 network-type=WWAN
> a=crypto:1 AES_CM_128_HMAC_SHA1_32
> inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31
> a=crypto:2 AES_CM_128_HMAC_SHA1_80
> inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31
> a=crypto:3 AES_CM_128_HMAC_SHA1_80
> inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31|1:1
> a=rtpmap:104 SILK/16000
> a=fmtp:104 useinbandfec=1; usedtx=0
> a=rtpmap:9 G722/8000
> a=rtpmap:111 SIREN/16000
> a=fmtp:111 bitrate=16000
> a=rtpmap:18 G729/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:103 SILK/8000
> a=fmtp:103 useinbandfec=1; usedtx=0
> a=rtpmap:97 RED/8000
> a=rtpmap:13 CN/8000
> a=rtpmap:118 CN/16000
> a=rtpmap:119 CN/24000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=maxptime:200
>
>
>
> and my 200OK to MS is:
>
> 2020/04/09 22:55:19.976427 KAMAILIO_IP:5061 -> 52.114.7.24:1024
> SIP/2.0 200 OK
> Record-Route:
> 
> Record-Route:
> 
> Via: SIP/2.0/TLS 52.114.7.24:5061;rport=1024;branch=z9hG4bKdb903e2c
> Record-Route:
> 
> Record-Route:
> 
> Record-Route:
> 
> Record-Route:
> 
> Record-Route:  ;transport=tls;lr>
> To:  :5061;user=phone>;tag=3795432917-393759697
> From:  ;user=phone>;tag=de28a5b5333b451a97312097f91f5564
> Call-ID: 3d5ad3cdd01457be94d127fa20478cf1
> CSeq: 1 INVITE
> Allow:
> PUBLISH,MESSAGE,UPDATE,PRACK,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL
> Content-Type: application/sdp
> Accept: application/sdp
> Content-Length: 282
> User-Agent: MY_DOMAIN
> Contact:
> 
>
> v=0
> o=ETPI-MSX1 0 0 IN IP4 KAMAILIO_IP
> s=sip call
> c=IN IP4 KAMAILIO_IP
> t=0 0
> m=audio 12176 RTP/SAVP 8
> b=AS:64
> a=maxptime:20
> a=rtpmap:8 PCMA/8000
> a=sendrecv
> a=rtcp:12177
> a=crypto:1 AES_CM_128_HMAC_SHA1_32
> inline:03ZmcR+CxxB7k7C8QvWBgseYq7cH7py7VxqfLM8j
> a=ptime:20
>
>
> --
> Aydar A. Kamalov
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> 

[SR-Users] kamailio as SBC for Teams

[Aidar Kamalov]

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 22:55:17.346092 52.114.7.24:1024 -> KAMAILIO_IP:5061
INVITE sip:+x@MY_KAMAILIO_FQDN:5061;user=phone;transport=tls SIP/2.0
FROM: Aidar Kamalov;tag=de28a5b5333b451a97312097f91f5564
TO: 
CSEQ: 1 INVITE
CALL-ID: 3d5ad3cdd01457be94d127fa20478cf1
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 52.114.7.24:5061;branch=z9hG4bKdb903e2c
RECORD-ROUTE: 
CONTACT: 
CONTENT-LENGTH: 2426
USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.4.4.3 i.ASEA.5
CONTENT-TYPE: application/sdp
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY

v=0
o=- 0 0 IN IP4 52.114.252.146
s=session
c=IN IP4 52.114.252.146
b=CT:5
t=0 0
m=audio 52939 RTP/SAVP 104 9 111 18 0 8 103 97 13 118 119 101
a=rtcp:52925
a=ice-ufrag:rKBm
a=ice-pwd:BkjUnkfIvYV5pjteSteevL1O
a=rtcp-mux
a=candidate:4 1 UDP 184547839 52.114.252.146 52939 typ relay raddr
31.13.144.55 rport 57780
a=candidate:4 2 UDP 184547326 52.114.252.146 52925 typ relay raddr
31.13.144.55 rport 57781
a=candidate:1 1 tcp-act 2121006590 100.78.247.179 1024 typ host
a=candidate:1 2 tcp-act 2121006590 100.78.247.179 1024 typ host
a=candidate:2 1 UDP 2130705919 100.78.247.179 39182 typ host
a=candidate:2 2 UDP 2130705406 100.78.247.179 39183 typ host
a=candidate:3 1 UDP 1694497791 31.13.144.55 57780 typ srflx raddr
100.78.247.179 rport 39182
a=candidate:3 2 UDP 1694497278 31.13.144.55 57781 typ srflx raddr
100.78.247.179 rport 39183
a=candidate:5 1 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
100.78.247.179 rport 41775
a=candidate:5 2 tcp-act 1684796926 31.13.144.55 9761 typ srflx raddr
100.78.247.179 rport 41775
a=candidate:6 1 tcp-pass 174453758 52.114.252.130 59925 typ relay raddr
31.13.144.55 rport 9761
a=candidate:6 2 tcp-pass 174453758 52.114.252.130 59925 typ relay raddr
31.13.144.55 rport 9761
a=candidate:7 1 tcp-act 174846462 52.114.252.130 59925 typ relay raddr
31.13.144.55 rport 9761
a=candidate:7 2 tcp-act 174846462 52.114.252.130 59925 typ relay raddr
31.13.144.55 rport 9761
a=x-candidate-info:4 network-type=WWAN
a=x-candidate-info:1 network-type=WWAN
a=x-candidate-info:2 network-type=WWAN
a=x-candidate-info:3 network-type=WWAN
a=x-candidate-info:5 network-type=WWAN
a=x-candidate-info:6 network-type=WWAN
a=x-candidate-info:7 network-type=WWAN
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31
a=crypto:2 AES_CM_128_HMAC_SHA1_80
inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31
a=crypto:3 AES_CM_128_HMAC_SHA1_80
inline:DY3r3DWRojJm94CJQ83OAavmlRCwPf5ciRxHCT40|2^31|1:1
a=rtpmap:104 SILK/16000
a=fmtp:104 useinbandfec=1; usedtx=0
a=rtpmap:9 G722/8000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 SILK/8000
a=fmtp:103 useinbandfec=1; usedtx=0
a=rtpmap:97 RED/8000
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:119 CN/24000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:200



and my 200OK to MS is:

2020/04/09 22:55:19.976427 KAMAILIO_IP:5061 -> 52.114.7.24:1024
SIP/2.0 200 OK
Record-Route:

Record-Route:

Via: SIP/2.0/TLS 52.114.7.24:5061;rport=1024;branch=z9hG4bKdb903e2c
Record-Route:

Record-Route:

Record-Route:

Record-Route:

Record-Route: 
To: ;tag=3795432917-393759697
From: ;tag=de28a5b5333b451a97312097f91f5564
Call-ID: 3d5ad3cdd01457be94d127fa20478cf1
CSeq: 1 INVITE
Allow:
PUBLISH,MESSAGE,UPDATE,PRACK,SUBSCRIBE,REFER,INFO,NOTIFY,REGISTER,OPTIONS,BYE,INVITE,ACK,CANCEL
Content-Type: application/sdp
Accept: application/sdp
Content-Length: 282
User-Agent: MY_DOMAIN
Contact:


v=0
o=ETPI-MSX1 0 0 IN IP4 KAMAILIO_IP
s=sip call
c=IN IP4 KAMAILIO_IP
t=0 0
m=audio 12176 RTP/SAVP 8
b=AS:64
a=maxptime:20
a=rtpmap:8 PCMA/8000
a=sendrecv
a=rtcp:12177
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:03ZmcR+CxxB7k7C8QvWBgseYq7cH7py7VxqfLM8j
a=ptime:20


-- 
Aydar A. Kamalov
___
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

[David Villasmil]

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
> > 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.
>
> There is a general principle, particularly in PSTN interworking, that
> signalling should be reliably conserved end-to-end. I think dropping
> messages is the most cavalier option available, perhaps worth
> considering only if every other logical possibility has been exhausted
> first.
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
>
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337
___
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

[Alex Balashov]

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, the call is already established, no need to forward
> the 180.

There is a general principle, particularly in PSTN interworking, that
signalling should be reliably conserved end-to-end. I think dropping
messages is the most cavalier option available, perhaps worth
considering only if every other logical possibility has been exhausted
first.

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
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

[Alex Balashov]

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. With this customer (a Brazilian mobile operator) I have
> seen scenarios where they send Re-Invite immediately after ACK, and
> sometimes it caused us problems. I can't think right now in other
> scenario,, but I'm afraid to find out in production. For what I see
> the Async module, as it is now, could help me to deal with requests.
> However, even though it's not a problem for SIP, the operator will
> complain, I know them. And also, they will not like to just drop the
> 180, because there will be scenarios with interworking, so it needs to
> propagate the ACM ISUP body, with parameters as backward call
> indicators.

Agreed that you need to conserve signalling messages end-to-end, as a
matter of principle; can't just drop things.

As I mentioned earlier, we had the same problem--ironically, with a
major mobile operator--sending reinvites and e2e ACKs almost
contemporaneously. We solved it with 'async' by delaying all reinvites
by 50 ms, and haven't had a single complaint since.

Aside from that specific scenario, we haven't seen ordering problems,
and have never had cause to call into question whether we can 'rely' on
Kamailio to conserve ordering. 

There are valid questions raised in this thread about whether any
user-space SIP element subject to the vicissitudes and realities of
packet-switched networking can be relied upon to preserve ordering in a
consistent and universal way.

At the end of the day, this is a network problem. PSTN interworking is
imperfect; it imposes synchronous assumptions upon asynchronous media,
and we see this play out in many areas, e.g. fax. Not much you can do
about it, but thankfully the corner cases are relatively few.

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
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

[David Villasmil]

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 need to keep a dialog status, but you can offload that to a
cache server, and only keep track of 200s for a couple seconds, then just
expire the cache record.

On Thu, 9 Apr 2020 at 13:34, Luis Rojas G.  wrote:

> Hello,
>
> Well, not really. I could present to the operator, for instance, three
> independent nodes running Kamailio. If they need to send calls to our
> platform, they send to any of them, and monitor their state with SIP
> OPTIONS.  A call that goes through that node will go just through the same
> node until the end. No need to synchronize nodes. So, for the operator we
> would have three nodes to send all the traffic to, instead of the 8 nodes
> PER SITE we have now (for geographic redundancy reasons), plus several
> ports in each server.   600.000 was the worst scenario, with one site
> completely down, and failures at the remaining site too. But I have to
> consider that case.
>
> Best regards,
>
> Luis
>
>
> thOn 4/9/20 3:09 AM, Henning Westerholt wrote:
>
> 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 scenario, but maybe it make
> sense to tackle this race-condition problem in the client instead of trying
> to fix it elsewhere. As already pointed out, you can’t control the network
> transmission anyway, if you use UDP.
>
>
>
> Cheers,
>
>
>
> Henning
>
>
>
> --
>
> Henning Westerholt – https://skalatan.de/blog/
> 
>
> Kamailio services – https://gilawa.com
> 
>
>
>
> *From:* Luis Rojas G.  
> *Sent:* Wednesday, April 8, 2020 11:04 PM
> *To:* mico...@gmail.com; Kamailio (SER) - Users Mailing List
>  ; Henning
> Westerholt  
> *Subject:* 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
> 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
> 
>
> 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 

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

[Luis Rojas G.]

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 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 (pull request) to make it work for other cases. The
developers will review the changes and if they don't break anything, it
will be merged.

Cheers,
Daniel

.



--
Luis Rojas
Software Architect
Sixbell
Los Leones 1200
Providencia
Santiago, Chile
Phone: (+56-2) 22001288
mailto:luis.ro...@sixbell.com
http://www.sixbell.com


___
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

[Luis Rojas G.]

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 used for synchronizing the execution 
of messages sharing the same Call-Id. In other words, enables Kamailio 
to execute the config script sequentially for the requests and replies 
received *within the same dialog* – a new message received *within the 
same dialog* waits until the previous one is routed out.


Locks to execute sequentially messages belonging to same dialog. How 
will Kamailio be aware that messages belong to same dialog, without the 
dialog module?. With just stateless proxy it has no idea about dialogs, 
it just forwards messages. I guess that's why just adding that parameter 
did not work.


Am I wrong?

Luis



On 4/9/20 3:47 AM, Daniel-Constantin Mierla wrote:


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 



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/ 



Kamailio services – https://gilawa.com 



*From:* Luis Rojas G. 
*Sent:* Wednesday, April 8, 2020 3:00 PM
*To:* Henning Westerholt ; Kamailio (SER) - Users 
Mailing List 
*Subject:* Re: [SR-Users] Kamailio 

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

[Luis Rojas G.]

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 where they send Re-Invite immediately after ACK, and sometimes 
it caused us problems. I can't think right now in other scenario,, but 
I'm afraid to find out in production. For what I see the Async module, 
as it is now, could help me to deal with requests. However, even though 
it's not a problem for SIP, the operator will complain, I know them. And 
also, they will not like to just drop the 180, because there will be 
scenarios with interworking, so it needs to propagate the ACM ISUP body, 
with parameters as backward call indicators.


Luis

On 4/9/20 3:27 AM, Olle E. Johansson wrote:
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.

The 1xx is seldom significant (unless you have PRACK but that’s 
another story).


Or do you really have a situation where the 180 is critical?

/O

On 8 Apr 2020, at 18:01, Steve Davies 
> wrote:


Hi Luis,

Kamailio architecture isn't going to change I'm sure.  There is no 
central orchestrator - each worker process just grabs messages as 
fast as it can.  If your processing is slow for some and fast for 
others then they can get out of order I reckon.  180s are really 
neither here nor there if there's a 200 OK right behind it.


Perhaps a proxy like Drachtio would work better for you?

Steve


On Wed, 8 Apr 2020 at 17:44, Luis Rojas G. > wrote:


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



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.

Re: [SR-Users] kamailio - IPSEC

[Pavithra M]

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(): SO_RCVBUF is initially
212992
Apr  9 15:32:13 tel-VirtualBox kamailio[4019]: INFO: 
[core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally
425984
Apr  9 15:32:13 tel-VirtualBox kamailio[4019]: ERROR: 

Re: [SR-Users] kamailio - IPSEC

[Henning Westerholt]

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: Thursday, April 9, 2020 11:14 AM
To: Kamailio (SER) - Users Mailing List 
Subject: [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

[SR-Users] kamailio - IPSEC

[Pavithra M]

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

[Daniel-Constantin Mierla]

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 dialog module.

Cheers,
Daniel

On 09.04.20 10:29, Henning Westerholt wrote:
>
> 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:* Thursday, April 9, 2020 9:48 AM
> *To:* luis.ro...@sixbell.com; Kamailio (SER) - Users Mailing List
> ; Henning Westerholt 
> *Subject:* 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 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
> 
> 
>
> 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
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda

___
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

[Henning Westerholt]

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: Thursday, April 9, 2020 9:48 AM
To: luis.ro...@sixbell.com; Kamailio (SER) - Users Mailing List 
; Henning Westerholt 
Subject: 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 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

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/
Kamailio services – 
https://gilawa.com

From: Luis Rojas G. 
Sent: Wednesday, April 8, 2020 3:00 PM
To: Henning Westerholt ; Kamailio 
(SER) - Users Mailing List 

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

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

[Daniel-Constantin Mierla]

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 (pull request) to make it work for other cases. The
developers will review the changes and if they don't break anything, it
will be merged.

Cheers,
Daniel


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] pcscf logs - error in kamailio

[Pavithra M]

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 tel-VirtualBox kamailio[2811]: ERROR: 
[core/lvalue.c:404]: lval_assign(): assignment failed at pos:
(106,30-106,48)
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 tel-VirtualBox kamailio[2811]: ERROR: 
[core/lvalue.c:404]: lval_assign(): assignment failed at pos:
(114,31-114,52)


kindly help me in this issue .. because of this , it is throwing 403 domain
not server error in scscf
___
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

[Daniel-Constantin Mierla]

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
>> 
>>
>> 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/
 

 Kamailio services – https://gilawa.com
 

  

 *From:* Luis Rojas G. 
 *Sent:* Wednesday, April 8, 2020 3:00 PM
 *To:* Henning Westerholt ; Kamailio (SER) - Users
 Mailing List 
 *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
 

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

[Olle E. Johansson]

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.

The 1xx is seldom significant (unless you have PRACK but that’s another story).

Or do you really have a situation where the 180 is critical?

/O

> On 8 Apr 2020, at 18:01, Steve Davies 
>  wrote:
> 
> Hi Luis,
> 
> Kamailio architecture isn't going to change I'm sure.  There is no central 
> orchestrator - each worker process just grabs messages as fast as it can.  If 
> your processing is slow for some and fast for others then they can get out of 
> order I reckon.  180s are really neither here nor there if there's a 200 OK 
> right behind it.
> 
> Perhaps a proxy like Drachtio would work better for you?
> 
> Steve
> 
> 
> On Wed, 8 Apr 2020 at 17:44, Luis Rojas G.  > wrote:
> 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 
> 
> 
> 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/ 
>> 
>> Kamailio services – https://gilawa.com 
>> 
>>  
>> 
>> From: sr-users  
>>  On Behalf Of Luis Rojas G.
>> Sent: Tuesday, April 7, 2020 10:43 PM
>> To: sr-users@lists.kamailio.org 
>> Subject: [SR-Users] Kamailio propagates 180 and 200 OK OUT OF ORDER
>> 
>>  
>> 
>> Good day,
>> 
>> I am testing the dispatcher 

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

[Henning Westerholt]

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 scenario, but maybe it make sense 
to tackle this race-condition problem in the client instead of trying to fix it 
elsewhere. As already pointed out, you can’t control the network transmission 
anyway, if you use UDP.

Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

From: Luis Rojas G. 
Sent: Wednesday, April 8, 2020 11:04 PM
To: mico...@gmail.com; Kamailio (SER) - Users Mailing List 
; Henning Westerholt 
Subject: 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 
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

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/
Kamailio services – 
https://gilawa.com

From: Luis Rojas G. 
Sent: Wednesday, April 8, 2020 3:00 PM
To: Henning Westerholt ; Kamailio 
(SER) - Users Mailing List 

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 

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

[Luis Rojas G.]

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 
probably, and it's not in my current scenario.


Problem, as I said, is that a thread like that would become a 
bottleneck, considering all the tasks you mentioned.


If I could support the  required load (over 4000 CAPS) with only one 
process, I would not be having this problem of race conditions between 
different processes.


if one process listening on public IP and port 5060 was able to process 
all messages. to send them to internal processes, then what do I need 
those processes for? Better to just forward directly to next hop.


Best regards,

Luis




On 4/8/20 4:51 PM, Daniel-Constantin Mierla wrote:


Hello,

On 08.04.20 22:17, Luis Rojas G. wrote:

Hi, Daniel, about this :

A distributor thread (or process) won't help here, if it distributes
traffic to other threads (processes) without waiting for them to finish,
which ends up to be serial processing. The distributor role for UDP
traffic is done by the kernel. For tcp/tls there is a distributor
process for connections.

Cheers,
Daniel


I disagree. A distributor thread could do something as simple as 
apply a hash to the Call-ID,


Actually what you refer "as simple as" involves parsing sip headers to 
find call id, which can be at the end of the headers, meaning parsing 
the entire set of headers. Then managing the queues (insert, drop in 
case of over load (which is done by kernel now), ...) etc. So that 
process will do a lot of processing when having to deal with high 
volume of traffic.


But my remark was about a pure packet dispatcher thread, without any 
dialog awareness processing. Alex followed up to clarify he thought 
more or less about a higher level dispatcher, aware of some 
states/dialog/etc...


and use it to select the process to send the message to, without 
waiting. the process will recive all messages for a specific call-leg.
it does not need to wait for an answer nor it needs states, as "which 
process is processing which message at any time".



You should be able to achieve pretty much this kind of behaviour via 
configuration based routing - just sketching:


  - one process listen on port 5060 public ip

  - many single processes per one port listening on 127.0.0.1

  - dispatch from the process on public ip to the processes on 
127.0.0.1 with different ports


  - corex module offers functions to set source address and received 
socket for more flexibility why processing on 127.0.0.1


Cheers,
Daniel



I think the main problem is that it introduces a bottleneck, and 
break the main philosophy of Kamailio's architecture, having only 
individual processes.


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 



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 

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

[Luis Rojas G.]

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 
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 



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/ 



Kamailio services – https://gilawa.com 



*From:* Luis Rojas G. 
*Sent:* Wednesday, April 8, 2020 3:00 PM
*To:* Henning Westerholt ; Kamailio (SER) - Users 
Mailing List 
*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 



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