GS Wave - Great APP


#1

App works great with few glitches and limited mobility

Deserve 3.5/5 stars

My experience so far using Samsung Note9,A530,J3,A70.
The good
App auto starts consistently as configured.
App is very responsive
Sound is clear and of good quality.
App auto switches in OK time when network changes(like roaming between WiFi and LTE/Data).

The Bad
Video calling doesn’t work much(maybe we need vp8/9 support linphone works flawlessly with this). Flipping video states during call doesnt work.
Using Android Work and Personal, if setup in work profile the app doesn’t save its configuration and need reconfiguring when reopened.
When connected through public networks the endpoint IP provided is mostly incorrect. Sometimes the endpoint IP is set to the local IP of the cellular data connection. This is normally a private ip and so result in the endpoint being unreachable.


#2

if it comes with local ip instead of public ip is a problem of settings, not of the app


#3

Actually on debug of the SIP Register packets it shows the app setting the Contact address and the Via address to that of the private IP. I think it just needs a few tweaking on the app during registration so that it detects if the server address is remote public and then set the Contact header accordingly.

I’ve tested this using LinPhone it works properly.

I’ve done each app running simultaneously one ext each.
If there’s a setting in GSwave that fixes this then I hope to find it.


#4

try publishing a screenshot of it


#5

Register From GSWAVE

69.158.246.37.57383 > server.mypbx.com.sip: [udp sum ok] SIP, length: 731
    REGISTER sip:server.mypbx.com SIP/2.0
    Via: SIP/2.0/UDP 10.19.195.44:57382;branch=z9hG4bK637077866;rport
    From: <sip:11102@server.mypbx.com>;tag=584739157
    To: <sip:11102@server.mypbx.com>
    Call-ID: 28322227-57382-1@BA.BJ.BJF.EE
    CSeq: 2004 REGISTER
    Contact: <sip:11102@10.19.195.44:57382>;expires=0
    Authorization: Digest username="11102", realm="asterisk", nonce="1578950154/c284b21365b199e4e24a2f7b64d4f840", uri="sip:server.mypbx.com", response="08999a1cbeb93856b2767d519f6cfd20", algorithm=md5, cnonce="13561714", opaque="1fb53ba6634873d8", qop=auth, nc=00000003
    Max-Forwards: 70
    User-Agent: Grandstream Wave 1.0.3.29
    Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
    Content-Length: 0

16:15:54.883910 IP (tos 0x60, ttl 64, id 21791, offset 0, flags [DF], proto UDP (17), length 394)
server.mypbx.com.sip > 69.158.246.37.57383: [bad udp cksum 0x5277 -> 0xd5d1!] SIP, length: 366
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.19.195.44:57382;rport=57383;received=69.158.246.37;branch=z9hG4bK637077866
Call-ID: 28322227-57382-1@BA.BJ.BJF.EE
From: sip:11102@server.mypbx.com;tag=584739157
To: sip:11102@server.mypbx.com;tag=z9hG4bK637077866
CSeq: 2004 REGISTER
Date: Mon, 13 Jan 2020 21:15:54 GMT
Server: FPBX-15.0.16.38(16.6.2)
Content-Length: 0

Register from Linphone

69.158.246.37.41143 > server.mypbx.com.sip: [udp sum ok] SIP, length: 889
    REGISTER sip:server.mypbx.com SIP/2.0
    Via: SIP/2.0/UDP 10.19.195.44:41142;branch=z9hG4bK.ySpDaI2WS;rport
    From: "Edward " <sip:11101@server.mypbx.com>;tag=1WWB9CqgK
    To: "Edward " <sip:11101@server.mypbx.com>
    CSeq: 25 REGISTER
    Call-ID: 3Ffo8S9int
    Max-Forwards: 70
    Supported: replaces, outbound, gruu
    Accept: application/sdp
    Accept: text/plain
    Accept: application/vnd.gsma.rcs-ft-http+xml
    Contact: "Edward " <sip:11101@69.158.246.37:41143;transport=udp>;+sip.instance="<urn:uuid:32ecfb80-a379-0041-864f-5ee541080f4b>"
    Expires: 3600
    User-Agent: LinphoneAndroid/4.2 (Galaxy A70) LinphoneSDK/4.3 (tags/4.3^0)
    Authorization:  Digest realm="asterisk", nonce="1578951903/82c8efa6fb118ca2e4dd602c0b48b951", algorithm=md5, opaque="32f87e7049f13ebb", username="11101",  uri="sip:server.mypbx.com", response="c5ac3d589e7773c84b3bef1ea4a1d10a", cnonce="~IZmdAyUQC3qBNjK", nc=00000001, qop=auth

