The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
From: Klaus Darilion [mailto:klaus.mailinglists@pernau.at] Sent: Thursday, July 26, 2007 9:04 AM To: Bogdan-Andrei Iancu Cc: Watkins, Bradley; users@openser.org Subject: Re: [OpenSER-Users] Problem with handling 3xx responses and contact with maddr
Thus, checking the ruri does not make sense in case of maddr parameter is present.
e.g:
INVITE sip:user@gooddomain.com;maddr=baddomain.com
route{ if (uri =~ "@gooddomain.com") { t_relay(); ...
Thus, adding routing based on maddr may cause security problems with existing config files.
I agree that adding automatic maddr handling could cause security issues with current config files. Perhaps this could be an optional parameter, even if just for a release so that existing configs don't inadvertently end up as swiss cheese?
It also means there should be a way to override it by policy, so that you aren't relaying messages to an intermediate proxy by accident. In my case, for example, I need to be able to interoperate with hardware that uses maddr extensively. But I certainly don't want people sending me SIP messages with other maddr parameters and having my proxy just blindly ship it off.
The way things are currently, it's easy enough to determine the maddr and just not set $du if it's not an "approved" destination. But depending on the implementation, automatic maddr handling could lead to a problem if there is no way to directly influence what destinations are allowed.
btw: why is the maddr parameter needed at all? Sending to a different target as announced in the RURI could be done with a Route: header too.
If I read the RFC correctly, the use of maddr in the RURI is actually deprecated but supported. So you are correct that the Route: header is where it should be.
Regards, - Brad