[OpenSIPS-Users] Opensips dosnt send ACK according to the route.

2019-04-25 Thread Олег Подгуйко via Users
Hello!

I am using  opensips as a proxy for load balansing. It listens two ports. 
Logically from one side it is SCTP port 5070 and from another side is UDP port 
5060.
UAC from UDP side sends INVITE via UDP protocol. OpenSips accepts it, checks 
it, gets the next sip address from dispatcher module for this request,  and 
sends INVITE  via SCTP protocol to the next SIP address. All are fine. From 
SCTP side I get 100, 180 and finaly 200. All messages was got via SCTP 
protocol.  200 consists record-route header 

SIP/2.0 200 OK
Via: SIP/2.0/SCTP 10.0.2.15:5070;branch=z9hG4bKccbc.5617e394.0, SIP/2.0/UDP 
10.0.2.6:5060;branch=z9hG4bK-24303-1-0
From: sipp ;tag=1
To: sut ;tag=4581SIPpTag015
Call-ID: 1-24303@10.0.2.6
CSeq: 1 INVITE
Record-Route:
Contact: 
Content-Length: 0
Opensips sends 200 responce to the UDP side.

In fine opensips get ACK from UDP side which has ROUTE header

 
ACK sip:796@10.0.2.15:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.2.6:5060;branch=z9hG4bK-24303-1-4
From: sipp ;tag=1
To: sut ;tag=4581SIPpTag015
Call-ID: 1-24303@10.0.2.6
CSeq: 1 ACK
Route: 
Max-Forwards: 70
Subject: Performance Test
Content-Length: 0
 

Furthet the most interesting. This is a log

апр 25 12:14:18 OpenSips.server /usr/sbin/opensips[1213]: DBG:uri:has_totag: 
totag found
апр 25 12:14:18 OpenSips.server /usr/sbin/opensips[1213]: 
DBG:core:parse_headers: flags=200
апр 25 12:14:18 OpenSips.server /usr/sbin/opensips[1213]: DBG:rr:is_preloaded: 
No
апр 25 12:14:18 OpenSips.server /usr/sbin/opensips[1213]: 
DBG:core:grep_sock_info: checking if host==us: 9==9 && [10.0.2.15] == 
[10.0.2.15]
апр 25 12:14:18 OpenSips.server /usr/sbin/opensips[1213]: 
DBG:core:grep_sock_info: checking if port 5060 matches port 5060
апр 25 12:14:18 OpenSips.server /usr/sbin/opensips[1213]: 
DBG:core:grep_sock_info: checking if host==us: 9==9 && [10.0.2.15] == 
[10.0.2.15]
апр 25 12:14:18 OpenSips.server /usr/sbin/opensips[1213]: 
DBG:core:grep_sock_info: checking if port 5060 matches port 5060
апр 25 12:14:18 OpenSips.server /usr/sbin/opensips[1213]: DBG:rr:after_strict: 
Next hop: 'sip:10.0.2.4:5070;lr;transport=sctp' is loose router
апр 25 12:14:18 OpenSips.server /usr/sbin/opensips[1213]: 
DBG:core:parse_headers: flags=
апр 25 12:14:18 OpenSips.server /usr/sbin/opensips[1213]: 
DBG:core:get_hdr_field: content_length=0
апр 25 12:14:18 OpenSips.server /usr/sbin/opensips[1213]: 
DBG:core:get_hdr_field: found end of header
апр 25 12:14:18 OpenSips.server /usr/sbin/opensips[1213]: DBG:rr:after_strict: 
The last route URI: 'sip:10.0.2.4:5070;lr;transport=sctp'
апр 25 12:14:18 OpenSips.server /usr/sbin/opensips[1213]: 
DBG:rr:run_rr_callbacks: callback id 1 entered with 
апр 25 12:14:18 OpenSips.server /usr/sbin/opensips[1213]: 
DBG:dialog:dlg_onroute: Route param 'did' not found

Opensips tryes to send this ACK to the SCTP side using UDP protocol!!! source 
port it uses 5060 and remote port 5070
Of course, such an ACK does not reach the addressee. And the call does not 
complete successfully.

ACK sip:10.0.2.4:5070;lr;transport=sctp SIP/2.0
Via: SIP/2.0/UDP 10.0.2.15:5060;branch=z9hG4bKccbc.5617e394.2
Via: SIP/2.0/UDP 10.0.2.6:5060;branch=z9hG4bK-24303-1-4
From: sipp ;tag=1
To: sut ;tag=4581SIPpTag015
Call-ID: 1-24303@10.0.2.6
CSeq: 1 ACK
Max-Forwards: 69
Subject: Performance Test
Content-Length: 0
 Why opensips do not send via SCTP protocol? What I do wrong?







-- 
Oleg Podguyko___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] check_source_address()

