sipservlet-spec
  1. sipservlet-spec
  2. SIPSERVLET_SPEC-39

Javadocs unclear for SipServletMessage.getRemoteAddr and getRemotePort

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0-pfd
    • Labels:
      None

      Description

      The "Returns" part of the Javadoc for getRemoteAddr, getRemotePort is confusing since it asserts that the result will be null for local messages which is in conflict with the description of the method immediately above. In the case of getRemoteAddr 15.7 of the spec states

      MUST return address of the remote SIP interface if the request was received from an external entity but if the request was internally routed (from one application to the next on the same container) then it MUST return the address of the container's SIP interface

      So the value null must NOT be used for an internally routed message.

      A similar problem exists for getRemotePort.

      The only scenario in which an incoming message should have a null value for the remoteAddr (or -1 for remotePort) is a container generated error response. In this case the message has not been "sent" and so it seems reasonable that information about the local and remote address/port and the transport would be null values (or -1 for the port). In fact this may be the only way for the application to distinguish a container generated response from those received from an app or externally. It would be helpful if the Javadoc page explicitly mentioned this scenario.

        Activity

        keith-lewis created issue -
        keith-lewis made changes -
        Field Original Value New Value
        Summary Javadocs unclear for SipServletMessage.getRemoteAddr and related methods Javadocs unclear for SipServletMessage.getRemoteAddr and getRemotePort
        keith-lewis made changes -
        Description The term "locally generated" is used in the Javadocs but not defined. See getLocalAddr, getLocalPort, getRemoteAddr, getRemotePort, getTransport, getInitialRemoteAddr, getInitialRemotePort, getInitialTransport. In the case of getRemoteAddr 15.7 of the spec states

        MUST return address of the remote SIP interface if the request was received from an external entity but if the request was internally routed (from one application to the next on the same container) then it MUST return the address of the container's SIP interface

        So the value null must NOT be used for an internally routed message, hence the term locally generated is NOT equivalent to locally routed.

        One interpretation which make sense is to take the term "locally generated" to apply to container generated responses passed to an application. In this case the message has not been "sent" and so it seems reasonable that information about the local and remote address/port and the transport would be null values (or -1 for the port). In fact this may be the only way for the application to distinguish a container generated response from those received from an app or externally.
        The "Returns" part of the Javadoc for getRemoteAddr, getRemotePort is confusing since it asserts that the result will be null for local messages which is in conflict with the description of the method immediately above. In the case of getRemoteAddr 15.7 of the spec states

        MUST return address of the remote SIP interface if the request was received from an external entity but if the request was internally routed (from one application to the next on the same container) then it MUST return the address of the container's SIP interface

        So the value null must NOT be used for an internally routed message.

        A similar problem exists for getRemotePort.

        The only scenario in which an incoming message should have a null value for the remoteAddr (or -1 for remotePort) is a container generated error response. In this case the message has not been "sent" and so it seems reasonable that information about the local and remote address/port and the transport would be null values (or -1 for the port). In fact this may be the only way for the application to distinguish a container generated response from those received from an app or externally. It would be helpful if the Javadoc page explicitly mentioned this scenario.
        binod made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        binod made changes -
        Fix Version/s 2.0-pfd [ 17068 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            keith-lewis
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: