[Blink] New Blink Pro for OSX version 4.1.0 with ZRTP end-to-end audio/video encryption

Dan Pascu dan at ag-projects.com
Fri Nov 21 07:16:42 CET 2014

On 21 Nov 2014, at 03:33, Kevin Layer <layer at franz.com> wrote:

> Dan Pascu wrote:
>>>> Counterpoint: Just because the video stream could not be negotiated
>>>> does not mean that it must reject the invite entirely.  
>>> Unfortunately things are not that simple as they seem at face
>>> value. It's a chicken and egg problem, because you need to decide
>>> early if you accept video or not and the error negotiating the
>>> codec happens later, by which time you cannot just go back on your
>>> decision and say I don't want video anymore.
> OK, fair enough.  And, I'm not an expert.  I'll will point out it used
> to work fine, though.  I've used Blink daily (at home and work) for >
> 6 months, and this is a new problem, with no changes to the Asterisk
> side.

As I said, the problem appeared because now blink supports video. Before video support, blink would automatically refuse the video stream if present and only accept audio, but now it will accept it and will fail if the codec cannot be matched.

> It's definitely an audio call.  What I see is an "Accept" button.  I
> don't see two, one for accepting audio and one for video.  In fact,
> the title of the window is "Audio call for ..." (or something like
> that, but it definitely had `audio' in it).
> So, to recap, I don't see "Audio only" anywhere.  I did look in
> Blink's Preferences and I did uncheck all the boxes I saw there.  That
> didn't change the observed behavior (server failure).

I didn’t mean the preferences. I meant the incoming call popup dialog. Something like this one (notice the video icon, the Video call title and the “Audio only” button):

What you say here raises an interesting conundrum. Because if things correlate that means that you get an audio+video call, yet blink tells you it’s audio only, but when you accept it also somehow accepts the video stream even though you didn’t accept that.

>>>> How do they
>>>> explain the successful operation of all of our other devices which
>>>> work properly with this version of Asterisk?  Are they all out of
>>>> spec?
>>> Do those devices support video? If not, then obviously they refuse
>>> the video stream off the bat, which is something you can do as well
>>> as mentioned above.
> Well, maybe I'm misunderstanding something, but I don't see that.  I'm
> on a Macbook but I have the lid closed and I'm using an external
> keyboard, mouse and monitor.

When I said other devices, I meant other software or hardware phones besides blink. I thought you said other devices (phones) work and I just try to tell you why they might work.

>  So, the camera is probably in some disabled state.
> At home, I'm on a Mac that does not have a camera, but I get the same
> behavior there.

This is useful information that gives a bit more context. Can you give us an account on that asterisk server so we can test it out ourselves? You’ll also have to reenable video support at least for the test.

> I don't have enough experience in this area to even have an opinion
> about Asterisk's worthiness or reliability.  We have used it for years
> here at work, and I've used it for at least 3 years at home.  Never
> had any problems at all.

I’m not saying you should have problems. But it’s small things like this (like adding a video stream always even when not requested by the user) that taint the experience and create unnecessary complications.

> What do you consider to be a better SIP implementation, on the server
> side?

It depends on what you try to do. For a small PBX like solution asterisk is fine, bar the occasional workarounds that you have to employ for issues like these and fighting against unreasonable defaults. If you want to handle more traffic, you might be interested in a SIP proxy like opensips, but that one requires more SIP knowledge to be set up. If you do not offer a service for others, but only plan to have a few sip accounts to talk with friends, you can considering using a free service like sip2sip.info which relieves you from the need to setup and configure a SIP server.

>>> If asterisk is under your control you might be able to configure it
>>> not to add a video stream to audio only calls. Not sure if there is
>>> a setting to make asterisk only add video if the caller asked for
>>> video, but if you do not need video at all, it can be disabled
>>> entirely:
>>> [default]
>>> videosupport=no
> It is under my control.  And thanks for the suggestion.  I just found
> this after my last email.  We use Freepbx on top of Asterisk, and I
> did find an option in the web interface to turn off video, server
> wide:
>  Settings -> Asterisk SIP Settings, Video Support: Enabled -> Disabled
> In fact, it has allowed me to accept audio calls again.
> This seems like a blunt instrument, though.

I didn’t suggest it as a permanent solution, only as a workaround until we figure it out.

>  If others want to do
> video calls, I've just stopped them from doing so,

When we fix it and you reenable video support in asterisk, every audio only call will show up as a video call, because asterisk will add video regardless if it was requested by the caller or not. Asterisk should not interfere and add streams on its own.

> just because Blink
> changed to not handle something it's handled for a long time.

As I said before, this is not a regression. blink didn’t break something, like it worked before but it doesn’t work anymore. Before blink didn’t support video and thus video was refused automatically. Now blink supports video and if you accept it it fails if codecs do not match.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ag-projects.com/pipermail/blink/attachments/20141121/972a7101/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2014-11-21 at 07.41.39.png
Type: image/png
Size: 297839 bytes
Desc: not available
URL: <http://lists.ag-projects.com/pipermail/blink/attachments/20141121/972a7101/attachment-0001.png>

More information about the Blink mailing list