2019-04-25 Thread Liviu Chircu

On 25.04.2019 17:11, Mark Farmer wrote:

Thanks so much for helping with this.

I have applied the suggested config but the result is the same. 
OpenSIPS routes the RE-INVITE to itself and it never gets routed back 
to the Asterisk box.
If the 2nd Route header in the RE-INVITE is the IP of the other 
interface - will that not always be the case? It's as though the 2nd 
Route header needs to be changed to have the IP of the Asterisk server.


Sanitized RE-INVITE from provider:

INVITE sip:aster...@my.host.name:5060 
 SIP/2.0


If OpenSIPS identifies "my.host.name:5060" as a local domain, this will 
screw up the routing,
as it will go from loose (RFC 3261) to strict (old, deprecated RFC 2543 
mechanism).  Notice how
its not preserving the R-URI when it routes to itself as should happen 
with RFC 3261 routing,

because it has fallen back to RFC 2543 routing.

Your provider needs to follow RFC 3261 and use as Re-INVITE Request-URI 
the exact Contact
advertised by the caller: , and not 
confuse your routing engine

with a random target such as:INVITE sip:aster...@my.host.name:5060.

--
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Autoscaling

2019-04-25 Thread Bogdan-Andrei Iancu
That's how we define the "load" from opensips perspective - as opposite 
of being available for handling new tasks :).


The "cycle" is specific to auto-scaling (not to load computing) and it 
can be configured : 
https://www.opensips.org/Documentation/Script-CoreParameters-3-0#auto_scaling_cycle


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS Summit 2019
  https://www.opensips.org/events/Summit-2019Amsterdam/

On 04/25/2019 05:43 PM, Dan Pascu wrote:

On 25 Apr 2019, at 17:29, Bogdan-Andrei Iancu wrote:


Hi Dan,

The load is considered as the time a processes is busy in doing something 
(instead of waiting for a new task to handle). It is completely unrelated to 
the CPU load. Also the load will count any busy waiting or I/O waiting done by 
the process.

In this case is it correct to define load per process as 
time_spent_processing_per_cycle/measurement_cycle?

Also regarding this measurement cycle, I see a loose reference in the docs mentioning that a cycle 
is "like 2 seconds". Can the cycle length be defined, and if so how? If it cannot be 
defined, what is its actual value? (the "like 2 seconds" reference sounds vague).


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS Summit 2019
  https://www.opensips.org/events/Summit-2019Amsterdam/

On 04/25/2019 04:47 PM, Dan Pascu wrote:

I'm trying to understand how autoscaling works and I'd like some clarifications.

When a process group load is calculated is that based on actual CPU load, or is 
it just computed as busy_processes/total_processes in that group?

What I'm trying to figure out is the behavior in the case of the TCP process 
group, which is let's say configured to spawn a new worker when it reaches 70% 
load for the TCP worker group. Now consider that this group starts with 5 
workers and at some point in time, all 5 workers are busy processing a message. 
In addition let's consider that the DNS lookup is misconfigured and it takes 3 
seconds to get an answer. This means that if the proxy receives 5 messages at a 
time, all 5 workers will be blocked in a synchronous DNS lookup for 3 seconds, 
but each using 0% CPU.

My question is, in this 3 second time window (when all 5 workers are blocked in 
waiting for the DNS lookup), if a new request arrives over TCP, will opensips 
spawn a new TCP worker because all 5 workers are busy and it considers the load 
to be 100%, or it will do nothing because it uses CPU load which is 0% since 
all 5 processes are sleeping waiting for the DNS answer?

--
Dan





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


--
Dan







___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Autoscaling

2019-04-25 Thread Dan Pascu

On 25 Apr 2019, at 17:29, Bogdan-Andrei Iancu wrote:

> Hi Dan,
> 
> The load is considered as the time a processes is busy in doing something 
> (instead of waiting for a new task to handle). It is completely unrelated to 
> the CPU load. Also the load will count any busy waiting or I/O waiting done 
> by the process.

In this case is it correct to define load per process as 
time_spent_processing_per_cycle/measurement_cycle?

