Grandstream Video Preview (SIP 183)

Hello all,
I am currently trying to get video preview working on two Grandstream GXV3370 phones.
The plan is to use this feature with a Grandstream video intercom at a later point (setting up due to current Covid situation in our area). I’ve been advised that the video preview feature will work exactly the same between two GXV3370 which is why we are using that for testing prior to bringing in the intercom.

Running FreePBX 15 on a cloud server with a public IP (no NAT), using the freepbx firewall. The two GXV3370 are behind the same NAT at this time while testing but once deployed they will be in separate locations both remote to FreePBX. Both extensions are using PJSIP

Currently when either extension calls the other, a black box that says “video preview” appears but video never comes through. As soon as the call is answered, both audio and video work perfectly.

I have contacted Grandstream and they have advised that I needed to turn on STUN for both endpoints. Doing so still allows two when audio when calls are answered, but video only works one way with STUN turned on. No change on preview (does not work).

Grandstream has advised the following based on a packet capture:

“the phones when they do Auto Preview; they send a 183 SIP message requiring media from the other endpoint in order to show the Preview. However, the phone sends that message and the FreePBX removes it from the process. The other end doesn’t the other phone is requiring Preview as the messages isn’t received. Is there any setting you could adjust to allow Direct Media between extensions under the FreePBX?”

In FreePBX I have Direct Media turned on for both extensions already.

In researching, SIP 183 appears related to progressinband but I cannot find any setting in FreePBX related to that within SIP or chan_pjsip settings. I found one other post in the forums trying to do this exact thing, but the topic was closed without a posted outcome 2 years ago. I’m pretty much at a loss, Grandstream says they have it working in lab (likely on UCM) but a UCM is not going to work for me due to requiring the PBX hosted off site. Hoping someone has some insight on a piece of this that I am missing

1 Like

Interesting problem. I know nothing about these phones but would like to see what is going wrong.

Please post a log of a failing call including SIP trace:
At the Asterisk command prompt, type
pjsip set logger on
make the failing call (you can hang up the calling phone a few seconds after its video fails to appear on the called phone), paste the Asterisk log for the call (which will include the SIP trace) at pastebin.freepbx.org and post the link here.

In addition to the measures you have already taken, I believe that you want to remove the ‘r’ option from Asterisk Dial Options for the extensions (check the Override box and leave the field blank). Also, set the phones to use different RTP port ranges (to avoid the complexity of source port rewriting by the local router).

Hi @Stewart1, thanks for taking time to look at this.

Here is log while placing a call: https://pastebin.freepbx.org/view/4cb9f1ab

This is still with STUN enabled on both phones. Video Preview does not work, and only one way video works when the call is answered (the callee receives video when answered, but the caller does not get video returned). Audio works in both directions. Before turning STUN on per Grandstreams request, video worked in both directions once the call was answered but no video preview.

The default Asterisk Dial Options is currently set to ‘HhTtr’. Should it just be ‘HhTt’? Or do I override to blank?

I did some testing by setting up a Custom extension that actually dials a trunk (I don’t have any phones that generate 183).

I discovered an apparent bug where setting Asterisk Dial Options blank results in it using the default, so set it to something innocuous such as ‘H’ (you won’t actually be using the DTMF-based commands).

You probably want STUN disabled and let Asterisk handle the NAT.

Retest and if no luck post another log.

@Stewart1 thanks again for your help on this.

Slight change. I decided to just bring in the intercom unit (GDS3710) to test with rather than trying a roundabout way with 2 video phones. Slight variation in the issue though.

STUN is disabled on all devices, RTP ports are set on all devices to randomized since the PBX is off site and multiple devices exist behind the same NAT (in this case, the GXV phone and the GDS doorbell). Dial Options overridden and set to ‘H’.

Doorbell is ext 220, and its set to ring ext 201 (GXV3370). Pressing the “call” button on the doorbell rings the phone immediately, and it can be answered. Two way audio works completely fine. But no video feed at all, and no video preview prior to the call being answered.

Here is a new pastebin of the Doorbell calling the GXV3370. No video preview, and no video when the call is answered: https://pastebin.freepbx.org/view/5ac54352

