Asterisk vmware esxi deployment RTP problems with one-way audio

Hello everyone.

This is my first post in communitiy since I’m using Asterisk. There was no need for me to ask anything because I found it in community. I’ve been working with Asterisk for 10 years now and have been deploying numerous system for business and also for branch I’m working in and that is telecommunications.

So lets go to my problems.

Few weeks ago I’ve deployed central Asterisk system which connects different Telecom providers for big Call Center so my Asterisk acts like gateway. There is no local extension. I have connected 3 GSM Gateways on same local subnet, telecom providers (on dedicated link and over the Internet) and cloud call center provider over the Internet.

This call center has in peak 80 concurent calls for now and will grow. What is started to happen is that on some calls there is no RTP i one direction. Mostly there are outbound calls from cloud call center over my Asterisk to telecom providers. My client (call center) reported that out of 260 calls that they made 230 were bad where B side (called customer) was unable to hear A side (agent that called them).

I’ve been researching for weeks now and I can’t figure this out. When I had problems with audio or no audio or no audio in one direction that was affecting ALL calls and not some.

Asterisk 16.6.0 is installed on Debian 10, has 16 CPU, 12GB of RAM and 500GB disk space on fast Netapp storage and esxi, where Asterisk VM is located, are connected over 4 10Gbps iface fiber optics.

When in peak of calls (70-80 simultanious) there is only 1GB of RAM used, and 1 CPU in total.

I’ve tried playing with directmedia, canreinvite and directrtpsetup and nothing worked.
Some provider do not support directmedia so I had to turn it down.

Here is my sip.conf:

[general]
context=public                 
allowoverlap=no                
udpbindaddr=0.0.0.0             
tcpenable=no                    
tcpbindaddr=0.0.0.0            
transport=udp                  

srvlookup=yes
jbenable=no


[mypbx]
usrname=user
secret=secret
host=10.xx.xx.xx
qualify=yes
type=friend
port=5060
nat=never
dtmfmode=inband
insecure=invite,port
canreinvite=no

[sipprovider]
disallow=all
allow=alaw:20
host=176.xx.xx.xx
nat=never
type=peer
dtmfmode=inband
qualify=yes
insecure=invite,port
canreinvite=yes
directmedia=yes

[cc1]
host=10.xx.xx.xx
qualify=yes
type=friend
port=5060
nat=no
dtmfmode=rfc2833
insecure=invite,port
canreinvite=no

[cc2]
host=10.xx.xx.xx
qualify=yes
type=friend
port=5060
nat=no
dtmfmode=rfc2833
insecure=invite,port
canreinvite=no

[cc3]
host=10.xx.xx.xx
qualify=yes
type=friend
port=5060
nat=no
dtmfmode=rfc2833
insecure=invite,port
canreinvite=no

[cc4]
host=10.xx.xx.xx
qualify=yes
type=friend
port=5060
nat=no
dtmfmode=rfc2833
insecure=invite,port
canreinvite=no

[cloudcc]
disallow=all
allow=alaw:20
allow=ulaw:20
allow=gsm
nat=no
host=194.xx.xx.xx
username=user
secret=secret
qualify=yes
type=peer
port=5186
dtmfmode=rfc2833
insecure=invite,port
canreinvite=yes
directmedia=yes
limit=20000

[cloudcc2]
disallow=all
allow=alaw:20
allow=ulaw:20
allow=gsm
nat=no
host=194.xx.xx.xx
username=user
secret=secret
qualify=yes
type=peer
port=5187
dtmfmode=rfc2833
insecure=invite,port
canreinvite=yes
directmedia=yes
limit=20000

[gsmAgw]
secret=secret
dtmfmode=rfc2833
canreinvite=no
host=dynamic
type=friend
port=5060
nat=no
qualify=yes

[gsmgw]
secret=secret
dtmfmode=rfc2833
canreinvite=no
host=dynamic
type=friend
nat=no
port=5060
qualify=yes

[gsmgw2]
secret=secret
dtmfmode=rfc2833
canreinvite=no
host=dynamic
type=friend
nat=no
port=5060
qualify=yes

[a1-sip1]
disallow=all
allow=alaw
remotesecret=secret
username=user
dtmfmode=inband
host=10.xx.xx.xx
type=peer
qualify=yes
canreinvite=no

