[Blink] New Blink Qt 3.0.0 version for MS Windows

Dan Pascu dan at ag-projects.com
Tue May 9 07:41:19 CEST 2017

On 05/09/17 00:17, Mediacast Guy wrote:
> On 5/8/2017 2:50 AM, Dan Pascu wrote:
>> On 05/08/17 03:32, Mediacast Guy wrote:
>>> On 3/11/2017 10:19 AM, Dan Pascu wrote:
>>>> On 10 Mar 2017, at 23:03, Mediacast Guy wrote:
>>>>> On 3/10/2017 8:23 AM, Dan Pascu wrote:
>>>>>> On 9 Mar 2017, at 14:58, Mediacast Guy wrote:
>>>>>>> On 1/11/2017 11:23 AM, Adrian Georgescu wrote:
>>>>>>>> This Windows version features SIP call transfer, migration to latest Google contacts API and several bug fixes.
>>>>>>>> Graphical user interface has been migrated to Qt5.
>>>>>>>> The automatic updater should kick in. To manually upgrade your Blink version go to:
>>>>>>>> http://icanblink.com
>>>>>>> I'm missing something. Where is call transfer in the Windows version? I have version 3.0.0 installed, and the update
>>>>>>> checker says it's the latest version.
>>>>>> http://icanblink.com/help/manual-qt/audio-calls-linux/#call-transfer
>>>>> Thanks for pointing that out. I'm sorry I missed it. It works great. What's strange is my VOIP provider (VOIPo) said
>>>>> they don't have call transfer on their residential accounts yet it clearly works.
>>>> Call transfer is a function of the client not of the provider.
>>> I just tried to do a transfer with Blink and my VOIPo number, the same one that worked in the exercise above. When I
>>> initiated the transfer, Blink said "trying" the transfer but never connected. If I dial the number directly, it works.
>>> Am I doing something wrong?
>> The SIP service provider must support forwarding in-dialog REFER messages, as well as allowing the Referred-By and
>> Refer-To headers in INVITE requests for call transfer to work.
>> If you see Blink displaying 'trying' and not moving forward with the call transfer is most likely that the REFER
>> message was not delivered to the destination or the destination doesn't know how to handle it, but a SIP trace is
>> needed to confirm what actually happened.
>> If this call was with a PSTN number and you attempted to transfer that, it's very likely to fail as no SIP-to-PSTN
>> gateway I know of implements call transfer functionality.
>> You need both SIP endpoints to support call transfer and a SIP provider that does forward in-dialog messages correctly
>> for this to work.
> I called into a SIP number using my cell phone and tried to transfer the call to another cell phone. It didn't work.

I literally addressed this particular example in my answer above and 
stated that it won't work as SIP-to-PSTN gateways do not support call 

> Then I tried to transfer to another SIP number it didn't work.

If one leg of the call was still a mobile phone, nothing changed nothing 
changed, so yes it would still not work.

> What I don't understand is why it worked before. It's
> confusing because I've been told that "call transfer is a function of the client not of the provider." Isn't Blink the
> client?

It takes two to tango. I laid down the conditions that need to be 
satisfied in my answer above. Both endpoints (clients) need to support 
call transfer. One endpoint/client (Blink) cannot magically make the 
other endpoint initiate/participate in a call transfer if the other 
endpoint/client doesn't support call transfer.

In all your examples that do not work you mention one endpoint being a 
mobile phone, hence one endpoint/client is a SIP-to-PSTN gateway that 
doesn't support this.

Plus if you want to talk specifics as to why your particular attempt 
failed, we cannot do that by guessing what is wrong or inferring the 
cause from loose descriptions. A SIP trace will show what is going on.

More information about the Blink mailing list