Re: [OpenSIPS-Users] Help dropping SQL injection attacks

[Gregory Massel via Users]

Thank you Bogdan!

It's worth noting that, if using {s.escape.user}, it won't detect a SQL 
injection, however, it may detect other potentially problematic 
characters, so one then has to apply both checks individually, e.g.


if ( $fU != $(fU{s.escape.common}) || $tU != $(tU{s.escape.common}) ) {
xlog ("Rejecting SQL injection attempt received from 
$socket_in(proto):$si:$sp (Method: $rm; From: $fu; To: $tu; Contact: $ct).");
send_reply (403,"Forbidden");
exit;
}
if ( $fU != $(fU{s.escape.user}) || $tU != $(tU{s.escape.user}) ) {
xlog ("Rejecting request with unusual characters received from 
$socket_in(proto):$si:$sp (Method: $rm; From: $fu; To: $tu; Contact: $ct).");
send_reply (403,"Forbidden");
exit;
}

So above doesn't block UTF-8; it just enforces that it must be received 
from the client in fully escaped form.


I'm gathering that UTF-8 is actually acceptable for the user part (and 
most other parts) of the URI, provided that it's encoded with '%'? I 
work with purely ASCII user parts however, out of interest, was 
wondering if it is allowable and/or commonplace to use Unicode extended 
character sets for any portions of the URI in parts of the world where 
other character sets are more frequently used? From what I could find, 
it seems that UTF16 is not allowed in the User Part and that the domain 
would be internationalised using Punycode, so the full URI should always 
be encoded in ASCII but with UTF-8 (but not UTF-16) permitted in 
%-encoded form for the user part?


With respect to the Contact header, I'm struggling a bit. Is the syntax 
below correct?


if ( $(ct.fields(uri){uri.user}) != 
$(ct.fields(uri){uri.user}{s.escape.common}) ) {
send_reply (403,"Forbidden");
exit;
}

--
Thanks
*Gregory Massel*

On 2023-12-05 11:33, Bogdan-Andrei Iancu wrote:

Hi Gregory,

As it is said, there is no single way to skin the cat :). Your 
approach is a valid one, by using the escaping transformation. Maybe 
you should check the s.escape.user [1].


Such checks make sense when using avp_db_query(), so raw queries. The 
internal queries (like auth, etc) are done via prepared statements, so 
safe to injections.


[1] https://www.opensips.org/Documentation/Script-Tran-3-2#s.escape.user

Regards,
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com
On 30.11.2023 02:34, Gregory Massel via Users wrote:


Hi all

I'm wondering what the best practice is in terms of detection and 
dropping attempted SQL injection attacks?


Is something like the following adequate or can this be enhanced:

if ( $fU != $(fU{s.escape.common}) || $tU != $(tU{s.escape.common}) ) {
drop();
}

Obviously this does not remove the need to escape anything passed to 
avp_db_query(), however, what I want to do is identify these sorts of 
attacks at the top of the script and avoid processing.


To date all the attacks I've seen focus on the contact and from user, 
e.g.:

INVITEsip:00111390237920793@x.x.x.x:5060;transport=UDP  SIP/2.0
Contact:
To:
From:;tag=v2pjtxqb
I'm not quite sure how to match the Contact user. Would the following 
work?

if ( $(ct.fields(uri){uri.user}) != 
$(ct.fields(uri){uri.user}{s.escape.common}) ) {
drop();
}
--
Regards
*Gregory Massel*

___
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

[OpenSIPS-Users] Help dropping SQL injection attacks

[Gregory Massel via Users]

Hi all

I'm wondering what the best practice is in terms of detection and 
dropping attempted SQL injection attacks?


Is something like the following adequate or can this be enhanced:

if ( $fU != $(fU{s.escape.common}) || $tU != $(tU{s.escape.common}) ) {
drop();
}

Obviously this does not remove the need to escape anything passed to 
avp_db_query(), however, what I want to do is identify these sorts of 
attacks at the top of the script and avoid processing.


To date all the attacks I've seen focus on the contact and from user, e.g.:

INVITEsip:00111390237920793@x.x.x.x:5060;transport=UDP  SIP/2.0
Contact:
To:
From:;tag=v2pjtxqb

I'm not quite sure how to match the Contact user. Would the following work?

if ( $(ct.fields(uri){uri.user}) != 
$(ct.fields(uri){uri.user}{s.escape.common}) ) {
drop();
}

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

Re: [OpenSIPS-Users] Odd URI formatting issue when using Exec to return a variable

[Gregory Massel via Users]

Just wondering if, perhaps, the script return a line terminated with 
\r\n instead of just \n ? Or perhaps even just a \n is being pulled into 
the variable?


Perhaps try a {s.trim} transformation?

On 2023-11-15 13:27, Bogdan-Andrei Iancu wrote:

Out of curiosity, if you replace the:
    $branch = $var(out);
with
    $ru = $var(out)
is the reply properly formed ?

Regards,
Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
   https://www.opensips-solutions.com
   https://www.siphub.com
On 11/15/23 12:19 PM, Ben Bliss wrote:


HI Bogdan,

Thanks for the reply.

I was using 3.2.13, so I have now patched this to 3.2.15, which is 
the latest version on the 3.2 branch. I repeated the test and got the 
same behaviour. Please see the below information as requested…


