#486 closed улучшение (fixed)
При изменении адреса назначения окончания RTP останавливать медиапоток
| Reported by: | san | Owned by: | alx |
|---|---|---|---|
| Priority: | средний | Milestone: | 1 очередь |
| Component: | any | Keywords: | |
| Cc: |
Description
- Соединил 2 окончания RTP друг на друга (253 на 255) передаю через этот поток данные тч канала.
- В окончании 253 изменил имя хоста на заведомо не существующее, окончание поменяло статус на Rem. host down.
- Я ожидал, что после изменения настроек, "старое" соединение будет разорвано и данные по нему не будут передаваться. Однако данные тч канала по прежнему проходят между 253 и 255 окончаниями.
Не уверен, что это баг, но в любом случае думаю, что для пользователя такое поведение будет не понятно, и гипотетически может кому-то навредить.
r2705
Attachments (1)
Change History (11)
comment:1 by , 20 hours ago
follow-up: 6 comment:2 by , 20 hours ago
Ну, например, Иванов разговаривает по очереди с Петровым и Сидоровым через канал ТЧ. Когда ему нужно соединиться с Петровым, он прописывает Ip Петрова в настройках RTP, нужно с Сидоровым - прописывает IP Сидорова. И это не я придумал такую гипотетическую схему, а видел в работе у пользователей. И, например, закончил он разговор с Петровым, прописал IP Сидорова, а у того Rem. host down и Иванов увидев ошибку в сердцах говорит: "Какой всё-таки нехороший человек этот Петров, что даже связь сломалась!", естественно он не ожидает что канал до Петрова всё ещё активен и Петров его слышит :-D
comment:3 by , 20 hours ago
| Summary: | При изменении настроек RTP, если Rem. host down, то данные передаются по старому соединению → При изменении адреса назначения окончания RTP останавливать медиапоток |
|---|---|
| Type: | баг → улучшение |
Изменил тип тикета на "улучшение" и скорректировал заголовок. Соотетствует ли измененный заголовок тому, что ты бы хотел, или может быть я неправильно понял твое желание?
comment:5 by , 19 hours ago
В таком случае, вроде бы реализовать такое улучшение будет несложно, и никаких потенциальных "граблей" от этого я вроде бы не вижу. Попробую сделать.
by , 19 hours ago
| Attachment: | photo_2026-08-06_13-59-37.jpg added |
|---|
comment:6 by , 19 hours ago
Replying to san:
Иванов разговаривает по очереди с Петровым и Сидоровым через канал ТЧ.
Твой пример, конечно же, взорвал мне мозг. :)
Сразу вспоминается вот этот мем:
А текстовыми сообщениями эта троица обменивается не иначе как с помощью nc... :) :) :)
follow-up: 9 comment:8 by , 19 hours ago
Подожди... Я закрыл тикет, и тут же подумал: а чем в этом контексте номер порта отличается от адреса? Может быть следует расширить твое предложение и на номер порта тоже?
comment:9 by , 18 hours ago
Replying to alx:
Подожди... Я закрыл тикет, и тут же подумал: а чем в этом контексте номер порта отличается от адреса? Может быть следует расширить твое предложение и на номер порта тоже?
Это звучит разумно, но, я предполагал, что если просто сменить порт и удалённый хост жив, то канал всё-равно будет пересоздан и описанной в тикете проблемы не будет...
comment:10 by , 18 hours ago
Да, все так. Я посмотрел в коде - порт обновляется независимо от того, известен ли MAC. Тогда все в порядке.


Replying to san:
И это не баг: не было задумано, что при изменении адреса существующий медиапоток будет немедленно остановлен.
Поясни, пожалуйста, каким образом.