Тема: голосовой трафик через АТС
При чём здесь SIP?
Где Вы в этой ветке увидели хоть что-либо о SIP ?Это вирус такой. Он везде!
😊
Zavr2008- простите, в соседней теме я Вас защищаю, но в данной Вы явно пишите не в тему.
В данной теме SIP даже близко не пробегал.
Давайте не создавать прециденты для баталий. - Просто отвечайте по теме. Сейчас Ваши посты совершенно не в тему...
Это вирус такой. Он везде!
Zavr2008- простите, в соседней теме я Вас защищаю, но в данной Вы явно пишите не в тему.
В данной теме SIP даже близко не пробегал.
Давайте не создавать прециденты для баталий. - Просто отвечайте по теме. Сейчас Ваши посты совершенно не в тему...
сохраню для истории 😊
в начале диалога в связке SIP Client 1 <-> SIP Server <-> SIP Client 2 оконечные устройства посылают RTP через сервер
В начале диалога нет обмена RTP-трафиком. Диалог ведётся SIP-сообщениями, а не RTP-пакетами.
в начале диалога в связке SIP Client 1 <-> SIP Server <-> SIP Client 2 оконечные устройства посылают RTP через сервер
В начале диалога нет обмена RTP-трафиком. Диалог ведётся SIP-сообщениями, а не RTP-пакетами.
Алексей, а от куда ему об этом знать?
Zavr2008, манагер по продаже шлюзов. Ему написали список из умных слов, вот он и пытается вставлять эти умные слова в посты по принципу, ” а может угадаю”.
Бугага.
Читайте между строк: естественно если речь идет о SIP то сигналлинг по нему и идет.
Я писал про media и про ситуацию когда после начала звонка сначала все ок, а потом через 20-60 сек перестает доходить голос.
В этом случае rtp начинает идти после INVITE по одной схеме, после reinvite - в режиме p2p. Теперь я доходчиво объяснил?
Вот немного по теме: http://asterisk-pbx.ru/wiki/doku.php/nat
Первый абонент запрашивает соединение у второго , сообщая свой IP адрес. Второй отвечает, сообщая свой IP. Голосовые пакеты направляются напрямую абонентам, минуя SIP сервер. Передача голосовых пакетов напрямую абонентам, минуя Asterisk, называется RE-INVITE или Native Bridge.
NAT может вызвать проблемы в нескольких местах.
Если одна из АТС находится за NAT, другая АТС не сможет связаться с ней, без проброса портов.
Если телефон находится за NAT, голосовые пакеты могут быть направлены на немаршрутизируемый адрес в сети, что приведет к потере звука.
Zavr2008 - Может так?
Речь чтоль про MGCP?
Ну каким боком SIP тут вообще вылез???
Почитай RFC 3261 и разруха в голове пройдет.
Коротко: в начале диалога в связке SIP Client 1 <-> SIP Server <-> SIP Client 2 оконечные устройства посылают RTP через сервер. Далее когда сервер понимает, что медиа-потоки могут идти и напрямую, снижая нагрузку на сервер он их коммутирует прямоходом. При этом направления Remote Part соединений - меняется. Ну и возникают все проблемы с NAT..
Причин с NAT - много: неправильная маршрутизация, наличие роутеров Dlink с гнилым SIP ALG, неправильные правила SNAT и DNAT, кривость реализации методов REINVITE в оконечном обопрудовании. Рекомендуется просто отключить этот режим и не париться.
Zavr2008, с удовольствием прочту эту сказку в первоисточнике. Укажите, пожалуйста номер раздела RFC 3261, где это описано.
Почитай RFC 3261 и разруха в голове пройдет.
Коротко: в начале диалога в связке SIP Client 1 <-> SIP Server <-> SIP Client 2 оконечные устройства посылают RTP через сервер. Далее когда сервер понимает, что медиа-потоки могут идти и напрямую, снижая нагрузку на сервер он их коммутирует прямоходом. При этом направления Remote Part соединений - меняется. Ну и возникают все проблемы с NAT..
Причин с NAT - много: неправильная маршрутизация, наличие роутеров Dlink с гнилым SIP ALG, неправильные правила SNAT и DNAT, кривость реализации методов REINVITE в оконечном обопрудовании. Рекомендуется просто отключить этот режим и не париться.Zavr2008, с удовольствием прочту эту сказку в первоисточнике. Укажите, пожалуйста номер раздела RFC 3261, где это описано.
Да-да, чертовски согласен с Михаилом. Мне вообще интересно узнать, как это случается, что ”когда сервер понимает, что медиа-потоки могут идти и напрямую..”. Сервер чертовски умный? Он, понятное дело, видит, что трафик RTP тупо перенаправляется, но как этот сервер может “понимать”, что от одной точки до другой сеть прозрачна?
Почитай RFC 3261 и разруха в голове пройдет.
Коротко: в начале диалога в связке SIP Client 1 <-> SIP Server <-> SIP Client 2 оконечные устройства посылают RTP через сервер. Далее когда сервер понимает, что медиа-потоки могут идти и напрямую, снижая нагрузку на сервер он их коммутирует прямоходом. При этом направления Remote Part соединений - меняется. Ну и возникают все проблемы с NAT..
Причин с NAT - много: неправильная маршрутизация, наличие роутеров Dlink с гнилым SIP ALG, неправильные правила SNAT и DNAT, кривость реализации методов REINVITE в оконечном обопрудовании. Рекомендуется просто отключить этот режим и не париться.Zavr2008, с удовольствием прочту эту сказку в первоисточнике. Укажите, пожалуйста номер раздела RFC 3261, где это описано.
Теме Re:INVITE более подробно посвящен отдельный документ: http://tools.ietf.org/html/rfc6141
Смотрите раздел 3 там.
Там всё четко расписано. Если чего не понятно - могу перевести)
Еще на практике разбор сессии в Wireshark расписан тут: http://blog.aeriandi.com/2011/04/06/wireshark-and-rtp/
Почитай RFC 3261 и разруха в голове пройдет.
Коротко: в начале диалога в связке SIP Client 1 <-> SIP Server <-> SIP Client 2 оконечные устройства посылают RTP через сервер. Далее когда сервер понимает, что медиа-потоки могут идти и напрямую, снижая нагрузку на сервер он их коммутирует прямоходом. При этом направления Remote Part соединений - меняется. Ну и возникают все проблемы с NAT..
Причин с NAT - много: неправильная маршрутизация, наличие роутеров Dlink с гнилым SIP ALG, неправильные правила SNAT и DNAT, кривость реализации методов REINVITE в оконечном обопрудовании. Рекомендуется просто отключить этот режим и не париться.Zavr2008, с удовольствием прочту эту сказку в первоисточнике. Укажите, пожалуйста номер раздела RFC 3261, где это описано.
Теме Re:INVITE более подробно посвящен отдельный документ: http://tools.ietf.org/html/rfc6141
Смотрите раздел 3 там.
Там всё четко расписано. Если чего не понятно - могу перевести)
За ссылку спасибо. А где обещанная ссылка на RFC 3261?
Сама тема реинвайтов - довольно муторна. Поэтому если нет ограничения производительности сервера, рекомендуется не усложнять и выключить в настройках. Где в TDE для SIP телефонов и транков устанавливается отмена этого режима? Я думаю многим это будет полезно.
Сама тема реинвайтов - довольно муторна. Поэтому если нет ограничения производительности сервера, рекомендуется не усложнять и выключить в настройках. Где в TDE для SIP телефонов и транков устанавливается отмена этого режима? Я думаю многим это будет полезно.
Если это вопрос ко мне, то ликбез на открытых форумах не устраиваю уже давно.
Теме Re:INVITE более подробно посвящен отдельный документ: http://tools.ietf.org/html/rfc6141
Смотрите раздел 3 там.
Там всё четко расписано. Если чего не понятно - могу перевести)/
Спасибо, перевод не требуется. Предложения в rfc6141 совсем частный случай.
Известно ли Вам, что огромное количество устройств SIP, различных производителей, вообще не понимают re-invite и используют сообщение update. И чего тогда с Вашим re-invite делать и как NAT обходить?
Знаток Вы наш, комментариев для обсуждения (RFC).
Zavr2008, с удовольствием прочту эту сказку в первоисточнике. Укажите, пожалуйста номер раздела RFC 3261, где это описано. Да-да, чертовски согласен с Михаилом. Мне вообще интересно узнать, как это случается, что ”когда сервер понимает, что медиа-потоки могут идти и напрямую..”. Сервер чертовски умный? Он, понятное дело, видит, что трафик RTP тупо перенаправляется, но как этот сервер может “понимать”, что от одной точки до другой сеть прозрачна?
НачШтаба, как-то вот, наверное, ну не узнаем мы с Вами ответ на этот вопрос.
Zavr2008 знает много умных слов, но вот в каком порядке их писать он путается.