Script…

    if ( $si == '10.10.14.71' && is_method("INVITE") ) {

exec("/usr/local/bin/sbc-route", $tU, $var(out));

    xlog("Value returned from Re-direct Script is 
$var(out)");


    $branch = $var(out);

    xlog("Target is set as $branch");

    send_reply(302, "Server Redirect");

    exit;

    }

Xlog information logged when the call request comes in…

2023-11-15T09:52:55.375039+00:00 uk-rdh-testast2 
/usr/sbin/opensips[283656]: Value returned from Re-direct Script is 
sip:33557719673@10.10.4.77


2023-11-15T09:52:55.375456+00:00 uk-rdh-testast2 
/usr/sbin/opensips[283656]: Target is set as sip:33557719673@10.10.4.77


The 302 response is below, exported from Wireshark…

No. Time Source    Destination   Protocol 
Length Info


15 09:53:20.012882 10.10.12.70   10.10.14.71   
SIP  666 Status: 302 Server Redirect |


Frame 15: 666 bytes on wire (5328 bits), 666 bytes captured (5328 bits)

Ethernet II, Src: bb:bb:bb:bb:bb:bb (bb:bb:bb:bb:bb:bb), Dst: 
aa:aa:aa:aa:aa:aa (aa:aa:aa:aa:aa:aa)


Internet Protocol Version 4, Src: 10.10.12.70, Dst: 10.10.14.71

User Datagram Protocol, Src Port: 5070, Dst Port: 5060

Session Initiation Protocol (302)

    Status-Line: SIP/2.0 302 Server Redirect

    Message Header

    From: 
sip:+4478341xx...@151.x.xxx.x;user=phone;tag=BN1699364674-1-1700041999-377836318


    To: 
sip:+4415279xx...@149.x.xxx.xx;user=phone;tag=5d8f.6023fbda08f41f7e9ebdc611f91805ef


    Call-ID: 55197572_103382...@151.x.xxx.x

    [Generated Call-ID: 55197572_103382...@151.x.xxx.x]

    CSeq: 61414 INVITE

    Via: SIP/2.0/UDP 
10.10.14.71:5060;branch=z9hG4bK-6a03d713-a7b27-28f11294-7f0923fc1278


    Via: SIP/2.0/UDP 
149.x.xxx.xx:5060;received=151.x.xxx.x;rport=5060;branch=z9hG4bK1699364674


    Via: SIP/2.0/UDP 
151.x.xxx.x:5060;branch=z9hG4bK0aB2fefabe20ff62d0e


    Contact:     [Expert Info (Warning/Malformed): Header has no colon after 
the name]


    [Header has no colon after the name]

    [Severity level: Warning]

    [Group: Malformed]

    Server: OpenSIPS (3.2.15 (x86_64/linux))

    Content-Length: 0

If it is any help, I did try another method of inputting the Contact 
header, which was using the ‘append_to_reply’ command, rather than 
using the $branch method, so I just formatted in the URI as such…


append_to_reply('Contact: <$var(out)>');

This pushed the closing > from the ‘Contact’ URI to the “Server” 
line, as you can see on the outputted 302 below…


No. Time Source    Destination   Protocol 
Length Info


 17 12:12:01.339034 10.10.12.70   10.10.14.71   
SIP  667 Status: 302 Server Redirect |


Frame 17: 667 bytes on wire (5336 bits), 667 bytes captured (5336 bits)

Ethernet II, Src: bb:bb:bb:bb:bb:bb (bb:bb:bb:bb:bb:bb), Dst: 
aa:aa:aa:aa:aa:aa (aa:aa:aa:aa:aa:aa)


Internet Protocol Version 4, Src: 10.10.12.70, Dst: 10.10.14.71

User Datagram Protocol, Src Port: 5070, Dst Port: 5060

Session Initiation Protocol (302)

    Status-Line: SIP/2.0 302 Server Redirect

    Message Header

    From: 
sip:+4478341xx...@151.x.xxx.x;user=phone;tag=BN1699364667-1-1699963921-901707368


    To: 
sip:080001xx...@149.x.xxx.xx;user=phone;tag=5d8f.a1daebfe0f15d4035f73e92edd390da9


    Call-ID: 55182316_87520...@151.x.xxx.x

    [Generated Call-ID: 55182316_87520...@151.x.xxx.x]

    CSeq: 706035 INVITE

    Via: SIP/2.0/UDP 
10.10.14.71:5060;branch=z9hG4bK-34260abf-94a28-2449afc3-7f0920d0abc8


    Via: SIP/2.0/UDP 
149.x.xxx.xx:5060;received=151.x.xxx.x;rport=5060;branch=z9hG4bK1699364667


    Via: SIP/2.0/UDP 
151.x.xxx.x:5060;branch=z9hG4bK0aB220722fa7bfe603d


    Contact: Server: OpenSIPS (3.2.13 (x86_64/linux))

    [Expert Info (Note/Undecoded): Unrecognised SIP header 
(>server)]


    [Unrecognised SIP header (>server)]

    [Severity level: Note]

    [Group: Undecoded]

    Content-Length: 0

Whether this is related or not, I cannot say, but thought I 

[OpenSIPS-Users] tls_peer_subject_cn not set on wolfssl?

[Gregory Massel via Users]

Hello

I'm using OpenSIPS 3.4.2.

When using tls_wolfssl.so, $tls_peer_subject_cn appears to always be .

However, when changing to tls_openssl.so, $tls_peer_subject_cn is then 
set correctly.


Is this an issue within tls_wolfssl, or, is $tls_peer_subject_cn only 
meant to work with OpenSSL?


--
Regards
*Gregory Massel*
*T* +27 87 550 
*F* +27 11 783 4877
*W* www.switchtel.co.za <http://www.switchtel.co.za/>___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] SQL injection in usernames

[Gregory Massel via Users]

I'm observing that fraudsters are attempting SQL injections within 
various SIP headers, e.g.


Contact:
From:;tag=t1cqzx35

Just a head's up to those using SQL queries in their dial plans to be 
careful to always *escape* the wrath!
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] $si showing contact address

[Gregory Massel via Users]

Good day all

I'm picking up a weird issue where $si is reflecting the IP address of 
the contact rather then the IP packet header.


If I run "opensips-cli -x mi ul_show_contact location redacted@domain" I 
get:


"Contact": "sip:redacted@1.2.3.1:45066",
"Received": "sip:102.132.225.36:45066",

When I look at my logs, it logged:

ACL mismatch for _*udp:1.2.3.1:45066*_ on REGISTER request for 
redacted@domain with auth-user redacted; ACL: "redacted".
xlog ("ACL mismatch for $socket_in(proto):*$si*:$sp on $rm request for 
$var(req_user)@$var(domain) with auth-user $au; ACL: \"$avp(acl)\".\n");


So it seems that, within this particular router, $si is actually being 
set to the contact IP rather than the IP source address.


Note that this check is done only after the MD5 authentication has 
completed. Even if the source failed to NAT the packet and arrived with 
spoofed IP source IP 1.2.3.1, it would never get to this point as I 
would first reply with a SIP 401 requesting authentication and they 
would never actually receive that 401 message and never be able to send 
me back an authenticated request.


If this were happening all the time, I'd expect to see tons of log 
entries with RFC1918 IP addresses, however, I don't and, in fact, this 
is an extreme rare log entry.


I do have the following which may or may not be relevant:

force_rport();
if (nat_uac_test(23)) {
if (is_method("REGISTER")) {
fix_nated_register();
setbflag("NAT");
} else {
fix_nated_contact();
setflag("NAT");
}
}

However, I still don't understand why $si would ever reflect anything 
other then the actual source IP address as per the IP packet header.


I cannot retrospectively sniff the registration that caused this, 
however, I have sniffer a subsequent REGISTER packet from the same endpoint:


2023/01/29 18:47:46.104058 102.132.225.36:45066 -> x.x.x.x:5060
REGISTERsip:domain  SIP/2.0
Via: SIP/2.0/UDP 1.2.3.1:45066;branch=z9hG4bK1021971937;rport
From:;tag=63384276
To:
Call-ID:598699451-1508...@bjc.bgi.a.baf
CSeq: 3158 REGISTER
Contact:;reg-id=1;+sip.instance=""
Authorization: Digest username="redacted", realm="domain", 
nonce="63d6a35179c64cd75dec932c20a438d014ba0ed633e2", uri="sip:domain", 
response="e549d1261c9cc5534aa0783db28529
", algorithm=MD5
Max-Forwards: 70
User-Agent: redacted
Supported: path
Expires: 180
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, 
UPDATE, MESSAGE
Content-Length: 0

The script logged $si as 1.2.3.1 at 16:56:32, however, the above was 
sniffer at 18:47:46 and the script did NOT log 1.2.3.1.


I initially considered that www_authorize() versus pv_www_authorize() 
may be introducing this, so I flushed my cache to ensure that I'd tested 
using both. It's not related to this.


It really seems to be extremely arbitrary. There are tens of thousands 
of endpoints registered and, if this was happening consistently, I would 
expect to see at least hundreds, even thousands of such log entries, 
however, I've only found ONE so far.


It appears to be to be a bug, however, before logging as such I would 
like to verify whether, perhaps, there is a valid case where $si may be 
reset to a contact IP (e.g. by one of the NAT helper functions)?


Could the following, in any shape or form, ever result in $si being 
re-set to a new value:


if ( $(si{ip.matches,$(avp(acl){csv.value,$var(i)})}) == 1 )

And, no, I never accidentally used '=' instead of '==' and the value of 
$avp(acl) would have been "165.165.0.0/16,102.132.128.0/17".


I'm using OpenSIPS 3.1.13.

Thanks

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

Re: [OpenSIPS-Users] Media server communication with OpenSIPS

[Gregory Massel]

You can send custom headers from Asterisk to OpenSIPS using:

https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Function_PJSIP_HEADER

If you need Asterisk to receive customer headers from OpenSIPS, you can 
read custom headers added by OpenSIPS to its 200 response using:


https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Function_PJSIP_RESPONSE_HEADER


If you are already midway through a call, you can force an UPDATE or 
re-INVITE using:


https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Function_PJSIP_SEND_SESSION_REFRESH


While I haven't personally tested, I'd expect that you should be able to 
signal custom information midway through a call with a 
Set(PJSIP_HEADER(add,X-MyHeader)=myvalue) followed by a 
Set(PJSIP_SEND_SESSION_REFRESH()=invite). This should then trigger a 
re-INVITE carrying the new X-MyHeader within it.


Similarly, after triggering the a re-INVITE or UPDATE, you should then 
be able to do a Set(MYVAR=PJSIP_RESPONSE_HEADER(read,X-MyHeader)) to 
extract what OpenSIPS has sent back to Asterisk in its 200 response.



Although more messy, there are also other tricks that you can use, 
including the CONNECTEDLINE function:


https://wiki.asterisk.org/wiki/display/AST/Manipulating+Party+ID+Information

https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Function_CONNECTEDLINE