[a1-sip2]
disallow=all
allow=alaw
remotesecret=secret
username=user
dtmfmode=inband
host=10.xx.xx.xx
type=peer
qualify=yes
canreinvite=no

[iptel]
secret=secret
fromuser=user
username=user
dtmfmode=rfc2833
host=public.ip
type=friend
port=5060
qualify=yes
canreinvite=no
fromdomain=some.domain
insecure=invite

[local-pbx-helper]
host=10.xx.xx.xx
qualify=yes
type=friend
port=5060
nat=no
dtmfmode=inband
insecure=invite,port
canreinvite=no

[ht]
disallow=all
allow=alaw:20
port=5060
insecure=invite,port
dtmfmode=rfc2833
qualify=yes
type=friend
host=192.xx.xx.xx
canreinvite=no

[nth]
type=friend
username=user
secret=secret
host=62.xx.xx.xx
port=5068
nat=no
insecure=port,invite
dtmfmode=rfc2833
canreinvite=no
qualify=yes
disallow=all
allow=alaw

[uni]
type=peer
disallow=all
allow=alaw
host=10.xx.xx.xx
insecure=invite,port
port=5060
dtmfmode=rfc2833
qualify=yes
canreinvite=no

There is no problems with GSM at all.

Here is rtp.conf:

;
; RTP Configuration
;
[general]
;
; RTP start and RTP end configure start and end addresses
;
; Defaults are rtpstart=5000 and rtpend=31000
;
rtpstart=10000
rtpend=31000
;
; Whether to enable or disable UDP checksums on RTP traffic
;
;rtpchecksums=no
;
; The amount of time a DTMF digit with no 'end' marker should be
; allowed to continue (in 'samples', 1/8000 of a second)
;
;dtmftimeout=3000
; rtcpinterval = 5000 	; Milliseconds between rtcp reports
			;(min 500, max 60000, default 5000)
;
; Enable strict RTP protection. This will drop RTP packets that
; do not come from the source of the RTP stream. This option is
; enabled by default.
strictrtp=no
;
; Number of packets containing consecutive sequence values needed
; to change the RTP source socket address. This option only comes
; into play while using strictrtp=yes. Consider changing this value
; if rtp packets are dropped from one or both ends after a call is
; connected. This option is set to 4 by default.
; probation=8
;
; Whether to enable or disable ICE support. This option is disabled by default.
; icesupport=true
;
; Hostname or address for the STUN server used when determining the external
; IP address and port an RTP session can be reached at. The port number is
; optional. If omitted the default value of 3478 will be used. This option is
; disabled by default.
;
; e.g. stundaddr=mystun.server.com:3478
;
; stunaddr=
;
; Hostname or address for the TURN server to be used as a relay. The port
; number is optional. If omitted the default value of 3478 will be used.
; This option is disabled by default.
;
; e.g. turnaddr=myturn.server.com:34780
;
; turnaddr=
;
; Username used to authenticate with TURN relay server.
; turnusername=
;
; Password used to authenticate with TURN relay server.
; turnpassword=

When I was testing this setup I had no problems with audio at all but that was max of 5 calls over each trunk.

Can Asterisk handle such traffic? Am I missing something?
Every help is much appreciated.

I think the question is not whether Asterisk can handle the calls, but your system.

If it is a hardware issue, then you should observe no problems with a few calls, distorted audio with more calls, and loss of audio when it gets messy.

The hardware seems to be adequate, but what about the internet connectivity? Since Asterisk is a B2BUA that typically stays in all paths, there could be a problem. A first hint would be to check what “sip show channelstats” says.

That said, Asterisk may not be the best solution in your case. Not because Asterisk is bad, but SIP servers like Kamailio seem to be more appropriate to me.

Hello.

Thank you for reply.

There are few calls now:

Peer             Call ID      Duration Recv: Pack  Lost       (     %) Jitter Send: Pack  Lost       (     %) Jitter
10.xx.xx.xx      41ac862d08d  00:02:30 0000003286  0000000000 ( 0.00%) 0.0000 0000007530  0000000000 ( 0.00%) 0.0024
194.xx.xx.xx    98545af4-78  00:00:25 0000000936  0000000000 ( 0.00%) 0.0000 0000001148  0000000000 ( 0.00%) 0.0011
192.xx.xx.xx   37929f226f6  00:00:25 0000001148  0000000000 ( 0.00%) 0.0000 0000000936  0000000000 ( 0.00%) 0.0002
176.xx.xx.xx     4dc8201f-78  00:02:30 0000007530  0000000000 ( 0.00%) 0.0000 0000007243  0000000000 ( 0.00%) 0.0015

