Interface IncomingSipResponse

    • Method Detail

      • getProxy

        Proxy getProxy()
      • createPrack

        OutgoingSipRequest createPrack()
                                throws Rel100Exception
        Create a PRACK request to acknowledge a reliable provisional response, as defined by RFC 3262:
        • The response status code must be in the range 101-199.
        • The response must contain a Require: 100rel header.
        • The response must contain a valid RSeq header.
        This method creates an in-dialog PRACK request and populates the RAck header with the correct RSeq and CSeq sequence numbers from the response.
        Returns:
        an outgoing PRACK request object
        Throws:
        Rel100Exception - if this response is not a reliable provisional response.
      • isForked

        boolean isForked()
        Determines whether this response was the result of a downstream element forking the initial request.

        If a downstream SIP element forks a dialog-creating initial request, such as INVITE, multiple 1xx and 2xx responses may be received for the same request. The first 1xx or 2xx response to arrive sets the to-tag (remote tag) for the original SipSession. Additional 1xx or 2xx responses that arrive with different to-tags are forked responses.

        Each forked response creates a new SipSession activity representing the new dialog that was created by the fork.

        The first final response that arrives (forked or not) will automatically end all other SipSessions (early dialogs) created by earlier 1xx responses. Any stray 2xx responses that arrive on these early dialogs are automatically handled by the RA, which will send an ACK and a BYE to ensure these dialogs are terminated at the UAS.

        Forked response events are fired on the ACI of the original SipSession; this is because the service will already be attached to this ACI, and doesn't know about the forked sessions until responses arrive. The SipMessage.getSession() method on forked responses returns the SipSession that resulted from the fork, so services can retrieve and attach to these activities if necessary.

        Subsequent 1xx or 2xx responses may arrive on sessions that were created by an earlier forked response. These subsequent responses are not forked responses, and will be delivered on their respective SipSessions. Therefore a service that wants to see all responses on all forked sessions must attach to forked sessions when they are detected.

        Returns:
        true if this response is the result of a downstream element forking; otherwise false.
        Since:
        EasySIP RA Type 1.3