Mobicents Diameter Tips&Tricks cz.1

Poniżej kilka porad dotyczących używania Diameter-a dostarczonego przez Mobicents w usługach Diameter:

  • stos Mobicents jest oparty o jDiameter – stan RA jest synchronizowany z podprocesami zarządzanymi przez jDiameter, co może się kończyć różnie, generalnie RA tylko nasłuchują zmian stanów sesji w jDiameter, więc jeżeli coś jest nie tak z sesją, tam trzeba szukać przyczyn
    • np. jeżeli wysyłając wiadomość otrzymujemy ją z powrotem to znaczy że routing wiadomości na poziomie MUX jest źle skonfigurowany lub peer do którego chcemy wysłać wiadomość jest niedostępny
  • każdy host, który się łączy jako klient do serwera Diameter opartego o Mobicents musi mieć mapowanie adresu IP na nazwę – za pomocą DNS lub innych (np. /etc/hosts). W innym wypadku w logach będą się pokazywać dziwne wyjątki
  • konfiguracja peer-ów serwerowych oraz rutowania do nich odbywa się tylko i wyłącznie w pliku jdiameter-config.xml (część mobicents-diameter-mux)
    • w sekcji Network/Peers dodajemy peery do których chcemy się łączyć (są peerami serwerowymi)
    • w sekcji Network/Realms dodajemy gdzie rutować dane aplikacje – wpisujemy w Realm/@peers po przecinku wszystkie peery do których powinny odbierać komunikaty dla aplikacji Diameter danego typu (można też stworzyć dla każdego hosta w osobnej sekcji Realm), przy czym stos jDiameter używa tylko peer-name, nie używa portu.
    • wysyłając komunikat Diameter z naszych aplikacji musimy ustawić co najmniej Destination-Realm, opcjonalnie Destination-Host – stos jDiameter wybierze do wysłania tego komunikatu jeden z dostępnych peerów akceptujących daną aplikację
  • niestety jeżeli peer serwerowy rozłączy się w czasie działania serwera stos nie ponawia połączenia i trzeba przerestartować stos a dokładnie mobicents-diameter-mux
  • konfiguracja rutowania komunikatów do peer-ów klienckich odbywa się dynamicznie – w miarę jak klienci Diameter łączą się do serwera tablica rutingu stosu Diameter jest uaktualniana
  • Stos jDiameter a tym samym Mobicents nie przyjmie połączenia od dwóch klientów Diameter posiadających taką samą nazwę określoną przez Origin-Host, drugie połączenie będzie cicho ignorowane bez odrzucenia negocjacji peer-a – CEA nie jest wysyłany a połączenie jest zamykane po chwili na poziomie TCP
  • testując aplikacje Diameter za pomocą seagul warto wyłaczyć zabezpieczenie przed duplikatami – np. seagul przy kazdym restarcie serwera zaczyna numerować sesje Diameter od nowa:
    • <DuplicateProtection value=”false” />