e.g. If you did a 
Set(CONNECTEDLINE(name)=Information_I_wish_to_share_with_OpenSIPS), then 
this will, in one step, trigger an UPDATE or re-INVITE carrying the new 
connected party name in the SIP headers, detail which you can then 
extract from OpenSIPS. Similarly, you can also use this approach read 
information that OpenSIPS has sent to Asterisk, with a 
Set(MYVAR=CONNECTEDLINE(name)).


I mention this in case, for whatever reason, the first approach 
(described above) doesn't work as planned, however, the first approach 
is definitely preferable as you can carry the information in your own X- 
header, making it far easier to send/receive multiple headers.


On Tue, Dec 27, 2022 at 8:55 AM Wadii ELMAJDI | Evenmedia 
 wrote:

>
> Hello,
>
>
> I am using Asterisk as a media server behind OpenSIPS.
> I need to send some additional data to opensips during the call or 
at the latest during the hangup. For instance a custom hang up reason.
> Asterisk does not allow neither to send a sequential request withing 
an ongoing dialog, nor add headers to a BYE method.
> The current solution I’m using is pushing a dialog var 
(dlg_push_var) using Call-ID via (mi_http), but that means I rely on a 
curl http request during my call…
> Is there any better option for a direct communication between the 
two boxes during a call ? without any intermediate server (Redis DB …)

>
> Thank you
>
> ___
> 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
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] 3.2.3 TLS issue

[Gregory Massel]

o available.
#6 0x7f5a9ad25263 in wolfSSL_Cleanup () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/tls_wolfssl.so

No symbol table info available.
#7 0x7f5a9acd65af in ?? () from 
/usr/lib/x86_64-linux-gnu/opensips/modules/tls_wolfssl.so

No symbol table info available.
#8 0x55fdf9138c78 in ?? ()
No symbol table info available.
#9 0x55fdf9138cb1 in ?? ()
No symbol table info available.
#10 0x55fdf9138cb1 in ?? ()
No symbol table info available.
#11 0x55fdf9138cb1 in ?? ()
No symbol table info available.
#12 0x55fdf9138cb1 in ?? ()
No symbol table info available.
#13 0x55fdf9138cb1 in ?? ()
---Type  to continue, or q  to quit---
No symbol table info available.
#14 0x55fdf9138cb1 in ?? ()
No symbol table info available.
#15 0x55fdf9138cb1 in ?? ()
No symbol table info available.
#16 0x55fdf9138cb1 in ?? ()
No symbol table info available.
#17 0x55fdf913b654 in destroy_modules ()
No symbol table info available.
#18 0x55fdf915b2e0 in cleanup ()
No symbol table info available.
#19 0x55fdf915bd2b in shutdown_opensips ()
No symbol table info available.
#20 0x55fdf9137798 in handle_sigs ()
No symbol table info available.
#21 0x55fdf9093343 in main ()
No symbol table info available.

Regards

Greg


On 2021-11-18 23:36, Vlad Patrascu wrote:


Hi Gregory,

It is difficult to draw any conclusions without a backtrace so I'm 
hoping you'll be able to get the proper core dumps again in order to 
investigate this further.


Regards,
--
Vlad Patrascu
OpenSIPS Core Developer
http://www.opensips-solutions.com
On 12.11.2021 14:44, Gregory Massel wrote:


Sorry, I do have the core files, however, my /usr/sbin/opensips is 
now 3.2.2 and the core dumps were taken against 3.2.3.


I should have thought to get the backtrace before downgrading.

This is a production server, however, I will try and schedule some 
downtime and then restore 3.2.3 to generate the backtrace and will 
try out the nightly release.


--Greg



___
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
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] 3.2.3 TLS issue

[Gregory Massel]

Sorry, I do have the core files, however, my /usr/sbin/opensips is now 
3.2.2 and the core dumps were taken against 3.2.3.


I should have thought to get the backtrace before downgrading.

This is a production server, however, I will try and schedule some 
downtime and then restore 3.2.3 to generate the backtrace and will try 
out the nightly release.


--Greg

On 2021-11-12 13:09, Andrew Yager wrote:

Do you have a core dump with the backtrace when it dies?

There are a few fixes in the nightly releases around some TLS things, 
and we've found these to be a better choice for SSL performance.


Thanks,
Andrew

On Fri, 12 Nov 2021 at 02:30, Gregory Massel  wrote:

Thanks.

This report lists it as a bug in WolfSSL, however, given that I'm
got similar errors (although not a segfault) when changing to
OpenSSL, it would appear more likely that it's in proto_tls or
tls_mgm.

--Greg

On 2021-11-11 17:06, Mark Farmer wrote:

Confirmed here too, 3.2.2 is running fine.

There does seem to be a bug report about this:

https://github.com/OpenSIPS/opensips/issues/2667


On Thu, 11 Nov 2021 at 14:33, Gregory Massel
 wrote:

I've managed to downgrade to 3.2.2 and all is working again.
So this appears to be a bug introduced in 3.2.3.

Environment is:

Linux msteams 5.4.0-90-generic #101~18.04.1-Ubuntu SMP Fri
Oct 22 09:25:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

The downgrade/fix was with:

apt-get install opensips=3.2.2-1
opensips-dialplan-module=3.2.2-1
opensips-http-modules=3.2.2-1 opensips-mysql-module=3.2.2-1
opensips-presence-modules=3.2.2-1
opensips-regex-module=3.2.2-1 opensips-tls-module=3.2.2-1
opensips-tls-openssl-module=3.2.2-1
opensips-tls-wolfssl-module=3.2.2-1
opensips-tlsmgm-module=3.2.2-1

--Greg

On 2021-11-11 15:56, Gregory Massel wrote:


I'm running OpenSIPS 3.2.3 and it keeps bombing out on SSL
connections.

With WolfSSL it segfaults:

Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
INFO:tls_wolfssl:_wolfssl_tls_async_connect: new TLS connection to52.114.75.24:5061  
<http://52.114.75.24:5061>  established
Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
INFO:tls_wolfssl:_wolfssl_tls_async_connect: new TLS connection to52.114.132.46:5061  
<http://52.114.132.46:5061>  established
Nov 11 11:52:05 msteams /usr/sbin/opensips[15328]: 
CRITICAL:core:sig_usr: segfault in process pid: 15328, id: 25
Nov 11 11:52:05 msteams kernel: [22403546.537543] opensips[15328]: 
segfault at 35 ip 7ff7b4b3f790 sp 7fff48dd0a30 error 4 in 
tls_wolfssl.so[7ff7b4a71000+1e3000]
Nov 11 11:52:05 msteams kernel: [22403546.537549] Code: ff ff e9 5b ff ff ff 
0f 1f 00 53 48 8d 3d 08 40 3b 00 e8 53 09 00 00 85 c0 75 4f 48 8b 3d 50 40 3b 00 48 
85 ff 74 14 0f 1f 00 <48> 8b 5f 08 e8 87 36 f7 ff 48 85 db 48 89 df 75
ef 5b 48 8d 3d d7
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
INFO:tls_wolfssl:_wolfssl_tls_accept: New TLS connection from52.114.75.24:17152  
<http://52.114.75.24:17152>  accepted
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
INFO:tls_wolfssl:tls_dump_cert_info: tls_accept: client TLS certificate subject: 
/CN=sip.pstnhub.microsoft.com  <http://sip.pstnhub.microsoft.com>, issuer: 
/C=US/O=Microsoft Corporation/CN=Microsoft RSA TLS CA 01
Nov 11 11:52:05 msteams /usr/sbin/opensips[15325]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15325]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15329]: 
CRITICAL:core:sig_usr: segfault in process pid: 15329, id: 26
Nov 11 11:52:05 msteams kernel: [22403546.732270] traps: 
opensips[15329] general protection fault ip:7ff7b4b0953d sp:7fff48dd0760 
error:0 in tls_wolfssl.so[7ff7b4a71000+1e3000]
Nov 11 11:52:05 msteams /usr/sbin/opensips[15326]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15326]: 
NOTICE:tls_wolfssl:veri

Re: [OpenSIPS-Users] 3.2.3 TLS issue

[Gregory Massel]

Thanks.

