newOptions event not firing | Request-URI does not point to us

[palmtown]

Please, do NOT open an issue if you have problems or questions regarding the use of JsSIP. Use the JsSIP Google Group instead:

https://groups.google.com/forum/#!forum/jssip

If you have found a bug in the software, or want to propose a new well documented feature or improvement, please delete this text and continue. :)

Hello Community,

I am receiving an SIP OPTIONS packet which is not directed to a specific user and JSsip responds with "SIP/2.0 404 Not Found." My goal was to listen for these options, and respond appropriately. However, I found that the newOptions event is not fired when the request is not directed back to correct URI.

It would be more customizable if this event fired regardless of if the Request-URI "point to us" or not.

[palmtown]

Hello Community,

It seems the file responsible for processing the request is https://github.com/versatica/JsSIP/blob/master/lib/UA.js at line 568.

Also, I was reading https://www.rfc-editor.org/rfc/rfc3261#section-11.2, and it did not state that the request URI is required to "point to us." I can see where it may not be wise to respond to all options request, however, giving a developer the option to make that decision seems reasonable.

What's your feedback on this? It would only take 20 minutes to implement a fix on my side, however, wanting to get your feedback.

[ibc]

This is very simple:

• JsSIP sends REGISTER to a server to become reachable.
• Reachable means that it can receive SIP messages/requests on the contact address JsSIP indicated during the registration process.
• So it doesn't make sense that it receives messages with a different target.

Please use the mailing list for further discussion.

[palmtown]

Hello @ibc

Thanks for your reply. I'd like to speak to that. In short, I don't disagree with your assessment, however, it doesn't account for all use cases. For example, servers can be configured to send OPTIONS packets for NAT and keep alive reasons. Some servers are hard coded not to include the contact address when sending these OPTIONS packet. Therefore, it would "make sense" to receive these messages and process them to properly respond to the server vs responding with a 404.

As mentioned, https://www.rfc-editor.org/rfc/rfc3261#section-11.2 does not specify that the request uri must match. Therefore, as it's not a requirement; it would give the developer more options in dealing with these use cases.

[ibc]

In that section of the RFC 3261:

The response to an OPTIONS is constructed using the standard rules for a SIP response as discussed in Section 8.2.6. The response code chosen MUST be the same that would have been chosen had the request been an INVITE.

It doesn't make sense for a registering UA to receive an INVITE with a RURI not pointing to it, so same for OPTIONS.

BTW as the issue template said, we use GitHub for reporting issues. Please use the mailing list for further discussion.

[palmtown]

Hello @ibc

Thanks for your response. Again, I don't disagree with you; I simply have a different use case. I also found another issue created here at https://github.com/versatica/JsSIP/issues/644 with the same use case.

Having stated that, I have implemented a solution in JsSIP to handle my use case accordingly which only took me about 20 minutes.

For anyone that needs a work around, you can see the steps below. Also, note that I don't believe this should be a long-term solution. I agree with @ibc that the server should include the correct uri when sending OPTIONS. However, when that's not the case, below I have listed the steps I took to resolve it. I did not submit this as a pull request as I believe this could be a feature request that allows the developer more control over how any SIP message is processed. For example, JsSIP allows the developer to inspect the packets and make changes to the packet if necessary. This is what SIP servers allow, and seems it may be a good fit for the client side.

1. Modify UA.js: if (request.ruri.user !== this._configuration.uri.user && request.ruri.user !== this._contact.uri.user && (method !== JsSIP_C.OPTIONS || !this._configuration.allow_mismatch_uri_options))

Note that && (method !== JsSIP_C.OPTIONS || !this._configuration.allow_mismatch_uri_options) was added.

2. Modify Config.js and add the below to the checker optional section:

allow_mismatch_uri_options(allow_mismatch_uri_options) {
      if (typeof allow_mismatch_uri_options === 'boolean') {
        return allow_mismatch_uri_options;
      }
    },

3. Add allow_mismatch_uri_options: true in your UA configuration.

4. Now events will be emitted for newOptions and you can decide to respond with 404, 200 etc. In my use case, I'm receiving keep alive request from my server and I inspect host information for security and respond with 200 OK if security checks pass.