Странно, почему на Эрланге нет полноценного SIP стека, включающего RTP, RTSP, RSVP и другие сопутствующие протоколы? Эрланг же конкретно должен быть заточен под подобные телефонные применения...
YXA в пример можно не приводить, т.к. реализации RTP в ней нет. А без этого она не является полноценной телефонной SIP библиотекой. Да и разработка этого проекта заглохла несколько лет назад. Она (уха) даже не собирается под последними релизами Erlang/OTP.
Ну нет стека, так нет.. Начал делать свой :). Уже работает регистрация и исходящие вызовы.
Мой стек: https://github.com/idubrov/siperl
Более-менее работают: синтаксис, транспорты (TLS, правда, нет), транзакции
Худо-бедно работают: UAC/UAS
Совсем грустно: диалоги, сессии
А у тебя что за стек? Опен-сорс или закрытый?
Пока проект закрытый, а даль?е видно будет :).
Я от диалогов и сессий ре?ил вообще отказаться, в том виде, в котором они в RFC описаны. ?МХО - сли?ком спецификация диктует подход к имплементации. Можно все сделать гораздо проще и нагляднее. Да и сама спецификация сильно смахивает на чью-то диссертацию - подробностей много, но в основном они между собой не согласованы :).
Если коротко, то у меня диалоги, сессии и части UAC и UAS сгруппированы в единую сущность - некие свои сессии.
А вот транспортный уровень остался. Но разбор и формирование SIP-сообщений отличается от спецификации, т.к. она сама себе противоречит во многом.
До TSL тоже пока не добрался.
При?ел к выводу об ущербности моей реализации, она не может быть использована во всех вариантах взаимодействия. Наверно правильно все-таки делать, как ты.
Спецификация, конечно, пипец как написана...
Не понимаю - может ли в пределах одной сессии быть несколько диалогов? Если да, то в каких случаях?
Но еще боль?е убивает книга Гольд?тейна "Протокол SIP"... Перевести RFC3261 постарались, а понять ее смысл - нет! :)
Про диалоги и сессии можно почитать две RFC: http://tools.ietf.org/html/rfc5057
http://tools.ietf.org/html/rfc6337
Сессия идентифицируется диалогом. Т.е одна сессия -> один диалог (но диалог может быть и без сессии).
Ага, спасибо, почитаю.
Еще книгами по SIP закупился, изучаю.
Кстати, переделал все на транзакции и диалоги. Стало выглядеть гармоничнее.
>Кстати, переделал все на транзакции и диалоги. Стало выглядеть гармоничнее.
Я весь мозг сломал, так и не придумал, как это красиво реализовать. Хочется с одной стороны реализовать по-максимуму во фреймворке (чтоб пользователи фреймворка не заморачивались с какими-то тонкостями), но в тоже время гибко (например, в плане выбора желаемого сценария offer/answer).
А пользователям фреймворка какие функции должны быть доступны? Наверное надо традиционно здесь подойти - предположить несколько конкретных юзкейсов и для них заточить фреймворк. На все случаи жизни все равно не получится сделать.
Я сейчас делаю под клиентский терминал. На прокси пока не замахиваюсь. Поэтому все вообще не сложно. Но жду, что когда закончу, появится понимание функциональности SIP-серверов.
Актуальная тема! На YXA (http://www.stacken.kth.se/project/yxa/)
не смотрели, коллеги?
Смотрели. 1 пост :).
Недавно был выбор - уху заюзать или свое написать. Остановился на своем. К ухе описания API нет, а поэтому пока буде?ь с ней разбираться... быстрее свою реализацию сделать.
Насколько я понял, YXA - это прокси-сервер, а не фреймворк. Последствия: например, SIP терминал из нее сделать тяжело.
Ага. Понял. Недосмотрел про YXA в первом посте.
Сори за глупый пост. Утром подняли, а разбудить забыли. :(
Еще предлагаю обсудить подходы к реализации SIP-рас?ирений (Хотя еще с сессиями и диалогами все до конца не ясно :)).
Например, начнем с заголовка "replaces".
На каком уровне делать рас?ирения? Если так:
Делаем некий диспетчер рас?ирений. К нему может обратиться сессия, чтобы запросить список поддерживаемых рас?ирений и чтобы запустить выбранное рас?ирение. А рас?ирение в процессе работы начинает дергать методы сессии, заставляя ее открывать новые диалоги, закрывать или модифицировать существующие.
Должно получиться?
Вопрос про TCP транспорт.
Предположим, есть диалог, в ходе которого отправляем несколько запросов и получаем несколько ответов. Предположим, выполнены все условия для использования протокола TCP.
Все эти сообщения должны ходить по одному соединению? ?ли для каждой пары запрос-ответ отдельное TCP-соединение устанавливать?
Для запросов следует (RECOMMENDED) переиспользовать соединение, но можно и новое открывать, RFC 3261 18.1.1. Кажется, есть более новые RFC, уточняющие переиспользование соединений.
Ответы обязательно посылать по тому же соединению (если оно ещё открыто), RFC 3261 18.2.2.
Диалоги ортогональны транспортам, т.е никак не влияют на логику.
Резюмируя... можно сделать как хочется. Хоть в одном соединении, хоть в нескольких :).
Думаю сделать транспортный уровень так: все входящие сообщения через одно горло пропускать, где сопоставлять их транзакциям по call-id, branch и т.д.. Не задумываясь о том, из какого именно соединения и из какого транспорта (UDP, TCP,...) данное сообщение было получено.
Вы должны войти в систему, чтобы оставлять сообщения.