5 Replies Latest reply: Apr 6, 2011 2:21 AM by 853159 RSS

    Diameter base protocol: fails handling

    817396
      Hi,
      i have some issues with access to base diameter protocol from my diameter-node.
      How can i catch messages like DPR?
      How can i be notified about the connection loss?
      Is there any method to handle fails (on connection layer)?

      Please provide any info about these problems.

      Thanks,
      Katya
        • 1. Re: Diameter base protocol: fails handling
          user56628 - oracle
          Hi Katya,

          Isn't is possible to check whether a connection to a Peer is still active by calling boolean Peer.isClosed()? If it has been closed, you will then have to re-establish the connection before sending the DIAMETER requests. Potentially boolean Connection.isClosed() could also be an option. I think you should try these out together with you server side.

          For DPRs, and as far as I can see, theya should be possible to detect by overriding the rcvMessage(Message msg) of the com.bea.wcp.diameter.Application class.
          (http://download.oracle.com/docs/cd/E17645_01/doc.50/e18767/html/toc.htm)

          Please let me know if I missed something.

          Regards
          /Thomas
          • 2. Re: Diameter base protocol: fails handling
            817396
            Hi Thomas,
            thank you for your responce.
            However, I'm still wondering if there any mechanizm exist to iterate over session objects opened over failed peer connection. It would be logical, if peer object in the case of connection lost iterate through related sessions and calls some session's method. It would allow to notify upper applications about session fail and destroy session related resources.
            In the case of peer.isclose() use it should be call at every sendReq / rsvReq and connection fail detection should cause the process to iterate over opened sessions - it's less suitable then if such an iteration is done by peer object.

            As for DPR, it arrives with appId=0, indicating diameter common messaging, so even as we created application with id=0, and override the method, DPR was not captured here. It seems as it's processed by node object and isn't propagated to other objects.

            Thanks,
            Katya
            • 3. Re: Diameter base protocol: fails handling
              user56628 - oracle
              Hi Katya,

              As far as I can see, there is no built in functionality for iterating over sessions in the OCCAS DIAMETER API, so this will have to be handled in the plug-in logic.

              As for DPR, it seems like the message will arrive either to the Application or to the Session dependent on whether there is a Session-Id AVP available or not (http://download.oracle.com/docs/cd/E17645_01/doc.50/e17648/dia_diameter_base.htm#i1086737). I assume you have overridden the Application.rcvMessage(), or?
              Could you also try overriding Session.rcvMessage, to see if this is where the DPR will arrive?

              Regards
              /Thomas
              • 4. Re: Diameter base protocol: fails handling
                817396
                Hi Thomas,
                ok, I'll try to handle connection loss in the higher layer over OCCAS DIAMETER API.

                As for DPR, I overrode rcvRequest and rcvAnswer in Application class because as I can see the DPR message have no Session-Id AVP inside. (Docs: "If there is no Session-Id AVP present, or if the session cannot be located, the Diameter application's rcvMessage() method is called"). It seems overriding Session's methods is not required.

                Thanks,
                Katya
                • 5. Re: Diameter base protocol: fails handling
                  853159
                  Hi Katya,

                  The connection lost is a low-layer event, so it is not intended to be exposed to application layer.
                  There is a request timeout mechanism which will notify application/session layer for error sending. Application can utilize request.send(long timeout) API to specify a timeout value, or use request.send() API which uses global request-timeout configuration. When any error occurs (like connection lost, peer not available), a notification answer with detailed reason will notify application/session.

                  The DPR/DPA messages are designed to be handled internally by Diameter stack and not be dispatched to application/session layer. Application should have no way to receive DPR/DPA messages.

                  B.R/scott

                  Edited by: user8028232 on Apr 6, 2011 12:21 AM