Hi Andreas, Hi Bradley,

Couple of days ago there were some fixes for maddr usage in VIA header ( affecting nat detection, reply routing, etc). There is some more work to do for maddr in R-URI, but I hope it will be soon.

Regards, Bogdan

Andreas Granig wrote:

Bradley,

I've submitted http://sourceforge.net/tracker/index.php?func=detail&aid=1660338&gro... some time ago, and the UA in question is also a Nortel CS2K, so it seems like this UA is using maddr in multiple places. Maybe the overall maddr-handling in OpenSER has to be reviewed (I'm not sure if your case complies with RFC 3261 and thus is valid though).

Cheers, Andreas

Watkins, Bradley wrote:

...

I'm using OpenSER to connect to a Nortel CS1000M, and I'm having some problems.

The way the Nortel works is that it has what they call a Network Routing Service (redirect server, really), that issues either a 302 (if a single SIP gateway exists on the CS1000) or a 300 (if multiple).

Here's a sample 300 from my system (IPs and domains changed to protect the guilty):

U 10.1.1.3:5060 -> 10.0.1.1:5060 SIP/2.0 300 Multiple Choices. Via: SIP/2.0/UDP 10.0.1.1;branch=z9hG4bKa66e.99fc1a25.1;received=10.0.1.1. Via: SIP/2.0/UDP 10.1.3.114;branch=z9hG4bK7d42804867A25509. From: "0004f2145263" sip:0004f2145263@dtw-openser01.sub.domain.com;tag=5F7CDD45-DDCE1F92. To: sip:12345@dtw-openser01.sub.domain.com;user=phone;tag=34887. Call-ID: 58dd5646-e86d140f-c2ead634@10.1.3.114. CSeq: 1 INVITE. Contact: sip:12345;phone-context=udp@domain.com:5060;maddr=10.1.1.1;transport=ud p;x-nt-redirect=redirect-server;x-nt-redirect=redirect-server. Contact: sip:12345;phone-context=udp@domain.com:5060;maddr=10.1.1.2;transport=tc p;x-nt-redirect=redirect-server;x-nt-redirect=redirect-server. Content-Length: 0.

The problem I have is that the Contacts have an maddr, and I need relay to it. However, I can't seem to be able to use transformations to get the maddr for relaying. Here are some log messages with comments inline:

Jul 16 19:50:49 dtw-openser01 /usr/local/sbin/openser[4306]: Branches are: sip:12345;phone-context=udp@domain.com:5060;maddr=10.1.1.1;transport=ud p;x-nt-redirect=redirect-server;q=0.01

This is just an xlog of $bR, but I'm not sure where the q= value is coming from (get_redirects?).

Jul 16 19:50:49 dtw-openser01 /usr/local/sbin/openser[4306]: ERROR: parse_uri: bad uri, state 0 parsed: <<sip> (4) / <sip:12345;phone-context=udp@domain.com:5060;maddr=10.1.1.1;transport=u dp;x-nt-redirect=redirect-server;q=0.01> (120) Jul 16 19:50:49 dtw-openser01 /usr/local/sbin/openser[4306]: tr_eval_uri: invalid uri [sip:12345;phone-context=udp@domain.com:5060;maddr=10.1.1.1;transport=u dp;x-nt-redirect=redirect-server;q=0.01]

These are what I get as a result of trying to xlog $(bR{uri.maddr})

Anyway, I would be greatly appreciative of any help someone might offer on the matter.

Regards,

• Brad

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. _______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Hi Brad,

There still an issue that need to be fixed in openser: if the RURI contains maddr, this should be used for sending the message to: sip:1234@domain.com;maddr=1.2.3.4 should be sent to 1.2.3.4 and not to domain.com

There is already a bug report on that and I hope it will be fixes soon.

Regards, Bogdan

Watkins, Bradley wrote:

Just as a follow-up to my own problem, I think I understand better what's happening (and have a band-aid/workaround).

It seems as though (and feel free to correct me if I'm wrong), OpenSER at present does not differentiate URIs when they are identical excepting for the addition of the maddr parameter. RFC 3261, in section 19.1.4 URI Comparison, states "A URI that includes an maddr parameter will not match a URI that contains no maddr parameter."

So:

sip:1234@domain.com != sip:1234@domain.com;maddr=1.2.3.4

This, in essence, is exactly what the Nortel system is doing.

The result seems to be that any attempt to push such a URI to $ru and then append_branch() fails.

My workaround is this: change the user part before the avp_pushto() call, then change it back in a branch_route after the append_branch().

It seems to be working so far, except that it seems to create two branches rather than one. That's quite possibly (probably...) my fault, as my script at the moment is pretty hacked up. I'll sound the alarm if I determine for sure that I'm not the culprit. ;)

• Brad

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.

Klaus,

RFC3261 defines maddr as "host" which can be "hostname / IPv4address / IPv6reference".

Regards, Bogdan

Klaus Darilion wrote:

May maddr be a domain?

Bogdan-Andrei Iancu wrote:

...

Hi Brad,

There still an issue that need to be fixed in openser: if the RURI contains maddr, this should be used for sending the message to: sip:1234@domain.com;maddr=1.2.3.4 should be sent to 1.2.3.4 and not to domain.com

There is already a bug report on that and I hope it will be fixes soon.

Regards, Bogdan

Watkins, Bradley wrote:

...

Just as a follow-up to my own problem, I think I understand better what's happening (and have a band-aid/workaround).

It seems as though (and feel free to correct me if I'm wrong), OpenSER at present does not differentiate URIs when they are identical excepting for the addition of the maddr parameter. RFC 3261, in section 19.1.4 URI Comparison, states "A URI that includes an maddr parameter will not match a URI that contains no maddr parameter."

So:

sip:1234@domain.com != sip:1234@domain.com;maddr=1.2.3.4

This, in essence, is exactly what the Nortel system is doing.

The result seems to be that any attempt to push such a URI to $ru and then append_branch() fails.

My workaround is this: change the user part before the avp_pushto() call, then change it back in a branch_route after the append_branch().

It seems to be working so far, except that it seems to create two branches rather than one. That's quite possibly (probably...) my fault, as my script at the moment is pretty hacked up. I'll sound the alarm if I determine for sure that I'm not the culprit. ;)

• Brad

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.

---

Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

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