I’m not sure what you mean by internet connectivity. This Asterisk is deployed in core of ISP network where I work. It has several interfaces. Interface with Public IP is directly connected (via VLAN) to core router that holds BGP to my uplink provider and doesn’t have any QoS or restrictions. Public IP is used to connect other voice providers over the internet that I couldn’t connect P2P. Second interface is in local network and its gateway is on Mikrotik CHR and this holds GSM Gateways trunks on same subnet. Other interfaces are P2P via VLAN and are directly connected with fiber optics. Only restriction is transreceivers on both sides and that is 1,25Gbps. All other interfaces are 10GE except uplink to provider which is 2x 1GE in LACP.

I basically meant bandwidth problems, 1.25 Gbps is a lot and that should not be a problem. The question is whether you identify a specific bottleneck when the traffic increases.

canreinvite option is deprecated and it is replaced by directmedia option, also directsetup option never worked, NAT settings need to be adequated based to the network enviroment, have you try using nat=force_rport,comedia and also adding localnet option

Hello. Thanks for reply.

Funny thing about canreinvite and directmedia. When I setup directmedia=yes on peer there was no audio at all until I setup canreinvite=yes also. So I realy don’t know what is depricated here. Directrtpsetup option was “just to try everything” but I did know that would not work.

I don’t see how NAT will help because my setup is not behind NAT, but for sake of test I did that and it didn’t make any difference. I did not use localnet and externaddr because those options are for NAT.

@EkFudrek I must gather and analyze data to see if there is some kind of bottleneck. Maybe vswitch is messing with my setup.

Your list of addresses indicates you must be operating in either a NAT environment or a broken multi-homing one (multi homing without border gateway protocol and autonomous system numbers).

If it still recognizes canreinvite at all, chan_sip treats it as an alias of directmedia, and uses the same code to handle the parameters, so it shouldn’t be possible for one to work but not the other unless canreinvite has been removed completely.

The nat= parameter is confusing, because it isn’t actually intended for inside NAT cases; it is intended for where Asterisk is on a public address and the peer is inside NAT, but not fully NAT aware.

If it’s not behind NAT why do you have NAT addresses connecting to you? How are they routing to you and visible in your peers?

The server might have a static IP, but there is a NAT issue at play here.

Are you maybe using 1to1 static NAT? That is after all a form of NAT and would drastically change your config.

Hello.

Thank you for reply.

It is not NAT. NAT is Network Address Translation and I do not use that local subnet to go out with public IP. It is just local network without NAT. So we can 100% say that is not NAT problem.

But I have some new information:

Problem is narrowed down to few peers:
Calls are originated from:
[cloudcc]
disallow=all
allow=alaw:20
allow=ulaw:20
allow=gsm
nat=no
host=194.xx.xx.xx
username=user
secret=secret
qualify=yes
type=peer
port=5186
dtmfmode=rfc2833
insecure=invite,port
canreinvite=yes
directmedia=yes
limit=20000

And go out over this:
[sipprovider]
disallow=all
allow=alaw:20
host=176.xx.xx.xx
nat=never
type=peer
dtmfmode=inband
qualify=yes
insecure=invite,port
canreinvite=yes
directmedia=yes

Or this four:
[gsmgw]
secret=secret
dtmfmode=rfc2833
canreinvite=no
host=dynamic
type=friend
nat=no
port=5060
qualify=yes

[gsmgw2]
secret=secret
dtmfmode=rfc2833
canreinvite=no
host=dynamic
type=friend
nat=no
port=5060
qualify=yes

[a1-sip1]
disallow=all
allow=alaw
remotesecret=secret
username=user
dtmfmode=inband
host=10.xx.xx.xx
type=peer
qualify=yes
canreinvite=no

[a1-sip2]
disallow=all
allow=alaw
remotesecret=secret
username=user
dtmfmode=inband
host=10.xx.xx.xx
type=peer
qualify=yes
canreinvite=no

Everything else seams to be fine as client confirmed that.