16:45:03.117748 IP (tos 0x60, ttl 64, id 34695, offset 0, flags [DF], proto UDP (17), length 479)
server.mypbx.com.sip > 69.158.246.37.41143: [bad udp cksum 0x52cc -> 0x95f0!] SIP, length: 451
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.19.195.44:41142;rport=41143;received=69.158.246.37;branch=z9hG4bK.ySpDaI2WS
Call-ID: 3Ffo8S9int
From: "Edward " sip:11101@server.mypbx.com;tag=1WWB9CqgK
To: "Edward " sip:11101@server.mypbx.com;tag=z9hG4bK.ySpDaI2WS
CSeq: 25 REGISTER
Date: Mon, 13 Jan 2020 21:45:03 GMT
Contact: sip:11101@server.mypbx.com:41143;transport=udp;expires=3599
Expires: 3600
Server: FPBX-15.0.16.38(16.6.2)
Content-Length: 0


#6

I meant the GSWave screenshots not the one


#7

Just seeing this reply. Not quite sure what GSWave screenshot would be helpful here. Figure the registration packet above already provides the required data for catching the error.

I’ve looked through the app and haven’t seen any settings that can modify that aspect of how the registration is crafted to be sent.


#8

Set the GS WAVE to use STUN. Also, what mobile service are you using?

If you want this to work well, get into your DNS server and set a local FQDN (ucm.mycompany.com) that points to the private IP of the UCM. Then in your public A record create a new entry with the same FQDN that points to the public IP of the UCM.

In this manner you can insert the FQDN into the sip server field and when the phone resolves the IP it will use an external service from the cellular carrier which will resolve to the public IP and when local and using WI-FI it will resolve to the private IP. Just makes it easier if you have the resources to do.

STUN is used to help the device determine what its public IP is and it will alter the connect and connection header to reflect this instead of the private. Otherwise, the app has no way to know what the public is.


#9

This is actually how it is configured from dns pov. the GSWave app always get registered.
Its just that it doesn’t always put the correct IP in the contact header

it does this
Contact: <sip:11102@10.19.195.44:57382>;expires=0

instead of this
Contact: "Edward " <sip:11101@69.158.246.37:41143;

I’ve used both the default gswave stun server stun.ipvideotalk.com and googles stun server stun1.l.google.com:19302

In both cases the result remain the same.


#10

instead of putting STUNn on NAT Traversal test with “keep-alive”.
test


#11

Keep-alive will do nothing relative to changing the SIP header to reflect the correct connect IP as it can’t determine the IP. I do not have the issue and am using T-mobile, but they threw me a curve as the APN they now use is using IPV6 as the default. Had to modify my firewall rules. I am using the ipvideotalk server.

The standard STUN port is 3478.
I suppose you could use a VPN, but suggest you submit a ticket.


#12

That’s correct keepalive wont fix anything.

even stun really shouldn’t matter as its mostly used when deciding for audio.

I’m using BELL and do get ipv6 occasionally.

There is an option in the server to rewrite contact. This is the workaround. It will rewrite the IP for the contact.


#13

I did not write that keep alive will solve the problem, nor that keep alive determines ip to use, it was just to do a test. It certainly doesn’t make it any worse.
To me a couple of times inserting the keep alive has solved the problem, and when a certain solution solves the problem I never ask “why”.
At the end of the day after 36 hours and 12 comments nobody has found the “sure” solution so even a “wrong” solution could be the correct one, never underestimate the problems, even if apparently easy to solve.


#14

Actually STUN does indeed matter. It is the method by which the client side can determine its public IP, NAT type and report same along with a local port to the server side. Without it, there is no way for the contact or connect header to be populated with the correct IP. I suppose ICE/TURN might help, but these are not options unless the SIP Server can support.

What is the Linphone using for detection?


#15

Not hitting at your suggestion at all. Sorry if you got that impression.
Actually I’d say longer than 36 hours, had there not being a workaround it would be weeks at least.


#16

I don’t know what you mean, I gave you the test suggestion, you’re free to do it or not.
Good job.


#17

AFAIK the linphone isn’t configured with any stun servers, not by default neither did I set any. but there are ways of detecting the public ip.
I guess it starts at detecting the IP being used to access the VoIP server(direct or via dns) then if public then detect your public IP. This can be done without stun.
dig +short myip.opendns.com @resolver1.opendns.com
dig TXT +short o-o.myaddr.l.google.com @ns1.google.com


#18

Yes, there are other ways, but I am not aware of any other methods in the GS Wave.

I suppose it may be possible to set the SIP server to use the IP seen at registration, rather than the contact.