17 Jul
2007
17 Jul
'07
5:04 a.m.
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(a)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.
18 Jul
18 Jul
4:01 a.m.
Bradley,
I've submitted
http://sourceforge.net/tracker/index.php?func=detail&aid=1660338&gr…
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(a)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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
20 Jul
20 Jul
1:03 p.m.
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&gr…
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(a)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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
26 Jul
26 Jul
12:22 a.m.
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.
11:51 a.m.
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.
1:05 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
1:32 p.m.
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6:04 p.m.
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 =~ "(a)gooddomain.com") {
t_relay();
...
Thus, adding routing based on maddr may cause security problems with
existing config files.
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.
regards
klaus
Bogdan-Andrei Iancu wrote:
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
6:28 p.m.
6:17 p.m.
6128
days inactive
6137
days old
9 comments
4 participants
participants (4)
-
Andreas Granig -
Bogdan-Andrei Iancu -
Klaus Darilion -
Watkins, Bradley