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
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).
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.
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.
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.
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.
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.
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.
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)!
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.