This report lists it as a bug in WolfSSL, however, given that I'm got 
similar errors (although not a segfault) when changing to OpenSSL, it 
would appear more likely that it's in proto_tls or tls_mgm.


--Greg

On 2021-11-11 17:06, Mark Farmer wrote:

Confirmed here too, 3.2.2 is running fine.

There does seem to be a bug report about this:

https://github.com/OpenSIPS/opensips/issues/2667


On Thu, 11 Nov 2021 at 14:33, Gregory Massel  wrote:

I've managed to downgrade to 3.2.2 and all is working again. So
this appears to be a bug introduced in 3.2.3.

Environment is:

Linux msteams 5.4.0-90-generic #101~18.04.1-Ubuntu SMP Fri Oct 22
09:25:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

The downgrade/fix was with:

apt-get install opensips=3.2.2-1 opensips-dialplan-module=3.2.2-1
opensips-http-modules=3.2.2-1 opensips-mysql-module=3.2.2-1
opensips-presence-modules=3.2.2-1 opensips-regex-module=3.2.2-1
opensips-tls-module=3.2.2-1 opensips-tls-openssl-module=3.2.2-1
opensips-tls-wolfssl-module=3.2.2-1 opensips-tlsmgm-module=3.2.2-1

--Greg

On 2021-11-11 15:56, Gregory Massel wrote:


I'm running OpenSIPS 3.2.3 and it keeps bombing out on SSL
connections.

With WolfSSL it segfaults:

Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
INFO:tls_wolfssl:_wolfssl_tls_async_connect: new TLS connection to52.114.75.24:5061  
<http://52.114.75.24:5061>  established
Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
INFO:tls_wolfssl:_wolfssl_tls_async_connect: new TLS connection to52.114.132.46:5061  
<http://52.114.132.46:5061>  established
Nov 11 11:52:05 msteams /usr/sbin/opensips[15328]: CRITICAL:core:sig_usr: 
segfault in process pid: 15328, id: 25
Nov 11 11:52:05 msteams kernel: [22403546.537543] opensips[15328]: segfault 
at 35 ip 7ff7b4b3f790 sp 7fff48dd0a30 error 4 in 
tls_wolfssl.so[7ff7b4a71000+1e3000]
Nov 11 11:52:05 msteams kernel: [22403546.537549] Code: ff ff e9 5b ff ff ff 0f 
1f 00 53 48 8d 3d 08 40 3b 00 e8 53 09 00 00 85 c0 75 4f 48 8b 3d 50 40 3b 00 48 85 
ff 74 14 0f 1f 00 <48> 8b 5f 08 e8 87 36 f7 ff 48 85 db 48 89 df 75
ef 5b 48 8d 3d d7
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
INFO:tls_wolfssl:_wolfssl_tls_accept: New TLS connection from52.114.75.24:17152  
<http://52.114.75.24:17152>  accepted
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
INFO:tls_wolfssl:tls_dump_cert_info: tls_accept: client TLS certificate subject: 
/CN=sip.pstnhub.microsoft.com  <http://sip.pstnhub.microsoft.com>, issuer: 
/C=US/O=Microsoft Corporation/CN=Microsoft RSA TLS CA 01
Nov 11 11:52:05 msteams /usr/sbin/opensips[15325]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15325]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15329]: CRITICAL:core:sig_usr: 
segfault in process pid: 15329, id: 26
Nov 11 11:52:05 msteams kernel: [22403546.732270] traps: opensips[15329] 
general protection fault ip:7ff7b4b0953d sp:7fff48dd0760 error:0 in 
tls_wolfssl.so[7ff7b4a71000+1e3000]
Nov 11 11:52:05 msteams /usr/sbin/opensips[15326]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15326]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15325]: 
INFO:tls_wolfssl:_wolfssl_tls_async_connect: new TLS connection to54.171.127.194:5061 
 <http://54.171.127.194:5061>  established
Nov 11 11:52:05 msteams /usr/sbin/opensips[15330]: CRITICAL:core:sig_usr: 
segfault in process pid: 15330, id: 27
Nov 11 11:52:05 msteams kernel: [22403546.801626] traps: opensips[15330] 
general protection fault ip:7ff7b4b3f790 sp:7fff48dd0a30 error:0 in 
tls_wolfssl.so[7ff7b4a71000+1e3000]
Nov 11 11:52:05 msteams /usr/sbin/opensips[15326]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15326]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:06 msteams /usr/sbin/opensips[15325]: 
INFO:tls_wolfssl:_wolfssl_tls_async_connect: new TLS co

Re: [OpenSIPS-Users] 3.2.3 TLS issue

[Gregory Massel]

I've managed to downgrade to 3.2.2 and all is working again. So this 
appears to be a bug introduced in 3.2.3.


Environment is:

Linux msteams 5.4.0-90-generic #101~18.04.1-Ubuntu SMP Fri Oct 22 
09:25:04 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux


The downgrade/fix was with:

apt-get install opensips=3.2.2-1 opensips-dialplan-module=3.2.2-1 
opensips-http-modules=3.2.2-1 opensips-mysql-module=3.2.2-1 
opensips-presence-modules=3.2.2-1 opensips-regex-module=3.2.2-1 
opensips-tls-module=3.2.2-1 opensips-tls-openssl-module=3.2.2-1 
opensips-tls-wolfssl-module=3.2.2-1 opensips-tlsmgm-module=3.2.2-1


--Greg

On 2021-11-11 15:56, Gregory Massel wrote:


I'm running OpenSIPS 3.2.3 and it keeps bombing out on SSL connections.

With WolfSSL it segfaults:

Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
INFO:tls_wolfssl:_wolfssl_tls_async_connect: new TLS connection to 
52.114.75.24:5061 established
Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:04 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
INFO:tls_wolfssl:_wolfssl_tls_async_connect: new TLS connection to 
52.114.132.46:5061 established
Nov 11 11:52:05 msteams /usr/sbin/opensips[15328]: CRITICAL:core:sig_usr: 
segfault in process pid: 15328, id: 25
Nov 11 11:52:05 msteams kernel: [22403546.537543] opensips[15328]: segfault at 
35 ip 7ff7b4b3f790 sp 7fff48dd0a30 error 4 in 
tls_wolfssl.so[7ff7b4a71000+1e3000]
Nov 11 11:52:05 msteams kernel: [22403546.537549] Code: ff ff e9 5b ff ff ff 0f 1f 00 
53 48 8d 3d 08 40 3b 00 e8 53 09 00 00 85 c0 75 4f 48 8b 3d 50 40 3b 00 48 85 ff 74 
14 0f 1f 00 <48> 8b 5f 08 e8 87 36 f7 ff 48 85 db 48 89 df 75
ef 5b 48 8d 3d d7
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
INFO:tls_wolfssl:_wolfssl_tls_accept: New TLS connection from 
52.114.75.24:17152 accepted
Nov 11 11:52:05 msteams /usr/sbin/opensips[15322]: 
INFO:tls_wolfssl:tls_dump_cert_info: tls_accept: client TLS certificate 
subject: /CN=sip.pstnhub.microsoft.com, issuer: /C=US/O=Microsoft 
Corporation/CN=Microsoft RSA TLS CA 01
Nov 11 11:52:05 msteams /usr/sbin/opensips[15325]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15325]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15329]: CRITICAL:core:sig_usr: 
segfault in process pid: 15329, id: 26
Nov 11 11:52:05 msteams kernel: [22403546.732270] traps: opensips[15329] 
general protection fault ip:7ff7b4b0953d sp:7fff48dd0760 error:0 in 
tls_wolfssl.so[7ff7b4a71000+1e3000]
Nov 11 11:52:05 msteams /usr/sbin/opensips[15326]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15326]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15325]: 
INFO:tls_wolfssl:_wolfssl_tls_async_connect: new TLS connection to 
54.171.127.194:5061 established
Nov 11 11:52:05 msteams /usr/sbin/opensips[15330]: CRITICAL:core:sig_usr: 
segfault in process pid: 15330, id: 27
Nov 11 11:52:05 msteams kernel: [22403546.801626] traps: opensips[15330] 
general protection fault ip:7ff7b4b3f790 sp:7fff48dd0a30 error:0 in 
tls_wolfssl.so[7ff7b4a71000+1e3000]
Nov 11 11:52:05 msteams /usr/sbin/opensips[15326]: 
NOTICE:tls_wolfssl:verify_callback: depth = 1, verify success
Nov 11 11:52:05 msteams /usr/sbin/opensips[15326]: 
NOTICE:tls_wolfssl:verify_callback: depth = 0, verify success
Nov 11 11:52:06 msteams /usr/sbin/opensips[15325]: 
INFO:tls_wolfssl:_wolfssl_tls_async_connect: new TLS connection to 
52.114.14.70:5061 established
Nov 11 11:52:06 msteams /usr/sbin/opensips[15325]: 
INFO:tls_wolfssl:_wolfssl_tls_async_connect: new TLS connection to 
54.172.60.3:5061 established
Nov 11 11:52:06 msteams /usr/sbin/opensips[15293]: INFO:core:handle_sigs: child 
process 15328 exited by a signal 11
Nov 11 11:52:06 msteams /usr/sbin/opensips[15293]: INFO:core:handle_sigs: core 
was generated
Nov 11 11:52:06 msteams /usr/sbin/opensips[15293]: INFO:core:handle_sigs: 
terminating due to SIGCHLD
Nov 11 11:52:06 msteams /usr/sbin/opensips[15296]: INFO:core:sig_usr: signal 15 
received
Nov 11 11:52:06 msteams /usr/sbin/opensips[15297]: INFO:core:sig_usr: signal 15 
received
Nov 11 11:52:06 msteams /usr/sbin/opensips[15293]: INFO:core:shutdown_opensips: 
process 3(15296) [time_keeper] terminated,

