Disruptive Telephony

Have you ever been curious about the process of creating a Request For Comments (RFC) document within the Internet Engineering Task Force (IETF)?  These are the standards like, oh, “HTTP”, that power the Internet. Have you been interested in understanding how they work?

If so, someone I know, Russ White, recently completed a 7-part article series about the entire process over on the Packet Pushers Network site. Russ has nicely summarized the series on his site at:

https://rule11.tech/the-rfc-process/

He does a nice job providing an overview of the long process of starting with an idea, creating an “Internet draft”, working it through the IETF process, and then hopefully getting it published.

There are many more details, of course, but Russ lays out the high-level aspects and mentions some of the parts of the process which are harder to understand for someone new to the IETF.

If you are interested in the RFC process, I would encourage you to give Russ’ series of articles a read.

Using Markdown instead of XML

I do have one area of disagreement with Russ. He advocates for using XML for writing Internet drafts, whereas I used to write drafts in XML but have moved over the years to instead using Markdown. If you are writing simple text documents, I believe Markdown is a simpler and easier way to work.

Back in 2019, I gave at tutorial session at the IETF meeting in Prague about “Writing Internet Drafts in Markdown”. The materials are at:

• Slides
• Video 
• Github repository

[One important note - this tutorial session was given FIVE YEARS AGO and the state of Markdown tools is always evolving. I would monitor https://authors.ietf.org/drafting-in-markdown to see about new tools and ways to work with Markdown.]

The video of the tutorial session is actually a great comparison of the two ways of creating Internet drafts. In the first half, my friend Matt Miller explains how to create I-Ds using XML tools, and then around the 32-minute mark I explain how to create drafts in Markdown.

Either way - XML or Markdown - hopefully Russ’ series helps explain a bit more about the whole process of writing a RFC.

For those who use WhatsApp, you may have noticed that your messages are secure and private, thanks to the encryption that is used. But what is encryption, and why is it so important?

Encryption is a process of scrambling information so that only the intended recipient can read it. Essentially, it takes the data you’re sending and scrambles it using a mathematical algorithm. To unscramble the data, you need a key, which is known only to the sender and the receiver.

WhatsApp uses end-to-end encryption, which means that your messages are encrypted on the sender’s device, travel securely to the receiver’s device, and remain encrypted until the receiver reads them. This means that no one – not even WhatsApp themselves – can see the messages you’re sending.

This is an important feature for anyone concerned about their privacy, especially in an era of increased surveillance. With WhatsApp’s encryption, you can be sure that your messages will stay safe, secure, and private.

WhatsApp is also working to improve their encryption, with plans to add a feature known as “Perfect Forward Secrecy”. This feature will generate a new encryption key for each message you send, ensuring that if one key is ever compromised, the others will remain safe.

Encryption is an important part of keeping our messages secure, private, and confidential. Thanks to WhatsApp’s use of encryption, we can be sure that our messages are safe and secure.

— A second version — 

In the age of increasing concern over privacy and security, end-to-end encryption has become an essential part of secure communication. WhatsApp, the popular messaging and voice-over-internet-protocol (VOIP) application, has been at the forefront of this movement, using the strong encryption protocols to keep users' conversations secure.

WhatsApp uses the Signal Protocol, an open-source encryption protocol developed by Open Whisper Systems, for its communications. The Signal Protocol is considered to be one of the most secure encryption protocols available, and is used by other popular messaging services such as Facebook Messenger, Google Allo, and Skype.

Using the Signal Protocol, WhatsApp transmits messages between users in an encrypted form, meaning that only the sender and recipient can see the contents of the message. This makes it impossible for third-party entities, such as government agencies or hackers, to read or intercept the messages. The encryption is also applied to all media messages, including photos, videos, and audio recordings, as well as group messages.

WhatsApp also uses a two-factor authentication system for added security. This means that users must enter a code sent to their phone before they can access their account. This provides an extra layer of protection that makes it difficult for hackers to gain access to user accounts.

Overall, WhatsApp's use of encryption is a great step forward in protecting users' privacy and security. The Signal Protocol provides a secure communication medium, and the two-factor authentication system helps ensure that users' accounts are secure. It's no wonder that WhatsApp is used by millions of people around the world.

— A third version — 

Recently, WhatsApp announced that it is now using end-to-end encryption for all its communications. This means that all messages, pictures, audio and video files sent through the popular messaging app will be encrypted so that only the sender and recipient can view or hear them.

WhatsApp's use of encryption is a huge step forward in protecting user privacy. With end-to-end encryption, even the company itself can't access the content of messages sent through its service, meaning that users can be sure that their conversations remain private. The encryption also makes it much harder for hackers or other malicious actors to intercept messages, protecting users from potential data breaches.

The encryption also has implications for businesses and organizations that use WhatsApp for communications. By securing messages with end-to-end encryption, companies can be sure that their confidential conversations remain private, even if an employee's device is hacked. This added layer of security can help protect businesses from potential data breaches, and also provide a higher level of assurance to customers who are sending sensitive information.

WhatsApp's use of encryption is a welcome move that will help protect user privacy and data security. It's a great example of how technology can be used to improve security and protect user data.

— Why three versions? — 

All three of these were “written” by the ChatGPT service using the prompt "Write a blog post about WhatsApp's use of encryption in the style of Dan York”. I just refreshed it to get another version. I used the default settings except for changing the maximum length to 1100

They’re not bad, eh?

The text is not entirely off from what I would normally write on my sites. I put a strikethrough on the last sentence of the first two because those were sentences I don’t think I would ever write. They feel a bit overly promotional. I included them just to show what ChatGPT would produce.

Certainly text like this could generate a quick “first draft” that I could then edit a bit to publish.

Would you have known that I did not write them if I didn’t indicate it was from ChatGPT?

We live in interesting times… 

With so many people now having to learn to work remotely due to restrictions related to COVID-19, what information can people share who have been working from home? Back in October 2019, I realized it was 20 years ago when I started working remotely, and so I sent out some tweets asking for opinions about the benefits of working remotely, the challenges / disadvantages, and then the lessons people have learned. I subsequently recorded podcast episodes on each of those three topics.

The links to the Twitter threads and podcasts are below.At some point I may turn them into longer articles themselves, but in the meantime, I hope they will help some of you with ideas for how to get adjusted to this new way of working.

And… I would suspect many of you might just want to jump directly to the lessons learned… 

Benefits

• Twitter thread: https://twitter.com/danyork/status/1181883371611406336
• Podcast episode: TDYR 380 - Remote Working, Part 1: What are the BENEFITS of working from home?

Many of the benefits were about no commute, the ability to be present with family, freedom to work and live wherever, flexibility, caring for family, and more.  (Note that a good number of the benefits mentioned (such as working from "anywhere") are currently NOT possible because of the self-isolation / quarantine imposed by the COVID-19 situation.)

Disadvantages

• Twitter thread: https://twitter.com/danyork/status/1182213497066868741
• Podcast episode: TDYR 381 - Remote Working, Part 2: What are the DISADVANTAGES of working from home?

Loneliness, isolation, and the lack of social connections with colleagues topped the list of disadvantages, along with the lack of physical activity, home distractions and more.

Lessons Learned

• Twitter thread: https://twitter.com/danyork/status/1182606706485977088
• Podcast episode: TDYR 382 - Remote Working, Part 3: What are some LESSONS LEARNED about working remotely?

Some of the key lessons that I have learned in over 15 years of working remotely, and that were common in other comments include:

• Create a separate space (ideally, a separate room) - this is critical if you can do it.
• Invest in a good chair and other office equipment - since you are going to be sitting in it so many hours of your day! (Or some people now have desks that let you stand, too.)
• Make time for physical activity - get OUTSIDE if you can! Go for a walk. Go for a run. Or work out in a home gym. Multiple people suggested dogs being a great way to force you to do this.
• Make a schedule - and STICK to that schedule - it is super easy to work many hours at all different times. Figure out a schedule that works for you,  your employer, your team, and your family - and then try to stick to that schedule.
• Use collaboration tools - things like Slack are critical for your own sanity so that you are “connected” to other people in your organization. (Granted, you may need to figure out how to not be too connected to everyone and spend your day drowning in notifications!)
• Take actual lunch breaks - step away from your computer and your home office. Get up and move around.
• Sit with your face toward natural light, if possible - it looks better than artificial light… and you’ll get some Vitamin D, too. 🙂
• Lighting IS important, particularly for video calls - you do want to have light shining on you in a way that works well for video. You may want to experiment with different lamps around you or on your desk.
• Have video calls with other remote workers - make time to connect with colleagues, ideally over video calls. Even if it is just to chat for 5 or 10 minutes. It can help ease the sense of isolation - and they may like it, too! Sometimes if I have a question that I’m going to write in email or Slack, I’ll ask myself, “would it be faster if I just ask them in person?” And if so, I’ll ping them via a message to see if they are available for a video call.
• Work in different locations - Try sometimes to get out of your home office and work in other parts of the house. Take a laptop and work in another room, or on a deck or yard if you have one. (Granted, this might be hard if you have many people in your household all working in the same building.)

On this last point, you’ll see in the Twitter thread and hear on the podcast all the comments about working from other locations. For example, working at cafes with WiFi, etc. That IS a critical lesson many of us have learned. Successful remote working can involve getting outside the walls of your home office - and outside of your home. Obviously this is currently NOT possible with the COVID-19 situation, but something to definitely think about if you continue working remotely once we are past all of this.

Other remote workers… what other lessons learned would you add?

Best wishes to you all as we all try to navigate this new world of social distancing and working remotely over the next weeks and months!

UPDATE #1 - over on Twitter, someone I know pointed out that this is NOT regular "working from home" (WFH). His text: "I've WFH 11 years. current situation is not normal WFH. you can't go to a coffee shop to interact w people, work out or take advantage of all sorts of WFH perks like normal.
self-quarantine != WFH"

I definitely agree, Paul, this is NOT regular "working from home".

Photo by Djurdjica Boskovic on Unsplash. - No, that’s not MY desk… far too clean! 😏

October 31, 2018, was a special day for me. Not because it was Halloween, but because after 10 years a small little document I co-authored about the "P-Charge-Info" header for SIP-based Voice-over-IP (VoIP) was published as informational RFC 8496. You can see it at either:

• https://datatracker.ietf.org/doc/rfc8496/
• https://tools.ietf.org/html/rfc8496

Ultimately, all this document does is register the Session Initiation Protocol (SIP) Header Field of "P-Charge-Info" within the "SIP Parameters" registry maintained by IANA at:

• https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2

But the story of getting that registration to happen is a long one!

In the beginning...

The short version is this. Back in around 2007 or so, I was working for Voxeo and we were using the "P-Charge-Info" header in our large SIP-based application server to pass along billing information. Essentially, when someone made a call on our system, we wanted to pass a billing identifier that was often different from the source phone number (i.e. "CallerID"). This quote from RFC 8496 was pretty much Voxeo's use case:

As another example, a hosted telephony provider or hosted voice application provider may have a large SIP network with customers distributed over a very large geographic area using local market PSTN numbers but with only a very few actual PSTN interconnection points.

The customers may all have local phone numbers yet outgoing calls are actually routed across a SIP network and out specific PSTN gateways or across specific SIP connections to other SIP service providers. The hosted provider may want to pass a billing identifier to its SIP service providers either for the purpose of simplicity in billing or to obtain better rates from the SIP service providers.

While we at Voxeo were already using P-Charge-Info extensively, we wanted to use the P-Charge-Info header with more SIP service providers, and needed some form of documentation for how to use the header. We also were concerned about the profileration of more P-headers and wanted to register "P-Charge-Info" with IANA so that more people might find and use that header rather than inventing their own. (We were happy with P-Charge-Info and didn't want to have to support more SIP headers related to charging identifiers.)

So I began the process of submitting an Internet Draft way back in February 2008 documenting P-Charge-Info and requesting its addition to the IANA registry.

Almost immediately Tolga Asveren, then at Sonus Networks, contacted me to let me know they were using P-Charge-Info in the SIP equipment they were selling. He had some great suggestions, supplied some additional text, and was interested in working on the document with me. So I published a -01 draft 3 days after the first draft, and Tolga and I began our 10-year journey through the process of getting this document published.

Square pegs in round holes - slamming ISDN info into a SIP header

Along the way, others approached us from traditional PSTN telecom companies indicating that they were interested in using P-Charge-Info as a way of passing the "ISUP Charge Number" that was part of ISDN signaling. Though it was not something that either Tolga or I worked directly with, we were okay adding this in, and so two new parameters got added:

• Numbering Plan Indicator (NPI)
• Nature of Address (NOA)

... along with a substantial amount of new text.

A 2011 version of the document can show what this was all about.

Lost in limbo

Meanwhile, the document had gotten caught up in the need to wait while RFC 3427 was replaced by RFC 5727, which defined the whole SIP Header Field registration process.

And then I wound up leaving Voxeo to join the Internet Society (my current employer). And so my attention was no longer focused on VoIP and so this draft was truly a "back burner" kind of thing that I just worked on in random moments.

And unfortunately, it turned out that slamming legacy PSTN signalling into a SIP header caused a whole number of challenges, both with getting agreement - and also with some of the internal IETF processes. It turned out that to do this registration, we were going to have to do some other registrations - and more.

I also published a version that changed some of the parameters values in a way that was not backwards-compatible, which caused some friction.

By 2015, both Tolga and I were ready to ... just... let... it... die...

Returning from the dead - and returning to the SIP roots

And then in early 2017, Henning Schulzrinne and Richard Shockey contacted me to let us know that the US FCC was interested in the status of P-Charge-Info. The FCC had some billing issues between carriers where the carriers were in some cases already using P-Charge-Info, but the carriers really wanted an actual RFC versus an expired draft. There was also some potential interest in having the header around as one of many different tools in the FCC's efforts to combat robo-calling / spam phone calls.

So Tolga and I worked with Henning and the IETF area directors to come up with a plan to resuscitate the document. In doing so, we stripped out all the legacy PSTN signaling. Specifically we removed the NPI and NOA parameters, and all the mentions of the ISUP Charge Number.

We returned it to the simplicity of the original document way back in 2008.

The original goal had been to simply document existing usage of the P-Charge-Info header, as it was being used by various SIP providers and vendors. We returned it to that root.

Success!

After a number of further drafts, an expert review by Adam Roach, and more feedback from Area Director Ben Campbell, the draft finally entered the RFC Editor queue by way of the Independent Series Editor (ISE). Many thanks are due to Ben to sponsoring the draft. He, Jean Mahoney, and Adam were all critical in helping get it across the finish line. Thanks, too, to Henning and Richard who provided the spark for us to revive the document.

It would not have happened, either, if Tolga had not taken the lead over the past year in making edits, answering all the questions from people, proposing solutions and continually asking how to move the draft forward. I may have been the one editing the XML and submitting the new draft versions, but he was the one driving the text revisions.

It's great to see the document finally published as Informational RFC 8496. Looking back on the journey, there were:

• 16 revisions of draft-york-sipping-p-charge-info (2008-2012)
• 6 revisions of draft-york-dispatch-p-charge-info (2012-2015)
• 9 revisions of draft-york-p-charge-info (2017-2018)

Now, granted, some of those were a simple "update to keep the document from being 'expired'", but still it was all a great amount of work.

I learned a HUGE amount along the way. When the journey began in 2008, I didn't really understand much about IETF processes. Now I do - and now understand how we could have done this quite differently along the way.

Thanks to everyone who provided feedback and support over the years.

P-Charge-Info is finally registered in that IANA registry! :-)

In one picture, this comic from xkcd nails the very sad state of fragmentation with our messaging systems today. The text says:

I have a hard time keeping track of which contacts use which chat systems.

And that is our major pain point today.

Think about it... do you know how to reach most of the people you need to communicate with?

Some readers may have just decided that they are going to ONLY use one service. They communicate on only, say, Facebook. Or WhatsApp. (Or in one case I know, someone has rejected all new messaging apps and will only communicate with email.)

And so if you want to communicate with them you have to use their one service.

But of course, if you want to communicate with other people, you have to use their service... which leads to this comic and the mental energy we all must expend to remember (names are made up):

• George likes to get Twitter DMs
• Sue and Jose only use Facebook Messenger
• Carlos only uses WhatsApp
• Heidi, Frederick and Laura only use Wire
• Your parents all use iMessage... except when they decide to use Facebook Messenger
• Your teenage kids ignore most messages except on Snapchat
• Nick only responds to Instagram DMs
• Jon is old-skool and can only be found on IRC
• Your work colleagues are best found on Slack... except a couple are also Facebook friends so you can reach them that way... and a couple of others are on Twitter and so you can reach them there
• Your friend in Asia prefers WeChat
• A number of people you know use Matrix and Riot.im
• and...
• and...
• and... the list goes on...

Think about the sheer amount of thought processing and memory we all must expend to keep this all straight in our heads! And yes, some tools and contact/address books can help... as can some clients.

But it's a mess.

Two years ago I wrote about why I thought that some degree of centralization was inevitable: The Directory Dilemma - Why Facebook, Google and Skype May Win the Mobile App War.

I still believe the "directory dilemma" is the key issue here. All this fragmentation can't last.

Naturally the large players would like us all to forget about the others and move all our messaging to be inside of Facebook Messenger, or iMessage, or WhatsApp. They have zero interest in sharing or federating because they are all about the lock-in and keeping people inside their pretty walled gardens.

And groups like Matrix.org are working on creating the kind of distributed, decentralized messaging I'd like to see. But they run into the issue that it's hard to do that in a way that's simple and easy to an end user.

We don't care about where Fred sends messages...

... we just want to reach Fred.

I do worry that in the end all our messaging will be inside the private, commercial walled gardens, because people will default to the ease of finding people. The big directories will win.

Right now it's a mess.

What do you think? What is our path out of this mess?

A related audio commentary is available:

Ten years ago today, on December 18, 2006, I launched this blog with a very short 1-paragraph post:

Welcome to Disruptive Telephony! For a number of years, I have been blogging about VoIP as part of my personal blog, "Blog.DanYork.com". However, I'm now in the process of splitting out some parts of my writing into separate blogs. This is one of those blogs. Right now... I'm just setting it up, so don't expect to see much here. Stay tuned, though... much will be happening soon.

At the time, I was living in Burlington, Vermont, and working remotely for the Office of the CTO at Mitel Networks back up in Ottawa, Ontario (where we lived from 2000-2005). Dave Edwards, a friend from Ottawa, left the only comment on that post.

In 2006, the "VoIP blogging" world was quite small - and we all pretty much knew other. Om Malik was writing on his own site (it was yet to become GigaOm). Andy Abramson had VoIPWatch. Jeff Pulver was writing on his sites. Tom Keating at his "VoIP and Gadgets blog" on TMC. Martin Geddes had his "Telepocalypse" site. Alec Saunders had "Saunderslog". And there were a few others...

This was back in the day when we read each others blog posts, commented on them, excerpted each other's posts, etc. And "social media" was not yet a big thing.

It's been a crazy 10 years since... being "restructured" out of a role at Mitel in 2007 after their merger with Inter-Tel, finding a role with Voxeo through this Disruptive Telephony blog (they read this post about telephony not mattering, and then my post about the role I was seeking)... moving to Keene, NH, in 2008... joining the Internet Society in September 2011... it's been a wild ride!

Along the way, I wrote a ton of articles about Skype, SIP, Google and many other VoIP technologies.  MANY relating to security. At one point I seemed to have become Skype's receptionist since no one could find a phone number on Skype's (pre-Microsoft) web site. I wrote about startups that showed great promise, and also about when those promises faded. Many articles on many different topics...

I learned a huge amount and met many great people and made great connections from the writing on this site.

Over this decade of writing, TypePad gives me these stats:

• 1,209,851 Lifetime Pageviews
• 331.10 Pageviews/Day
• 800 Total Posts (including this post)
• 924 Total Comments

Very appropriately - and with no plan whatsoever - this is the 800th post on this site.

I started using Google Analytics on the site in October 2007 and it tells me I've had 1,817,045 pageviews since time, proving, once again, how difficult it is to track viewers, since the stats are different. More interestingly, GA shows me the top posts that have attracted interest over the years:

1. Google Voice Now Offers SIP Addresses For Calling Directly Over IP (March 2011)

2. Understanding Today's Skype Outage: Explaining Supernodes (December 2010)

3. Did Google Hang Up On Calling Google Voice Via SIP? (March 2011)

4. Will iOS 9 Make My iPad2 Usable Again? (June 2015)

5. What is an Over-The-Top (OTT) Application or Service? - A Brief Explanation (July 2012)

6. How To Set A Skype Chat So That New Arrivals See (Some) Chat History (March 2011)

7. You Can Now Call Into Google+ From Regular Phones - Google Connects Google Voice To Hangouts (May 2013)

8. UPDATE: Will iOS 9 Make My iPad2 Usable Again? (Reports after the upgrade.) (September 2015)

9. Why Is Skype Forcing A Software Upgrade On All Of Us? (Plus The Community Outrage) (August 2014)

10. Did Google REALLY Kill Off All XMPP/Jabber Support In Google+ Hangouts? It Still Seems To Partially Work (May 2013) 

 No real surprises there... my post about Google Voice and SIP addresses STILL receives a significant volume of interest, even though that capability died long ago. For a while, back in maybe 2009-2012, I was one of the main people writing about Skype, and so many of my posts of that era were highly viewed.

A few of my own favorite posts that aren't on that list include:

A. The Directory Dilemma - Why Facebook, Google and Skype May Win the Mobile App War (June 2015 and December 2014) - one of my longer pieces diving into what I see as the prime challenge for new entrants into VoIP / messaging. (The link is to the updated version on CircleID, but the original version was here on this site.)

B. Why The Opus Codec Matters - Even If You Don't Care About Audio (July 2013) - my thoughts on why people need to care about audio codecs.

C. Moving Beyond Telephone Numbers - The Need For A Secure, Ubiquitous Application-Layer Identifier (May 2013) - After SIPNOC 2013, I dove into the whole area around "What do we use as an application-layer identifier for Internet-connected devices?"

D. A Brief Primer on the Tech Behind Skype, P2PSIP and P2P Networks (November 2010) - I kept needing to explain peer-to-peer (P2P) networks to people, and Skype's setup in particular, that I felt compelled to do a deep dive and explain how P2P systems worked. Fun to write!

E. Hypervoice - The Fundamental Flaw In The Proposal (October 2012) - this piece analyzing a proposal from Martin Geddes and the ensuing comment trail make for good reading about different viewpoints on the future of telecommunications.

F. Ch-changes - Taking A New Job At The Internet Society To Join The Fight For The Open Internet (September 2011) - this one is of course a favorite as it explains why I am doing what I am doing now with the Internet Society.

There were many other favorites, like my rant about WebRTC and who we were building it for, but these were the main ones.

Of course, if you look at both of those lists you can notice that with the exception of the two iPad / iOS9 posts and the updated "Directory Dilemma" in 2015, all of these are older posts.

This shows, though, the decline I've had in posting here.  Look at these numbers:

• 2016 - only 7 blog posts (including this one)
• 2015 - 25 blog posts
• 2014 - 28 blog posts
• 2013 - 30 blog posts
• 2012 - 40 blog posts
• 2011 - 154 blog posts
• 2010 - 90 blog posts
• 2009 - 52 blog posts
• 2008 - 110 blog posts
• 2007 - 234 blog posts

Clearly my velocity has decreased in a serious way, mostly as a result of new responsiblities with the Internet Society and a decreased amount of time for writing here.

I have a loooooonnnnnnnggggg queue of articles I want to write here. The reality is that while some things have changed over the 10 years, many of the same issues are still here.

We'll see where I go with this in 2017. I have a great amount of focus I'd like to give to messaging... let's see if I can make that happen!

Meanwhile... today I will just say THANK YOU TO ALL THE READERS OVER THE 10 YEARS! I'm glad to have helped many people along the way - and I'm glad to have been challenged by many people as well.

I'm looking forward to the next 10 years of writing here... because one thing is definitely for certain: telephony will continue to be disrupted!

Want to learn the latest about WebRTC inside of Firefox? Nils Ohlmeier from Mozilla sat down for an interview at the IIT RTC Conference last week with Mark Fletcher of the Avaya Podcast Network. I found it quite a useful explanation of what Mozilla is doing with Firefox and how different aspects of WebRTC come into play in different parts of Firefox. Give it a listen...

This week I will briefly be in Bucharest, Romania, for the Internet Society's ION Bucharest conference. We've got a great set of sessions on the agenda, including:

• Deploying DNSSEC
• Romanian DNSSEC Case Study
• Let's Encrypt & DANE
• Mind Your MANRS & the Routing Resilience Manifesto
• The Case for IPv6
• IPv6 Success Stories
• What's Happening at the IETF? Internet Standards and How To Get Involved

I will have two roles in the event tomorrow:

• Presenting the "Deploying DNSSEC" technical session.
• Doing the live streaming of the event through the Deploy360 YouTube channel.

I enjoy doing the production of live video streams and so this should be a good bit of fun (it's also intense work in the midst of it).

You can WATCH LIVE starting at 14:00 EEST (UTC+3, or 7 hours ahead of the US East Coast where I live).

The sessions will also be recorded for later viewing.

It will be a short trip for me. I'm currently (Tuesday morning) writing this from the Munich airport. I land in Bucharest tonight. The event is tomorrow - and then I fly home Thursday afternoon.

Despite the short visit, I'm looking forward to it - it should be a great event!

An audio commentary on this topic is also available:

Photo credit: Nico Trinkhaus on Flickr - CC BY NC

The messaging wars continue! Today Facebook Messenger added "Instant Video" to it's iOS and Android app, allowing you to easily share live video while still in a text chat. Facebook has had "video calling" since back in May 2015, but that requires both parties to answer the video call in the same way that Facetime, Wire and every other video app does it.

"Instant Video" is different:

• VIDEO STARTS OUT ONE-WAY - Only the video of the person initiating "Instant Video" is shown. The recipient sees the video of the sender, but their video connection is NOT enabled. Now, the recipient can start sending video, but they don't have to.

• AUDIO IS OFF INITIALLY - When the sender starts their video, the recipient receives the video without any sound. They can easily start getting sound by tapping on the speaker icon on the video, but this is great because often you are having a text conversation precisely because you don't want to use audio.

• YOU CAN STILL SEE THE CHAT - The video overlays the upper right corner of the chat window, but that's it. You can still see the chat messages and continue having your chat.

This last point is quite important and useful. This "Instant Video" lets you add video to a chat, while still allowing chat to be the primary communication medium.

Predictably, there was a great amount of media coverage of this launch today. Some noted that this was yet-another-way Facebook was cloning Snapchat. Others called this an answer to Google Duo.

Regardless, I immediately saw a personal use case. Occasionally I will go to a local coffee shop to pick up muffins for my wife and I. The flavors are always changing. If I don't see one I think she'll like, I often wind up calling - or texting her with the flavors. But it would be actually a bit easier and faster if I texted her "which one do you want?" and then sent her a live video stream where I panned back and forth across the choices. Sure, that may seem a silly use case... but it immediately sprang to my mind.

For "Instant Video" to work, a couple of conditions need to be true:

• YOU BOTH NEED THE LATEST MESSENGER APP - You need to have the latest version for either iOS or Android.

• YOU BOTH NEED TO BE *IN* THE CHAT - This is key. You can't just open up Messenger and start sending video to someone who is listed in your contacts. You need to actually be in communication with the other person.

Once this second item is true the video icon on the top of the screen starts pulsating - at which point you can start sending "Instant Video".

I'd note that this is the same icon used to initiate a "regular" video call. However, when you are in a chat with someone else the pulsating icon means you can do this new "Instant Video" style of chat.

I found I really liked the overlay aspect. Here's the view I saw on my end:

It worked very well to continue the text conversation while having the video right there, too.

It's an interesting addition as Facebook continues to try to make Messenger be THE tool that people use for messaging. Facebook has this advantage of having an absolutely massive "directory" of users (see "the Directory Dilemma") and so we may see this helping with keep people inside of Facebook's shiny walls.

What do you think? Do you see yourself using this "Instant Video"?

Continuing their efforts to be THE communication platform you use, the Messenger team at Facebook rolled out "group calling" this week within the Messenger app on iOS and Android. The new feature was announced by David Marcus, head of the FB Messenger team. Right now this is audio-only (i.e. not group video) and per media reports is limited to 50 participants.

I had to go to the AppStore and upgrade the Messenger app on my iPhone to the latest version, but once I did, I suddenly had a phone icon in the upper right corner of a group chat:

Tapping that phone icon brought me to a screen where I could choose which of the group members I wanted to bring into the group call:

After tapping "Call" in the lower right, Messenger launched the call and gave me feedback about who it was connecting, etc:

It then connected those who were available and four of us were in a group conference call:

As you can see in the screen captures, I had the standard buttons to mute my microphone and to activate the speakerphone.

AUDIO QUALITY - The audio quality was quite good. I couldn't find any technical info about what they are doing "under the hood" but one of the folks on the call understood that it was WebRTC-based, which would then imply the use of the excellent Opus audio codec. We experienced a couple of audio hiccups but nothing outside the normal VoIP experience and nothing that really detracted from the call. It certainly sounded like a rich, wideband-audio connection.

We didn't stay on the call for long as I didn't want to take their time (or my own), but exiting the call was simple and brought us right back into the group chat to continue our communication.

MOBILE-ONLY - One concern noted by a couple of folks was that the incoming audio call only rang on their tablet or phone, i.e. the iOS or Android app. It did not ring inside of Facebook in a desktop web browser or in the Messenger.com website.

Beyond that, though, it seemed a very straightforward and positive experience.

Now, Facebook Messenger is not the first to do this, of course. Skype has had group audio and video calls for years. As Venturebeat noted, in March of last year Line launched group calling for up to 200 people and WeChat added group audio and video calls in September.

Still, this is Facebook Messenger, with its 900 million users, providing yet another reason to NOT use traditional audio conferencing solutions.

I would suspect, too, that video conferencing can't be too far off, either, given that Facebook Messenger currently does let you do 1:1 video calls - and also that competitors offer group video calls.

It continues to be an absolutely fascinating time to watch the severe disruption of traditional telecommunications... and this move by Facebook is yet another example of how the ways we are communicating are changing.

What do you think? Will you use the group calling within Facebook Messenger?