I do not think that this is a bad configuration. If the WRONG_IP_ADDRESS is the IP address of a gateway this would be a simple approach to bypass the billing logic in the SIP proxy to achieve free calls.
The INVITE is perfectly valid. For example, if a sip:alice@atlanta calls sip:bob@biloxy the Atlanta SIP proxy sees a similar request. (although usually the To URI would be the same as the RURI).
You could: screen the RURI for bad IP addresses (manually or by using the permission module).
regards klaus
Andreas Sikkema wrote:
Klaus,
Maybe someone sent a SIP message with the local IP address in the R-URI to your proxy. According to your config this should not matter as you rewrite the domain for every incoming SIP request - except for loose-route.
The IP address in the Request-URI is one that for some reason (incorrect configuration?) is being sent by the SIP UA. This IP address is NOT the same machine as OpenSER...
The loose_route block could indeed be the culprit here. Is there a way I can see in an INVITE being sent to OpenSER that loose_route() will
return true?
This is the (sanitized) INVITE that is causing the problems:
INVITE sip:[NUMBER]@[WRONG_IP_ADDRES] SIP/2.0 Call-ID: 6181509477cc0df82db6313a276492d5@[SIP_DOMAIN] From: sip:[USERNAME]@[IPADDRESS_PROXY]:[PROXYPORT];tag=45fa8 To: "[NUMBER]" sip:[NUMBER]@[SIP_DOMAIN];tag=as52bb63c2 CSeq: 101 INVITE Via: SIP/2.0/UDP 10.1.2.71:5060;branch=z9hG4bK-45a33f186083645f5232ca79048af818 Contact: "[USERNAME]" sip:[USERNAME]@10.1.2.71:5060 Max-Forwards: 70 Route: sip:[IPADDRESS_PROXY]:[PROXYPORT];lr User-Agent: [USER_AGENT] Supported: timer Content-Type: application/sdp Content-Length: 151
(I've removed the body of the message; it's not very interesting here)
The problem is that the Request-URI contains [WRONG_IP_ADDRESS]. When this OpenSER receives an INVITE it should never forward the INVITE to an IP address a SIP UA has added to the Request-URI. OpenSER should be the one
to decide this.
So far we've never had any issues in this area, so I don't want to change too much in the config (like removing the whole loose_route() stuff) unless that is the only way I can solve this problem.
If the Request-URI would have been correct, [NUMBER] would have been rewritten to something usefull and the call would have succeeded.
For loose-route I would suggest to check for a to-tag too. Then, the called SIP UA should reject the call. You could also use dialog module to see if a dialog exists before forwarding in loose_route.
How would checking for a to_tag help? There is no existing Ddialog; this
is handling the initial INVITE message where it already goes wrong...