Skip to content

V7 (VSEVEN HOTELS) — IP Phone Fleet

Status: Phones live — 17 of ~18 GRP2602P registered and green; ext 05 is powered off at the hotel (see Known issue).

The hotel's Grandstream GRP2602P desk phones register directly to the cloud Asterisk over the WireGuard tunnel — independent of the UCM6301/BSNL inbound trunk work in V7 — Setup. This page covers the phone fleet: how it connects, the extension/IP map, how to reach phone web UIs, the provisioning model, and the ext 05 issue.

Architecture

GRP2602P phones (192.168.0.0/24)
        │  register: SIP 10.20.0.1:5080 (UDP)
        ▼
GWN7002 router  ──wg1 WireGuard──►  Cloud Asterisk (Mumbai PROD 147.93.168.216)
(holds the VPN)                     tunnel IP 10.20.0.1  ·  org_moijhj2l
  • The GWN7002 router holds the wg1 WireGuard tunnel to the cloud. The phones themselves have only the cloud SIP address configured (10.20.0.1:5080, UDP) — they reach it through the router's tunnel.
  • Cloud presents the tunnel as 10.20.0.1. After the France→Mumbai migration this is the Mumbai box 147.93.168.216 (see Prod India Migration).
  • Org: org_moijhj2l. Phone endpoints are named org_moijhj2l__<ext>.
  • Green/orange in the dashboard = PJSIP qualify (OPTIONS keep-alive) status Avail/Unavail.

Phone inventory (ext → IP)

GRP2602P desk phones. IPs are DHCP from the GWN7002 — they can change (see the ext 05 story below).

Ext IP Ext IP
01 .79 104 .65
02 .74 105 .66
03 .62 106 .67
04 .73 107 .68
05 (Housekeeping) .61 ⚠️ powered off at hotel 108 .69
07 .80 109 .70
09 .133 110 .71
101 .63 111 .72
102 .77 103 .64

Check live registration from the cloud:

ssh root@147.93.168.216 'asterisk -rx "pjsip show contacts" | grep moijhj2l'

Phone web login: admin / GDMS-provisioned password (NOT admin@12345 — see Provisioning).

WiFi APs & router (GDMS Networking)

Managed in gdms.cloud/gwn (GDMS Networking), separate from the phones. Do not try local logins on these — they're GDMS-paired and will lock out after 5 tries.

Name IP Model
Router .1 GWN7002
RECEPTION-LOBBY .81 GWN7660E
V7 FIRST FLOOR-1 .159 GWN7660E
V7 FIRST FLOOR-2 .96 GWN7660E
V7 FIRST FLOOR-3 .33 GWN7660E
RESTAURANT .157 GWN7660E
COFFE SHOP .203 GWN7660E

⚠️ .81 is the RECEPTION-LOBBY access point, not a phone — DHCP reassigns IPs, so always verify against the phone table above, not a remembered IP.

Reaching a phone's web UI from your Mac

The phones are on the hotel LAN behind the tunnel — not directly routable. To reach a phone's web UI by its real IP, route a browser through the cloud with a SOCKS proxy (a plain ssh -L port-forward fails because the phones redirect HTTP→their own LAN IP).

A helper script lives on the CSM Mac at ~/AstradialDevelopment/Clients/v7/v7-phone-access.sh:

cd ~/AstradialDevelopment/Clients/v7
./v7-phone-access.sh                 # open phone 05 (192.168.0.61) login
./v7-phone-access.sh 192.168.0.80    # any device by its real IP
./v7-phone-access.sh stop            # tear the proxy down when done

It opens ssh -D 1080 root@147.93.168.216 (SOCKS5 through Mumbai, which routes the V7 LAN over wg1) and launches a dedicated Chrome profile pointed at that proxy. The self-signed-cert warning is expected → Advanced → Proceed.

Provisioning model