I’m very puzzled. Line 274 (part of the 183 response from the GXV) shows
a=sendonly
At face value, this makes no sense – it obviously wants to receive video (to show the preview) and won’t be sending any. However, it may send a few frames of dummy content so the server can see the NAT port mapping and return video to the right address and port. Then, the GXV might send another 183. But with sendonly, the GXV doesn’t get any video packets and wouldn’t know to do that.

Unless I’m missing something, this is a bug in the GXV and it couldn’t be expected to work. But, it does work with Grandstream’s own UCM PBX appliances, and those are also based on Asterisk, so WTF? Conceivably, they’re using chan_sip which is handling the RTP differently.

Can you configure the GDS and a GXV to communicate directly (no PBX)? If that works properly (including preview), take a packet capture (including RTP), which we can then compare with a similar capture on FreePBX. Possibly, this will show a trick to get it working.

I configured the devices to communicate via direct IP, everything works from preview to in call video and audio.

Here is the capture filtered to SIP and RTP data: https://pastebin.freepbx.org/view/b369db16
I don’t know if this is going to give you what you want fingers crossed!

IP 60.205 is the GXV, 60.201 is the Doorbell (GDS)

Again, super grateful for the help @Stewart1

The new capture is strange. Frame 105 shows the call being answered, ~3.5 seconds after it was initiated. Was there preview during this time (somehow without any 183 or RTP being shown)? Or, is there something wrong with the capture itself or the way Wireshark parsed it?

Please rename the .pcap file to a .tgz and the forum should allow you to upload it as an attachment. Or, put it on Dropbox / Google Drive / whatever and post the link. If the file is too big or contains data you don’t want to publicly post, in Wireshark select File -> Export Specified Packets and (with default settings) save a new .pcap consisting of only the packets that passed your display filter.

1 Like

directip.tgz (434 KB)

Here is the full pcap (likely the previous was from me filtering to sip/rtp only)

AFAICT, this call was answered normally (with GDS->GXV video and two-way audio) about 3.5 seconds after it started ringing, possibly an auto-answer. Five seconds after that, it was hung up from the GXV end. There was definitely no ‘preview’ video – the first 3.5 seconds had no RTP at all (or any way for the GDS to know where to send it) and the last 5 seconds was a fully answered call.

I have no idea why this is different from what happened through the PBX.

Hello @badams,

The GDS3710 sends a Call-Info header with the ip address of itself to the GDS3370.
For example, this is the Call-Info header from your sip trace:

Call-Info: <http://192.168.60.201:80/capture/8001> ;purpose=GDS-view

Then, in the GDS3370, you need to enable value added services to open the door after the video preview.
Here is a manual how to do it with a direct ip call, or through a sip proxy:

You need to verify that you allow early media in the sip settings of the extensions (100rel, 183 progress), Otherwise, the GXV3370 will not get the Call-Info header and the video preview will not work like in your case. Actually, I know that the PJSIP does not support the early direct media - only after answering the call. So, maybe this is a not a bug but a feature in the PJSIP stack.

maybe a direct ip call from the GDS3710 to your GXV3370 is your best option.
I hope this will help you to solve your problems.

Thank you,

Daniel Friedman
Trixton LTD.

1 Like

Hi @danielf,
Could you elaborate on “verify that you allow early media in the sip settings of the extensions”?

I was previously using pjsip, I have migrated the extensions to chan_sip and confirmed audio and video work in calls again but no preview. Do I just need to add “earlymedia=yes” in other sip settings? I do not see any Early Media settings in the extension itself

Unfortunately while direct IP works on the bench, our end goal is to have the GXV’s at remote working locations with the ability to answer the intercom at a (at times) unmanned office. Unlocking the door would be a nice feature in the future when the office is staffed, but right now we would be extremely excited to just get the video preview working (either between the GXV or with the GDS to a GXV)! :slight_smile:

Hello @badams,

If you are using the chan_sip, then add these settings to the sip settings module:

prematuremedia=no
progressinband=yes

If this is still does not work for you, you will need to add the Progress application to your dialplan.

If you want to allow video calls between the GXVs, make sure that you add the h.264 codec list and that you are allowing video calls.

Thank you,

Daniel Friedman
Trixton LTD.

1 Like

Hello, I am experiencing the same issue with my system and a grand stream phone. Since this conversation died out, did you come up with a solution? I would love to know what you did if you solved it.

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