Softphone summary:
Zoiper: works ok making and receiving calls.
GS Wave: makes calls, but doesn't receive them due to issues with registration
Linphone: makes calls, but doesn't receive them. In Android answers 400 Bad request, in Desktop crashes.

BR

And here is the complete log of the issue with the GS Wave softphone (@10.33.31.66 internal IP - but using NAT - 900890099@sip.xxx.com.br): - Registration - Call from 900890000 (in the VPN) to 900890099 (NATted) Please note: In Wireshark I see a sequence of 6 INVITE, going to the public IP but ...

Additional situation: Linphone, despite being recommended by Brekeke, is also not taking calls. It makes calls, but doesn´t receive them. In the desktop versions, the phones just crash. In the case of Android softphones, the Linphone softphone sends after the INVITE, back to BSS the message "400 Bad ...

The Outbound Proxy is BSS itself.

Still sending INVITEs to the private IP in the case of GS Wave...

Wireshark is being run at BSS machine.

After phone reboot Zoiper is still working without OB Proxy... The registration is now ok. This is crazy... I didn't touch with BSS or Zoiper, just turned OB Proxy off, but now the registration isn't offering the private IP! It recognizes as NAT but offers only the public IP address for ...

Yes, it is still sending the INVITE to 10.33.31.66. The devices behind 200.168.45.78 are now Zoiper using OB. We gave up on GS Wave there... It is the network 192.168.15.0 To continue the GS Wave tests I've deployed an Android with GS Wave and Zoiper at 10.33.31.66. But the public address is 179.55 ...

When I use the provider Sipgate in the same Android phone and same GS Wave, the softphone works without problems, making and receiving calls, without the Outbound Proxy set. The only difference I've seen in the softphone configuration is that it requires a fixed UDP port, in this case 5160. I've ...

Comparing the Zoiper and the GS Wave REGISTER attempts, I see the Contact field as having the private IP on the GS Wave and the public IP in the Zoiper.

I had to reinstall GS Wave. Here is the info from 'Registered Clients': sip:900890099@10.33.31.66:50702 (179.55.81.134:50702) Expires : 60 Priority : 1000 User Agent : Grandstream Wave 1.0.3.34 Transport : UDP Time Update : Fri May 08 19:14:01 BRT 2020 The REGISTER message under Dial Plan > History ...

Yes, as I've said before, Zoiper with Outbound Proxy works. GS Wave doesn't, in LAN or with Outbound Proxy (though it works with Sipgate ITSP) Here is the registration message: REGISTER sip:200.139.100.200;transport=TCP SIP/2.0 Via: SIP/2.0/TCP 192.168.15.78:60250;branch=z9hG4bK-524287-1 ...

Hello Niloc,

Now that we discarded GS Wave and with Zoiper we turned on Outbound Proxy, the internal IP addresses don't show up anymore.

sip:900890002@200.168.45.78:60263
(200.168.45.78:60263)

BR

Hello Niloc,

Both are empty.
I've handled VPNs in a different way, I'm using a very efficient SD-WAN solution...

BR

Udo

Hello Mohney, I'm not 100% sure that the software update broke it or if something just changed. As mentioned, I did a few actions. Also Windows was updated. What I've noticed after further testing: a) GS Wave has real problems. I can make calls to NATted Snom phones and to Zoiper android phones on ...

The Grandstream phones are GS Wave Android softphones. They can be on open internet or behind a WiFi router: in any case they can call the phones in the VPN, but the can't be called UNLESS they are in the same LAN, in which case 2 of them can talk to each other. So it seems to be an issue with Far ...

1. Brekeke Product Name and Version: Brekeke SIP Server, Version 3.9.5.8, Standard 2. Java version: Version 8 Update 161 3. OS type and the version: Win7 64 bits 4. UA (phone), gateway or other hardware/software involved: Snom phone connected thru VPN to BSS Grandstream phone behind NAT BSS has ...

I'm keeping it simple: when somebody needs CDRs I upload the BSS CDRs to the cdr2cloud service. From there I can even make invoices. Small system means less resources needed, so I think pooling and sharing aren't that useful... But monitoring is good! Where is the information regarding monitoring in ...

Hello James, Thanks for the prompt answer. As I use the system mostly as front end for another SIP system, to authenticate users and other proxies, and then generate the CDRs, most of the differences between Standard and Advanced edition aren't relevant for me. Basically, I have to register the ...

1. Brekeke Product Name and Version: BSS 3.8.5.2/493-3 Standard 2. Java version: 1.8.0_161 3. OS type and the version: Win7 Pro 64 bits 4. UA (phone), gateway or other hardware/software involved: 5. Your problem: I want to migrate BSS from Win7 to Windows Server 2008 R2, as I suspect that some stops ...

1. Brekeke Product Name and Version: 3.8.5.2/493-3 2. Java version: 3. OS type and the version: Win764 4. UA (phone), gateway or other hardware/software involved: 5. Your problem: I have a customer that can't control the number of channels that they are sending. I'm using route.underlimit to hold ...

I like your dial plan for registered user, will use it as well.
Thanks!

Sure! UA is well registered on BSS, and needs correct user/password for this purpose. Also, if this was to be the issue, the UA would have answered to the 407 with another INVITE, but with wrong user/password. This is not the case, it simply accepts the 407 and stays quiet instead of answering the ...

Ok, found it. I had BSS challenging the UA with a 407 when making calls between extensions. $auth=false solved the issue. I have UAs (of different brands) that for some reason stop the SIP communication when receiving a 407 Proxy authorization required. Other UAs answer the 407 with a new INVITE ...

Ok, makes sense.
And can I:
a) Put all gateways in one dial plan entry only?
b) Distribute calls in a round-robin way?

BR

Udo

Looking at the Wireshark traces I see that when the INVITE comes from the extension with problems, BSS effectively DOESN'T send the INVITE to the target IP phone. However, when the call happens the other way around, Wireshark shows the SIP packets flowing between both extensions without problems ...

I keep getting these 481 errors. Typically happens in calls between extensions in the VPN network, when the extension is outside of the LAN of BSS. But the VPNs are integrated into the network gateways and when the extensions get registered only their real IP shows up, not the VPN gateway's IP ...