So every bad call is originated from cloudcc and goes through one of 5 mentiond peers which depends what number is called.

@EkFudrek I’ve checked everything and there is no bottleneck. I have 500/500Mbps throughtput and most of the time traffic is not greater than 50Mbps.

P.S. - there is no directimedia=yes options anymore since that did not fix the problem.

You will need to provide the actual SDP exchanges from the SIP prootocol logging, to see what addresses and ports are acutally being used.

You can either eliminate more, or you have something else to fix, though this might not have anything to do with the problem. You are using different DTMF modes.

Hello.

After analizing houndreds of calls with Wireshark i got to conclusion.
All “bad” calls without audio in one way were using RTP port higher that 20000.

My port range in rtp.conf is from 10000-20000 and there is no firewall rule for that ports. I mean, I do not block anything.

Why am I receiving RTP from SIP provider on ports higher than in my range? Should I open more ports? OR is there something else to do?

You could try it and check whether it helps…

On the other hand, initially you wrote that the rtp ports are between 10000 and 31000.

I’m sorry. Yes from 10000-31000 but i receive rtp higher than that. On some calls higher than 40000.

Are you talking about the remote source port, which can be up to 65535, or the local destination port, which should be what is offered by Asterisk in the SDP, and in your configured range?

I’m talking about remote src port. Calls received on rtp port higher than 31000 I have no audio. When in my rtp range, call is fine. My asterisk always offer port from range in rtp.conf Maybe cloud provider where calls end and from where calls originate blocks higher ports. It is on me to find that information.

Hello.

I’m sorry for not updating this thread. I’m still working on this problem and I loosing battle with this.

After analyzing hundreds of calls and changing everything I could think of, I have finaly figured out what is is cousing my problems but not where.

Jitter. This nice little word with so bad impact on performance.

Here is what I’ve got capturing with tshark for 15-20 seconds per address:

------------------------------------------------------------------------------------------------------------------------------------------------------Local network 
   SSRC          Payload  Pkts         Lost   Max Delta(ms)  Max Jitter(ms) Mean Jitter(ms) Problems?
0x651278E1 ITU-T G.711 PCMA    24     0 (0.0%)           20.76            0.35            0.41
0x2998DD99 ITU-T G.711 PCMA    91     0 (0.0%)           23.78            0.85            0.42
0x0F42045E ITU-T G.711 PCMA     1     0 (0.0%)            0.00            0.00            0.00
0x3BA867F7 ITU-T G.711 PCMA   208     0 (0.0%)           23.49      6489151.93       501766.92 X
0x47C4A155 ITU-T G.711 PCMA   269     0 (0.0%)           33.64            2.18            0.68
0x1D85C5CB ITU-T G.711 PCMA   337     0 (0.0%)           28.97            7.53            5.78
0x7EF487FA ITU-T G.711 PCMA   344     0 (0.0%)           32.23            1.59            0.54
------------------------------------------------------------------------------------------------------------------------------------------------------Local network 

------------------------------------------------------------------------------------------------------------------------------------------------------Public network
    SSRC          Payload  Pkts         Lost   Max Delta(ms)  Max Jitter(ms) Mean Jitter(ms) Problems?
