Как отправить сообщение Diameter на IP-адрес, отличный от значения Destination-Host в mobicents

Во всех реализациях Diameter, которые я видел, сообщения, исходящие с сервера, всегда отправляются на разрешенный DNS IP-адрес того, что находится в AVP Destination-Host. Но на коммерческих серверах мы видим возможность настроить DRA или DEA, которые принимают все сообщения и маршрутизируют их.

Таким образом, когда дело доходит до стека диаметров мобицентов, этот подход иногда трудно реализовать. В любом случае я могу перенастроить файл hosts так, чтобы сообщение попало в DRA/DEA, но это больно. Я не вижу возможности отправить эти сообщения агенту центрального диаметра, который возьмет на себя всю грязную работу за меня.

Следующая проблема заключается в том, что если я планирую создать такой DRA/DEA, стек не будет принимать сообщения на другой хост. Где параметр Destination-Host сообщения может содержать имя хоста, отличное от нашего. (что было бы конечным пунктом назначения, куда ему нужно было бы отправиться)

Есть ли способ добиться этого, не вмешиваясь во внутренности кода jdiameter и кода RA?


diameter-protocol mobicents jain-slee
person Tharaka Devinda    schedule 04.01.2016    source источник
comment
Интерфейсы какого диаметра вы используете? Версии?   -  person delephin    schedule 04.01.2016
comment
Последняя версия jdiameter с github и Credit Control RA 2.8.0. Если он сможет это сделать, я запущу любую версию :)   -  person Tharaka Devinda    schedule 04.01.2016
comment
Кто создает CCR? У вас есть sbb, создающий их?   -  person delephin    schedule 04.01.2016
comment
Да. Я хочу направить свое сообщение на другой IP-адрес, когда я это сделаю; CreditControlClientSession.sendCreditControlRequest(CreditControlRequest r)   -  person Tharaka Devinda    schedule 05.01.2016
comment
У нас нет DRA, поэтому я немного не в себе, но, может быть, вы могли бы попробовать изменить конфигурацию jdiameter? Добавьте сетевое пространство и одноранговое устройство, чтобы идентифицировать ваш DRA, затем нужно изменить CCR и установить это пространство в качестве места назначения. Хост назначения не нужен.   -  person delephin    schedule 05.01.2016
comment
Ух ты. Это то, что нужно попробовать. Я попробую это и скажу вам. У нас тоже нет рабочего. Но есть приложения, где мне нужно отправить сообщение вот так.   -  person Tharaka Devinda    schedule 06.01.2016

Ответы (2)


arrow_upward
1
arrow_downward

Если вы измените конфигурацию jdiameter на что-то вроде этого:

<Network>
    <Peers>
      <Peer name="aaa://127.0.0.1:21812" attempt_connect="false" rating="1" />
      <Peer name="aaa://CUSTOM_HOST:4545" attempt_connect="false" rating="1" />
    </Peers>
    <Realms>
      <Realm name="custom.realm" peers="CUSTOM_HOST" local_action="LOCAL" dynamic="false" exp_time="1">
        <ApplicationID>
           ...
        </ApplicationID>
      </Realm>
     </Realms>
 </Network>

В вашем sbb вам нужно будет создать сеанс клиента, предоставляющий вашу пользовательскую область, используя этот метод:

DiameterCCAResourceAdaptor.CreditControlProviderImpl.createClientSession(DiameterIdentity destinationHost, DiameterIdentity destinationRealm)

Пример:

ccaRaSbb.createClientSession(null, "custom.realm")

где ccaRaSbb — экземпляр CreditControlProvider (интерфейс адаптера ресурсов)

наконец, при создании CCR метод CreditControlClientSession.createCreditControlRequest() будет использовать область сеанса для поиска ранее настроенного доступного однорангового узла.

Дайте мне знать, если это имеет смысл для вас

person delephin    schedule 07.01.2016
comment
Это невозможно для моей ситуации. Смотрите решение, которое я разместил. Вот как я решил проблему. В своем ответе вы предположили, что у меня есть прямая связь с пунктом назначения. Дело не в этом. - person Tharaka Devinda; 21.08.2020

arrow_upward
0
arrow_downward

Публикация метода, который я использовал для решения этой проблемы.

Как оказалось, невозможно из коробки отправить сообщение диаметра узлу, который не настроен в файле jdiameter-config.xml стека.

Для меня вариант с переделкой стека в данном случае тоже был неосуществим. Поэтому я разработал обходной путь для решения проблемы, сотрудничая с DRA, который у нас есть. (большинство DRA должны поддерживать этот метод)

  1. Я добавил в исходящий запрос два пользовательских AVP, а именно Ultimate-Destination-Host и Ultimate-Destination-Realm.
  2. В DRA я попросил администратора удалить мои Destination-Host и Destination-Realm AVP и заменить их теми, что были созданы на шаге 1.

Теперь всякий раз, когда я отправляю пакет, предназначенный другим одноранговым узлам диаметра за пределами сконфигурированного однорангового узла, я нацеливаю их на DRA и устанавливаю эти «конечные» AVP назначения.

У нас есть Oracle DSR, способный выполнять эти манипуляции с AVP. Большинство коммерческих должно быть в состоянии справиться с этим. Надеюсь, что кто-то, кто хотел получить ответ на этот вопрос, нашел это полезным.

person Tharaka Devinda    schedule 21.08.2020