Comments 39
Ну, революцией это называть слишком громко, есть аналоги и на Flash, который ещё не умер. А поддержка WebRTC настолько узка, что её даже и на CanIUse ещё нет.
Flash с SIP нормально и напрямую еще не работал, что толку, что голос и видео в WEB на флеш, а все корпоративные сервера на SIP?
Кстати, случайно наткнулся на RTMP модуль для FreeSwitch. Получается, что напрямую. Появилось чуть больше года назад.
Давно ждал и следил за проектом.
Считаю, что в некоторых проектах этот вариант вообще единственный, например, на айпад.
Считаю, что в некоторых проектах этот вариант вообще единственный, например, на айпад.
UFO just landed and posted this here
Аллиуя! Наконец то мои мечты сбылись!
А в asterisk есть поддержка websocket?
А зачем в asterisk поддержка websocket? SIPML5 это клиент к серверу он подключается по протоколу SIP
SIPML5 подключается по протоколу SIP, который работает поверх протокола WebSocket, который работает поверх TCP, ну т.д.
Вашу мысль понял, насколько знаю поддержки нету, но думаю добавить ее не особо сложно, только есть ли смысл в итоге все равно же будет преобразование WebSocket<-->SIP на стороне Asterisk, при общении с клиентами использующими SIP протокол. Вообще есть уже проекты работающие на WebSocket и взаимодействующие с AMI Asterisk.
Конечно, добавить не сложно, websocket — простой протокол. Но без него SIPML5 работать не сможет, он подключается к серверу по websocket. Преобразования не будет, websocket — это транспортный уровень для SIP.
Положу здесь ссылку на релевантный пост, там есть пара полезных ссылок.
Положу здесь ссылку на релевантный пост, там есть пара полезных ссылок.
Тоесть вы хотите чтобы можно было миную стороний веб сервер, напрямую подключатся к Asterisk? Ну да такой вариант тоже можно расматривать только опять же на хосте где работает Asterisk поднять тот же web-server дело минутное!
Нет, я не об этом. Веб сервер не должен никуда подключатся, вся прелесть в том что он отдал хтмл и расслабился, все действие происходит на клиенте. У js клиента есть только один способ установить соединение с SIP сервером — websocket.
Набросал на скорую руку небольшое пояснение.
Ждем, ждем. Судя по динамике разработок и общему интересу к sip_в_браузере, к концу года в релизных ветках chrome и firefox уже будет поддержка WebRTC.
Вообще надо ждать пока примут вот это — datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket/
Тоесть мост все таки понадобится… WebSocket…
Нет, websocket не мост, websocket транспортный протокол как TCP и UDP.
— WebSocket работает поверх TCP (http://ru.wikipedia.org/wiki/WebSocket)!
— Чтобы подключится по протоколу SIP через WebSocket понадобится мост!
Вот что я хотел сказать…
— Чтобы подключится по протоколу SIP через WebSocket понадобится мост!
Вот что я хотел сказать…
Вы не правы, «мост» не понадобиться. Из того что WebSocket работает поверх TCP/TLS нельзя сделать вывод про «мост».
Выше я вам дал ссылку на draft-ibc-sipcore-sip-websocket-02, в ней WebSocket объявлен протоколом транспортного уровня для SIP, наравне с UDP/TCP/TLS.
Вот что я хотел сказать.
Выше я вам дал ссылку на draft-ibc-sipcore-sip-websocket-02, в ней WebSocket объявлен протоколом транспортного уровня для SIP, наравне с UDP/TCP/TLS.
Вот что я хотел сказать.
То есть я прямо сейчас могу с помощью SIPML5 подключится к любому SIP серверу?
Не можете, т.к. основная масса SIP серверов ничего не знают про WebSocket.
Вместо «мост» надо использовать понятие SIP Proxy — вот что нужно. Нужна СИП прокся, которая принимает SIP по протоколу WebSocket и потом переправляет (проксирует) эти ппакеты дальше, по TCP или UDP, на старый добрый SIP сервер, не поддерживающий WebSocket.
Вместо «мост» надо использовать понятие SIP Proxy — вот что нужно. Нужна СИП прокся, которая принимает SIP по протоколу WebSocket и потом переправляет (проксирует) эти ппакеты дальше, по TCP или UDP, на старый добрый SIP сервер, не поддерживающий WebSocket.
PS: В том документе что вы указали прямо написано: «It is inappropriate to use Internet-Drafts as reference material or to cite them other than as „work in progress.“
Я конечно же вас понимаю… Вполне возможно что через годик этот документ примут но это еще не означает что все так и бросятся реализовывать это у себя в серверах… А к конечному пользователю это приплывет ой как не скоро…
Это конечно же мое ИМХО но ошибки в своих утверждения я не вижу.
Для использования этого клиента понадобится мост… Я не гуглил но уверен что такая тулза уже есть или будет написана в самое ближайшее время. И таких приблуд еще будет вагон.
За сем откланяюсь и попрошу не разводить холивар на пустом месте. Вашу точку зрения я услышал.
Я конечно же вас понимаю… Вполне возможно что через годик этот документ примут но это еще не означает что все так и бросятся реализовывать это у себя в серверах… А к конечному пользователю это приплывет ой как не скоро…
Это конечно же мое ИМХО но ошибки в своих утверждения я не вижу.
Для использования этого клиента понадобится мост… Я не гуглил но уверен что такая тулза уже есть или будет написана в самое ближайшее время. И таких приблуд еще будет вагон.
За сем откланяюсь и попрошу не разводить холивар на пустом месте. Вашу точку зрения я услышал.
Да пожалуй и я исчерпал аргументы, все ссылки на стандарты я привел. Ссылка на публичные SIP сервера с поддержкой WebSocket есть в статье.
Ваши домыслы комментировать не буду.
Ваши домыслы комментировать не буду.
Внимательно смотрим на картинку, на верхний блок, в нем написано SIP Proxy — то есть SIP сервер (пусть слово proxy вас не смущает см.rfc3261). Дальше смотрим стрелочку UDP/TCP/TLS — это коммуникация с другими SIP серверами, ничего не обычного, тоже самое делают сервера без websocket, см. rfc3261. Дальше смотрим, этот сервер еще умеет общаться с PSTN, хорошо, но ничего не обычного, как asterisk. То есть это самый обычный SIP сервер, ед-ное отличие — websocket.
Да, с публичный серверами я возможно и погорячился.
Да, с публичный серверами я возможно и погорячился.
Ну «proxy» там слово не зря, а потому что так и есть. Обычные сервера не понимают WebSocket и еще долго не будут понимать…
То что конкретно их реализация поддерживает этот драфт означает только одно: они молодцы…
И в итоге либо ты будеш использовать приблуды(мост) либо будеш переходить на их сервер. Оба варианта сомнительны.
То что конкретно их реализация поддерживает этот драфт означает только одно: они молодцы…
И в итоге либо ты будеш использовать приблуды(мост) либо будеш переходить на их сервер. Оба варианта сомнительны.
Я настаиваю: см. rfc3261 там все написано про слово proxy — это одна из ролей любого из известных сейчас SIP серверов.
>То что конкретно их реализация
Их реализация чего? «Моста» или SIP сервера!?
>И в итоге либо ты будеш использовать приблуды(мост)
Я не буду :)
>Опять же их замечание на сайте
Причем здесь это, хотите сменить тему?!
>То что конкретно их реализация
Их реализация чего? «Моста» или SIP сервера!?
>И в итоге либо ты будеш использовать приблуды(мост)
Я не буду :)
>Опять же их замечание на сайте
Причем здесь это, хотите сменить тему?!
http://en.wikipedia.org/wiki/Protocol_bridge
Вот что такое мост, а что такое Stateless SIP Proxy вы уже похвастались что знаете.
Ну и в чем я не прав?
Вот что такое мост, а что такое Stateless SIP Proxy вы уже похвастались что знаете.
Ну и в чем я не прав?
Я не хвастался (хотя :) я даже знаю что такое statefull proxy), просто для меня rfc — это аргумент/факт, а википедия — ну можно глянуть, что там люди пишут. Но это именно по этой конкретной теме, если бы мы обсуждали жирафов, я бы тоже с вики ссылки приводил.
Ну открыл вашу ссылку, вижу в первой строчке:
A Protocol Converter is a device used to convert standard or proprietary protocol of one device to the protocol suitable for the other device or tools to achieve the interoperability.
И о чем мне должно сказать, это вообще про железяки и embedded?!
Но вы продолжайте штудировать информацию, советую больше все же налегать на rfc, или статьи на профильных сайтах, википедию не советую. Должна же быть какая-то польза от этого спора.
Ну открыл вашу ссылку, вижу в первой строчке:
A Protocol Converter is a device used to convert standard or proprietary protocol of one device to the protocol suitable for the other device or tools to achieve the interoperability.
И о чем мне должно сказать, это вообще про железяки и embedded?!
Но вы продолжайте штудировать информацию, советую больше все же налегать на rfc, или статьи на профильных сайтах, википедию не советую. Должна же быть какая-то польза от этого спора.
Все что вы делали это придирались к словам и терминологии.
Как жаль что мозга у вас все таки не проявилось.
И нихрена это не RFC это гребаный DRAFT в IETF так вот прочтите хотя бы первую его страницу и все поймете, хотя я сомневаюсь.
Троллинг удался… и каждый раз думаешь что общаешься с умным человек для которого в споре не кто прав, а где правда, а оказывается гребаный тролль который втягивает тебя в непонятно что.
Как жаль что мозга у вас все таки не проявилось.
И нихрена это не RFC это гребаный DRAFT в IETF так вот прочтите хотя бы первую его страницу и все поймете, хотя я сомневаюсь.
Троллинг удался… и каждый раз думаешь что общаешься с умным человек для которого в споре не кто прав, а где правда, а оказывается гребаный тролль который втягивает тебя в непонятно что.
Опять же их замечание на сайте:
«Please note that the server application is currently a bleeding edge proof-of-concept implementation»
Ну и как такое в продакшн?
«Please note that the server application is currently a bleeding edge proof-of-concept implementation»
Ну и как такое в продакшн?
В Asterisk 11 обещают поддержку WebRTC — blogs.digium.com/2012/05/23/asterisk-11-webrtc/
Sign up to leave a comment.
SIPML5 — SIP клиент для браузера на базе WebRTC