Also regarding this measurement cycle, I see a loose reference in the docs 
mentioning that a cycle is "like 2 seconds". Can the cycle length be defined, 
and if so how? If it cannot be defined, what is its actual value? (the "like 2 
seconds" reference sounds vague).

> 
> Regards,
> 
> Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>  https://www.opensips-solutions.com
> OpenSIPS Summit 2019
>  https://www.opensips.org/events/Summit-2019Amsterdam/
> 
> On 04/25/2019 04:47 PM, Dan Pascu wrote:
>> I'm trying to understand how autoscaling works and I'd like some 
>> clarifications.
>> 
>> When a process group load is calculated is that based on actual CPU load, or 
>> is it just computed as busy_processes/total_processes in that group?
>> 
>> What I'm trying to figure out is the behavior in the case of the TCP process 
>> group, which is let's say configured to spawn a new worker when it reaches 
>> 70% load for the TCP worker group. Now consider that this group starts with 
>> 5 workers and at some point in time, all 5 workers are busy processing a 
>> message. In addition let's consider that the DNS lookup is misconfigured and 
>> it takes 3 seconds to get an answer. This means that if the proxy receives 5 
>> messages at a time, all 5 workers will be blocked in a synchronous DNS 
>> lookup for 3 seconds, but each using 0% CPU.
>> 
>> My question is, in this 3 second time window (when all 5 workers are blocked 
>> in waiting for the DNS lookup), if a new request arrives over TCP, will 
>> opensips spawn a new TCP worker because all 5 workers are busy and it 
>> considers the load to be 100%, or it will do nothing because it uses CPU 
>> load which is 0% since all 5 processes are sleeping waiting for the DNS 
>> answer?
>> 
>> --
>> Dan
>> 
>> 
>> 
>> 
>> 
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> 


--
Dan





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Autoscaling

2019-04-25 Thread Bogdan-Andrei Iancu

Hi Dan,

The load is considered as the time a processes is busy in doing 
something (instead of waiting for a new task to handle). It is 
completely unrelated to the CPU load. Also the load will count any busy 
waiting or I/O waiting done by the process.


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com
OpenSIPS Summit 2019
  https://www.opensips.org/events/Summit-2019Amsterdam/

On 04/25/2019 04:47 PM, Dan Pascu wrote:

I'm trying to understand how autoscaling works and I'd like some clarifications.

When a process group load is calculated is that based on actual CPU load, or is 
it just computed as busy_processes/total_processes in that group?

What I'm trying to figure out is the behavior in the case of the TCP process 
group, which is let's say configured to spawn a new worker when it reaches 70% 
load for the TCP worker group. Now consider that this group starts with 5 
workers and at some point in time, all 5 workers are busy processing a message. 
In addition let's consider that the DNS lookup is misconfigured and it takes 3 
seconds to get an answer. This means that if the proxy receives 5 messages at a 
time, all 5 workers will be blocked in a synchronous DNS lookup for 3 seconds, 
but each using 0% CPU.

My question is, in this 3 second time window (when all 5 workers are blocked in 
waiting for the DNS lookup), if a new request arrives over TCP, will opensips 
spawn a new TCP worker because all 5 workers are busy and it considers the load 
to be 100%, or it will do nothing because it uses CPU load which is 0% since 
all 5 processes are sleeping waiting for the DNS answer?

--
Dan





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] check_source_address()

2019-04-25 Thread Mark Farmer
Thanks so much for helping with this.

I have applied the suggested config but the result is the same. OpenSIPS
routes the RE-INVITE to itself and it never gets routed back to the
Asterisk box.
If the 2nd Route header in the RE-INVITE is the IP of the other interface -
will that not always be the case? It's as though the 2nd Route header needs
to be changed to have the IP of the Asterisk server.

Sanitized RE-INVITE from provider:

INVITE sip:aster...@my.host.name:5060 SIP/2.0
Max-Forwards: 67
Session-Expires: 1800;refresher=uac
Min-SE: 600
Supported: timer
Route:

Route:

To: "Test User" ;tag=26907c86-afbc-4626-b8f2-fb901de15f17
From: ;tag=3765189400-415903398
Call-ID: 4dfc3a95-7488-448c-b015-438e806eccae
CSeq: 2 INVITE
Allow: UPDATE,INFO,OPTIONS,BYE,INVITE,ACK,CANCEL
Via:
SIP/2.0/UDP 
prov.ider.ip.addr:5060;branch=z9hG4bK66abd71f0399f743ce9ff2e625aeb636
Contact: 
Content-Type: application/sdp
Accept: application/sdp
Content-Length: 263

v=0
o=sbc-uk-bs13b 454176 454177 IN IP4 prov.ider.ip.addr
s=sip call
c=IN IP4 prov.ider.ip.addr
t=0 0
a=sendonly
m=audio 42458 RTP/AVP 8 101
b=RR:3000
b=RS:1000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=maxptime:40

---

And the next Re-INVITE to itself:

