Pull to refresh

Comments 11

Вы описали пример в котором sip:petr@mydom.org совершает звонок пользователю sip:ivan@domain.ru, при этом в примере нет промежуточных proxy серверов. В реальной жизни клиентам не назначают доменные имена с корнями (org, ru), правильнее на мой взгляд в вашем случае указывать IP адреса, хостов. Это я для того что-бы новички не путались. А статья отличная, спасибо, ждем продолжений.
Взаимодействие через Proxy будет во второй части. Спасибо на добром слове.
Спасибо большое за статью! Как раз то, что нужно и очень доходчиво. Жду продолжения!
Одна из фундаментальных проблем SIP-а в том, что это нагормождение различных костылей. Эйфелева башня из костылей. Одна треть костылей устарела, другая треть — никогда не используется. Я занимаюсь VoIP с 1999 года и убедился, что никто из разработчиков — ни клиентов, ни серверов — целиком не понимает всего стэка. А, по правде говоря, никакого стэка и нету. Есть просто десятки разрозненных документов и какие-то реализации.

> Детальное описание работы протокола SDP заслуживает отдельной статьи

Ох, как это знакомо :)
Во всех подобных статьях и книгах про VoIP очень много внимания уделяется SIP-у, а про SDP и RTP никто не пишет — видимо, уже здоровья не хватает :)
На самом деле реальный кошмар и хаос — это не сам SIP, а SDP и (как правило, кривые) реализации медиа-части в клиентах и серверах.
Постараюсь про SDP и RTP тоже написать — сам лучше начинаю разбираться, когда пишу.
А что вы предлагаете взамен с эквивалентным функционалом? H323 ещё страшнее.
Да что тут предложишь…
Жалкое зрелище… Душераздирающее зрелище… Кошмар! © Ослик Иа
На самом деле эта проблема возникает в результате отсутствия соответствующих встреч / семинаров разработчиков. Я задумывался над организацией докладов, но дальше мыслей дело увы пока не пошло, постараюсь все таки реализовать задуманное в ноябре/декабре. Думаю всем будет полезно послушать и пообщаться.
Совершенно согласен. Один только парсинг синтаксиса SIP чего стоит, для этого нужно применять «тяжелую артиллерию» в виде всяких Yacc и т.п. Далее, нагромождение всяких «branch», «tag», которые необходимо отслеживать. Плохая поддержка NAT, а ведь во время разработки этих протоколов (по меньшей мере второй версии) многие клиенты уже сидели за NAT. И главное — с какой целью все эти сложности? Нужно всего лишь сообщить «провайдеру», что мы хотим позвонить такому-то абоненту, дайте нам его IP-адрес и порт. Про SDP вообще молчу. Еще один синтаксис, еще один парсер. И самая главная информация — IP-адрес абонента и порт — кодируется в нем ну очень уж неочевидно.

Единственный нормальный протокол в этой системе — RTP. Он несколько избыточный, но не смертельно. Реализовывать поддержку RTP сложно, особенно приемник, но это проблема не RTP, а фундаментальное свойство решаемой задачи передачи сигнала в реальном времени.
Что касается NAT, если дойдут руки, то опишу ICE, STUN и TURN.
Какую поддержку NAT вам надо? На правильных серверах все и так работает замечательно. Если у вас исключительно примитивные потребности «позвонить», то это не значит что всем остальным тоже ничего не надо.
Sign up to leave a comment.

Articles