I have a Grandstream DoorPhone (GDS3710) that calls a Grandstream GXP2170. This is supposed to send image frames to the phone when the doorbell is pushed even though the GXP is not a video phone. Grandstream support says this is an issue with FreePBX or how I have it configured. I’ve enabled Video Calls in Asterisk SIP Settings, and both extensions are Chan SIP. This is the last message I received from Grandstream:
Cory ,
I Confirmed with team, the FreePBX will not pass this images into phone, as this is no video phone, will be image frames that will pass , on this case the UCM Grandstream has an implementation for this not to happen , but on this case, the required of passing images frames from the server Free PBX , will come from same server. Not an implementation either of GDS3710 or GXP21xx phone.
So at this point what could recommend is to contact FreePBX support and verify if they have a way to support this image frames on their server.
Regards.
So… I guess what I’m asking is do any of you wonderful people know how I can accomplish this? I would be eternally greatful, as would my school.
FreePBX version 14.0.3.6
Asterisk Version 13.22.0
Active protocol CHAN_SIP
Network Structure build on Ubiquiti UniFi - Including USG Pro and gigabit switches.
What they are saying is it only works with their PBX as they have some proprietary setup for it since with FreePBX and SIP their is no concept pictures being sent just video.
There is also an option to do dorect ip calling between the gds and the gxp which also supports the images. Ive tried, but the calls can not complete. If both devices are registed, is tgere a setting in FreePBX that would dossallow ip calling between these two devices?
There shouldn’t be a problem with direct SIP calling, but as we’ve already established, there’s no way in SIP to do what you want to do.
If only we had something like wireshark and a way to capture the packets that were being transmitted so we could reverse engineer something that might work. What a shame that we don’t have complete control over all of the aspects of the system…
With this line in the context the Call-Info SIP header is copied into the destination. In the Call-Info header there is an URL which will be called by the GXP2170 to grab pictures from the GDS3710. Actually the video call settings have nothing to do with this.
However I have a problem. This works great if I put it into some context or macro which is executed during the call, however I don’t know how to put this line into the extensions-custom.conf in order to preserve it through reloads.
So this line is the solution, however I need some help, how can I inject this code into the from-internal context using the extensions-custom.conf.
It seems that your Grandstream support person is a bit more knowledgeable than the one I had. This is great news.
That said, I haven’t figured out how to make it work on mine. I put this in extensions.conf in the from-internal context. Maybe I’m doing this wrong. I am SO new to this level.
I think I have a solution for your extensions-custom.conf thing though… I’m pretty sure you should be able to do this:
[from-internal-custom]
exten => s,n,SIPAddHeader(Call-Info: ${SIP_HEADER(Call-Info)})
include => from-internal-noxfer
include => from-internal-xfer
include => bad-number ; auto-generated
exten => h,1,Macro(hangupcall)
Then, in the extension GUI, set the context (under advanced) to be from-internal-custom.
I can get the call to complete this way. It just doesn’t send the stream. If you have any other advice on how to do that, it would be great. I don’t understand how to tell which contexts or macros are being used during a call, and while I’m aware I have “complete control over all of the aspects of the system,” that doesn’t mean much when I’m completely ignorant and working with a time frame that doesn’t allow me to drop everything and read manuals for days. Please don’t misunderstand… I want to learn, and I want to know why, but I have to finish this on the quick side to make the deadline for budget meetings and school board project approvals.
Actually we used also Wireshark to see what’s sent by the GDS and it was true, it had a Call-Info in the SIP header with a URL. The guy from the helpdesk wrote also, that this URL is used by the GXP2170 to grab the pictures.
But Asterisk does not forward this specific header key-value to the destination, so the GDS sends (you can see in wireshark) but the GXP does not receive it (the outgoing call from the Asterix to GXP does not contain the header key-value pair any more). Using the line I provided I managed to copy the header key-value pair to the destination, and it worked.
Make sure you put this line in your context before the “copy sip headers” macro is called. It was working when I put it to the beginning.
Also make sure you use the latest firmware on both GDS and GXP devices.
I will let you know if this custom context is working or not for me.
If you put this into the extensions_custom.conf, this macro will be called by the default internal call logic, and this way the Call-Info header is preserved. This is what you can see in the log:
Executing [s@macro-dialout-one-predial-hook:1] NoOp(“SIP/1001-00000ffa”, “******************** PRE DIAL HOOK ********************”) in new stack
Executing [s@macro-dialout-one-predial-hook:2] SIPAddHeader(“SIP/1001-00000ffa”, “Call-Info: <https ://10.3.137.174:443/capture/8001> ;purpose=GDS-view”) in new stack
You can here also see what the Call-Info header contains, it has basically the IP address:port of the GDS device, with some URL to grab the picture frames.
Now for me it is working correctly. The extensions and also the GDS extensions use the “from-internal” context.
You, sir, are brilliant, and I can’t thank you enough for your help! Sorry I pointed you in the wrong direction, but I’m super pleased that you figured it out and you were willing to share. Have a fantastic day, and I’ll be sure to let the grandstream guy know this is the solution for FreePBX.