[OpenSIPS-Users] 3.2.3 TLS issue

[Gregory Massel]

opensips/issues
Nov 11 15:46:35 msteams /usr/sbin/opensips[5044]: CRITICAL:core:io_watch_add: 
#012>>> used fd map fd=227 is not present in fd_array 
(fd=227,type=19,flags=8002,data=0x7f4b4e12eb80)#012#012It seems you have hit a 
programming bug.#012Please help us make OpenSIPS better by reporting it 
athttps://github.com/OpenSIPS/opensips/issues
Nov 11 15:46:35 msteams /usr/sbin/opensips[5044]: CRITICAL:core:io_watch_add: 
#012>>> unused fd_map fd=236 has bogus data 
(fd=-1,flags=2000,data=(nil))#012#012It seems you have hit a programming 
bug.#012Please help us make OpenSIPS better by reporting it 
athttps://github.com/OpenSIPS/opensips/issues
Nov 11 15:46:35 msteams /usr/sbin/opensips[5044]: CRITICAL:core:io_watch_add: 
[TCP_main] check failed after successful fd add 
(fd=244,type=19,data=0x7f4b4e1c8240,flags=2) already=0

I didn't have these issues with OpenSIPS 3.1, however, am not sure how 
to downgrade as, when I do, it complains that the database table 
structure is not suitable and there does not appear to be a migration 
script to revert to an older version.



--
Regards
*Gregory Massel*
*T* +27 87 550 
*F* +27 11 783 4877
*W* www.switchtel.co.za <http://www.switchtel.co.za/>___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] OPUS transcoding query

[Gregory Massel]

A few factors to consider:

_1. Quality_

1.1. If you transcode to PCMU using RTPengine, you will lose the 
wideband audio quality benefits of Opus. By contrast, if Asterisk 
accepts the calls using Opus, it will transcode internally to sln16 for 
purposes of media processing (playing IVRs, music-on-hold, etc.), 
allowing for superior audio quality on that media (IVR, MOH, etc.). If 
Asterisk is going to be generating media, it would be preferable to let 
it receive the call in Opus.


1.2. If Asterisk is merely bridging endpoints and not generating any 
media nor recording calls and its only media-processing role in your 
scenario is transcoding, then the call quality will, in any case, never 
be better than PCMU quality and there would be no difference in call 
quality whether transcoding within Asterisk or RTPengine.


1.3. If the other side supports some other wideband codec that Asterisk 
doesn't support, RTPengine may be better. E.g For a GSM Mobile network, 
they may support AMR-WB and RTPengine should be able to transcode Opus 
to AMR-WB. This would give a quality advantage to RTPengine over 
Asterisk (although Opus to AMR-WB may be computationally expensive).


1.4. If you're recording some (or all) of the calls within Asterisk, 
consider the format in which you're recording them and the call quality. 
Again, if Asterisk receives the call as Opus and records in a 
high-definition format (e.g. Sln16 or MP3), then the recordings will be 
superior versus if it receives the calls already transcoded to PCMU.


_2. Processing_

2.1. RTPengine is much more efficient at RTP proxying _when using 
in-kernel packet forwarding_ versus non-kernel packet forwarding. The 
difference in terms of CPU usage and system load is significant.


2.1. Per https://github.com/sipwise/rtpengine "Transcoding happens in 
userspace only, so in-kernel packet forwarding will _not be available 
for transcoded codecs_."


2.2. I've not seen any measured benchmarks of Asterisk versus 
RTPengine's _non-kernel_ packet forwarding, however, in my experience, 
both result in similar load on the same hardware. RTPengine does, 
however, materially outperform Asterisk in scenarios where in-kernel 
packet forwarding is possible (i.e. no transcoding required).


2.3. My scenarios never involved transcoding Opus. It's possible that 
either Asterisk or RTPengine may have a superior approach towards the 
transcoding, however, this is extremely unlikely (and even more unlikely 
to have a material impact on performance) as the codecs are the same and 
should follow the same algorithms.


_3. Scale_

3.1. Even on generous hardware, Asterisk is unlikely to comfortably 
transcode more than 1,000 simultaneous Opus-to-PCMU calls.


3.2. I'm not sure about RTPengine, however, it's probably safe to say 
that the transcoding itself is sufficiently computationally expensive 
that you'll encounter a similar limit.


3.3. Depending on your configuration, you may find it easier to have 
OpenSIPS direct calls through a pool of multiple RTPengine servers. By 
comparison, if you're directing calls through to a pool of Asterisk 
servers, you *MAY* have additional complexity (e.g. consider conference 
calls where the Asterisk server needs all the calls on one server in 
order to conference them).


3.4. If you're pushing the limits of Asterisk (e.g. using it to 
conferencing hundreds or thousands of participants), then it would 
almost certainly be wiser to have RTPengine first transcode to PCMU, as 
a single Asterisk box won't be able to perform that volume of 
transcoding and conferencing.


_4. Other_

4.1. WebRTC supports PCMU. Consider establishing the call PCMU-to-PCMU 
from the outset and avoiding transcoding altogether!


4.2. WebRTC generally requires that the media be encrypted with DTLS. If 
RTPengine is already performing the task of decrypting DTLS-encoded 
media, then you may get a performance advantage by transcoding to PCMU 
at the same time, particularly if Asterisk can then cut itself out of 
the media path and direct the media from the RTPengine to the other 
bridged endpoint. In essence, you're then only manipulating the media 
ONCE, not TWICE, cutting down on latency, network traffic, etc. If 
RTPengine first decrypts and then passes decrypted media to Asterisk and 
Asterisk then transcodes, this will likely be less efficient.



So obviously it's not as simple as saying one will always outperform the 
other, however, there are probably more scenarios in which option 2 
would be preferable.



On 2021-07-19 08:53, Mark Allen wrote:

I wonder if anyone can offer any insights...

We are using OpenSIPS 3.1 as a mid-registrar and in front of an 
Asterisk box. We include incoming WebRTC traffic using the OPUS codec. 
Which do you think would be the better option:


1 - Pass OPUS directly through to Asterisk
2 - Use RTPEngine to transcode OPUS to PCMU before passing it on to 
Asterisk to reduce the workload on the Asterisk box


If option 2 would 

Re: [OpenSIPS-Users] time going backwards?

[Gregory Massel]

Per https://www.opensips.org/Documentation/Script-CoreVar-3-1 



$Tsm - reference to current microseconds _*of the current second*_

This means that if the second counter cycles up, the microsecond counter 
will cycle back to zero and you'll get a negative.


