Что нужно для SIP RE-INVITE в отношении ICE?

Одним из примеров промежуточного блока, который может быть заинтересован в результате согласования ICE, является диспетчер пропускной способности.

Представьте себе корпоративное развертывание с конечными точками внутри корпоративного брандмауэра, а другие бродят по Интернету или за частными домашними брандмауэрами. Развертывание также включает общедоступный сервер TURN. Затем давайте представим конечную точку внутри корпоративного брандмауэра, выполняющую вызов. Если пункт назначения оказывается доступным в той же сети, вызов будет передаваться от хоста к хосту, а сервер TURN не будет использоваться (т. е. привязки будут отменены). Это локальная сеть, и нет необходимости накладывать ограничения на пропускную способность. С другой стороны, если вызов поступает в роуминговую конечную точку, то в дело вступает сервер TURN, и данные проходят через корпоративный брандмауэр, возможно, через восходящий канал с ограниченной пропускной способностью. Мы вполне можем представить себе некоторую политику, которая хотела бы ограничить пропускную способность вызова. Один из способов сделать это — чтобы диспетчер полосы пропускания оставался на пути передачи сигналов (используя маршруты записи SIP) и просматривал SDP любого проходящего INVITE, перезаписывая значения полосы пропускания в зависимости от медиа-адресов.

Я полагаю, что общее намерение состояло в том, чтобы устаревшее оборудование этого типа, не поддерживающее ICE, продолжало работать в смешанной среде, вводя конечные точки ICE. Чтобы сохранить эту обратную совместимость, ICE должен только вводить новую обработку (проверки STUN и т. д.), но с точки зрения элементов, не поддерживающих ICE, он не должен удалять какие-либо существующие правила (по-прежнему необходимы повторные INVITE для изменения пункт назначения медиапотока).

В учебнике Розенберга я полагаю, что повторное ПРИГЛАШЕНИЕ отправляется, потому что сокеты, выбранные ICE, отличаются от сокетов в линиях мультимедиа и соединения (m/c-линии) исходного SDP И для того, чтобы любые сетевые элементы, которые находятся между два пользовательских агента должны быть проинформированы о фактических сокетах, которые будут использоваться. RTP повторно INVITE отправляется с выбранным сокетом (-ами) ICE в медиа- и соединительных линиях SDP.

Если бы сокеты, выбранные ICE, были бы такими же, как сокеты в строках SDP m/c исходного запроса INVITE, тогда не было бы необходимости в повторном запросе INVITE. Или, если вы знаете, что нет «мидлбоксов», которые должны быть проинформированы об изменениях в сокетах RTP, тогда также не будет необходимости отправлять повторно INVITE.