asterisk.ru

10й слайд этой презентации как раз ведет на страницу блога, которую я использовал для настройки.

Наконец дождался ошибки(если ничего не предпринимать во время звонка):
WARNING[28794]: chan_sip.c:4164 retrans_pkt: Retransmission timeout reached on transmission 5d88adf5-b5bc-ee04-655f-333eeaae771a for seqno 46643 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/ ... nsmissions
Packet timed out after 32000ms with no response

но после добавления nat=yes,force_rport рвать звонок перестал. хотя звук не появился

ага, надо пробовать без роутера.

На тестовой странице http://sipml5.org/call.htm звук есть у кого-нибудь?

там куча ньюансов начиная от версии хрома/ff, заканчивая особенностями ната и версией патча под астер. вкратце - астер и webrtc работает раком (особенно media-path и ее discovery) и эту тему дижиуму придется еще пилить не один год. единственно рабочий вариант - использовать webrtc2sip [ http://www.webrtc2sip.org/ ] с медиа-кодером для экзотических вариантов.

Это да, в WebRTC намудрили всяких премудростей.

1. Без ICE работать не будет (как я вычитал в гуглогроуп).
2. Они все стараются передавать по одному RTP потоку. И видео с аудио (разные ssrc в RTP пакетах) и rtcp там-же (rtcp-mux)
Отмазываются они это тем, что, если звук и видео идет в одном потоке, то отставание одного от второго - будет минимально.

Попробовал тут jssip под канарейкой, долго с круглыми глазами смотрел на SDP
ICE транспорт от pjsip, кстати отработал как media транспорт более-менее, если пропатчить его на предмет поддержки RTP/AVPF и RTP/SAVPF.
Вот дальше не реализовано ни rtp-mux, ни раскидывание по media stream в зависимости от ssrc

1. Компилю/ставлю srtp-1.4.4
Все верно?

* Машина в инет смотрит напрямую(для теста). Начинаю звонить через хром 24й, на внутренний экстеншн с Playback'ом и Hangup'ом. Звука нет. В дебаге тот самый РАНДОМ.invalid.

Здесь http://code.google.com/p/sipml5/wiki/Asterisk такая же фигня, но некоторые пишут: "все круто, видео притормаживает" ... ппц

астер по жизни ложился от directmedia видео - связано это с неумением разрабов грамотно обрабатывать скоростные входящие медиа-потоки. там же лежит патч, который немного фиксит VP8 pass-through, но это по-любому мертвому припарка (стоит загрузить его какими-то 10 абонентами)