e.g. Let's assume that at the time of the first reading of $Tsm it is 
12:00:00.9 and, at the time of the second reading, it's 
12:00:01.3, then you'll get a result of -0.6, because you're 
looking at the fraction of a second in isolation to the second counter.


So you probably need something like:

$var(t0s) = $Ts;
$var(t0ms) = $Tsm;
$var(node_number) = route(get_my_node_number);
$var(dur) = (($Ts - $var(t0s))*100) + $Tsm - $var(t0ms);

Note: I'm not sure whether the syntax above is correct (I've never tried 
to do arithmetic operations within OpenSIPS), but the basic idea is there.


--Greg

On 2021-06-25 22:01, Kingsley Tart wrote:

Hi,

For testing, this code at the top of my route script:

$var(t0) = $Tsm;
$var(node_number) = route(get_my_node_number);
$var(dur) = $Tsm - $var(t0);
xlog("My node number is $var(node_number) and it took $var(dur) 
microsecconds to find out\n");

has just logged this:

Jun 25 20:55:01 [598]: My node number is -1 and it took 65 
microsecconds to find out
Jun 25 20:55:03 [598]: My node number is -1 and it took 67 
microsecconds to find out
Jun 25 20:55:05 [598]: My node number is -1 and it took 64 
microsecconds to find out
Jun 25 20:55:05 [578]: My node number is -1 and it took 602523 
microsecconds to find out
Jun 25 20:55:06 [579]: My node number is -1 and it took -79396 
microsecconds to find out
Jun 25 20:55:07 [598]: My node number is -1 and it took 63 
microsecconds to find out
Jun 25 20:55:07 [580]: My node number is -1 and it took -455503 
microsecconds to find out
Jun 25 20:55:07 [579]: My node number is -1 and it took 108 
microsecconds to find out
Jun 25 20:55:09 [598]: My node number is -1 and it took 78 
microsecconds to find out
Jun 25 20:55:11 [598]: My node number is -1 and it took 68 
microsecconds to find out
Jun 25 20:55:13 [598]: My node number is -1 and it took 66 
microsecconds to find out
Jun 25 20:55:15 [598]: My node number is -1 and it took 68 
microsecconds to find out
Jun 25 20:55:17 [598]: My node number is -1 and it took 65 
microsecconds to find out
Jun 25 20:55:18 [578]: My node number is -1 and it took 107 
microsecconds to find out
Jun 25 20:55:19 [598]: My node number is -1 and it took 71 
microsecconds to find out

which is weird because time seems to have gone backwards a couple of times.

Using OpenSIPS 3.1.2 in a VM running Debian 10, with the host being a
CentOS 7 machine running Qemu KVM.

Any idea what's happening here?

Cheers,
Kingsley.


___
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] Handling mobile switch from wifi to data

[Gregory Massel]

Just wondering what clients people are using that support this?

LinPhone and MizoVoIP? Are there others?

On 2021-03-17 11:32, Johan De Clercq wrote:

sending push before you send the invite solves many many problems.

Op wo 17 mrt. 2021 om 08:54 schreef Mark Allen <mailto:m...@allenclan.co.uk>>:


OK - thanks for that. I'll give it a try

On Tue, 16 Mar 2021 at 12:22, Johan De Clercq mailto:jo...@democon.be>> wrote:

Implement push.

Op di 16 mrt. 2021 om 13:15 schreef Mark Allen
mailto:m...@allenclan.co.uk>>:

We are using OpenSIPS 3.1 as a mid_registrar in AOR
Throttling mode. When a mobile moves from data to wifi or
vice versa, my understanding is that the registration on
OpenSIPS becomes stale (because the phone has a new IP
address). Does this mean that the mobile phone is not
registered until registration expiry is reached on the
mobile app and a new REGISTER is sent? If so, is there
anything that can be done to mitigate this?
___
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>

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

___
Users mailing list
Users@lists.opensips.org <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
<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

--
Regards
*Gregory Massel*
*T* +27 87 550 
*F* +27 11 783 4877
*W* www.switchtel.co.za <http://www.switchtel.co.za/>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] [BLOG] Exploring SSL/TLS libraries for OpenSIPS 3.2

[Gregory Massel]

Are there any temporary ways to mitigate the issues in the mean time?

E.g. Would "tcp_workers=1" help? (i.e. avoiding multiple processes 
calling OpenSSL in parallel).


On 2021-02-11 14:33, Vlad Patrascu wrote:

Hello everyone,

Check out this new blog post [1] that recounts our process of 
searching for and choosing a SSL/TLS library to use in OpenSIPS 3.2, 
as an alternative to the problematic OpenSSL.


[1] 
https://blog.opensips.org/2021/02/11/exploring-ssl-tls-libraries-for-opensips-3-2/


Cheers,



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

[OpenSIPS-Users] libcrypto segfault

[Gregory Massel]

Does the following mean that the issue is with libcrypto or could it 
still be something with OpenSIPS?


It's intermittent on startup.

Feb 20 05:25:44 vpbx2 /usr/sbin/opensips[3726528]: CRITICAL:core:sig_usr: 
segfault in attendant (starter) process!

Reading symbols from /usr/sbin/opensips...
(No debugging symbols found in /usr/sbin/opensips)
[New LWP 3725546]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/sbin/opensips -P /run/opensips/opensips.pid -f 
/etc/opensips/opensips.cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f2689db7116 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.1
(gdb) bt full
#0  0x7f2689db7116 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.1
No symbol table info available.
#1  0x7f2689db742f in OPENSSL_cleanup () from 
/lib/x86_64-linux-gnu/libcrypto.so.1.1
No symbol table info available.
#2  0x7f27aa7fba27 in __run_exit_handlers (status=-1, listp=0x7f27aa99d718 
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, 
run_dtors=run_dtors@entry=true) at exit.c:108
atfct = 
onfct = 
cxafct = 
f = 
new_exitfn_called = 16
cur = 0x7f27aa99f980 
#3  0x7f27aa7fbbe0 in __GI_exit (status=) at exit.c:139
No locals.
#4  0x7f27aa7d90ba in __libc_start_main (main=0x55e6af838600 , argc=11, 
argv=0x7fff109b3b58, init=, fini=, rtld_fini=,
stack_end=0x7fff109b3b48) at ../csu/libc-start.c:342
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {94449277169232, 
-321819203431826978, 94449275489840, 140733471996752, 0, 0, 321596249648921054, 
416582796304579038}, mask_was_saved = 0}},
  priv = {pad = {0x0, 0x0, 0xb, 0x7fff109b3b58}, data = {prev = 0x0, 
cleanup = 0x0, canceltype = 11}}}
not_first_call = 
#5  0x55e6af83ce5e in _start ()
No symbol table info available.

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

[OpenSIPS-Users] Auto process scaling (UDP worker) and crashes

[Gregory Massel]

Hello

Is anyone successfully using auto process scaling on a high volume system?

I've been having a number of issues, including excessive system load, 
deadlocks on the UDP worker processes and segmentation faults, both once 
running as well as in the attendant (starter) process.


While I haven't yet been able to establish a conclusive reason, one of 
the changes that I implemented in the last week was to enable an 
auto_scaling_profile.


Unfortunately my init scripts weren't set up to collect core dumps, so I 
cannot establish with any certainty the exact point at which the past 
segfaults occurred. I have now corrected these so that, going forward, I 
should be able to obtain backtraces. But there mere fact that average 
system load has been ~33% less in the hour since restarting with auto 
scaling disabled versus the hour prior (despite traffic levels being 
similar) is, in itself, quite curious.


Thanks

Greg


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

Re: [OpenSIPS-Users] API Question

[Gregory Massel]

MI: https://www.opensips.org/Documentation/Interface-MI-3-1

On 2021-02-10 16:44, Alexander Perkins wrote:
Hi All.  I have what may appear to be a silly question.  Does OpenSIPS 
have some sort of way to interact with it via an API?  For example 
(very simplistic) something where I can consume a URL of the OpenSIPS 
server and pass it a to and from number and it can send me the 
result?  Like 200, etc?


I know this sounds overly simplified, but I just need a point in the 
right direction.


Thanks, All!

Alex

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

--
Regards
*Gregory Massel*
*T* +27 87 550 
*F* +27 11 783 4877
*W* www.switchtel.co.za <http://www.switchtel.co.za/>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] opensips-cli and /tmp

[Gregory Massel]

I struggled for quite some time to get opensips-cli working on Ubuntu 
20.04 LTS.


It seems that there are now some security protections within the Linux 
kernel (|fs.protected_fifos) |against users other then the original 
creator from writing to fifo files in /tmp.


https://unix.stackexchange.com/questions/503111/group-permissions-for-root-not-working-in-tmp 



I eventually got opensips-cli working by moving the opensips_fifo into 
/var/run/opensip/ instead of /tmp and then setting up an 
opensips-cli.cnf file that pointed opensips-cli to the new fifo path.


I don't fully undertand the reasons for protecting fifos in this manner 
but I'm guessing that the intent is to prevent something other then the 
intended application from creating the fifo first and then snooping in 
to any data sent by client applications. Although the risk for something 
like opensips-cli is probably minimal, I can see how this may present a 
security risk for other applications.


This calls into question whether it is sensible to continue creating the 
opensips_fifo within /tmp by default? Perhaps, for future versions, the 
default should be in a directory owned by the opensips user (rather than 
one with the sticky bit set)?


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

[OpenSIPS-Users] BLF with parallel forking on OpenSIPS 3.1.1

[Gregory Massel]

Seasons greetings!

I've implemented BLF using presence, presence_dialoginfo and 
pua_dialoginfo and, provided there is only one dialed branch, it works 
as expected.


However, I do allow multiple registrations and, as soon as I have two or 
more contacts registered and parallel forking of calls, BLF does not 
work correctly in respect of the called party.


I'm running OpenSIPS *3.1.1* and what I'm seeing, when parallel forking 
takes place, is as follows:


_1. NOTIFY messages are issued for both branches with unique dialog id's:_

earlysip:1...@vpbx2.switchtel.co.zasip:sw...@vpbx2.switchtel.co.za


earlysip:1...@vpbx2.switchtel.co.zasip:sw...@vpbx2.switchtel.co.za

At this stage, BLF is behaving as one would expect, and the light 
indicates that the extension is ringing.

Then I answer the call.

_2. NOTIFY messages are issued for both branches, one "confirmed" and 
one "terminated""_



confirmedsip:1...@vpbx2.switchtel.co.zasip:sw...@vpbx2.switchtel.co.za


terminatedsip:1...@vpbx2.switchtel.co.zasip:sw...@vpbx2.switchtel.co.za

The above behavior is as one would expect; it has correctly notified 
that one branch was answered and the other terminated.

However, what follows is where the problem comes in.

_3. NOTIFY message is immediately issued with "full" state:_




After this, the BLF light goes from flashing (indicating that it was in 
the ringing state) to indicating that the extension is available again, 
despite the fact that it is on an active call.


When one then hangs up the call, no PUBLISH message is generated 
internally by OpenSIPS nor is any NOTIFY message sent.



It appears that the presence server thinks that the call terminated as 
soon as one of the branches terminated and is unaware that the other 
branch confirmed.


I'm at a loss as to what I've done wrong or how to correct it.


The moment I deregister the additional contacts (so that only a single 
contact remains for the subscriber and no parallel forking takes place), 
everything works perfectly again.


Any advice on how I can resolve this would be greatly appreciated.


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

Re: [OpenSIPS-Users] shm memory error

[Gregory Massel]

This issue has come back again:

Oct 15 11:55:20 proxy /usr/sbin/opensips[21737]: ERROR:core:fm_malloc: 
not enough free shm memory (651730736 bytes left, need 6720), please 
increase the "-m" command line parameter!


Lots of shared memory left, but it's still saying not enough.

Any guidance on how I can debug this would be hugely appreciated.

Thanks
Greg

On 2020-09-14 4:20 pm, Gregory Massel wrote:

Hello

Does anyone know what would cause the following:

Sep 14 15:33:39 proxy /usr/sbin/opensips[30920]: ERROR:core:fm_malloc: 
not enough free shm memory (290427312 bytes left, need 6720), please 
increase the "-m" command line parameter!
Sep 14 15:33:39 proxy /usr/sbin/opensips[30920]: ERROR:core:fm_malloc: 
not enough free shm memory (290416528 bytes left, need 6720), please 
increase the "-m" command line parameter!
Sep 14 15:33:39 proxy /usr/sbin/opensips[30919]: ERROR:core:fm_malloc: 
not enough free shm memory (290401384 bytes left, need 6720), please 
increase the "-m" command line parameter!
Sep 14 15:33:39 proxy /usr/sbin/opensips[30917]: ERROR:core:fm_malloc: 
not enough free shm memory (290388104 bytes left, need 6720), please 
increase the "-m" command line parameter!
Sep 14 15:33:39 proxy /usr/sbin/opensips[30919]: ERROR:core:fm_malloc: 
not enough free shm memory (290373648 bytes left, need 6720), please 
increase the "-m" command line parameter!


Note that it's saying that it needs far less than what is actually 
left, so it doesn't appear to be a case that the shared memory has 
actually run out, despite it reporting that.


This is OpenSIPS 3.0.3.

The weird thing is that, after approximately five minutes, it just 
seemed to come right by itself.


Thanks
Greg



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

[OpenSIPS-Users] shm memory error

[Gregory Massel]

Hello

Does anyone know what would cause the following:

Sep 14 15:33:39 proxy /usr/sbin/opensips[30920]: ERROR:core:fm_malloc: 
not enough free shm memory (290427312 bytes left, need 6720), please 
increase the "-m" command line parameter!
Sep 14 15:33:39 proxy /usr/sbin/opensips[30920]: ERROR:core:fm_malloc: 
not enough free shm memory (290416528 bytes left, need 6720), please 
increase the "-m" command line parameter!
Sep 14 15:33:39 proxy /usr/sbin/opensips[30919]: ERROR:core:fm_malloc: 
not enough free shm memory (290401384 bytes left, need 6720), please 
increase the "-m" command line parameter!
Sep 14 15:33:39 proxy /usr/sbin/opensips[30917]: ERROR:core:fm_malloc: 
not enough free shm memory (290388104 bytes left, need 6720), please 
increase the "-m" command line parameter!
Sep 14 15:33:39 proxy /usr/sbin/opensips[30919]: ERROR:core:fm_malloc: 
not enough free shm memory (290373648 bytes left, need 6720), please 
increase the "-m" command line parameter!


Note that it's saying that it needs far less than what is actually left, 
so it doesn't appear to be a case that the shared memory has actually 
run out, despite it reporting that.


This is OpenSIPS 3.0.3.

The weird thing is that, after approximately five minutes, it just 
seemed to come right by itself.


Thanks
Greg

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

[OpenSIPS-Users] OpenSIPS NOTIFY for MWI on Asterisk PUBLISH?

[Gregory Massel]

Hello

I'm wondering whether it is possible to bulk publish MWI information 
from Asterisk to OpenSIPS and have OpenSIPS generate NOTIFY messages?


I've set up Asterisk with PJSIP as follows:

[opensips-mwi]
type=outbound-publish
server_uri=sip:asterisk-mwi@opensips:5060
event=asterisk-mwi

[opensips-mwi]
type=asterisk-publication
mailboxstate_publish=opensips-mwi
device_state=no
mailbox_state=yes

Now it's generating numerous SIP requests such as the following:

PUBLISH sip:asterisk-mwi@opensips:5060 SIP/2.0
Via: SIP/2.0/UDP 
1.2.3.4:5060;rport;branch=z9hG4bKPj00450957-4e0c-408e-bdc2-3a4560613253
From: ;tag=d13b162a-6b45-418e-9443-66944b5cc88e
To: 
Call-ID: 761d94e5-1d41-4bfd-9354-66651e1692bd
CSeq: 17836 PUBLISH
Event: asterisk-mwi
Expires: 3600
Max-Forwards: 70
User-Agent: Asterisk
Content-Type: application/json
Content-Length:93

{"type":"mailboxstate","uniqueid":"201@test","old":0,"new":0,"eid":"90:b1:1c:0d:12:84"}