Important for any phone fix: the phones are provisioned by GDMS UC (Grandstream's cloud Unified Communications), not by the Astradial platform.

  • The Astradial platform (userProvisioningService.js) writes only the server-side PJSIP account (endpoint/auth/aor in /etc/asterisk/pjsip_users.conf). It generates no phone device config — no .cfg, no MAC mapping, no admin password.
  • Asterisk's built-in phoneprov is the stock Polycom sample bound to 127.0.0.1 — unused.
  • The phones' SIP server, account enable, and web admin password all come from GDMS UC. That admin password is not stored on our servers and can't be recovered from the cloud box.
  • The current GDMS login is a Networking-only sub-account — it cannot see the UC module. Rebooting/fixing a phone from GDMS, or recovering the admin password, requires UC permission on the master Grandstream account.

Known issue: ext 05 not registering — RESOLVED (phone powered off)

Resolution: the hotel confirmed phone 05 (Housekeeping) is simply turned off. That explains every symptom below — no REGISTER, NOTIFY "ignored", silence on the wire. The server side (org_moijhj2l__05 endpoint/auth/aor) is correct and waiting; the phone will register as soon as it's powered on. No further debugging needed — if 05 is "down", first ask the hotel whether the phone is plugged in/powered.

Original investigation (kept for the diagnostic value):

  • Phone 05 moved to 192.168.0.61 (DHCP reassigned its old .81, which is now the RECEPTION-LOBBY AP) and stopped registering.
  • Server side correct and waiting: endpoint org_moijhj2l__05 (auth/aor/internal context) exists, Unavailable, 0 contacts. No auth failures in the logs — the phone was silent (because it was off).
  • A check-sync;reboot=true NOTIFY got no response — at the time read as "Grandstream NOTIFY-reboot disabled by default"; actually the phone was off. (The NOTIFY-disabled-by-default fact is still true of GRP phones generally.)
  • Lesson: "endpoint silent + no auth failures + NOTIFY unanswered" looks identical for a powered-off phone and a misprovisioned one — rule out power first before any SIP-level debugging.

Audio troubleshooting (no audio / silence / choppy)

V7 had a long no-audio incident. Two distinct causes, both worth knowing:

1. Opus↔G.711 transcode over a lossy leg → TOTAL SILENCE (not choppy)

V7 was on the lossy-link codec profile (opus,g722,ulaw,alaw). The phones (e.g. GRP2602P .133) actually negotiated ulaw (they list ulaw before opus in their SDP answer), while a softphone leg used Opus. So Asterisk transcoded Opus↔ulaw, and on a lossy leg that transcode produced dead silence — not graceful degradation. Diagnosis tool: pjsip show channelstats (shows per-leg codec + loss); tshark -r <pcap> -q -z rtp,streams shows the actual on-wire codec (don't trust the SDP — .133 showed g711U on the wire despite Opus in the offer).

Fix that restored audio: switch the org to the Standard (G.711) codec profile (editor → Settings → Voice Quality → Codec profile, then Deploy Config → Reload Asterisk). G.711 end-to-end has no transcode, so loss degrades gracefully (choppy, audible) instead of going silent. Mechanism: Organization.settings.sip.codec_profile, resolved by api/src/services/asterisk/codecProfiles.js (standard = ulaw,alaw,g722; lossy-link/low-bandwidth = Opus). For lossy links, prefer standard (G.711) unless the phones are provisioned Opus-first (then Opus FEC engages end-to-end and rides out loss — but that needs a GDMS phone codec-priority change, not just the server profile).

2. The Reception phone (.133, ext 09) has high, intermittent ISP packet loss

Measured 25–35% loss at 50pps (call rate) on the .133 leg, while a normal ping shows ~0% — the link only collapses under real call load. So:

  • Ping-based monitoring lies here. Always measure at call rate: ping -i 0.02 -c 250 192.168.0.133 (50pps), or read pjsip show channelstats during a live call. Show the ISP the call-rate loss.
  • This is the hotel's BSNL/ISP last-mile, not the cloud or the tunnel (the NUC wg0 leg measured 0% the same moment).
  • Wiring .133 (PoE Ethernet) instead of WiFi is the single biggest fix if it's wireless. A static IP does NOT help — it's packet loss, not IP churn. See the orange-status note above (same root cause).

Net: with G.711, V7 intercom + inbound-queue audio work; they stay choppy/intermittent until the Reception ISP link is fixed, then crisp.