Голосовые меню must die

Понял, почему меня так бесят голосовые меню при звонках в техподдержку, банки и т.п. Они тратят моё время! Зачем это делается? Тут два варианта.

1. Неудачный дизайн меню. Может быть, в теории меню должны помочь клиенту быстрее получить справку или найти нужную услугу, но на практике выходит наоборот. В качестве примера отвратительного дизайна можете послушать голосовое меню Стройпарка +7 (3822) 90‒00‒17. Хочешь спросить например о наличии товара или уточнить часы работы магазина, но сперва вынужден прослушать длинные и весьма неспешно произносимые анонсы и нудное перечисление пунктов меню.

2. Голосовое меню организуют для экономии времени сотрудников своего call center за счёт времени клиента. Это вообще-то свинство, но похоже на правду, потому что код соединения с живым сотрудником поддержки часто сообщают в последнюю очередь или прячут на последних уровнях многоуровневого меню.

Я совсем не против кратких сообщений типа "наберите внутренний номер сотрудника или дождитесь ответа оператора", или даже "все операторы заняты, пожалуйста подождите". Речь о явных злоупотреблениях, особенно о многоуровневых меню.

Или может я один такой, кто их не любит? Но если я звоню по телефону, я ведь явно рассчитываю на разговор с живым человеком, иначе я на сайт сходил бы.

Бага в IPSec transport mode?

Искренне надеюсь, что это всё же какое-то моё непонимание или незнание темы, а не конструктивный недостаток во FreeBSD: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744

В линухах оно как, кто знает или может проверить? Тоже DF флаг принудительно ставится на ESP? И как тогда работает простой IPSec transport mode между двумя хостами?

Между FreeBSD 11 и Windows 7 транспортный режим работал без проблем, ssh, FTP и прочее TCP ходило. Жаль что не осталось пакетных дампов. Предполагаю, что Windows знает, что надо в такой ситуации уменьшить MSS.

UPD Специально проверил, Windows Server 2012 также генерирует в транспортном режиме ESP пакеты с флагом DF. Но работе TCP это не мешает. Видимо неправильным будет предлагать решение для FreeBSD с принудительным снятием флага DF с ESP. Тем более в свете IPv6, в котором собственно этого флага и нет: если отправитель не позаботился фрагментировать пакет и вставить Fragment extension header, то на транзитном устройстве уже ничего с этим поделать нельзя.