However, I'm struggling to transform these on OpenSIPS.
I've used the json.so module to interpret the body and sipmsgops.so to 
remove and the old body and add a newly constructed body with an 
application/simple-message-summary structure.
I've managed to get the packet looking almost right, however, one major 
issue remains:
No matter what I do, I cannot modify the request method from PUBLISH to 
NOTIFY.
Using subst("/PUBLISH/NOTIFY/") from textops.so, it succeeds in 
modifying the CSeq header, but it cannot change the request method.


Is it possible to modify the request method? If not, is there some other 
way that I can generate completely new MWI NOTIFY packets?


Note that presence is working 100%; that's not an issue. It's strictly 
MWI that's a problem.
Documentation on presence_mwi.so seems to be extremely limited. It's 
unclear what it actually does.


It's not really an option to have a separate PJSIP endpoint definition 
in Asterisk for each mailbox as Asterisk/PJSIP struggles to reload with 
tens of thousands of endpoints. Things work reasonably up until roughly 
12,000 endpoints, but beyond that reloads get slow. I don't forsee this 
being any better with realtime, as sorcery would still have to load all 
the endpoints into cache and merge the changes. Having a single 
(OpenSIPS) endpoint in Asterisk and publishing the voicemail status 
should allow for far greater scale.


Any help would be greatly appreciated.

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

Re: [OpenSIPS-Users] TLS handshake failure

[Gregory Massel]

Thank you Alexey.

Your suggestions solved the problem!

On 2020-07-07 8:15 am, Alexey Vasilyev wrote:

Hi Gregory,

Starting from 01.07.2020 Microsoft requires Route headers with SBC_FQDN in
SIP replies too. Instead of simple record_route() for SIP request from MS
servers OpenSIPS should add FQDN.

I've updated the article. Check it.
https://blog.opensips.org/2019/09/16/opensips-as-ms-teams-sbc/



-
---
Alexey Vasilyev
--
Sent from: 
http://opensips-open-sip-server.1449251.n2.nabble.com/OpenSIPS-Users-f1449235.html

___
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

[OpenSIPS-Users] TLS handshake failure

[Gregory Massel]

Hello

As of five days ago, my OpenSIPS 'SBC' for Microsoft Teams has started 
failing outbound Teams calls (with no changes to the config and after 
everything was working for many weeks prior).


In the direction where OpenSIPS sends the INVITE to Microsoft, 
everything still works normally. It's only problematic in the direction 
where Microsoft sends the INVITE to OpenSIPS.


In my logs, I can see it accepts the first TLS connection, however after 
the INVITE is received, Microsoft tries to establish another TLS 
connection from the same IP and that fails during the TLS handshake.


Jul  7 00:10:02 msteams /usr/sbin/opensips[26344]: 
INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
Jul  7 00:10:02 msteams /usr/sbin/opensips[26344]: 
INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 178
Jul  7 00:10:02 msteams /usr/sbin/opensips[26326]: 
NOTICE:tls_mgm:verify_callback: depth = 2, verify success
Jul  7 00:10:02 msteams /usr/sbin/opensips[26326]: 
NOTICE:tls_mgm:verify_callback: depth = 1, verify success
Jul  7 00:10:02 msteams /usr/sbin/opensips[26326]: 
NOTICE:tls_mgm:verify_callback: depth = 0, verify success
Jul  7 00:10:02 msteams /usr/sbin/opensips[26326]: INFO:proto_tls:tls_accept: 
New TLS connection from 52.114.76.76:2560 accepted
Jul  7 00:10:02 msteams /usr/sbin/opensips[26326]: 
INFO:proto_tls:tls_dump_cert_info: tls_accept: client TLS certificate subject: 
/CN=sip.pstnhub.microsoft.com, issuer: 
/C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=Microsoft 
IT/CN=Microsoft IT TLS CA 4
Jul  7 00:10:02 msteams /usr/sbin/opensips[26326]: 
INFO:proto_tls:tls_dump_cert_info: tls_accept: local TLS server certificate 
subject: /CN=msteams.switchtel.co.za, issuer: /C=US/O=Let's Encrypt/CN=Let's 
Encrypt Authority X3
Jul  7 00:10:02 msteams /usr/sbin/opensips[26326]: Call from 
sip:+27105000...@sip.pstnhub.microsoft.com:5061;user=phone to 
sip:+27875500...@samsip1.switchtel.co.za, Socket tls:52.114.76.76:2560 to 
tls:196.216.192.19:5061, 
Contact-URI=sip:api-du-b-usea.pstnhub.microsoft.com:443;x-i=346158ef-e50e-4a58-9f08-af7e7813acef;x-c=720af6d686d05fba9a27b237dd0a5ecb/d/8/222b0a8fe57c4584ab717a05b7f0b93f,
 Teams_Domain=msteams.switchtel.co.za

The logs above show the connection from 52.114.76.76:2560 was 
successful, client and server certificates verified, and the INVITE 
packet was received from Microsoft.
The logs below show the connection from 52.114.76.76:2561 and 
52.114.76.76:2562, just two seconds later, with TLS handshake failure. 
The 2 second gap is the time it takes to send the "200 OK"; that is 
transmitting via the initial connection, however, it seems that 
Microsoft thinks the first connection is dead and attempts to reconnect.


Jul  7 00:10:04 msteams /usr/sbin/opensips[26344]: 
INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
Jul  7 00:10:04 msteams /usr/sbin/opensips[26344]: 
INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 179
Jul  7 00:10:04 msteams /usr/sbin/opensips[26328]: ERROR:proto_tls:tls_accept: 
New TLS connection from 52.114.76.76:2561 failed to accept
Jul  7 00:10:04 msteams /usr/sbin/opensips[26328]: 
ERROR:proto_tls:tls_read_req: failed to do pre-tls reading
Jul  7 00:10:04 msteams /usr/sbin/opensips[26344]: 
INFO:core:probe_max_sock_buff: using snd buffer of 416 kb
Jul  7 00:10:04 msteams /usr/sbin/opensips[26344]: 
INFO:core:init_sock_keepalive: TCP keepalive enabled on socket 179
Jul  7 00:10:04 msteams /usr/sbin/opensips[26328]: ERROR:proto_tls:tls_accept: 
New TLS connection from 52.114.76.76:2562 failed to accept
Jul  7 00:10:04 msteams /usr/sbin/opensips[26328]: 
ERROR:proto_tls:tls_read_req: failed to do pre-tls reading

If I take a TShark sample, the first connection gets "Certificate, 
Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted 
Handshake Message" while the second and third connections seem to lack 
this part of the TLS handshake:


 22 9.027531791 52.114.76.76 â 196.216.192.19 TLSv1.2 2370 Client Hello
   23 9.027555818 196.216.192.19 â 52.114.76.76 TCP 54 5061 â 7106 [ACK] Seq=1 
Ack=2317 Win=63232 Len=0
   24 9.030106811 196.216.192.19 â 52.114.76.76 TLSv1.2 2934 Server Hello, 
Certificate
   25 9.030278247 196.216.192.19 â 52.114.76.76 TLSv1.2 230 Server Key 
Exchange, Certificate Request, Server Hello Done
   26 9.223719073 52.114.76.76 â 196.216.192.19 TCP 60 7106 â 5061 [ACK] 
Seq=2317 Ack=3057 Win=525568 Len=0
   27 9.226831508 52.114.76.76 â 196.216.192.19 TLSv1.2 3823 Certificate, 
Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted 
Handshake Message
   28 9.226854910 196.216.192.19 â 52.114.76.76 TCP 54 5061 â 7106 [ACK] 
Seq=3057 Ack=6086 Win=62080 Len=0
   29 9.228225293 196.216.192.19 â 52.114.76.76 TLSv1.2 2248 New Session 
Ticket, Change Cipher Spec, Encrypted Handshake Message
   30 9.421672079 52.114.76.76 â 196.216.192.19 TCP 60 7106 â 5061 [ACK] 
Seq=6086 Ack=5251 Win=525568 Len=0
   31 9.423493322 52.114.76.76 â 196.216.192.19 TLSv1.2