Рероутинг звонка внутри 1016M при помощи 302 Redirect
Добавлено: 14 май 2013 04:07
Добрый день.
Возникла задача делать перенаправление звонка с потока на поток или в другой SIP-интерфейс при помощи внешнего Redirect-сервера.
Звонок приходит на SIP-сервер, он отвечает 302 с новым адресом с префиксом, который перемаршрутизируется SMG в нужную ТГ.
Идея заключалась в том, чтобы избавиться роста задержки голоса при пакетизации-депакетизации на SIP-интерфейсе, и не гонять RTP-трафик с SMG на SMG. Мы продолжаем разбираться с эхом через SMG и стараемся минимизировать источники эха.
Но насколько я увидел в статистике занятия MSP, он все равно создает RTP-каналы с SMG на SMG при таком редиректе, а значит, видимо и пакетизирует--депакетизирует RTP, на чем видимо теряет как минимум 20 мс.
Как сделать так, чтобы редиректнутые звонки PRI<->PRI оставались внутри SMG, а не выкидывались через его внешний интерфейс ip-интерфейс сам на себя? Или SMG даже при работе PRI<->PRI гоняет трафик через свой RTP-стек?
Возникла задача делать перенаправление звонка с потока на поток или в другой SIP-интерфейс при помощи внешнего Redirect-сервера.
Звонок приходит на SIP-сервер, он отвечает 302 с новым адресом с префиксом, который перемаршрутизируется SMG в нужную ТГ.
Идея заключалась в том, чтобы избавиться роста задержки голоса при пакетизации-депакетизации на SIP-интерфейсе, и не гонять RTP-трафик с SMG на SMG. Мы продолжаем разбираться с эхом через SMG и стараемся минимизировать источники эха.
Но насколько я увидел в статистике занятия MSP, он все равно создает RTP-каналы с SMG на SMG при таком редиректе, а значит, видимо и пакетизирует--депакетизирует RTP, на чем видимо теряет как минимум 20 мс.
Как сделать так, чтобы редиректнутые звонки PRI<->PRI оставались внутри SMG, а не выкидывались через его внешний интерфейс ip-интерфейс сам на себя? Или SMG даже при работе PRI<->PRI гоняет трафик через свой RTP-стек?