[OpenSER-Users] Problem with handling 3xx responses and contact with maddr

[Watkins, Bradley]

> 
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 at pernau.at] 
> Sent: Thursday, July 26, 2007 9:04 AM
> To: Bogdan-Andrei Iancu
> Cc: Watkins, Bradley; users at 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 at 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