Из первых рук: подводные камни на пути к поддержке WebRTC

    Logo
    Многие из вас слышали про новый стандарт для реализации реалтайм веб-коммуникаций, он же WebRTC. Мы занимаемся разработкой сервисов для голосового общения (click-to-call/tap-to-call) с пользователями веб-сайтов и мобильных приложений. И именно поэтому нам очень близка идея голосовых и видео-звонков прямо из браузера без установки дополнительных плагинов. И вообще любого дополнительного ПО. Наша компания входит в рабочую группу W3C по разработке данного стандарта вместе с Google, Mozilla, Cisco, Ericsson, Skype и многими другими (да, мы попали в отличную компанию). Над стандартом работает команда серьезных профессионалов, как, например, Cullen Jennings (Cisco), Justin Uberti (Google), Daniel Burnett (Voxeo), Cary FitzGerald. Многие из них участвовали в создании IP-телефонии в том виде, какой мы знаем ее на протяжении последних 10-15 лет.

    Инициатором всего WebRTC-движения выступил Google после приобретения GIPS.Они же стали первыми, кто добавил поддержку последней draft-версии стандарта в свой браузер. WebRTC уже отлично работает в Google Chrome 23. Но да, чтобы WebRTC-версия вашего онлайн-сервиса «взлетела», необходимо потратить время и разобраться с тем, как все устроено сейчас. А чтобы ваш WebRTC-сервис продолжал работать, надо еще и следить за тем, что происходит в рабочей группе, и за всеми изменениями стандарта, что не так тривиально, как кажется.

    Немного истории. Первым браузером, в котором была реализована хоть какая-нибудь поддержка WebRTC, был экспериментальный браузер от Ericsson. Нам не терпелось попробовать WebRTC в действии, и мы «напилили» поддержку в таком виде, чтобы наши сервера работали с этим браузером. Как оказалось потом, это было достаточно глупой затеей. Как только за дело активно взялся Google, все наработки Ericsson отправили куда подальше, и началось постоянное изменение стандарта, а также соответствующей реализации в девелоперской сборке Chrome Canary.

    Были и достаточно забавные моменты, когда разработчики браузера использовали какие-то странные варианты RFC (или вообще их не использовали) и получалось, что STUN или ICE приходилось переписывать заново, чтобы оно хотя бы как-то заработало. В итоге здравый смысл победил, и все сделали по RFC, но достаточно много времени было потрачено на пляски с бубном и разъяснения, что так делать не хорошо.

    Можно выделить несколько моментов, которые сейчас вызывают трудности при работе с WebRTC:

    1. Работа над стандартом в самом разгаре, и до некой законченной версии еще далеко. Меняется все – например, выходят новые версии браузеров, которые требуют перепроверки и зачастую переработки всей реализации. При этом не факт, что есть обратная совместимость. Зачастую ее нет.
    2. Реализация стандартных протоколов (например, SDP) все еще далека от идеала. Скажем, сейчас PeerConnection умеет отправлять видео и аудио только по одному порту, даже если в SDP другого участника указано обратное. Правда справедливости ради стоит отметить, что ситуация постепенно исправляется. Например, ICE в последних версиях Chrome работает в соответствии с RFC.
    3. Сложности в интеграции с SIP добавляет и невозможность реализации методов Media Control XML. Поэтому при потере пакетов от шлюза до SIP-оборудования будут проблемы с восстановлением картинки. Коллеги из Google сказали, что у них это реализовано на уровне протокола RTP, поэтому с этим вопросом еще нужно разбираться.
    4. Нет поддержки распространенных видео-кодеков (читай — H.264). Конечно, часть софтфонов уже имеет реализацию VP8, но никакое промышленное решение еще не поддерживает этот кодек. С этим вопросом ясности пока нет никакой, есть ряд компаний, выступающих за поддержку H.264, но так как кодек запатентован MPEG-LA, а использовать планируется только royalty free кодеки, то пока доступен только VP8.


    С точки зрения UX/UI, WebRTC явно лучше Flash (см. скриншот), но есть ряд недоработок, которые в будущем, надеемся, будут устранены. Например, если сохранить выбор устройства записи (доступно только при использовании HTTPS), то потом чтобы эту настройку сбросить нужно пойти в Settings -> Advanced Settings… -> Privacy -> Content Settings… -> Media -> Manage exceptions… Нужно ли говорить, что обычный пользователь туда не доберется никогда?

    Было (Flash)


    Стало (WebRTC)


    Надо сказать, что качество звука при использовании WebRTC действительно серьезно лучше, чем во Flash. Например, в WebRTC есть полноценная автоматическая регулировка усиления (AGC, Automatic Gain Control) для микрофона, а Adobe по каким-то, видимо, религиозным причинам не стали включать столь полезную функцию. Ну и остальная часть аудио движка GIPS работает очень даже хорошо. В ближайшее время в WebRTC появится возможность использовать аудиокодек Opus, который является гибридом скайповского SILK и CELT и уже принят как обязательный для WebRTC наряду с G.711. Google уже вовсю работает над поддержкой WebRTC для мобильной версии Chrome под Android, что означает наличие серьезного будущего на мобильных платформах (в Adobe отказались от попыток продвижения и развития Flash для мобильных).

    Ну и напоследок: на WebRTC Conf & Expo было объявлено, что поддержка WebRTC будет добавлена в релизной версии Firefox 18, и произойдет это замечательное событие ориентировочно в апреле 2013. Ждем Opera, IE и Safari. Кстати, мы были непосредственными участниками конференции и даже умудрились выиграть приз, об этом постараемся написать отдельный пост.
    Voximplant
    Облачная платформа голосовой и видеотелефонии

    Похожие публикации

    Комментарии 26

      0
      Немного offtopic, но когда в вашем виджете появится возможность выбора не только микрофона, но и устройства воспроизведения?

      P.S. На большинстве сайтов использующих Zingaya загружается WebRTC версия, исключение встретилось только одно — ИБ ТКС Банка, всё ещё используется flash версия.
        +1
        Выбор устройства воспроизведения не поддерживается пока ни в WebRTC, ни во Flash. Используется устройство, которое выбрано как устройство по умолчанию в системе.
          0
          С другой стороны чрезмерная «хитрость» софта вредит — пример тому Скайп для Mac OSX. ОС и железо поддерживает телефонные гарнитуры а Скайп настаивает на выборе конкретного устройства о котором «он знает» из кое-как полученного списка звукозаписывающих устройств от ОС. При включении проводной гарнитуры (от телефона, с микрофоном) невозможно использовать ни встроенный микрофон ноутбука ни микрофон гарнитуры — собеседники ничего не слышат.
          0
          Работа над стандартом в самом разгаре, и до некой законченной версии еще далеко

          Согласно их расписанию рекомендации должны быть готовы в Q1 2013.
          Последнее серьёзное изменение было в августе, после этого они устаканивают детали.
            0
            На WebRTC Expo сказали, что рекомендация будет ближе к концу 2013 года
              0
              Я так понимаю это связано с тем, что есть зависимости от других рабочих груп (например IETF CODEC group, Device APIs & Policy Working Grou, кому интересно все зависимости можно посмотреть тут), и некоторые из них задерживаются. Судя по доступной открытой переписке, глобальных изменений вближайшее время нас не ждет.
              Если у вас есть какие-то другие сведения, было бы интересно о них узнать.
                0
                Как минимум, нет определенности с видео кодеками, со стороны W3C измнения скорее всего будут минимальными, но все равно будут — не хватает ряда методов API нужных для реализации работы со списком доступных устройств, еще не до конца определено как будут работать некоторые уже описанные методы (синхронно/асинхронно) и т.д. поэтому рекомендацию обещали к Q4
                  0
                  Кодеки и работа со списком доступных устройств — этим занимаются две другие группы. Изменения в кодеках вообще не должно коснуться public API, исключительно внутренняя реализация поддержки утвержденных кодеков, подождем обновления браузеров и ок :). Что касается работы со списком доступных устройств, то есть подозрения что это тоже не особо коснется WebRTC, все останется на уровне удаления-добавления новых медиа потоков.
                  А что еще осталось синхронного, что может приехать на асинхронный вызов?
                    0
                    Например, в Chrome 24 beta есть возможность выбора разрешения захвата с камеры и некоторых других параметров а-ля фреймрейт, а в Chrome 23 нет, так что public API может много что еще коснуться. Про синхронное/асинхронное, например, про метод getUserMedia еще до сих пор идет обсуждение.
                      0
                      А не подскажите, где почитать про эти фишки (разрешение захвата и т.д.)?
                        0
                        Где-то в Google Groups видел, попробую найти ссылку
                          0
                          Расширение захвата называется GetUserMedia, работает в последнем Chrome на всех настольных платформах.

                          Примеры реализаций: раз, два, три.
                            0
                            Вы видимо меня не поняли, меня интересует не как получить доступ к камере, этому уже сто лет в обед, а как управлять разрешением потока.
                              0
                              Ссылку так и не нашел, но код выглядит так:
                              navigator.webkitGetUserMedia({ audio: true, video: {
                                      mandatory: { maxWidth: 320, maxHeight: 240, maxFrameRate: 15 }
                                    }, ....
                              
                                0
                                2012 год, додумались дать возможность указать разрешение. Круто!

                                Ждем конструкций вида:
                                ffmpeg -i input.mpg -f mpegts -acodec copy -vcodec libx264 -level 41 -crf $CRF -bufsize 20000k -maxrate 25000k -g 250 -coder 1 -flags +loop -cmp +chroma -partitions +parti8x8+parti4x4+partp8x8+partb8x8 -flags2 +brdo+dct8x8+bpyramid -me umh -subq 7 -me_range 16 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -rc_eq «blurCplx^(1-qComp)» output.mpg

                                А то вот сейчас, к примеру, во флеше можно кодировать звук, но сделать с ним ничего нельзя. Или, можно его поправить, но и кодировать тогда тоже самому. Аналогично во флеше и с камерой — ничего нельзя настроить, кроме битрейта или абстрактного «качества».
                                  0
                                  Во флэше всю жизнь разрешение камеры настраивалось, непонятно о чем вы
                                    0
                                    Ну настройка разрешения — это и так само собой, можно даже задать кейфреймы. И все
                                    cam.setMode(320,240,25);
                                    cam.setKeyFrameInterval(5);
                                    cam.setLoopback(true);
                                    cam.setQuality(0,70);
                                    И больше ничего.

                                    А посмотрите на опции кодирования видео в ffmpeg (libavcodec), лично мне богатство опций всегда нравилось, а кодек, завернутый в какой-то абстрактный веб-интерфейс, обычно лишен тонкой настройки и теряет ряд преимуществ. Вот это неприятно.
              0
              Не знаю, а по мне все это какие-то пляски трупов.

              «Здравствуй дорогой пользователь, у нас есть инновационная WebRTC, но работать оно будет в 0.5 браузеров»

              В случае флеша, который как известно не нужен, количество обслуживаемых пользователей несколько выше.

              «ой, какая у нас клевая полосочка для подтверждения доступа, а не этот мерзкий попап флеша!» — мне честно говоря смешно читать такое, равно как и записывать это в преимущества. Если у вас такие преимущества — какие же недостатки? Завтра покрасите кнопки в красненький/зелененький и это тоже будет прорывом и инновацией?

              AGC не включили, какая плохая эта ваша адоба. А то, что многие микрофоны шумят как советский радиоприемник, порой работая как простенькое радио — с этим вы наверное не сталкивались. Ну пропустите такой сигнал через компрессор, заслушайте. Приятно? Зато сраный адоб позволяет получить доступ к семплам звука, а полученные данные скормить модулю на сишке, который сможет и пофильтровать, и сделать усиление, и даже упаковать в ЛЮБОЙ кодек. Конечно, усе это работает внутри AVM2, что скорости не прибавляет, но вполне съедобно, говорю как автор одной такой реализации.

              Лет через 15 захват семплов будет тоже работать в любом браузере, а не как сейчас в 1.5, а мощностей хватит на кодирование звука js-кодировщиком. Но это дело далекого будущего. Как и нормальная поддержка RTP, как и поддержка всех кодеков, в зависимости от их наличия в системе.

              В общем, мой выбор — говнофлеш + RTMP (которые, как известно, не нужны) для веба. Говно, но вкуснее ничего нет. А когда надо что-то стабильное — ставь милый пользователь СИП-клиент и не выпендривайся. Я правда выпендриваюсь и еще все хочу добавить поддержку мамбла, уж больно он удобен для некоторых целей, использует CELT + speex, а на входе микрофона есть достаточно клевый фильтр шума.
                0
                Chrome установлен на 35% компьютеров, скоро подтянется Firefox и станет более 50%, так что это просто вопрос времени. По поводу доступа к сэмплам и упаковке — для реалтайма это не работает. Если ваш выбор говнофлеш+RTMP, то это ваше личное дело, для нормальных реалтайм сервисов коммуникаций такая связка работает не лучшим образом.
                  0
                  Я извиняюсь, а что вообще работает? Мне нужно отправить звук на сервер, как можно ближе к реалтайму. Как это сделать? Я могу хватать семплы, самостоятельно паковать и отправлять на сервер. В случае флеша, мне доступно только TCP. Не реалтайм, но близко и без заиканий. А могу эту работу поручить самому флешу, дабы он там все сам сделал. Недостатком такого решения являются встроенные кодеки флеша — это спикс с отвратительным качеством или неллимосер, который хоть еще большее говно, зато хоть умеет честные 44 килогерца. Поэтому если брать флеш — лучше ничего не выйдет.

                  Да, флеш должен сдохнуть. Да, он не нужен. Я верю, в будущем все будет хорошо. Но СЕГОДНЯ кроме флеша альтернатив в общем-то и нет. Я правда видел уже чатики на вебсокетах, js и g711, но слушать это было несколько неприятно, да и работало это как технодемка с привязкой к конкретным браузерам (и их билдам)
                    0
                    Во Flash есть UDP-протокол, называется RTMFP. Работа с сэмплами напрямую на уровне виртуальных машин — это извращение, по крайней мере на текущем этапе развития таких реализаций. Для нормального реал-тайма код должен быть написан на более низком уровне и взаимодействовать с железом напрямую. Во Flash кроме Speex и Nellymoser есть G.711
                      0
                      вы забыли упомянуть, что в некоторых случаях происходит фоллбек обратно на ртмп, а там с реалтамом все хуже. Далее, не любой кодек выдержит потерю ракетов, кроме пожалуй г711 и некоторых специально заточенных под это дело. Выходит, нам все равно надо как-то восстанавливать стрим.

                      Работа же с семплами хоть и извращение, но по моему опыту очень даже неплохо, я даже по началу хотел сделать работу по микшированию звука на сишке и упаковать в алчеми, однако выяснилось что это не нужно и в алчеми отправился только енкодер, а микшер так и остался на ас3. Все работает, все всем вещается.

                      и да, а где вы увидели поддержку г711?
                        0
                        Во Flash с версии 11
                          0
                          Спасибо, переключил Runtime и все увидел. Правда не знаю зачем он там, «упаковать» и передать проблем нет и так.
                0
                Так а каковы подводные камни-то? А то прямо одна радость сплошная.
                  0
                  Камни — в постоянно изменяющемся стандарте и его реализации, поэтому нужно следить за изменениями и перелопачивать код, на что уходит много времени и сил.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое