Jump to content

Incoming calls fail

Valadis Support

Recommended Posts



One ITSP sents OPTION requests before a INVITE to validate the state of the (called) UA.


OPTIONS sip:account@;transport=udp;line=abcd4321 SIP/2.0


What we see is that the SnomOne does not answer.

As result the platform assumes that the UA is not ready and no INVITE is sent.


We already found http://wiki.snomone.com/index.php?title=How_to_enable_options-requests_outside_of_dialogs

However following the instructions did not resolve the issue.


Secondly in RFC 3261 it is stated:


11. Querying for Capabilities

... All UAs MUST support the OPTIONS method.


From this I would conclude that the current default behavior is not RFC 3261 compliant!


However if the OPTION requests are not seen as part of a dialog (but they are starting their own?) it might be the ITSP is doing a wrong assumption:


11.1 Construction of OPTIONS Request


... ... However, only when an OPTIONS

is sent as part of an established dialog is it guaranteed that future

requests will be received by the server that generated the OPTIONS



See http://www.ietf.org/rfc/rfc3261.txt



1) Could there be an issue with following http://wiki.snomone.com/index.php?title=How_to_enable_options-requests_outside_of_dialogs ?

2) Is the default behavior compliant to the RFC or not?


Best regards,



Link to comment
Share on other sites

Well, the problem with answering OPTION is that all kinds of scanner use this method to identify their next target. Anyway, we have already a fix. If you want to help verify that the problem is fixed, let us know what OS you are running and we'll provide you with a new build (available for 4.5 and for 5.0).

Link to comment
Share on other sites

let us know what OS you are running and we'll provide you with a new build (available for 4.5 and for 5.0).



Thank you for your fast reply.

I am checking with our customer what/if it is necessary.

They already have a work-around as the ITSP stopped sending SIP OPTIONS.


But for my understanding, is answering SIP OPTIONS a requirement if you follow the RFC?


To do SIP hardening on CPE's in the past we have used the following requirement:

The CPE may not answer any SIP requests that are not coming from an IP outside the scope (of all) of the IP's resolved by DNS for the register and proxy server(s).

I.e. if register.example.com resolves to and and proxy.example.com resolves to and, only if a request comes from any one of these four IP's it may answer.

The only requirement on the ITSP side would be that the do not use other IP's. But some ITSP's do fail this requirement. So it is not a catch-all.


Best regards,


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...