0xCA3320CE ITU-T G.711 PCMA    97     0 (0.0%)           26.35            1.33            0.59
0x12A0A35A ITU-T G.711 PCMA   127     0 (0.0%)           20.07            0.02            0.01
0xCA2A7382 ITU-T G.711 PCMA   129     0 (0.0%)          116.27            9.13            3.16
0x4B1AE43F ITU-T G.711 PCMA   171     0 (0.0%)           21.24            0.52            0.40
0x33C735E3 ITU-T G.711 PCMA   166     0 (0.0%)          540.06            0.04            0.02
0xA5FF32AC ITU-T G.711 PCMA   185     0 (0.0%)           70.75           24.78            1.88
0x73EA68ED ITU-T G.711 PCMA   289     4 (1.4%)          100.00      4127203.74       228497.89 X
0x82478CC9 ITU-T G.711 PCMA   300     0 (0.0%)          105.35           10.41            2.83
0x72037BFB ITU-T G.711 PCMA   393     0 (0.0%)           20.22            0.04            0.02
0x1ADBE760 ITU-T G.711 PCMA   400     0 (0.0%)           23.95     24582251.54            0.61 X
0x07A11479 ITU-T G.711 PCMA   402     0 (0.0%)           22.12            0.52            0.38
0x225D1907 ITU-T G.711 PCMA   398     0 (0.0%)          119.62           11.69            3.22
0x5A5C2C98 ITU-T G.711 PCMA   409     0 (0.0%)           58.77            4.35            1.03
0xAE243DD0 ITU-T G.711 PCMA   407     0 (0.0%)          160.01            8.38            2.40
0x368B6D4A ITU-T G.711 PCMA   450     0 (0.0%)           24.30            0.82            0.41
0x0280B9C8 ITU-T G.711 PCMA   454     0 (0.0%)           23.84            0.99            0.49
0x021874B3 ITU-T G.711 PCMA   551     0 (0.0%)           63.58            5.50            1.10
0x5EB98DE6 ITU-T G.711 PCMA   556     0 (0.0%)           20.49            0.25            0.11
0x3BB098AC ITU-T G.711 PCMA     1     0 (0.0%)            0.00            0.00            0.00
0x022BF0E3 ITU-T G.711 PCMA   534     0 (0.0%)          182.10          117.31            0.48
0xBE120C93 ITU-T G.711 PCMA   648     0 (0.0%)           66.75            5.48            1.07
0x91EDC9B2 ITU-T G.711 PCMA   696     0 (0.0%)           56.43            4.23            0.58
0xCA6ACC32 ITU-T G.711 PCMA   736     0 (0.0%)           58.16            4.31            0.63
0x6FBB566A ITU-T G.711 PCMA   738     0 (0.0%)           20.10            0.03            0.02
0x133A13A7 ITU-T G.711 PCMA   752     0 (0.0%)           20.27            0.06            0.03
0x1A248C06 ITU-T G.711 PCMA   755     0 (0.0%)           67.37            9.65            2.88
------------------------------------------------------------------------------------------------------------------------------------------------------Public network 

------------------------------------------------------------------------------------------------------------------------------------------------------Dedicated SIP trunk1
      SSRC          Payload  Pkts         Lost   Max Delta(ms)  Max Jitter(ms) Mean Jitter(ms) Problems?
0x4417D259 ITU-T G.711 PCMA   219     0 (0.0%)           28.36            1.59            0.30
0x5A0007A5 ITU-T G.711 PCMA   225     0 (0.0%)           20.08            0.04            0.03
0x209C3D1A ITU-T G.711 PCMA   410     0 (0.0%)           20.05            0.01            0.01
0x44FA7688 ITU-T G.711 PCMA   412     0 (0.0%)           28.24            1.57            0.65
0x7BB9E7F8 ITU-T G.711 PCMA   304     0 (0.0%)           40.00            0.59            0.07
0x52205B80 ITU-T G.711 PCMA   550     0 (0.0%)           23.36            0.43            0.08
0xE0DB7750 ITU-T G.711 PCMA   571     0 (0.0%)           21.25            0.50            0.35
0x7028919E ITU-T G.711 PCMA   691     0 (0.0%)           31.50            2.00            0.57
0xC068C91E ITU-T G.711 PCMA   695     0 (0.0%)           20.16            0.03            0.02
0x1355F5CC ITU-T G.711 PCMA   881     0 (0.0%)           20.44            0.10            0.04
0x1E5CFC97 ITU-T G.711 PCMA   960     0 (0.0%)           31.20            1.83            0.59
0x392091A4 ITU-T G.711 PCMA   961     0 (0.0%)           20.55            0.08            0.02
0x452F0463 ITU-T G.711 PCMA  1051     0 (0.0%)           20.44            0.27            0.06
0x22C28820 ITU-T G.711 PCMA  1078     0 (0.0%)           50.66            3.64            0.57
0x50B2B040 ITU-T G.711 PCMA  1150     0 (0.0%)           64.50            5.33            0.84
0xE5E65883 ITU-T G.711 PCMA  1152     0 (0.0%)           20.11            0.04            0.02
0x41BE4850 ITU-T G.711 PCMA   618     0 (0.0%)           59.98            4.92            0.90
0x45240A8C ITU-T G.711 PCMA   940     0 (0.0%)           20.43            0.20            0.05
0x69A44905 ITU-T G.711 PCMA  1175     0 (0.0%)           45.73            3.42            0.79
0x2B9A8CAD ITU-T G.711 PCMA  1178     0 (0.0%)           40.22            3.13            0.80
0x58B86D02 ITU-T G.711 PCMA  1178     0 (0.0%)           20.29            0.06            0.03
0x1FCFF8F3 ITU-T G.711 PCMA  1179     0 (0.0%)           45.60            3.27            0.90
0x00D3FC66 ITU-T G.711 PCMA  1180     0 (0.0%)           21.50            0.20            0.02
0x45302962 ITU-T G.711 PCMA  1181     0 (0.0%)           21.45            0.21            0.05
0x4ED3351F ITU-T G.711 PCMA   475     0 (0.0%)           64.79            5.06            0.99
0x32B391EB ITU-T G.711 PCMA   941     0 (0.0%)           44.73            3.24            0.89
0x1D472A9B ITU-T G.711 PCMA  1184     0 (0.0%)           47.66            3.37            0.68
0x4C9C4682 ITU-T G.711 PCMA   940     0 (0.0%)           62.09            4.90            0.85
0xF025EEE0 ITU-T G.711 PCMA  1186     0 (0.0%)           21.81            0.24            0.02
0x44112B73 ITU-T G.711 PCMA  1187     0 (0.0%)           65.77            5.16            0.72
0x4528BAA2 ITU-T G.711 PCMA   478     0 (0.0%)           20.40            0.24            0.10
0x45355EC5 ITU-T G.711 PCMA   940     0 (0.0%)           52.39            0.60            0.06
0x4529DDB4 ITU-T G.711 PCMA   941     0 (0.0%)           65.30            0.24            0.06
0x2D15756D ITU-T G.711 PCMA  1192     0 (0.0%)           20.18            0.03            0.02
0x01DDFB75 ITU-T G.711 PCMA  1193     0 (0.0%)           59.18            4.88            0.73
0x56BD6FD5 ITU-T G.711 PCMA  1198     0 (0.0%)           20.30            0.06            0.03
0x7870C5A3 ITU-T G.711 PCMA   906     0 (0.0%)           20.43            0.28            0.07
0x2CD58107 ITU-T G.711 PCMA   906     0 (0.0%)           40.01            0.10            0.02
------------------------------------------------------------------------------------------------------------------------------------------------------Dedicated SIP trunk1

------------------------------------------------------------------------------------------------------------------------------------------------------Dedicated SIP trunk2
SSRC          Payload         Pkts      Lost        Max Delta(ms)    Max Jitter(ms) Mean Jitter(ms) Problems?
0x251590CF ITU-T G.711 PCMA   639     0 (0.0%)           69.82            5.91            1.40
0x136F9200 ITU-T G.711 PCMA   643     0 (0.0%)           27.08            1.19            0.05
0x2A125CF6 ITU-T G.711 PCMA  1757     1 (0.1%)           60.14            6.56            1.79 X
0x134842F4 ITU-T G.711 PCMA  2310     0 (0.0%)          245.26            0.26            0.02
0x39499617 ITU-T G.711 PCMA   582     0 (0.0%)           46.48            5.46            1.34
------------------------------------------------------------------------------------------------------------------------------------------------------ADedicated SIP trunk2

So, jitter is my problem but I don’t know where and why I have one. There is no bottleneck, I have enough bandwidth… Funny thing is that there is jitter in Local network also. Between two VM hosts (my asterisk and another SIP server) inside sam virtualization infrastructure?!

Since I don’t have anything else to do about Asterisk itself I’ve started fine tunning vmware esxi hosts and vSphere. I’ve setted up Latency Sensitive option tu High for Asterisk and turned off Power Management both in BIOS and vSphere for both HP ProLiant hosts.

And today client report that there is no change at all. I’m left with 3 more possible fixes if virtualization is making problems. And that is: 1) Reduce CPU’s from 16 to 14 because host hase 14 physical CPU’s and give 100% reservation to Asterisk host. 2) Move from SATA disk to SAS and last third option is to give this host dedicated vSwitch. And that is it. After that there is no more options to make. Except put my router (Mtik CHR) and Asterisk on hardware outside of virtualization.

Can someone explain me how is this Jitter possible? I can understand that there can be high Jitter when connected over Public Internet but inside of LAN?!

Do someone have some kind of idea what else I can do?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.