Incoming calls fail

[Valadis Support]

Hi,

 

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

 

OPTIONS sip:account@192.0.2.123:5060;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

response.

 

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

 

So:

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,

 

Alcindo

[Vodia PBX]

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).

[Valadis Support]

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).

Hi,

 

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 192.0.2.1 and 192.0.2.1 and proxy.example.com resolves to 192.0.2.3 and 192.0.2.4, 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,

Alcindo

[Vodia PBX]

I think the problem should be solved in the latest versions. It is not always easy to stick with the RFC, especially if they are an invitation for denial of service. IMHO stability of the system has a higher priority than RFC compliance.