Комментарии 23
Сочувствую...
Вообще по сравнению с другими альтернативами типа h323 как раз sip вообще душка.
И если начинаешь разбираться, писать роутеры и клиенты — то как то начинаешь понимать, что без многих описанных штук оно будет еще хуже.
From и To нужны для оборудования, которое не имеет памяти и делает выбор не на первом пакете.
Теги это более позднее добавление.
Также есть всякое оборудование(здравствуй, cisco) которое традиционно поддерживает «немного отличающийся» вариант, и его вносили в RFC.
А уж регистрозависимость в UA вообще странно обсуждать, каждый писал в меру своего бюджета, лишь б работало хоть с чем-то.
Вон есть IAX2 протокол, он лучше, но не взлетел ибо для оборудования в реале он хуже.
Чем именно хуже? Я подозреваю, что IAX[2] не взлетел только потому, что опоздал и что SIP успел закрепиться в 3GPP.
Ну напишите лучше.
(здесь был стрип с xkcd про 15 конкурирующих стандартов)
From и To нужны для оборудования, которое не имеет памяти и делает выбор не на первом пакете.
Теги это более позднее добавление.
Реально такого оборудования сейчас нет (если мы про RFC3261, а не про, например, RFC2543, и то — придёт INVITE якобы с существующим звонком, когда такого нет, что вы будете с таким stateless делать? верить входящему?)
От того, что теги — более позднее добавление, не значит, что их надо было вписывать в эти From и To.
А уж регистрозависимость в UA вообще странно обсуждать, каждый писал в меру своего бюджета, лишь б работало хоть с чем-то.
В том и дело, что когда начинается 1000 возможностей выбрать любую форму, пойдут конфликты реализаций, закрепившихся на одном конкретном варианте. Ну и зачем?
Также есть всякое оборудование(здравствуй, cisco) которое традиционно поддерживает «немного отличающийся» вариант, и его вносили в RFC.
Про '#' в username есть какой-нибудь RFC?
"Чем именно хуже? Я подозреваю, что IAX[2] не взлетел только потому, что опоздал и что SIP успел закрепиться в 3GPP."
Он вообще — бинарный… та еще дичь
Он вообще — бинарный… та еще дичь
Ну сама по себе бинарность не дичь. Вон IP и TCP бинарные, и видеть на их месте текстовый протокол — думаю, никакая фантастика не позволит :)
С другой стороны, "совсем текстовые" ужасны по-своему.
В этом плане, как ни странно, неплох JSON. Текстовость, но при этом можно отрезать все возможности начудить...
Ах, если бы... Так что только CBOR (да, к 2013 IETF уже смог родить почти идеальный формат).
Ну напишите лучше.
(здесь был стрип с xkcd про 15 конкурирующих стандартов)
Автор, вы маньяк. Вам не нравится готовая реализация, и вы не желаете делать новую, «потому что засмеют». Так вы слона не продадите, да.
Вообще, поднята проблема всех начинающих разработчиков — они столкнулись с тяжёлым наследием прошлого и громко заплакали. Но дело в том, что либо вы кушаете «это» ложками, либо делаете своё. Других вариантов нет. Вас для того и наняли, что бы вы это разгребали. То есть нет кого-то другого, кто бы это за вас сделал. В широком смысле вы нигде не будете иметь радость ничего не делать и получать одни удовольствия (ну если вы не дочь олигарха, разумеется). Поэтому, как уже писали в комментариях здесь — одеваем противогаз, берём лопату и разгребаем нечистоты. И даже способ вам предложили — сделайте своё, чистое, непахнущее. Но вам 15 стандартов помешали…
Автор, вы маньяк. Вам не нравится готовая реализация, и вы не желаете делать новую, «потому что засмеют». Так вы слона не продадите, да.
Скорее реалист. Новый стандарт может вводиться (так, чтобы выжил) в одном из трёх случаев:
Открылась новая ниша, и её надо закрывать. Это самый типовой случай, навскидку процентов 90. При этом, как правило, реализацию делают люди, которые имеют опыт в этой нише, но не общий архитектурный опыт, и соответственно делают примерно столько же ошибок с такими же последствиями, как при разработке того же SIP.
Часто при этом, пока ниша не занята, возникают несколько стандартов, а затем начинается интересная борьба между ними. Но это пока ещё можно втиснуться в ту нишу.
Принцип NIH говорит, что все существующие решения имеют фатальный недостаток и надо делать своё. Примеров полно — и в статье по ссылке, и за пределами. Вот недавно IETF выпустила своё Concise Binary Object Representation. На рынке их уже, наверно, сотня, включая ASN.1 со всеми BER/XER/etc., protobuf, gRPC, но им нужен свой. Но IETF толстая контора, у неё получится. На это я дам ещё 9%.
Новый стандарт имеет действительно принципиальное преимущество над старыми. На это дам 1%, такие случаи реально редчайшие.
Новые ниши рядом ходят, да. Про них отдельный разговор, не сейчас. Но мы все живём с технологиями местами 60летней давности.
Вообще, поднята проблема всех начинающих разработчиков — они столкнулись с тяжёлым наследием прошлого и громко заплакали.
А вы переводите на несуществующие эмоции ("заплакали") — я не плачу, я ворчу :)
Я никак не отношусь к "начинающим разработчикам" — только этот продукт я начал вести в 2004-м. С перерывами потом, да. Вопрос не в плаче или не плаче самом по себе — а в том, что я показываю набор ошибок, которые не надо повторять.
И даже способ вам предложили — сделайте своё, чистое, непахнущее.
"Мышки, станьте ёжиками".
Это тоже было. И позволяет с высоты сравнения со своим "чистым непахнущим" (которое на самом деле тоже страдает сотнями запахов) оценить ошибки и делать выводы.
Про своё тоже когда-нибудь расскажу… но это небыстро.
И далее вы приводите «случай №2», который по сути есть разрешение бегемотам делать то, что они хотят. Но как раз бегемоты и сделали SIP. И как раз вы этим недовольны. Так какая же из ваших мыслей «правильная»?
>> Новый стандарт имеет действительно принципиальное преимущество над старыми. На это дам 1%, такие случаи реально редчайшие.
И вот опять — вам же не нравится SIP? Или всё поменялось за один день? Или вот именно SIP (а с ним и всё дерево станадартов с корнями в RFC822), это как раз и есть 1%? Вы точно в этом уверены? А если посчитать?
>> Но мы все живём с технологиями местами 60летней давности.
О да, я как раз про это вам говорил в предыдущем комментарии. Но вы же вроде были несогласны? Или весь ваш ответ — это такая форма подачи полного одобрения мною сказанного?
>> Вопрос не в плаче или не плаче самом по себе — а в том, что я показываю набор ошибок, которые не надо повторять.
И при показе вы всё же продолжаете настаивать — нет новому стандарту! Но тогда чему быть? Как устранить косяки конструкции не меняя стандарт на подобные изделия?
В целом выше показан набор противоречий, которые никак не дают мне возможности назвать ваш подход хоть сколько-нибудь стоящим. Да по сути подхода вообще нет, есть одно ворчание ((с) ваш).
Попробуйте кратко сформулировать предлагаемый вами путь выхода из ситуации, на примере SIP-а, но с пониманием, что точно такая же ситуация присутствует везде. И попробовав, вы наверняка сами поймёте, что в статье вы ничего не предложили, а только и исключительно ворчали. И так же поймёте, что никто за вас исправлять это не будет. Ну и, вполне возможно, осознаете простую истину — надо взять лопату и начать копать. И перестать ворчать.
И далее вы приводите «случай №2», который по сути есть разрешение бегемотам делать то, что они хотят. Но как раз бегемоты и сделали SIP.
SIP — это случай 1, а не 2. Иначе бы он был прямее (just IMHO).
И вот опять — вам же не нравится SIP? Или всё поменялось за один день?
Да, не нравится. Нет, не за один день.
И при показе вы всё же продолжаете настаивать — нет новому стандарту!
Нет (в смысле, не получится) именно в этой нише. Но может получиться в новой.
Цель написания — показать, как не надо делать, чтобы не плодилось такого нового — там, где его будут создавать.
В продолжении я надеюсь раскрыть эту цель подробнее.
Принцип NIH говорит, что все существующие решения имеют фатальный недостаток и надо делать своё. Примеров полно — и в статье по ссылке, и за
пределами. Вот недавно IETF выпустила своё Concise Binary Object
Representation. На рынке их уже, наверно, сотня, включая ASN.1 со всеми
BER/XER/etc., protobuf, gRPC, но им нужен свой. Но IETF толстая контора,
у неё получится. На это я дам ещё 9%.
Вообще-то как раз тот случай, когда действительно сделали хорошо, и лучше, чем все те альтернативы. За ASN.1 в нашем веке надо расстреливать. Всякие protobuf, gRPC - фактически проприетарны (не сообщество определяет). BSON, MsgPack - не имеют вменяемой возможности расширений. Ну да собственно там в RFC есть секция, где описаны критерии, и это большая ниша - я еще в 2009 хотел себе подобный формат, как в текстовой версии фревого netgraph, и его к счастью таки родили. На двадцать лет позже нужного (SCTP вот тоже припозднился), но куда деваться.
интерпретаторах вроде Python, и на Java на строках, это превращается в чудовищную затрату или времени, или памяти, или обоих сразу.
А почему не использовать реализацию на Си в Python или Java? Просядет у Вас немного производительность на GIL и все. В JNI скорее всего попадает виртуалка при отладке. Чего изобретать SIP стеки, которых сегодня написано уже десятки.
Чего изобретать SIP стеки, которых сегодня написано уже десятки.
Этому конкретно стеку скоро 20 лет. И переходить с него сложнее, чем развивать. Для многофункционального B2BUA требования по стеку резко другие, чем для конечного UA (а ~90% стеков в лучшем случае обеспечивают режим конечного UA) или прокси. Другие… я собрался постепенно подбираться к этому, но из открытых сейчас более-менее приличный только один — resiprocate. Остальные из этих десятков реализуют 1-2 типовых сценария и менее 1% всех особых случаев и специфик.
А почему не использовать реализацию на Си в Python или Java? Просядет у Вас немного производительность на GIL и все.
В обоих случаях — цена сопровождения полученного результата слишком высока.
Остальные из этих десятков реализуют 1-2 типовых сценария и менее 1% всех особых случаев и специфик.
Как минимум там уже решен вопрос разбора SIP сообщений, который в статье активно пытаетесь реализовать.
В обоих случаях — цена сопровождения полученного результата слишком высока.
Так вы пытаетесь удешевить серверные решения? А почему не возьмете готовый Asterisk или FreeSwitch? Они уже готовы и работают.
Как минимум там уже решен вопрос разбора SIP сообщений, который в статье активно пытаетесь реализовать.
"Как минимум" он решён неполно и в большинстве случаев некорректно. Это же касается и Asterisk и Freeswitch (Asterisk вообще ужасен в этом смысле, Freeswitch тоже чуть получше, но не то).
А почему не возьмете готовый Asterisk или FreeSwitch? Они уже готовы и работают.
На их основе нужное не строится в принципе.
«Как минимум» он решён неполно и в большинстве случаев некорректно.
А вот с этого места расскажите по подробнее. Что в Asterisk, а точнее в pjlib реализовано неполно или некорректно, а точнее не так как это описано в RFC? Это результаты опытов и изысканий? Неполно относительно вашего бизнес решения?
Sofia библиотека используемая в FreeSwitch от компании Nokia дает различные слои от парсера SIP сообщений и до абстракций вроде UA. Хотите ветвитесь, а хотите городите свое решение поверх. Единственный недостаток это проступающая поддержка стандартов сотовой связи, но и это можно отключить флагами или выпиливанием.
Сегодня полным полно готовых реализаций при крупных компаниях, которые активно инвестируют в разработку и актуализацию этих стеков. В качестве академического исследования в институте этот код подойдет, но в реальном мире без штата инженеров и хорошего такого запаса денег и времени это же просто огромные объемы работ. Вы в одиночку просто обрекаете себя на годы разработок.
Если так претит реализация на C подобных языках, то есть почти рабочая реализация JsSIP на Node. Вы ее смотрели?
мда, я так же столкнулся, сказал что думал, мнения не изменил, одел распиратор и взялся за лопату...
Вы, получается, ругаете протокол и его разработчиков за то, что какие-то вендоры от него отклоняются. И за то, что он реализует/учитывает уже устоявшиеся стандарты и соглашения, типа регистронезависимости хоста и канонической формы пользователь: пароль@система.
Вы, получается, ругаете протокол и его разработчиков за то, что какие-то вендоры от него отклоняются.
В данном случае за провокацию этого отклонения. Полная реализация весьма сложна, требует достаточно нестандартных (как для отрасли) подходов, плохо ложится на существующие механизмы и потому чревата огромным количеством ошибок и дыр.
В продолжениях (надеюсь, что хватит пороху) будет ещё примеров на других слоях логики.
И за то, что он реализует/учитывает уже устоявшиеся стандарты и соглашения, типа регистронезависимости хоста и канонической формы пользователь: пароль@система.
Хост я зацепил вскользь (и только в соответствующем типе адресного параметра, который достаточно редок). А вот какие "устоявшиеся стандарты и соглашения", по-вашему, требуют регистронезависимости имён параметров и особенно значений параметров (таких, как теги)?
Это автор ещё про конференции не рассказал и subscribe
По этому под сип не так много либ, по этому реализации разных вендоров в sip по разному иногда взаимодействуют, по этому программные сип клиенты с кастомными либами обычно боль и содомия, по этому sip-alg на роутерах обычно часовая бомба. Хочешь немножко поржать, это все нормально, жить можно. Посмотри на T38)
Привычный ужас в SIP, или о том, как не надо проектировать сетевые протоколы. Часть 1 — синтаксис и морфология