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
transfer.
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.
_______________________________________________
Blink mailing list
[email protected]
http://lists.ag-projects.com/mailman/listinfo/blink
