Valadis Support

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: 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

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

Thanks! I will provide feedback later if I know if and how it was solved. Best regards, Alcindo

I will check if using multiple extensions is acceptable. As I understand it the behavior would be for the same trunk. However it suggests an interesting solution, use multiple trunks: - one that the ITSP always hiddes the number - a second one that the ITSP always shows the main number - a third trunk that the ITSP allows the DDI number to be shown. Using the dial plan prefix could make this work. Thanks and best regards, Alcindo

Thanks! I was aware of the flexible headers. So I know it can be "fixed", although I did not try it yet. But that it would be fixed both in the sense that it would send out the wanted Caller ID and that this would require changing the headers any time you want to change it (back). But I understand that changing the resulting behavior of *67 is not possible at this moment. Best regards, Alcindo

Hi, One of our customers wants to be able to easily switch calls from an extension to external between the main trunk ANI, the phone DDI ANI and anonymous. For switching to activate/deactivate anonymous calls we can use *67/*68. Is there also some way to switch between the main/trunk ANI and the phones own DDI ANI for outgoing calls? Thanks, Alcindo

Hi, One of our customers has a SIP trunk to an ISP which does support anonymous calls. However they are not following the RFC's and require anonymous calls to carry the following Caller-ID (ANI): This would be the anonymous Caller-ID that i presume active after *67 is activated: Is there some way to change the RFC complaint anonymous Caller-ID by the one the the ITSP requires and be able to (de)activate it by *67/*68? Best regards, Alcindo