INVITE
sip:10.98.0.53;r2=on;lr;ftag=26907c86-afbc-4626-b8f2-fb901de15f17;did=7e4.6832a52
SIP/2.0
Max-Forwards: 66
Session-Expires: 1800;refresher=uac
Min-SE: 600
Supported: timer
To: "Test User" ;tag=26907c86-afbc-4626-b8f2-fb901de15f17
From: ;tag=3765189400-415903398
Call-ID: 4dfc3a95-7488-448c-b015-438e806eccae
CSeq: 2 INVITE
Allow: UPDATE,INFO,OPTIONS,BYE,INVITE,ACK,CANCEL
Via: SIP/2.0/UDP 109.234.226.243:5060;branch=z9hG4bKc156.ac684935.0
Via: SIP/2.0/UDP 147.152.17.42:5060
;branch=z9hG4bK66abd71f0399f743ce9ff2e625aeb636
Contact: 
Content-Type: application/sdp
Accept: application/sdp
Content-Length: 263

v=0
o=sbc-uk-bs13b 454176 454177 IN IP4 prov.ider.ip.addr
s=sip call
c=IN IP4 prov.ider.ip.addr
t=0 0
a=sendonly
m=audio 42458 RTP/AVP 8 101
b=RR:3000
b=RS:1000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=maxptime:40

-

Perhaps I'm missing the point?

Mark.


On Thu, 25 Apr 2019 at 14:10, Liviu Chircu  wrote:

> On 24.04.2019 20:10, Mark Farmer wrote:
> > Sure, I'll send the pcap off list.
>
> It seems you are performing an interface switching operation when
> routing out,
> which leads to a double Record-Route header.  While this is completely
> fine,
> you should be aware that OpenSIPS handles a double RR'ed mid-dialog
> request by
> routing the request to itself exactly once, as it consumes the top-level
> Route
> header field.
>
> So, you definitely don't have to provision and mark OpenSIPS as a trunk,
> since
> that will likely break some other logic of your script (e.g. I see it
> now returns
> 404 in the pcap).  Rather, just extend your possible sources of traffic
> and keep
> applying loose_route() to those mid-dialog requests, then route them out:
>
> if (check_source_address("1","$avp(trunk_attrs)")) {
>  # request comes from trunks
>  xlog ("MF - $rm FROM $avp(trunk_attrs)");
>  setflag(IS_TRUNK);
> } else if (has_totag() && is_myself("$si")) {
>  setflag(IS_MYSELF);
> } else {
>  send_reply("403", "Forbidden");
>  exit;
> }
>
> if (has_totag()) {
>  ...
>  if (!loose_route())
>  send_reply("404", "Not Here");
>  else
>  t_relay();
>  exit;
> }
>
> Regards,
>
> --
> Liviu Chircu
> OpenSIPS Developer
> http://www.opensips-solutions.com
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Mark Farmer
farm...@gmail.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] Autoscaling

2019-04-25 Thread Dan Pascu

I'm trying to understand how autoscaling works and I'd like some clarifications.

When a process group load is calculated is that based on actual CPU load, or is 
it just computed as busy_processes/total_processes in that group?

What I'm trying to figure out is the behavior in the case of the TCP process 
group, which is let's say configured to spawn a new worker when it reaches 70% 
load for the TCP worker group. Now consider that this group starts with 5 
workers and at some point in time, all 5 workers are busy processing a message. 
In addition let's consider that the DNS lookup is misconfigured and it takes 3 
seconds to get an answer. This means that if the proxy receives 5 messages at a 
time, all 5 workers will be blocked in a synchronous DNS lookup for 3 seconds, 
but each using 0% CPU.

My question is, in this 3 second time window (when all 5 workers are blocked in 
waiting for the DNS lookup), if a new request arrives over TCP, will opensips 
spawn a new TCP worker because all 5 workers are busy and it considers the load 
to be 100%, or it will do nothing because it uses CPU load which is 0% since 
all 5 processes are sleeping waiting for the DNS answer?

--
Dan





___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] check_source_address()

2019-04-25 Thread Liviu Chircu

On 24.04.2019 20:10, Mark Farmer wrote:

Sure, I'll send the pcap off list.


It seems you are performing an interface switching operation when 
routing out,

which leads to a double Record-Route header.  While this is completely fine,
you should be aware that OpenSIPS handles a double RR'ed mid-dialog 
request by
routing the request to itself exactly once, as it consumes the top-level 
Route

header field.

So, you definitely don't have to provision and mark OpenSIPS as a trunk, 
since
that will likely break some other logic of your script (e.g. I see it 
now returns
404 in the pcap).  Rather, just extend your possible sources of traffic 
and keep

applying loose_route() to those mid-dialog requests, then route them out:

if (check_source_address("1","$avp(trunk_attrs)")) {
    # request comes from trunks
    xlog ("MF - $rm FROM $avp(trunk_attrs)");
    setflag(IS_TRUNK);
} else if (has_totag() && is_myself("$si")) {
    setflag(IS_MYSELF);
} else {
    send_reply("403", "Forbidden");
    exit;
}

if (has_totag()) {
    ...
    if (!loose_route())
    send_reply("404", "Not Here");
    else
        t_relay();
    exit;
}

Regards,

--
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users